Hello Ben, Thanks for comments!
On 2018-11-08, 05:56, "Ace on behalf of Damm, Benjamin" <[email protected] on behalf of [email protected]> 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 _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
