The normative portion of this draft (sections 4, 5) is pretty boring (in the
best possible way); it pretty much says "insert ML-KEM into TLS in the obvious
way, and use these code points".
On a minor note: when talking about failures (5.2), well, yes, decryption
failure (that is, both sides do the protocol honestly, both sides receive the
key shares correctly, but the two sides generate different secrets) is
possible; however the probability is so low that almost certainly no such
failure will ever occur anywhere in the world for this protocol. A failure is
far more likely to be due to a transmission error, an implementation bug or an
active attack (each of which have, in my estimation, a probability greater than
2^-138 of happening).
On the other hand, if we look at the security considerations (section 6), it
looks misguided. In my view, the security considerations of a draft or RFC
should give actionable advice on how to implement the protocol securely. This
does that only to a limited extent.
Section 6.1 mainly talks about the dangers of variable length secrets. This
has nothing to do with ML-KEM, which has fixed length secrets. In addition, it
cites Aviram et al which talks about the possible weaknesses when using a
hybrid construction with a non-collision resistant hash function - that doesn't
apply for several reasons.
Section 6.2 starts to talk about IND-CCA2 and Fujisaki-Okamoto transforms
(academic concepts that may mean little to an implementor) and DH (which has
nothing to do with this draft). On the other hand, at the bottom of the
section, it does give some advice ("recommended not to reuse KEM public keys;
if you have to, abide by any a bound on the number of reuses that the KEM
mandates (ML-KEM has no such bound); MUST NOT reuse randomness in the
generation of KEM ciphertexts).
Section 6.3 talks about binding properties and admits that they don't apply to
TLS 1.3 (in which case, why bring it up?)
IMHO, this security considerations section should be replaced with only those
things relevant to the implementor and things he can address, such as:
- Public key reuse (the current draft permits it; I can see the argument that
it should be forbidden, especially given how cheap key generation is in ML-KEM)
- MUST NOT reuse randomness in the generation of KEM ciphertexts - that text
from the draft is good
- Good randomness is essential
- Possibly some statements about side channels (although, without reuse, the
attacker gets only a single trace, and there are likely larger side channel
vulnerabilities available in a TLS implementation).
Also, why is RFC 9180 a normative reference?
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
