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

From: Francesca Palombini <[email-masked]>
Date: Thu, 6 Jul 2017 12:35:09 +0000

Hi Dan,

Thank you so much for a very useful review and for your support!
Most of your comments have been incorporated in v-07. We'll come back for a discussion on the rest.

Thanks,
Francesca

> -----Original Message-----
> From: Ace [mailto:[email-masked]] On Behalf Of Dan Harkins
> Sent: den 1 juli 2017 00:17
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Ace] review of ace-cose-ecdhe
> 
> 
>    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.
> 
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace