Hi Tanja, On 07.07.26 00:37, Tanja Lange wrote:
Respectfully, that's not correct. The WG paid special attention to your /technical/ concerns and spent quite some energy in addressing those. See inline below.I do not support publishing this document.Significant developments have occurred both within this document and in the broader TLS ecosystem to address the concerns raised in the last WGLC. Therefore, the third consensus call is warranted. We ask the working group to consider document publication in light of these recent changes:I do not see any of my concerns addressed by the changes, nor do I see any acknowledgment of those concerns in the document.
For reference, see below for
one of my emails from the previous last call.
Regards
Tanja
----- Forwarded message from Tanja Lange<[email protected]> -----
Date: Wed, 25 Feb 2026 21:04:24 +0100
From: Tanja Lange<[email protected]>
To: Nadim Kobeissi<[email protected]>
Cc: Paul Wouters<[email protected]>,[email protected]
Subject: Re: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)
I very much dislike this definition of "participant" and the assumption that
those who don't speak up are in agreement. [...]
I believe that's how IETF works.
I think it is irresponsible of the WG to publish an RFC that encourages risky behavior. Users will take the reputation of the IETF and understand this as a recommendation, whether it says = N or not.
Bas worked very responsibly to set X25519MLKEM768 = Y. I responsibly approved his PRs. The WG responsibly agreed to our proposal.
The draft now responsibly includes promotion of hybrids. Can you show me a concrete attack resulting from risky behavior?
The WG spent quite some time in planning, discussing and executing the formal analysis to the extent that nobody was complaining about formal analysis. Thanks to Nadim, it was finally formally verified in ProVerif and checked by at least one FATT member. So we have done "the best" we could do, as you seem to be saying. Computational proofs already exist and the WG seemed to believe that to be sufficient.As much as I like PQC and push for its adoption asap because we're too late (not my fault), I also warn about stability and code quality and we must acknowledge that. I love formally verified software like everybody else and it's the best we can do,
but also that is still a research area and we are currently in a situation where code can be formally verified and have bugs at the same time.
That's may be the case but I don't know what we could technically do here other than forbidding key reuse. Maybe if you would have shared concrete ideas, we could have addressed it better.
That's not even addressing the mathematical stability of the problems.
I don't know what could be concretely done here.
Still, it's better to add ML-KEM than not deploying it, but please not without ECC.
FWIW, that's what RECOMMENDED = Y/N does. So I believe it was addressed. Best regards, -Usama [0] https://www.ietf.org/archive/id/draft-ietf-tls-mlkem-08.html#section-5-1
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
