[Lake] EDHOC Issues related to cryptographic algorithms and cipher suites

[John Mattsson <[e-mail]>]

 Hi,

Below is a list of issues we think should be discussed on the list, at IETF 109, and at an upcoming interim meeting. More issues will follow in a second mail later today.

Cheers,
John



1. Choice of hash algorithm in cipher suites. 

Hash functions are used in several places in EDHOC.
- Transcript Hash
- Key-Derivation Function (KDF)
- Signature algorithm
- Credential identifiers (ID_CRED_R and ID_CRED_I)
- Application, e.g. OSCORE KDF.

The signature algorithms Ed25519 mandates the use of SHA-512. This means that to implement the cipher suite

   0. ( 10, -16, 4, -8, 6, 10, -16 )
      (AES-CCM-16-64-128, SHA-256, X25519, EdDSA, Ed25519, AES-CCM-16-64-128, SHA-256)

the implementation has to support both SHA-256 and SHA-512.

A solution would be to specify only SHA-512 in cipher suites with Ed25519. We plan to do this change in the next version of the draft. Requires more memory to handle larger digests. Note that it also increases the length of x5t identifiers to 256 bit instead of 64.

Should the Ed25519 cipher suites specify only SHA-512?




2. Use of SHA-512 in constrained IoT.

SHA-512 is not supported on many IoT devices and the question is if it ever will. Currently SHA-256 have wide support and is often HW accelerated. Adding also SHA-512 requires more code storage. If SHA-256 gets replaces it would likely be with SHAKE128 or some future XOF emerging from the NIST lightweight standardization protect (e.g. Gimli).

Ed25519 is currently only specified with SHA-512. While there are benefits of having a single algorithm, CFRG should maybe have taken IoT more into consideration. Specifying Ed25519 with another hash algorithm is technically easy, but would mean even less implementations.

It has been suggested that draft-ietf-lwig-curve-representations-05 and W-25519 from Draft NIST SP 800-186 would solve this problem. As far as we know, they only helps with implementing X25519 and Ed25519 on devices which only has acceleration of Weierstrass curves. They do not affect the hash function in any way. We plan to add references to draft-ietf-lwig-curve-representations-05 and W-25519 with the text that they may help with HW acceleration.

Is the use of SHA-512 in Ed25519 a problem?



3. Mandatory cipher suite

EdDSA (and to a smaller degree X25519) does not have as many IoT implementations as ES256 and P-256. curve25519 offers much better performance in general, but the performance is likely similar to P-256 if X25519 has to be expressed in Weierstrass form (W-25519) to be able to use HW acceleration. Also many IoT devices have HW acceleration for SHA-256.

Question how much the MTI cipher suite matters, as most IoT implementation are expected to only support a single cipher suite.

Shall we change MTI to ECDSA?



4. Support of SHAKE and KMAC.

The COSE WG is working on adding SHAKE128 and SHAKE256 to COSE and there is ongoing work to define the use of KMAC128 the KMAC256 as KDFs.

https://tools.ietf.org/html/draft-ietf-cose-hash-algs
https://tools.ietf.org/html/draft-schaad-cose-more-algs

There has been interest in the IETF IoT community to use these algorithms. As currently specified, EDHOC supports SHAKE, but would run SHAKE in HMAC mode, which is inefficient. 

Should EDHOC should be updated to use a KMAC KDF together with SHAKE?



5. Rekeying of AEAD algorithms

The TLS WG have analyzed, discussed, and specified bounds for distinguishing and forgery attacks on various AEAD algorithms in TLS. The distinguishing attack lets an attacker destringing the ciphertext from a random string and the forgery attack lets an attacks forge a single message (typically consisting of a random looking string). CFRG is now planning to publish a document with formulas to calculate AEAD limits. The limits chosen by TLS are stricter that any earlier protocol or specification. This is fine if rekeying is easy.

It would be good if the IETF IoT community discussed which probability is acceptable for the IoT protocols in IETF. 

EDHOC does not use the same key more than once, but the exported session key might be used for a long period in e.g. OSCORE. The most efficient solution may be to rekey in the application security protocol. E.g. if OSCORE would frequently derive a new Sender/Recipient Key from the Master Key, this would effectively mitigate distinguishing attacks. See e.g. "key_derivation_rate" in SRTP (RFC 3711). This is not currently part of OSCORE but could quite easily be added in a backward compatible way.

What is the acceptable probability for IoT? How do we do this rekeying for OSCORE? Do we need to do anything in EDHOC at all?