Subject: [Ace] review of ace-cose-ecdhe

From: Dan Harkins <[email-masked]>
Date: Fri, 30 Jun 2017 15:17:19 -0700

Hello,

   I reviewed the latest version of this draft from
https://ericssonresearch.githum.io/EDHOC. I hope it's not too late
to get these in before the cut-off, if too late then please consider
them as comments on -07. My comments are as follows:

  -- Technical

   o Consider the ability to use a deterministic AEAD

     The definition of Enc() in section 2 makes it look deterministic
     but the mandatory algorithm (CCM) is not. I know that cose doesn't
     define how to use SIV (RFC 5297) but perhaps this draft should.
     I hope you don't consider this as a mere request for a vanity cipher.
     SIV does not need additional randomness, counters, or tweaks. It
     is, in that sense, misuse resistant and ideal for use in a key
     management protocol like EDHOC because it removes the possibility
     of a security critical error being accidentally performed.

     If you choose to accept this comment you'll need to not just add
     SIV to your IANA Considerations, you'll need to make reference in
     section 3.2 the fact that an IV is not needed for deterministic
     AEAD algorithms.

     A related comment, in section 3 it says "The application data may
     e.g. be protected using the negotiated AEAD algorithm". The "e.g"
     is superfluous but what if one desires to not do that, how is the
     cipher for the application data negotiated with EDHOC?

   o Use compact representation per RFC 6090

     The draft says, in section 3.1, that for EC2 curves to use point
     compression. There is contention regarding IP on point compression.
     (draft-ietf-cose-msg says in 13.1.1, this "encoding has not been
     recommended in the IETF due to potential IPR issues.")Better to
     specify the use of "compact representation" and "compact output" per
     RFC 6090. Since this draft is just doing ECDH there is no need for
     any indication of which y-coordinate should be used, it doesn't
     matter if it's y or -y. And it saves a whole byte! :-)

   o Validate received points when doing EC2 curves

     When using EC2 curves, the ephemeral keys in the first two messages
     need to be validated as points on the curve. If you use "compact
     representation" per RFC 6090 then it's a matter of checking whether
     there is a solution to the curve definition for the given x. If you
     choose not to use "compact representation" per RFC 6090 then you'll
     need to make sure that received points (once uncompressed) are valid
     points on the curve.

     This needs reference among the other verification checks in 4.2.3 and
     4.3.3 (for asymmetric EDHOC), and 5.2.3 and 5.3.3 (for symmetric EDHOC)
     which result in an error message if they fail.

  -- Editorial

   o Section 2, seconded bulleted paragraph, it is "full-fledged" with a 
"d".

   o In 4.3.3 last paragraph, Party U should send the error message back,
     right? Not Party V.

   This is a very well-written draft and I am happy to see SIGMA being
applied to every layer of the stack.

   regards,

   Dan.