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:ace-boun...@ietf.org] On Behalf Of Dan Harkins > Sent: den 1 juli 2017 00:17 > To: draft-selander-ace-cose-ecdhe....@ietf.org > Cc: ace@ietf.org > 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 > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
