[TLS] Re: Last Call comment: draft-ietf-tls-mlkem-09 - nam ed-group downgrade / negotiation policy

On Wed, Aug 12, 2026 at 07:17:22AM -0400, Mark C. Langston wrote:
> 
> - The residual risk is at named-group granularity, where TLS 1.3 has no
>   downgrade signal. RFC 8446 Section 4.1.3's downgrade protection is
>   version-granular only. So (a) an active attacker can induce fallback
>   across connections by black-holing the PQC handshake (unknown group,
>   or an oversized/fragmented ClientHello) so the client or application
>   retries with a reduced offering, and transcript protection does not
>   span separate connections; and (b) a client that offers ML-KEM
>   alongside classical groups completes on classical with no signal that
>   PQC was available but not used. In neither case does the client learn
>   that its post-quantum intent was defeated.

I do not see how this is different from composites, but...


Client REALLY SHOULD NOT fallback supported_groups. Version
downgrade (which SHOULD NOT be done) does that implicitly, but should
be caught by version downgrade protection.

But there is second more obscure failure mode: Client downgrading
key shares to work around tldr.fail and server not preferring PQC. The
client SHOULD completely clear key shares on downgrade.


> Related, the large ClientHello that standalone ML-KEM produces (the
> ML-KEM-768 encapsulation key is 1184 bytes, ML-KEM-1024 is 1568, and
> multiple offered groups compound it) feeds the induced-fallback vector
> above wherever it crosses record or datagram boundaries and trips
> intolerant middleboxes. A sentence acknowledging that ClientHello-size
> interaction would reinforce the same point.

Records can be up to 16kB, so crossing that is very unlikely. And there
are quite many servers that puke on fragmented ClientHello.

Client Hello crossing datagram boundaries is much more common, and the
related failures are known as tldr.fail. AFAIK, it was not just some
middleboxes that failed, but also some servers.

Then there are various limits intermediate between those two. IIRC,
there were experiments on PQC key sizes many years back, and the
result was that execeeding 3300 bytes causes failure rate to become
too high. That would fit 2 PQC keys.




-Ilari

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