Re: [secdir] secdir review of cose-msg-18

[Kathleen Moriarty <[e-mail]>]

Hi Steve,

Thank you very much for your detailed review, it's helpful.  I'll
respond on the normative/informative question, the chairs and/or Jim
should respond on your other questions as some (like removing text)
may not be done as I believe it was WG consensus to have the content
you mention in this draft.  The nits are helpful too, so Jim will add
those into the next revision.

On Wed, Sep 21, 2016 at 10:26 AM, Stephen Kent <[e-mail]> wrote:
> 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.

The reference is fine as informative IMO as it is clearly stated in
the draft in Section 1.3:

       "The CDDL grammar is informational, the prose description is normative."

This is common and we've seen many drafts using UML descriptions and
other formats similarly.

Thank you,
Kathleen

>
>
>
>
>
> 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



-- 

Best regards,
Kathleen