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

I do not understand the content of this objection. There already is an
alternative for PQ support in TLS, namely MLKEM + ECC hybrids,
defined in:

https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/

It's just not specified in this document.
-Ekr


On Tue, Jul 7, 2026 at 10:03 PM Bruno Henc <[email protected]> wrote:

> Hello everyone,
>
> I do not support the publication of this document.
>
> Opinions are my own and reflect practical experience with the mess when
> NIST didn't adopt/endorse ed25519 for quite a while.
> The practical result was that a certain IDS vendor who shall remain
> unnamed rejected all connections that had ed25519
> as part of the list of signature algorithms. The workaround was to
> remove ed25519 from the signature algorithms list.
> Now the IDS vendor did issue patches to address the problem, in a quiet,
> mostly undocumented way. Figuring out that
>
> the vendor elected to arbitrarily reject TLS connections based on a
> single parameter wasted massive amounts of time.I think that
>
> One would think RFC8701 would have prevented these interoperability
> problems but it did not.
>
>
> This is all a long winded way to say the the current tls-mlkem-08 draft
> lacks "cryptographic agility". To narrow down even further,
> there should be a second option available as part of the draft, in case
> of any issues with ML-KEM. This would prevent the
>
> vendors from only supporting a single algorithm and hardcoding it
> everywhere.
>
>
> Similar objections have been raised to the roughtime draft about
> cryptographic agility (see
>
> https://datatracker.ietf.org/doc/review-ietf-ntp-roughtime-15-secdir-lc-reddyk-2026-01-12/
> ).
>
>
> If SSL2.0 shipped with more than one algorithm in 1996, I don't see why
> the "pure PQ" options should be allowed to ship without supporting an
> alternative.
>
> It is my opinion that if this draft is published as-is, TLS1.3 will
> ossify into only supporting "pure PQ" options at the vendor level
> causing interoperability problems later on.
>
>
>
> Sincerely,
>
> Bruno Henc
>
> _______________________________________________
> 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]