Hi Ilari, I agree with you but have a few clarifying questions to be on the same page.
On 22.04.26 16:08, Ilari Liusvaara wrote:
On Tue, Apr 21, 2026 at 05:51:29PM +0200, youssef hamdi wrote:Dear TLS Working Group, I am reporting a structural gap in hybrid TLS 1.3 KEM negotiation that allows silent post-quantum downgrade without client notification. SUMMARY ─────── Stripping the kemgroup extension from ClientHello (6-byte edit) forces any TLS 1.3 server configured for hybrid ML-KEM to fall back to classical-only key exchange. The AND-property guarantee is vacuously satisfied — ML-KEM is never invoked — while the client receives no alert. All four hybrid configurations tested are vulnerable.Editing ClientHello causes both handshake signature verification and finished MAC to fail.
Agree but elaborating it a little bit more to see if we are on the same page:
In CertificateVerify message, the server signs the transcript hash up to the Certificate message. So it contains ClientHello message (together with its extensions including kemgroup). The client should verify this signature in CertificateVerify message. If the server (or the adversary) stripped some extension (kemgroup in this case), this signature verification would fail as the transcript hash on the client side still includes that extension.
Similar argument applies for the hmac in Finished message (which includes transcript hash of ClientHello with all extensions).
Is it the reasoning here?
THE CORE ISSUE ────────────── RFC 8446 does not mandate that a server REJECT a ClientHello offering only classical groups when the server's policy requires hybrid KEM. Server-side enforcement is currently optional. This means deployments advertising post-quantum protection — including those migrating under NIST PQC standards — can be silently downgraded to classical-only sessions with no client-visible error.Client ignoring signature verification and finished MAC failures (without explicitly disabling all security[1]) is a critical client security vulnerability. And server not correctly enforcing its configured security policy is at least high-level[2] server security vulnerability. [1] Disabling these checks is _not_ allowed by TLS 1.3 specification. I can come up with some rare cases where one would disable signature verification, but can not come up with any where disabling MAC checks would make any sense.
I think the cases which skip signature verification are the ones with self-signed certificates, but I guess they still do some authentication at some upper layer then. I am thinking of Tor. Is it the one you are thinking of? If not, mind sharing the case you were thinking of?
[2] I initially thought completely compromising confidentiality would be considered critical severity. Nope, it is apparently only considered high severity.
I would expect it to be critical too. Could you explain how to judge the severity for a given weakness? Are you somehow referring to CVSS scores or CWEs?
Thanks, -Usama
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
