2025-06-15 19:15 GMT+02:00 Scott Fluhrer (sfluhrer)
<[email protected]>:
> 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).
Indeed, I think it’s the responsibility of specification authors who understand
the concept of cryptographically negligible probability to omit these virtual
impossibilities from implementor-aimed documents.
A chance of 2^-138 is 1000x smaller than the chance of deriving the obviously
insecure all-1s AES-128 key. It’s also likely to be smaller than the chance of
a cosmic ray corrupting the flags register flipping the direction of an if
check.
I disagree that “implementers should be aware” of this eventuality. They will
at best do nothing (correctly) and at worst add useless complexity.
> 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]
>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
