Re: [Ace] EDHOC support

[Göran Selander <[e-mail]>]

Hello Ben,

Thanks for comments!

On 2018-11-08, 05:56, "Ace on behalf of Damm, Benjamin" <[e-mail] on behalf of [e-mail]> wrote:

    Hello ace,
    
    We've done an internal review of EDHOC and support its movement towards
    RFC.  A few questions:
    
    * It isn't clear (to us) how EDHOC's message 2 achieves proof of
      possession prior to use. NIST SP-800-56A seems fairly clear that proof
      of possession is required before confirmation of a derived key, but
      message 2 seems to force U to derive and use a key before PoP can be
      done.  A pointer to why this is considered safe would be appreciated.
    	
I'm not sure I understand the concern. Having received message 2, the U can verify the signature by V (over e.g. the ephemeral key of U) and thus prove that the communicating party possesses the private key. Is it the derivation of the encryption key needed to decrypt the signature that is your concern? Note that this is by construction of the Sigma-I protocol, see page 19 of
http://webee.technion.ac.il/~hugo/sigma-pdf.pdf

    * The requirement to support curve x25519 is an odd one for us because
      our device fleet is using P-256. This is not a request to require
      P-256, but rather, that a required curve is not needed. Instead of a
      MUST I'd like to see this be a SHOULD.

By some Best Common Practice (RFC7696 I think) we have to specify at least one algorithm that a mandatory to implement. Curve25519 is superior terms of security and performance so that seemed a natural choice  since we have to pick one curve. If others have the same problem we could of course have a discussion around this.

    
    * Given the spectre of PQC we think providing for some flexibility in
      algorithms a must. We use P-256 today but might use P-384 or other
      higher-order curves tomorrow. Transition periods mandate algorithm
      flexibility.


We definitely want to keep the algorithm negotiation in the protocol. The change which is proposed is to move from negotiating individual protocols to negotiate cipher suites, which reduces overhead further, and makes the protocol even simpler. 
    
    We're looking forward to applying EDHOC/OSCORE to secure end-to-end CoAP
    application traffic that is transiting multiple proxies.

Thanks for your support!

Göran