> > I feel I need to ask this (both to you and to others who have suggested > that ML-KEM cannot be trusted): do you support the publication of > draft-ietf-tls-ecdhe-mlkem?
Nitpicking, that's fine. The hybrid draft is fine. It's a reasonable first step. What I'm trying to mitigate against is a trivially horrible worst case scenario: ML-KEM being broken by affordable classical computers. The hybrid approach makes the assumption that a given opponent can't afford to break both ECC and ML-KEM, which is a weaker-or-equal assumption than assuming they can't break ML-KEM. Since we're pushing standards that will determine the safety of tens of millions of people, I think it's only reasonable to pick the weaker assumption. Being conservative here doesn't harm anyone. Even if ML-KEM turns out to be breakable, a hybrid approach gives us more years of protection: - Hybrid ECDHE + ML-KEM protects up until max(Q-day, ML-KEM breaks-day) - Whereas the PQ-only approach protects up until 'ML-KEM breaks-day' I hope that makes sense. --Félix El jue, 2 jul 2026 a las 14:49, Scott Fluhrer (sfluhrer) (< [email protected]>) escribió: > I feel I need to ask this (both to you and to others who have suggested > that ML-KEM cannot be trusted): do you support the publication of > draft-ietf-tls-ecdhe-mlkem? > > That draft would appear to be TLS working group's answer to postquantum > privacy, and I expect that it would be extensively used in that role. > However, if you don't trust that ML-KEM is secure, then you can't trust > that draft-ietf-tls-ecdhe-mlkem is postquantum secure. That sounds like > you would be recommending people to use something that you don't believe > meets the security goal, and would be, in fact, insecure after Q-day. > > Now, if you make the weaker statement that "ML-KEM is likely to be secure, > but doing ECDH alongside it is cheap and gives me the warm fuzzies", that's > a reasonable statement - however, just because ML-KEM only doesn't give you > the same warm fuzzies seems like a weak justification for attempting to > block it. > > ------------------------------ > *From:* Fe Lix <[email protected]> > *Sent:* Thursday, July 2, 2026 12:48 PM > *To:* [email protected] <[email protected]> > *Subject:* [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends > 2026-07-08) > > Hi yall. I'm Félix Fischer Marqués. I'm from Chile. > > I don't support the publication of this document. As to why, that's coming > up > next. I'll try to be brief. > > In cryptography today, we rely on strong assumptions. We try to make the > least amount of those we can, but as of right now, we're kind of screwed: > we > must make assumptions. Nonetheless, we try to keep the number and strength > of > them as low as we can. > > This draft assumes that ML-KEM is computationally strong. Meaning, it > assumes > that any adversary would indeed need an exponentially-growing amount of > resources to break it (exponential in terms of the cost to the users). > > That's an extremely silly assumption to make. There is so much we just > don't > know about computational complexity that, in the best scenario, I would > describe this as hubris. We don't even know if one-way functions exist, > much > less public-key cryptography. Let's remain humble and accept the reality > that > ML-KEM might not be computationally strong at all. > > We have to remember that standards like these are adopted in tens of > millions > of devices. Hubris here kills people over there. > > Have a good week. > -- Félix >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
