Hi Joshua,I find it very insightful and comprehensive analysis, except that you have not talked about my concerns on FATT process. If you dislike formal methods or do not have any opinion on it, it's perfectly fine. But I find improving security considerations by formal methods at least as good as the reasons you are mentioning.
I very much appreciate your clarifying diagrams.In general, I agree with most of what you are saying but have a few clarifying questions. Please see inline:
On 28.02.26 02:45, Joshua wrote:
-> motivation: "Hybrids increase cycle counts [over plain ML-KEM]"
Marginally. A full ML-KEM exchange takes about 33% of the cycles
for a full x25519 exchange, including key generation.
I don't understand what exactly you mean by "cycle counts". Could you please explain a little bit how exactly you measured this? More specifically, for ECDHE, is this based on:
1. generation of keys (x and y) on client and server 2. Exchange of ClientHello and ServerHello messages, containing g^x and g^y in extensions 3. computation of shared secret g^xy on both client and serverand for ML-KEM, based on [0] and the exchange of ClientHello and ServerHello messages?
There are some times where chairs will ask a question or take a poll toward the end of a discussion in order to figure out the state of consensus, but this must be done with extreme caution. [RFC7282]
I believe one of the questions should be (paraphrasing from [1] where not a single WG participant took responsibility):
Who is willing to actually take responsibility of the security considerations and risks of the draft?
I think it is clear that we will not reach consensus to adopt this draft.
Clarification question: Did you mean publish instead of "adopt"? or are you making the case to un-adopt this draft?
(the latter also seems reasonable to me as well, given the amount of WG energies this draft has wasted, and concerns from all sides: motivation, risk, formal, ... and has led to no useful outcome IMHO.)
I can attest to it; this seems to be constructive way forward.I believe that's also close to the idea Stephen proposed.I believe it would be far more productive to step away from the problem of ML-KEM specifically and try to find consensus in the best way to proceed in the overall realm of post-quantum adoption for TLS. There are many more areas where a lack of such strong disagreement will allow us to make real progress.
So far, the only denial-of-service regarding the working group is the continued insistence that majority votes consist of consensus. They do not; quality always trumps quantity.
I believe the quality of arguments in your email alone plus violation of FATT process far outweigh all supporters' arguments.
If anything, this WGLC has shown that increasingly more concerns are being presented, as more and more folks are exploring this encaps decaps thingy. I, for example, had no opinion at adoption time; requested some changes at first WGLC (which were all ignored anyway) and now have strong opposition at this WGLC, leading to potential appeal.
- The best time to set X25519MLKEM768 as Recommended=Y was yesterday, but the second best time is *right now*.
I can again attest to it. It's already late but the work [2] has started. Do you have any opinion on SecP256r1MLKEM768 and SecP384r1MLKEM1024?
I believe making it dependent on discouraging ECDHE (as in Bas draft) will only further delay it.
I hope this letter helps set the WG back on track towards the long term goal of ensuring post-quantum security of TLS, rather than trying to rush premature standalone adoption without any clear benefit to the general public.
I hope as well. -Usama [0] https://www.ietf.org/archive/id/draft-ietf-tls-mlkem-07.html#section-3 [1] https://mailarchive.ietf.org/arch/msg/tls/5n9k4AE6XCQVGj7W8W5O_ewTAn4/ [2] https://datatracker.ietf.org/doc/draft-usama-tls-ecdhe-mlkem-update/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
