Last Call Review of draft-ietf-cose-msg-18
review-ietf-cose-msg-18-secdir-lc-kent-2016-09-22-00

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