For your pleasure, here is the SEC DIR review that I got for the COSE document. I have responded to these comments, resisting some changes and making changes in other cases.
You can look at the current set of changes that I intend to publish tomorrow evening so that the IESG telechat can continue. The biggest change is the title of sections 5.1.1 and 12 have been updated to what I consider to be better ones as suggested by Stephen in a later message, but in response to a comment below. While comments before I publish the new the new version tomorrow, the fact that I have published should not be considered as a reason to object if you feel these are bad changes. Jim From: Stephen Kent [mailto:k...@bbn.com] Sent: Wednesday, September 21, 2016 7:27 AM To: secdir <sec...@ietf.org>; Jim Schaad <i...@augustcellars.com>; Justin Richer <jric...@mit.edu>; Kepeng Li <kepeng....@alibaba-inc.com>; Kathleen Moriarty <kathleen.moriarty.i...@gmail.com> Subject: secdir review of cose-msg-18 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
_______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
