Hi all, Some comments on draft-ietf-tls-mlkem-04- almost all are just for clarity- I think the draft is in great shape!
Abstract The phrasing of the abstract could be a bit clearer. The basis for the changes I'm suggesting: - key agreement -> key establishment (though this is not a hill I will die on) - post-quantum -> quantum-resistant (quantum-resistant might be clearer without a reference as the meaning is explicit in the name) - cut "standalone" (if someone reads this document in the future, the meaning could be unclear without the context of "standalone vs. hybrid") - explicit reference to the IANA registry Perhaps something like this: This document specifies the use of ML-KEM for quantum-resistant key establishment in TLS 1.3 and registers values from IANA in the TLS Supported Groups registry for ML-KEM-512, ML-KEM-768, and ML-KEM-1024. 1.1 Motivation And again, similar justification for changes in the 1.1 Motivation section, plus the below: - strike "new" - S in FIPS = standard :-) - E in KEM = encapsulation - some of this context is likely not necessary/enlightening for the reader (e.g. re-stating FIPS in addition to the reference, specifying ML-KEM use "versus" hybrid) Perhaps: ML-KEM [FIPS203] is a quantum-resistant key encapsulation mechanism (KEM) that can be used to perform key establishment. This document specifies the use of ML-KEM to perform quantum-resistant key establishment in TLS 1.3. It also registers values from IANA in the TLS Supported Groups registry for the three parameters of ML-KEM: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. >From Section 3: "This document models key agreement as key encapsulation mechanisms (KEMs), which consist of three algorithms:" Is it helpful to use this verbiage, or does it suffice to say something more simplistic like: "Key encapsulation mechanisms (KEMs) consist of three algorithms:" "...conform to this API" Can API be expanded here or can different phrasing be used? >From Section 4: "We define the KEMs as NamedGroups, sent in the supported_groups extension." -remove "we" - rephrase so this can say NamedGroup instead of NamedGroup (even though the text is referring to multiple 'NamedGroup's it could be confusing since 'NamedGroups' is undefined by RFC 8446 - include reference to relevant section of RFC 8446 (4.2.7 supported groups, 4.2.8 key share) - note that NamedGroup is also send in the key_share extension so it could be better to either mention both or neither (no preference for which) Could instead say something like: This document specifies a NamedGroup value for each parameter of ML-KEM. NamedGroup values are used in the supported_groups (Section 4.2.7 of [RFC8446]) and key_share (Section 4.2.8 of [RFC8446]) extensions and are used by TLS clients and servers to indicate which key establishment methods are supported. Section 4.1: "Each method is its own solely post-quantum key agreement method, which are assigned their own identifiers, registered by IANA in the TLS Supported Groups registry:" -> "Each parameter of ML-KEM is assigned an identifier, registered by IANA in the TLS Supported Groups registry:" Section 4.2: Consider adding an "each" in the first sentence: "...ciphertext values are each directly encoded..." so it is clear that the encapsulation key and ciphertext are encoded separately. Also note that in Section 3, pk is referred to as "public encapsulation key" so it might be best to call it that again here in this section for consistency. Maybe also consider adding (pk) and (ct) following each term in this sentence, so the reader can more easily map this back to Section 3. I also might consider removing this sentence: "The client's shares are listed in descending order of client preference; the server selects one algorithm and sends its corresponding share." I think it is repeated from RFC8446 if I am remembering correctly, and I don't see a specific reason it is useful to include here. If the point is to illustrate that there may be other algorithms besides ML-KEM-x listed here, you could say something like the following: Note that KeyShareClientHello includes a list of KeyShareEntry structs that represent the key exchange algorithms the client supports. For each parameter of ML-KEM the client supports, the corresponding KeyShareEntry consists of a NamedGroup that indicates the appropriate parameter, and a key_exchange value that is the pk output of the KeyGen algorithm. "If ML-KEM decapsulation fails for any other reason, the connection MUST be aborted with an internal_error alert." Could there be an instance where another error alert may be more appropriate (such as decrypt_error), or where it could be justified to not send an error at all and silently fail? Section 4.3 "results in the same shared secret shared_secret" "the same" as what? Does this mean to say that it is the same as specified by RFC8446? It would be good to say "as x" Section 5.1 Rewrote this section for readability and conciseness. (I think there is probably a better way to say "without compromising the security of the keys" in the penultimate sentence of the last paragraph): ML-KEM satisfies the indistinguishability under adaptive chosen ciphertext (IND-CCA2) security property. IND-CCA2 corresponds to security against an active attacker, in which, even if an attacker has the ability to decapsulate arbitrary ciphertexts, shared secret values will appear indistinguishable from random strings. TLS 1.3 does not prohibit key re-use; some implementations may use the same ephemeral public key for more than one key establishment at the cost of limited forward secrecy.[include reference to section in RFC8446 that states this?] Care must be taken to ensure that keys are only re-used if the algorithms from which they are derived are designed to be secure under key-reuse. ML-KEM's IND-CCA2 security satisfies this requirement such that the public key/secret key pair can be used long-term or re-used without compromising the security of the keys. However, it is stillrecommended that implementations avoid re-use of any keys (including ML-KEM keys) to ensure perfect forward secrecy. Implementations MUST NOT reuse randomness in the generation of ML-KEM ciphertexts. Section 5.2 Can this section provide a definition and reference for binding? Also, can it define "commits" as this might not be understood by readers who are not cryptographers? Thanks! Rebecca Rebecca Guthrie she/her Center for Cybersecurity Standards (CCSS) Cybersecurity Collaboration Center (CCC) National Security Agency (NSA)
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
