[Ace] review of ace-cose-ecdhe

[Dan Harkins]

  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] Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing review comments

[Mike Jones]

The Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification 
has been updated to address comments received since its initial publication.  
Changes were:

  *   Tracked CBOR Web Token (CWT) Claims Registry updates.
  *   Addressed review comments by Michael Richardson and Jim Schaad.
  *   Added co-authors Ludwig Seitz, Göran Selander, Erik Wahlström, Samuel 
Erdtman, and Hannes Tschofenig.

Thanks for the feedback received to date!

The specification is available at:

  *   https://tools.ietf.org/html/draft-jones-ace-cwt-proof-of-possession-01

An HTML-formatted version is also available at:

  *   
http://self-issued.info/docs/draft-jones-ace-cwt-proof-of-possession-01.html

   -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1711 and as 
@selfissued.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace