[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 20 26-07-08)

Hiya,

On 07/07/2026 21:26, Scott Fluhrer (sfluhrer) wrote:
> Sophie's point as that Google-based connections (which is what she
> is concerned about) will not use pure ML-KEM without nontrivial and
> deliberate configuration, which will be rare.

Well, google != the public Internet. The latter was the phrase
used, not the former.

> 
> On the other hand, if ML-KEM is compromised, then hybrid ML-KEM+ECC
> will not be secure after q-day.
> 
> That is a point that the 'hybrid-only' proponents want to ignore;

That's not relevant to my point, and I don't know how you know what
other people want to ignore or not.

S.

> ECC security appears to have an end date, and while we don't know
> when that is, it may well be in the next several years.  At that
> point, the security of ML-KEM and ML-KEM+ECC becomes equivalent, and
> all the horrible scenarios they imagine if ML-KEM is used will also
> become a reality with hybrid.
> 
> ________________________________ From: Stephen Farrell
> <[email protected]> Sent: Tuesday, July 7, 2026 4:11 PM To:
> Sophie Schmieg <[email protected]>; [email protected]
> <[email protected]> Subject: [TLS] Re: WG Last Call: draft-ietf-tls-
> mlkem-08 (Ends 2026-07-08)
> 
> 
> Hiya,
> 
> On 07/07/2026 19:49, Sophie Schmieg wrote:
>> I think it is important to emphasize that, even if one assumes a
>> total compromise of pure ML-KEM there exists no risk to the public
>> internet from this draft.
> 
> I find the above unconvincing. The dual-ec fiasco also involved 
> paying commercial entities to implement the borked alg as well as
> the odd code additions in the Juniper case. Were there a backdoor in
> ML-KEM (which I do not think is the case) then it could be
> exploited, and the existence of this putative RFC would increase the
> liklihood of successful exploitation.
> 
> Cheers, S.
> 
> PS: To recap, I no longer object to this draft now the WG has 
> preferred the hybrid, but I think better to be precise about the
> pros and cons.
>

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQQwbnhHy1kPJkWsM6fk2On5l6gz3QUCak1nMwUDAAAAAAAKCRDk2On5l6gz3aEr
AQCbVbmeesL6tVX6ZsDhVhyNkOmsMSx7cyJKBmy5CHTWwAD+PxLUPhlgj2N5zEkhN0gduhIAdv+f
7QE5LGFE3sgEhw4=
=VRRe
-----END PGP SIGNATURE-----