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 _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
