Hi Thom, Rich, all, TL;DR: Please check PR#20 to constructively move forward to wrap it up.
Sincere apologies, I meant to say /member/ of FATT. As I understood from your email, I am fine that you as a /member/ of FATT had a look at the code and attested to it to be making reasonable modeling choices so that when we use it in future, it will hopefully not be labelled by WG participants as "advertised" or doing any "marketing".Op 12 jun 2026, om 23:30 heeft Muhammad Usama Sardar <[email protected]> het volgende geschreven:Since the formal analysis has received review from FATT, that resolves my objection #1 in [0].My comment should not be construed as “review from the FATT”.
My *personal* opinion is that sending this to the FATT is a massive waste of time though:
FWIW, not as "massive waste of time" as it was for RFC8773bis, which was just standard TLS from formal analysis perspective and was still sent to FATT, while I and Russ were pushing back on it and we didn't know what to prove for it beyond what is already proven for TLS. Out of (genuine scientific) curiosity, I'd love to hear your thoughts about its comparison to RFC8773bis.
BTW I don't understand why checking a small diff over reftls is such a "massive waste of time." So could you please clarify for future reference?
Please note that I am no longer advocating this to be sent to other FATT members, just trying to understand "massive waste of time." Your attestation is sufficient for me, and as previously mentioned, my objection #1 is resolved, unless some other FATT member on list or WG participant raises some technical concern on artifacts.
it’s all pretty straightforward.
Looking at the previous sentence, I'm confused what "it" is referring to: draft? artifacts? paper? results? ...?
FWIW, this "pretty straightforward" ML-KEM draft has put the WG in several controversies since the adoption, with the latest WGLC having ca. 25 opponents to ca. 21 proponents.
In my experience, when a proof is done, it is easy for others to say proof was "pretty straightforward."
Similarly, when an attack is found, it is also easy for others to say it was "pretty straightforward" attack.
I wonder if it would be better that from now on, all draft authors start doing the "pretty straightforward" analyses themselves. I will appreciate any opinions on that.
Anyway, now that the proof is attested -- at least in my understanding -- I'd be happy if we can move on and if folks could agree on your proposal in PR#20 to resolve my final objection to wrap it up.
===
I’ve already posted about “a draft that defines A need not compare itself to B”
For PQ authentication, it may be fine because nothing adopted existed beyond ML-DSA, and in my current understanding, one unadopted proposal (composite signature) has weaker security of EUF-CMA compared to SUF-CMA of ML-DSA, and the other (dual certs) requires some changes in TLS. There does not seem to be any WG agreement on both unadopted proposals.
IMHO, for PQ key exchange, the situation is very different and this A-B argument doesn't seem to technically apply. There is a draft in the publication queue for hybrid key establishment. As I understand, nearly 70% of real-world human traffic at Cloudflare [0] is using hybrid key establishment. So it's not just the "Proponents of hybrid PQ/T key establishment" as the editor's copy says, it's being used in most of the real world and formally proven via both computational and symbolic models by several works -- the latter of which Thom seems to mention in his suggestion in PR#20. Adding the results of analysis was supported by several WG participants. I would be very surprised if Thom's proposal of adding 'this is supported by [...]' would hurt the draft. Nevertheless, as I clarified in [1] already, WG is free to ignore it and I will stay (not strongly) opposed in that case.
Sincerely, -Usama [0] https://radar.cloudflare.com/post-quantum?dateRange=7d [1] https://mailarchive.ietf.org/arch/msg/tls/NPOK-YKZGoRYE1xZA_57mULvoEg/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
