On Sun, Jun 15, 2025 at 10:44 AM Filippo Valsorda <[email protected]> wrote:
> 2025-06-15 19:15 GMT+02:00 Scott Fluhrer (sfluhrer) <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. > I tend to agree with this position. More generally, ISTM that we should be consistent between this draft and draft-ietf-tls-ecdhe-mlkem, which does not seem to say anything about this. Similar comments probably apply to the topics Scott raises below about security considerations. To the extent to which security considerations apply to both ML-KEM and ML-KEM hybrids, then they should be consistent between both drafts. -Ekr > > > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
