[TLS] Re: [Last-Call] Last Call comment: draft-ietf-tl s-mlkem-09 - named-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,

No TLS 1.3 stack I know of retracts supported_groups on handshake
failure.  One could perhaps on retry predict a different keyshare, but
shrinking the set of supported groups would simply be an implementation
design flaw.

What more often happens is the opposite, e.g., the Postfix (3.11+ with
OpenSSL 3.5+) SMTP client initially predicts X25519, but since it also
advertises X25519MLKEM768 in supported_groups, the Postfix SMTP server
chooses that via HRR, and CH2 send X25519MLKEM768.

> For an Informational document registering standalone PQC groups, it is
> worth stating that the assurance has to come from local policy, not from
> the handshake. Suggested text for Security Considerations:
> 
>     However, the protocol provides no
>     signal by which a client can detect that its post-quantum
>     key-establishment intent was defeated by induced fallback across
>     connections or by a peer that prefers a classical group.

This is not needed.  The fallback scenario you've envisioned is not
grounded in reality.  Your mistake is conflating the supported_groups
and keyshare extensions.

-- 
    Viktor.  🇺🇦 Слава Україні!

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