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

-> It is intended that a profile of this document be created that

defines the interoperability