[Lake] [LAKE] Review on draft-ietf-lake-authkem-edhoc-00

[Wang Guilin <[e-mail]>]

Hi, authors,

Just completed a review on the specification.

The main issue I do not understand is the first point of Main comments given below. Namely, when using ML-KEM for ephemeral key exchange in EDHOC, no size limit to messages 1 and 2?

Cheers,

Guilin

==============================
KEM-based Authentication for EDHOC
draft-ietf-lake-authkem-edhoc-00
https://www.ietf.org/archive/id/draft-ietf-lake-authkem-edhoc-00.html
-----------------------------------------------
Reviewer: Guilin Wang
---------------------------------------------
Main comments:

- The most important question: As I understand, the size of messages 1 and 2 in EDHOC is very limited (e.g., no more than 51 or 58 bytes). This specification defines how to use ML-KEM for both ephemeral key exchange and also KEM-based authentication. So pk_eph (the ephemeral KEM public key) and ct_eph (the ephemeral ciphertext) are sent in message 1 and message 2 respectively. However, even for ML-KEM-512, their sizes are 800 bytes and 768 bytes respectively. This seemingly violates the size limit of messages 1 and 2. Did I miss something here?

- Maybe a brief explanation why KEM-based authentication is possible in Section 1 or 1.1. This can be very helpful for the readers who are not familiar to this concept.

- Highlight that both I and R have static long-term KEM public already (in 2.1?)

-ML-KEM-1024 is for security level 5, but the draft states "the ML-KEM algorithm is used at NIST security levels 1 and 3, is proposed in Table 3" in 5.2. But in Table 3, value 8 for a suite with ML-KEM-1024 with security level 5.

- Why is ML-KEM-768 not considered in this specification?  Better to explain the rationale.
- Yes, understand any PQ KEM can be used by following this specification. But any particular requirement for the PQ KEM used here? Say any requirement on public key size and/or ciphertext size.

- If the following "MUST" is really necessary? 2.1.3.1: "The same KEM algorithm selected for the EDHOC key exchange in the cipher suite MUST be used for both the ephemeral KEM key exchange and the authentication static KEM keys. "

---------------------------------------------
Minor comments:

Section 1. "The purpose of this document is to address the quantum-resistant transition of the Ephemeral Diffie-Hellman Over COSE (EDHOC) protocol by defining a new authentication method in which both parties use Key Encapsulation Mechanism (KEM)-based authentication together with Post-Quantum Cryptography (PQC) cipher suites supporting PQC KEM algorithms such as the NIST-standardized ML-KEM-512.." This sentence is long and a little confusing to me, as it seeming does not tell the relation between (PQ) KEM and cipher suites. How about to reword it as something like the following?

"The purpose of this document is to address the quantum-resistant transition of the Ephemeral Diffie-Hellman Over COSE (EDHOC) protocol by defining a new authentication method in which both parties use Key Encapsulation Mechanism (KEM)-based authentication.  In particular, this specification registers the NIST-standardized ML-KEM, together with cipher suites, to support PQ KEM-based authentication in EDHOC."

To update references
[I-D.ietf-pquip-pqc-engineers]=> [RFC 9958].
[I-D.ietf-lamps-kyber-certificates] =>  [RFC 9935]

"Elliptic-Curve Cryptography(ECC)" => "Elliptic-Curve Cryptography (ECC)"

"the KEM-based authentication Method defined" => "the KEM-based authentication method defined"

"[RFC9053], When "=> "[RFC9053]. When"

"Instead, the party must first receive a ciphertext that encapsulates its static public key, "=>  "Instead, the party must first receive a ciphertext that encapsulates by using its static public key,"?

"cipher suit" => "cipher suite"

"ct_R is the responder ciphertext computed by the Initiator" => "ct_R is the ciphertext for Responder computed by the Initiator"?

"c_I is the Iniatiator ciphertext" => "c_I is the ciphertext for Initiator"

"retrieved from the received ID_CRED_I in message_1."=>  "retrieved from the received ID_CRED_I in message_3.

Fig. 1: No MAC-1, just MAC-2 and MAC-3? How about to replace them by MAC-1 and MAC-2?

2.1.2. What will happen if method 5 proposed by I in message 1 is not accepted by R? Namely, I would like to use KEM-based authentication, but R does not.

2.1.3 "The protocol transports information about credentials ID_CRED_I and ID_CRED_R in message_2 and message_3, respectively. " => "The protocol transports information about credentials ID_CRED_R and ID_CRED_I in message_2 and message_3, respectively. "

3.1.1.1: Better to explain the meaning of "TH2" in "The salt SHALL be TH_2". I thought it is just string TH_2, before reading the first paragraph of 3.1.2.

6.1. Security Properties

"The Responder must first receive the encapsulation of its static public key generated by the Initiator to authenticate itself. "  This description seems inaccurate or even wrong. I guess you are here talking about message 3. But in this case, ct_R is the encapsulation of a challenging secret ss_R generated by the Initiator, rather than  "the encapsulation of its static public key generated by the Initiator".

"Then it cannot generate MAC_2 or authenticate itself until then. " A little bit complex, with double "then" as well. How about to say "Until then, it cannot generate MAC_2 or authenticate itself. "

"ensuring key confirmation to the other party" => "ensuring key confirmation to the other party."

"forward secrecy" is mentioned twice in 6.1, but no explanation about what this means.