[TLS] Re: [Last-Call] Last Call comment: draft-ietf-tl s-mlkem-09 - named-group downgrade / negotiation policy

On 2026-08-12 07:53, Viktor Dukhovni wrote:
> 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.

Viktor, thank you, you're right, and I appreciate the correction. I
was conflating supported_groups with key_share, and I agree that no
conformant TLS 1.3 client retracts supported_groups on a handshake
failure, so the cross-connection induced-fallback scenario I described
does not hold. A server that wants a PQC group obtains the share via
HRR, and the negotiated group is authenticated in the transcript and
visible to the client. That removes the basis for my suggested text,
so I withdraw the request. Appreciate you walking through it.

Mark

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