Last Call Review of draft-ietf-cose-msg-18
review-ietf-cose-msg-18-secdir-lc-kent-2016-09-22-00
| Request | Review of | draft-ietf-cose-msg |
|---|---|---|
| Requested rev. | no specific revision (document currently at 24) | |
| Type | Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2016-09-27 | |
| Requested | 2016-09-15 | |
| Draft last updated | 2016-09-22 | |
| Completed reviews |
Genart Last Call review of -18 by Meral Shirazipour
(diff)
Secdir Last Call review of -18 by Stephen Kent (diff) |
|
| Assignment | Reviewer | Stephen Kent |
| State | Completed | |
| Review | review-ietf-cose-msg-18-secdir-lc-kent-2016-09-22 | |
| Reviewed rev. | 18 (document currently at 24) | |
| Review result | Has Issues | |
| Review completed: | 2016-09-22 |
Review
review-ietf-cose-msg-18-secdir-lc-kent-2016-09-22
SECDIR
review of draft-ietf-cose-msg-18
I
have reviewed this document as part of the
security directorate's ongoing effort to review all IETF
documents being
processed by the IESG.
These
comments
were written with the intent of improving security
requirements and
considerations in IETF drafts.
Comments
not addressed in last call may be included in AD reviews
during the IESG
review.
Document
editors and WG chairs
should treat these comments just like any other last call
comments.
This
document defines formats
for signing and/or encryption of data encoded using CBOR
(RFC7049). The
signing/encryption approach adopted here is based on the
standards developed in
JOSE (RFCs 7515-18), since CBOR is based on JSON.
This is a
large document:
about 90 pages plus almost 30 pages of appendices (providing
useful examples).
Close
to half of the (non-appendix portion)
document is devoted to specifications for a set of algorithms
for encryption,
signatures, message authentication, and key distribution. Only
when the reader
reaches page 73 is it made clear that the algorithm
descriptions are not MTI;
they define a set from which application developers must (?)
choose when
creating a profile for COSE use in a specific application
context. Given the
long-standing IETF policy to trying to facilitate algorithm
agility,
I think it
preferable to
extract these descriptions and publish them as separate RFCs,
a practice often
employed in documenting many other security protocols
(including JOSE, from
which this work is based).
The
document begins with a
brief explanation of how COSE differs from JOSE, an excellent
preface to the
document. The cited design differences all seem very
appropriate for CBOR,
e.g., using binary encoding instead of base64url, shedding
some of the odd
constraints adopted in JOSE because of pre-existing work in
the area, and
updating the list of algorithms.
Since there
is no standard
grammar for CBOR, the author adopted the primitive types
defined in an I-D
(draft-ietf-
greevenbosch-appsawg-cbor-cddl)
to allow for a concise specification of COSE formats. I
recommend that this document
be held for publication until that I-D is approved. I also
note that the cited
I-D is Informational, but this document is Standards Track.
the cited I-D is
listed as informative, but the syntax it defines is used
extensively throughout
this document, thus I believe it really is normative.
Section 2
defines the
basic COSE data structure. The description seems clear and
logical, but the
list of message types is a bit puzzling (absent information
that is provided
later, in Sections 4 and 5). For example, there is a Single
Signer data Object,
and a Signed Data Object. If the latter accommodates multiple
signers, why not
make that part of the name? The same nomenclature confusion
arises for
encrypted objects directed to a single recipient vs. multiple
recipients.
Section 3
Describes the
header parameters. It provides generally good, detailed
descriptions of the
common header elements and explains why certain conventions
are adopted. It
clearly describes requirements imposed on senders and
recipients.
Section 4
describes the
objects used to convey one or more signatures for objects. The
description here
is a bit confusing when it discusses one vs. multiple
signatures. The format
that allows carriage of multiple signatures does not
necessarily imply that
there are multiple signers, e.g., the multiple signatures may
be present to
accommodate different algorithm capabilities for different
recipients. The
introduction to 4.2 says:
“The COSE_Sign1 signature structure is used
when only one signer
is going to be placed on a message.”
Perhaps it
would be
clearer to say that this structure is used when only one
signature
is to be
placed in
a message.
Overall
this section is
well written and provides useful details about how to compute
signatures and
counter signatures.
Section 5
describes the
COSE encryption objects. I disagree with one choice of
terminology adopted
here: “recipient algorithm classes” which is described in
5.1.1. This is really
a discussion of classes of key distribution/management
algorithms, focusing on
how each recipient of an encrypted message acquires the CEK
used to decrypt the
message. I’d prefer a less obscure name for this sub-section.
Otherwise this
section is well written and provide lots of useful details
about how to encrypt
and decrypt messages for two classes of encryption algorithms.
Section 6
describes the
MAC objects. Here too there are two types of structures,
depending on whether a
recipient implicitly knows what key to use to verify the MAC,
or whether an ID
for one or more MAC keys must be communicated. The text here
closely parallels that
of Section 5 and is very good.
Section 7
describes the COSE
key structure. It is designed to accommodate the data needed
by a wide range of
key distribution mechanisms and encryption techniques.
Section 8
defines two classes
of signature algorithms that can be used with COSE, specifies
an algorithm of
each type, and provides security guidance for each algorithm.
I think it would
be preferable to remove the detailed algorithm descriptions
(Sections 8.1 and
8.2) and associated security considerations (which are well
written) from this
document. The comments below apply to sections 9, 10, 11 and
12.
I have
several concerns
about including the algorithm (vs. algorithm class)
descriptions here. For many
security protocols (and security-focused data formats), we
usually (though not
always) specify mandatory and optional to implement algorithms
in separate
documents, to facilitate algorithm agility. I think we should
follow that model
for COSE. Also, the text here does not mandate support for
these algorithms; it
merely provides details for a set of algorithms that a sender
and/or receive
may choose to implement. One has to read the final sentence of
the opening
paragraph of Section 15 to learn that this is the intent,
i.e., that selection
of specific algorithms is deferred to the each application
that makes use of
COSE. Given that later statement, it appears that the
algorithms specified in
Sections 8-12 ate intended to define the set from which
application developer
MUST choose, but that too is not clearly stated. I think this
makes it even
more appropriate to remove the detailed algorithm discussions
from this
document.
Section 12
describes the
“recipient algorithm classes” aka key distribution/management
methods. Most of
this section is analogous to the preceding sections (9-11)
where specific
algorithms are described for use with COSE, and thus my
comments about undue
bundling of algorithms with a protocol specs apply here too. I
do not object to
describing key transport, key wrapping and key agreement
methods in general,
but the detailed specs in 12.2.1, 12.4.1 and 12.5.1 seem
inappropriate here,
for the reasons noted above.
Section 13
describes
parameters for key objects used by COSE. The specs here are
sufficiently
generic that they do not suffer from the problems I noted for
Sections 8-12.
Section 15
provides
guidance for application developers making use of COSE. This
is where a reader
finally discovers that
the
algorithms
described in Sections 8-12 are not MTI, and that each
application is expected
to specify which algorithms are MTI in that context, to
facilitate
interoperability.
Section 16
(IANA Considerations)
describes the registries that need to be created for COSE, and
extensions to
the CoAP registry to support COSE. It seem to be well written
and
comprehensive.
Section 18
(Security
Considerations) is a good adjunct to the already well-written
security
considerations discussions provided for the algorithms in
Sections 8-12.
Typos and suggested rewording.
Section 2:
The COSE
object structure
is designed so that there can be a large amount of common code
when parsing and
processing the different
security
messages.
-> The COSE object
structure is designed so
that there can be a large amount of common code when parsing
and processing the
different
types of
security
messages.
COSE
messages are also
built using the concept of using layers to …
-> COSE
messages are
built using the concept of layers to …
Section 3:
The integer
and string
values for labels has been divided …
-> The integer and
string values for labels
have
been divided …
Applications
SHOULD
perform the same checks that the same label …
->
Applications SHOULD
verify
that the same label …
Applications
should have a
statement if the label can be omitted.
->
Applications
SHOULD
(?) have a
statement if the label can be
omitted.
Integers
are from the
"CoAP Content-Formats" IANA registry table. (
no
reference
)
As the IV
is authenticated
by the encryption process, it can be placed in the unprotected
header bucket.
(in general, an
encryption process will not “authenticate” an
IV, but use of a modified IV will yield mangled plaintext,
which can be
detected by an integrity check or a signature. the same
comment applies to the
similar statement in the “partial IV” description.)
Section 4:
Edwards
Digital Signature Algorithm
(EdDSA) signature algorithm and with the Elliptic Curve
Digital Signature
Algorithm (ECDSA) signature algorithm.
->
Edwards Digital
Signature Algorithm (EdDSA)
(cite)
and with the
Elliptic Curve Digital Signature Algorithm (ECDSA)
(cite)
.
One of the
features
supplied in the COSE document is the ability…
-> One
of the features
offered by the COSE
format
is the ability …
This
algorithm takes in
the body information …
->
The signing and verification processes
take in the
body information …
Counter
signatures provide
a method of having a different signature occur on some piece
of content.
->
Counter signatures
provide a method of
associating
different signatures
generated by different signers with
some piece of
content.
Section 5
Other:
The key is randomly
generated.
->
Other:
The key is
randomly or
pseudo-randomly
generated.
Section 6
(This
knowledge of sender
assumes that there are only two parties involved and you did
not send the
message yourself.)
-> (This
knowledge of
sender assumes that there are only two parties involved and
you did not send
the message
to
yourself.)
Section 15:
It is
intended that a
profile of this document be created that
defines the
interopability
->
I
t is intended that a profile
of this document be
created that
defines the
interoperability