[Lake] Mandatory to implement cipher suite (issue #22)

[John Mattsson <[e-mail]>]

Hi,

Mališa asked me to post a summary of this issue (including differences between the algorithms) to the list as there was an objection to the compromise text suggested by Stephen Farrell some meetings ago. 

"For many constrained IoT devices it is problematic to support more than one cipher suite.  Existing devices can be expected to support either ECDSA or EdDSA.  To enable as much interoperability as we can reasonably achieve, less constrained devices SHOULD implement both cipher suite 0 (AES-CCM-16-64-128, SHA-256, X25519, EdDSA, AES-CCM-16-64-128, SHA-256) and cipher suite 2 (AES-CCM-16-64-128, SHA-256, P-256, ES256, AES-CCM-16-64-128, SHA-256). Constrained endpoints SHOULD implement cipher suite 0 or cipher suite 2."

The main discussion regarding this issue has been the signature algorithm, where the two choices are ES256 (ECDSA with SHA-256) and EdDSA. The rest of the parameters affecting the signature are decided by the public key algorithm in the COSE_Key/X.509:

- ES256 would typically be used with secp256r1 (P-256)
- EdDSA would typically be used with Ed25519 which implies SHA-512

The cipher suites combine ES256 with P-256 and SHA-256 for key exchange/derivation and EdDSA with X25519 and SHA-512 for key exchange/derivation. When used in method 3, the signature algorithm is not used. There has not been that much discussion of non-signature cipher suite aspects.

- Performance: EdDSA + Ed25519 is significantly faster than ES256 + secp256r1 in most public benchmarks. Some recently published benchmarks show equal performance on some platforms. Unclear if this is because of more optimized secp256r1 code or if the benchmarks were done on platforms with acceleration of Weierstraß curves, were Ed25519 would have to be transformed to Weierstraß form and back again.

- Trust: Some years ago there was a discussion if secp256r1 could be trusted as it was invented by the NSA. Note that DSA and SHA-2 were also invented by the NSA. This discussion seems to have largely died. I don't see any reason to mistrust any of these algorithms, they have been publicly reviewed by a huge amount of people globally. EdDSA was invented by Schnorr/Bernstein and X25519 was invented by Bernstein, and they were standardized by CFRG.

- Security: Both algorithms should have similar security as long as they are implemented correctly. EdDSA is significantly more resistant against implementation mistakes and side-channel attacks. ECDSA is standardized with both deterministic and random nonces. EdDSA is only standardized with deterministic nonces, but as discussed in CFRG, any choice of nonce generation is compatible with all verifiers and implantation can therefore chose any nonce generation method. Comparing ECDSA with random nonce against EdDSA with deterministic nonce, ECDSA is significantly more resistant against side-channel attacks. If both use deterministic nonces, EdDSA is significantly better.

- Support: ECDSA is the clear winner here as it has been standardized for a long time. EdDSA is however well supported in cryptographic libraries. Some hardware only has acceleration of Weierstraß curves, but as shown in draft-ietf-lwig-curve-representations Ed25519 can be transformed to Weierstraß form and back allowing acceleration on such hardware.

- Features: Ed25519 can easily be used for threshold cryptography while secp256r1 cannot. This has been mentioned as an important feature by companies interested in using EDHOC.

I think both are good choices. My understanding is that industries would like to use ECDSA for older more constrained devices and EdDSA for newer less constrained devices. Note that in many IoT deployments, systems often consist of devices controlled by a single entity. The same company might use ECDSA for one kind of devices and EdDSA for another without them ever having to talk to each other.

There was also discussion about ECDSA with Wei25519. As it is a new algorithm, I don't personally see this as a candidate for MTI. The transforms in draft-ietf-lwig-curve-representations are very important to accelerate Ed25519 and X25519 but I don't see ECDSA with Wei25519 taking much market share from ECDSA with secp256r1 or EdDSA with Ed25519.

Note that this discussion has taken a huge amount of time both before LAKE (in ACE) and in LAKE. It is also completely independent of all the other issues. I was personally extremely happy with the current compromise text suggested by Stephen Farrell. I cannot see why anybody would like to spend time discussing this issue more. If needed, let's have a vote and get rid of the issue. If discussion is needed I would suggest we do that as late as possible when all other issues are done.

Cheers,
John