Subject: [Ace] EDHOC support

From: "Damm, Benjamin" <[email-masked]>
Date: Wed, 7 Nov 2018 22:56:35 +0000

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.

* 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.

* 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're looking forward to applying EDHOC/OSCORE to secure end-to-end CoAP
application traffic that is transiting multiple proxies.

Ben

---

From: Göran Selander <[email-masked]>
Date: Thu, 8 Nov 2018 07:12:17 +0000

Hello Ben,

Thanks for comments!

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

    Hello ace,

    	
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

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.

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. 

Thanks for your support!

Göran