Hi all,
# TL;DRNo FATT report is shown despite my repeated requests to the chairs for last 10 days. Speaking as someone who has been doing the formal analysis of various TLS drafts since the time FATT process was initialized, please try to put yourself in my shoes. While it is easy for many of you to just have a quick look and say 'I support publication' and move on with your life, I and the team working with me have a responsibility to maintain proofs and thoroughly check security considerations etc. The more I am looking into the issues like key reuse (see John's email below), the more I am convinced that the security considerations have serious concerns. Thus, I *strongly oppose* publication of -07. If rough consensus is declared on this draft to move on, I will put up a humble *appeal* to the responsible AD for his kind consideration on the matter of violation of FATT process [0].
# Long storyUnless FATT report is shown which tells me that they unanimously agree that the security considerations are acceptable, please consider the above as my conclusive opinion on this WGLC. I sincerely apologize to everyone for the bundle of emails in this thread. I tried my best to understand this encaps decaps thingy and how the existing proofs might hold. If FATT report was available, I would have put all my trust in FATT for a matter in which I am not an expert, but that report was unfortunately not shown. Absent that report, I have taken into consideration the opinions of my UFMRG chair (Stephen Farrell) and one FATT member (Dennis Jackson) who have shared their opinions in this/other related threads on the list. Unless I have missed something, I haven't seen any other FATT member commenting on the matter so far.
Like John, I am frustrated too that I raised some concerns in first WGLC, including an /intuitive/ attestation to his concern on key reuse. None of that was addressed in the version in this WGLC. I spent quite some time during this WGLC, and I have raised several concerns including introduction, motivation, security considerations etc. in this thread but very little of that is addressed in the editor's version at the time of sending this email, and the rest is not even promised to be addressed. How is a protocol designer -- who is knowledgeable with TLS 1.3 and ECDHE but not with this encaps decaps thingy -- supposed to use it properly in achieving the desired properties? What are the desired properties in the first place? How are the implementers supposed to understand the security and privacy implications? I very much like John's distinction of the three cases in his email below which precisely disambiguates the scenarios and IMHO and to the best of my understanding, the two responses of author to John still seem to be colluding points #2 and #3 of John.
Given that I have made repeated requests for clarification of FATT process violation and I haven't received any answer on why the chairs apparently did not "inform the WG of their decision" as per FATT process [0], I will go for an appeal to the AD for consideration of violation of FATT process if the decision of the chairs comes out to be to publish the document and no such "inform" email is shown to me. What John is mentioning in his email below is exactly an example of where FATT could have helped in refining the security considerations.
While I very much respect that some vocal proponents see some value in this draft, FWIW I would like to propose my humble proposal (adapted from the one proposed by Ekr in the other thread) which I strongly believe as the constructive way forward (feel free to bash it):
1. Adopt draft-barnes-tls-this-could-have-been-an-email to save WG energies for useful and constructive work 2. Adopt draft-usama-tls-ecdhe-mlkem-update for recommending hybrids 3. Following #1, respectfully decline to publish draft-ietf-tls-mlkem until WG views it important and secure enough for Recommended = Y and FATT report is availableRegarding SDOs which need stable links, the link https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ is a perfectly stable link. If expiry is an issue, running 3 commands every 6 months and accepting an email is not a big effort, I presume. If this is still a big effort, add me as a collaborator in the repo, and I will update it every 6 months for you to let it not expire.
# Question for proponentsHow many of you -- those who have supported publication of the draft on the list -- can actually take responsibility of the security considerations of the draft?
I sincerely thank John, Ekr, Thom, Nadim and Nico for the discussion on the formal modeling.
Thank you for your kind consideration, -Usama [0] https://github.com/tlswg/tls-fatt?tab=readme-ov-file#document-adoption On 25.02.26 08:31, John Mattsson wrote:
HiI received an offline comment from a senior IETF participant suggesting that I had misunderstood the draft and that the key reuse in question referred to reuse within a single session. That is not accurate. The draft talks about static keys, i.e., keys used in more than one key-establishment.Given the apparent confusion between 1. reuse of ephemeral keys within a session, 2. reuse of ephemeral keys across sessions, and 3. static keys, each of which carries distinct privacy and security implications, I recommend that the AD ensure that all not yet published drafts use very precise terminology. Specifically, a key used in more than one key-establishment should use the well-established term “static key”.--- 1. Reuse of ephemeral keys within a session:- Session A: ClientHello with MLKEM768 KeyShareEntry1 and X25519MLKEM768 KeyShareEntry2 both containing the same ML-KEM public key.2. Reuse of ephemeral keys across sessions:- Session B1. ClientHello with MLKEM768 KeyShareEntry3 and X25519 KeyShareEntry4. Sever picks X25519 KeyShareEntry4.- Session B2. ClientHello with MLKEM768 KeyShareEntry3 and X25519 KeyShareEntry5.3. Static keys- Session C1. ClientHello with MLKEM768 KeyShareEntry6. Sever picks MLKEM768 KeyShareEntry6- Session C2. ClientHello with MLKEM768 KeyShareEntry6. Sever picks MLKEM768 KeyShareEntry6---Issues with the text on static keys were clearly raised during the first WGLC and should have been addressed before the second. Having to repeat the same issues is both frustrating and a waste of time.The major issues, that the draft lacks proper security considerations for the use of static keys (they should be quite negative), and that it does not explain how an implementation using static keys can be conformant with NIST specifications, were raised during the first WGLC and have not been addressed. During the second WGLC, it was identified that conformance is intrinsically linked to the patent license.My constructive suggestion is to remove all text regarding static keys, as there is no reason for this draft to include them. I do not believe comparisons with draft-ietf-tls-hybrid-design are relevant, since that document serves a completely different purpose and does not register code points.If the draft intends to retain any text on static keys, NIST SP 1800-37, /Addressing Visibility Challenges with TLS 1.3 within the Enterprise/, is a useful reference regarding the negative privacy and security implications of static keys. I do not have specific guidance on how to achieve conformance with NIST specifications when using static keys, but that issue must clearly be resolved.I do not find any text in RFC 8446 that allows the use of static keys. If the TLS WG intends to explicitly permit static keys again, their use should be explicitly negotiated, as done in TLS 1.2 or draft-rhrd-tls-tls13-visibility.As I have seen no response from the authors indicating that they plan to address this issue, I am opposed to publishing this document.Cheers, John
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
