Subject: Re: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

From: Göran Selander <[email-masked]>
Date: Tue, 7 Jul 2020 16:33:54 +0000

Hi Rene,

Some of your comments belong to the requirements phase, but others may still be relevant to discuss. In particular, the ciphersuite recommendations are not carved in stone by EDHOC being adopted.

From: Lake <[email-masked]> on behalf of Rene Struik <[email-masked]>

-- some of the ciphersuite recommendations are somewhat odd. Having co-authors of this draft advocate EdDSA, while claiming this to be insecure (given easy fault attacks, esp, in IoT-setting?), in draft-mattsson-cfrg-det-sigs-with-noise-02 seems to be inconsistent.

[GS] The referenced draft speaks about ECDSA as well as EdDSA, and that completely randomized signature is not suitable for all IoT devices. It wasn’t clear to me what is inconsistent.

Why not simply use ECDSA (if one wishes ECDSA25519) and suggest a non-clamped version of ECDH (like all the co-factor ECDH schemes apart from RFC7748 do.? Why not supporting NIST curves, why enforcing both SHA512 and SHA256 at the same time, why pure-EdDSA (which requires two data passes), etc.?

[GS] EdDSA and X25519 are recommended for performance and security. As EDHOC is based on COSE, the specifics of curves of algorithms follow from RFC8152 and its successors. Any curve with a COSE code point can be supported. PureEdDSA is motivated here: https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-algs-08#section-2.2

[GS] Good point about the SHA algorithms. If I understand right there are two solutions to the problem, and the short term solution is to only use SHA512. I opened an issue:
https://github.com/lake-wg/edhoc/issues/2

Göran