I have reviewed draft-ietf-tls-mlkem-01. Comments below. OVERALL First, as I noted previously, there is quite a bit of material that seems to apply both to pure MLKEM and to MLKEM-ECDHE hybrids. This includes:
- How to actually compute the MLKEM shared secret - Section 5 (though I would actually just strike this section). - Much of Section 6 (Security Considerations) Now that we have accepted both drafts, I would suggest that we merge them and then we can merge this material as well, leaving things much cleaner. I think some of these comments also duplicate comments Scott Fluhrer and Filippo Vasorda made. DETAILED COMMENTS S 1.1. FIPS 203 standard (ML-KEM) is a new FIPS standard for post-quantum key agreement via lattice-based key establishment mechanism (KEM). The "S" in FIPS is for "standard" 1.3 is necessary for migrating beyond hybrids and for users that need to be fully post-quantum. I'm not sure "fully" is the right word. It's not like the hybrids are not secure in a post-CRQC environment (at least under the assumption MLKEM is secure). Perhaps "purely". S 4.2. The encapsulation key and ciphertext values are directly encoded with fixed lengths as in [FIPS203]; the representation and length of elements MUST be fixed once the algorithm is fixed. I don't understand what this text is doing. The representation *is* fixed by this specification for all the algorithms in this specification. Is this levy from some sort of generic draft that got imported into one about MLKEM? S 5.1. I'm not sure this text is needed. It's generically true that things need to fit inside TLS's PDUs, but the algorithms defined here fit just fine, so why say anything? S 5.2. This was discussed on-list previously. The chance of failure here is ludicrously low, and there are plenty of other low probability failure cases, such as undetected bit errors in the key shares; these would also cause the sides to derive different shared secrets. Why can't we just handle this in the same way as that, by failing the connection? S 6.1. This also seems like it was imported from some generic spec in that this spec doesn't have variable length secrets, so why do we need to talk about why they are bad? There are plenty of other mistakes that this spec doesn't make that we don't cover here. S 6.2. TLS 1.3 does not require that ephemeral public keys be used only in a single key exchange session; some implementations may reuse them, at the cost of limited forward secrecy. As a result, any KEM used in the manner described in this document MUST explicitly be designed to be secure in the event that the public key is reused. Finite-field Again, this is a levy on KEMs generally, but don't these KEMs meet this requirement? Why is this text neeedd? transform [FO] [HHK] applied. While it is recommended that implementations avoid reuse of KEM public keys, implementations that do reuse KEM public keys MUST ensure that the number of reuses of a KEM public key abides by any bounds in the specification of the KEM or subsequent security analyses. What are those bounds for ML-KEM? Implementations MUST NOT reuse randomness in the generation of KEM ciphertexts. S 6.3. Because of the inclusion of the ML-KEM ciphertext in the TLS 1.3 key schedule, there is no concern of malicious tampering (MAL) adversaries, nor of just honestly-generated but leaked key pairs (LEAK adversaries). The same is true of KEMs with weaker binding properties, even if they were to have more constraints for secure use in contexts outside of TLS 1.3 handshake key agreement. These This text is hard to read. Does "KEMs with weaker binding properties" refer to "KEMs other than ML-KEM"? If so, then this doesn't need to be in this spec. If not, then the text probably needs a rewrite for clarity.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
