Hi Usama, all, Thanks for preparing draft-usama-tls-fatt-extension-08. I think the current direction is useful. Focusing the document on a concrete draft-writing template seems more actionable than treating this only as a process discussion, because it gives authors something they can directly add to TLS drafts before or during formal-analysis review.
I have a few concrete suggestions. First, the scope trigger could be made more operational. The current phrase "non-trivial extensions of TLS, which require formal analysis" is directionally right, but it may be difficult for authors to apply without examples. It may help to list classes of changes that usually deserve this treatment, for example changes to authentication, key schedule inputs, transcript binding, downgrade or negotiation behavior, post-handshake authentication, exporter-derived values, externally asserted identities, or mechanisms that claim a new security property. Second, I would separate two ideas that are related but not identical: 1. How the WG/FATT/chairs decide whether a draft needs additional formal analysis. 2. What authors can put into a draft so that reviewers and formal analysts can understand the intended protocol properties. The second point is where this draft can be especially helpful. Even when the process decision is made elsewhere, draft authors can still make the threat model, security goals, and protocol structure explicit enough for independent review. Third, Sections 3.2--3.4 could be made more mechanical, almost as a fill-in template. For the threat model, useful fields might include: - protocol participants and roles; - assets or properties to protect; - initial authenticated knowledge; - adversary capabilities; - trust boundaries; - key-compromise assumptions; - downgrade and negotiation assumptions; - deployment or migration assumptions; - explicit non-goals. For security goals, a compact structure such as the following might help authors write goals that can later become formal queries: - Property: - Protected object: - Adversary capability: - Required assumptions: - Failure condition: - Non-goals: - Candidate formal query or correspondence: Fourth, for protocol diagrams, I would suggest asking authors to mark not only the message flow, but also the security-relevant state. In particular, the diagram should identify modified TLS messages, extension points, key schedule or transcript inputs affected by the proposal, authentication or attestation evidence, the point at which protected application data may be released, and what remains unchanged from base TLS 1.3. That would make the diagram useful both for formal modeling and for implementation review. Finally, as a document-style point, idnits reports that the draft includes BCP14 boilerplate but does not currently use requirement-level keywords in the body. If this remains an Informational guidance/template document, removing the boilerplate may avoid confusion. If the intent is to define requirements for drafts in scope, then the checklist could instead be written with explicit BCP14 language and applicability conditions. Overall, I support the direction of -08. My main suggestion is to make the template concrete enough that authors of a new TLS draft can copy the relevant subsection headings, fill in the fields, and thereby give the WG and formal-analysis reviewers a clearer starting point. Best, Songbo On Thu, 2 Jul 2026 22:36:06 +0200, Muhammad Usama Sardar <[email protected]> wrote: > Hi folks, > > Admittedly not a good time to distract people in the ML-KEM > battlefield, but cutoff is coming fast, so pardon my distraction. > > I would like to share a cleaned up adoption-ready minus one > version, i.e., I personally believe draft is in good shape to > request for adoption in Vienna, and I request your feedback on > what to improve until the cutoff for adoption-ready version. > > Main changes are: > > To address David B's comments, all ML-KEM related stuff is gone > to a separate draft. > > To address Ekr's comments, all litigation is gone now (thanks > to chairs for addressing them) and the "Verifier" which was > creating misunderstanding is retired now. > > The substantive addition is a concrete motivational example > justifying the need of this draft: Sec. 1.1.1. It presents > illustrative and motivational example that unverified drafts that > asked for adoption in this WG have practically led to severe > exploits in real-world production systems, and FATT process has > successfully caught those exploits. To facilitate catching those, > we propose a non-binding document template. > > For bunch of new WG participants: a very warm welcome. Request > for adoption does not mean it is ready for publication; > it just means in author's opinion, it is a good starting > point for the WG to work on. Please keep that very important > distinction in mind while giving your feedback. Thank you! > > I look forward to your opinions. > > Best, > > -Usama > > -------- Forwarded Message -------- > > Subject: > > New Version Notification for > draft-usama-tls-fatt-extension-08.txt > > Date: > Thu, 02 Jul 2026 13:23:40 -0700 > > From: > [email protected] > > To: > Muhammad Sardar > [<[email protected]>](mailto:[email protected]), > Muhammad > Usama Sardar > [<[email protected]>](mailto:[email protected]) > > A new version of Internet-Draft > draft-usama-tls-fatt-extension-08.txt has been > > successfully submitted by Muhammad Usama Sardar and posted to the > > IETF repository. > > Name: draft-usama-tls-fatt-extension > > Revision: 08 > > Title: Proposed Document Template for TLS FATT Process > > Date: 2026-07-02 > > Group: Individual Submission > > Pages: 13 > > URL: > https://www.ietf.org/archive/id/draft-usama-tls-fatt-extension-08.txt > > Status: > https://datatracker.ietf.org/doc/draft-usama-tls-fatt-extension/ > > HTML: > https://www.ietf.org/archive/id/draft-usama-tls-fatt-extension-08.html > > HTMLized: > https://datatracker.ietf.org/doc/html/draft-usama-tls-fatt-extension > > Diff: > https://author-tools.ietf.org/iddiff?url2=draft-usama-tls-fatt-extension-08 > > Abstract: > > This document applies only to non-trivial extensions of TLS, which > > require formal analysis. FATT process has successfully discovered > > CVEs of *CVSS 7.5* and most recently expected *CVSS 9.1* in the > > *production* implementations of the drafts proposed for adoption > in > > the TLS WG. To achieve high cryptographic assurances, this > document > > proposes the drafts specify a clear threat model and informal > > security goals in the Security Considerations section, as well as > > motivation and a protocol diagram in the draft. > > The IETF Secretariat _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
