]> TU Dresden, Germany

muhammad_usama.sardar@tu-dresden.de

Stevens Institute of Technology

New York USA bluedognull@gmail.com

Security Transport Layer Security 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. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Transport Layer Security Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction While the TLS FATT process marks a historic change in achieving high cryptographic assurances by tightly integrating formal methods in the working group (WG) process, it would be helpful to adapt the way in which drafts are typically written to get the benefits.

Motivation Unverified protocol designs, imprecisely stated threat model and security goals have led to high and critical severity vulnerabilities of the extensions proposed in the drafts.

Concrete Motivational Example: Practical Exploits in Production Systems As an illustrative example, authors of asked for adoption in IETF 121, explicitly requesting us (by name) for formal analysis . We carried out formal analysis of draft in support for FATT process. The formal analysis led to three orthogonal issues:

• Formal analysis found diversion attacks for . For technical details, please see the corresponding paper .
• Formal analysis of several production implementations of led to discovery of of CVSS 7.5 for relay attacks. For technical details, please see the corresponding paper .
• Further formal analysis of production implementation of has led to discovery of another class of attacks and will potentially lead to three CVEs (currently under responsible disclosure) each with an expected CVSS 9.1.

This shows the value of FATT process in the design of secure protocols to find subtle vulnerabilities, which could otherwise be missed.

Proposal To produce high-quality specifications, this document outlines the corresponding changes in the way drafts are typically written. For the draft to be useful for the formal analysis, this document proposes that it would be helpful for the formal analysis if the draft contains four main items, namely:

• motivation,
• a threat model,
• informal security goals, and
• a protocol diagram ().

Each one of these is summarized in . Future versions of this draft will include further concrete examples.

Scope The scope of this document is only non-trivial extensions of TLS, which require formal analysis. As per FATT process , this includes changes in the key schedule or the authentication process or any other part of the cryptographic protocol that has been formally modeled and analyzed in the past. As per FATT process , the chairs make a determination whether the change proposed by the document requires review by the FATT to determine if formal protocol analysis is necessary for the change. Hence, such a determination is out of scope of this document.

Concrete CVEs We consider the example of extension of TLS with remote attestation.

Intra-handshake.fail presents a general approach to analyze the intra-handshake (aka early) attestation proposals. From a security perspective, one of the key decision factors is the candidate binding mechanism. The artifacts are available in under Apache-2.0 license for reproducibility, extensibility, and further research.

• This work resulted in of CVSS 7.5.

ID-Crisis A complementary paper presents the identity crisis in pre- and intra-handshake attestation. The formal analysis is available in under Apache-2.0 license for reproducibility, extensibility, and further research.

EarlyAttestationBleed presents a formal analysis together with regression tests of the broader attestation ecosystem and discovered three critical-severity vulnerabilities in implementations of early attestation:

• Ultraviolet Cocos AI in TDX path resulting in of CVSS 9.1.
• Ultraviolet Cocos AI in AMD SEV-SNP path resulting in of CVSS 9.1.
• Edgeless Systems Contrast in policies resulting in of CVSS 9.0-10.0 and of CVSS v3.1 of 9.6.

Architectural Flaws in Early Attestation Sec. 7 of presents four architectural flaws in early attestation:

• A malicious TLS client retrieves sensitive hardware-level and firmware-level information from the server’s Evidence before the server has authenticated the client.
• Early attestation can typically provide information about only boot-time Claims, since most runtime Claims may not be available at the handshake time.
• Re-attestation requires post-handshake attestation. Early attestation thus adds unnecessary complexity.
• Early attestation results in high handshake latency, timeouts, and even failures.

EarlyAttestationTschüss (EAT) resulted in the following CVEs demonstrating relay and diversion attacks against early attestation implementations/deployments:

• of CVSS 9.1 against Edgeless Systems Contrast
• of CVSS 9.1 against CCC Attestation SIG
• of CVSS 9.1 against Privasys
• of CVSS 9.1 against Privasys
• of CVSS 9.1 against Privasys
• of CVSS 9.1 against Privasys
• of CVSS 9.1 against Privasys
• of CVSS 9.1 against Privasys

More details Further examples of CVEs are in .

Conventions and Definitions

Protocol Diagram In the context of this document, a Protocol Diagram specifies the proposed cryptographically-relevant changes compared to the standard TLS protocol . This is conceptually similar to the Protocol Model in . However, while only recommends diagrams, we consider diagrams to be essential to reduce the gap between:

• the specifications and formal analysis
• the specifications and implementation

Contents of Drafts The following contents are expected in drafts:

Motivation Drafts are expected to provide the motivation of the work (i.e., the proposed extension of TLS).

Threat Model A threat model identifies which threats are in scope for the protocol design. So it can answer questions like:

• What are the capabilities of the adversary? What can the adversary do?
• Whether post-quantum threats are in scope?
• What can go wrong in the system? etc.
• What are the computational and memory resources available to the adversary?

Typical Dolev-Yao adversary A typical threat model assumes the classical Dolev-Yao adversary, who has full control over the communication channel. Any additional adversary capabilities and assumptions ought to be explicitly stated.

Keys This is particularly relevant for proposals of hybrid key establishment or hybrid authentication. This section ought to specify any keys in the system (e.g., long-term keys of the server) in addition to the standard TLS key schedule. Theoretically and arguably practically, any key may be compromised (i.e., become available to the adversary). For readability, we propose defining each key clearly as in Section 4.1 of . Alternatively, present as a table with the following entries for each key:

• Name (or symbol) of the key
• Purpose of the key
• (optionally but preferably -- particularly when the endpoint is not fully trusted) Which software in the system has access to the key?

If more than one servers are involved (such as migration cases), the keys for servers ought to be distinguished in an unambiguous way.

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.

Informal Security Goals Knowing what you want is the first step toward achieving it. Hence, informal security goals such as integrity, authentication, freshness, etc. ought to be outlined in the draft. Examples:

• Integrity of message X holds unless some key Y is leaked.
• (stated differently) Integrity of message X holds as long as some key Y is protected.
• Freshness of message X holds unless some key Y or some key Z is leaked.
• Server Authentication holds unless some key Y or some key Z is leaked.

See Section 5.1 of for concrete examples.

Template

• Property:
• Protected object:
• Adversary capability:
• Required assumptions:
• Failure condition:
• Non-goals:
• Candidate formal query or correspondence:

Protocol Diagram A Protocol Diagram ought to clearly mention the initial knowledge of the protocol participants, e.g., which authentic public keys are known to the protocol participants at the start of the protocol. An example of a Protocol Diagram for is provided in Figure 5 in .

Document Structure While the needs may differ for some drafts, we propose the following baseline template, with examples of and : The template is easy for:

• readers
• reviewers
• formal analysis team

TODO: Currently it is almost a copy of the guidance email to the authors. We request feedback on what to add in next versions.

Introduction

• Problem statement: Say in general what the problem is.
• For , we believe this may preferably not include CATS. Anyone unfamiliar with CATS ought to be able to understand the problem statement.

Terminology

• Define any terms not defined in RFC8446bis or point to other drafts from where the definition is used.

Motivation and design rationale

• We really like how the author of motivates the problem statement. Use it as a sample.
• Here authors can address all the concerns from WG, including justification with compelling arguments and authentic references why authors think it ought to be done within TLS WG (and within handshake).
• For , authors could put CATS here as a motivational use case.
• For , it should clarify why the problem is specific to PQ-only and why did the WG do such a thing for the transition for other primitives, as requested by several WG participants.

Proposed solution (one or more sections)

• Protocol design with Protocol Diagram: we work on the formal analysis of TLS 1.3 exclusively. Please contact someone else if your draft relates to older versions.

Security considerations

Threat model

Desired security goals As draft proceeds these desired security goals will become what the draft actually achieves.

• For , it should clarify which property of the TLS protocol is broken and how does the proposal improve the security.

Other security implications/considerations

Security Considerations The whole document is about improving security considerations. As mentioned in , unverified specifications have led to high and critical severity exploits. Like all security proofs, formal analysis is only as strong as its assumptions and model. The scope is typically limited, and the model does not necessarily capture real-world deployment complexity, implementation details, operational constraints, or misuse scenarios. Formal methods should be used as complementary and not as subtitute of other analysis methods.

IANA Considerations This document has no IANA actions.

References Normative References IETF TLS WG Informative References Independent This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. Intuit Arm Limited Arm Limited Arm Limited Huawei Linaro The TLS handshake protocol allows authentication of one or both peers using static, long-term credentials. In some cases, it is also desirable to ensure that the peer runtime environment is in a secure state. Such an assurance can be achieved using attestation which is a process by which an entity produces evidence about itself that another party can use to appraise whether that entity is found in a secure state. This document describes a series of protocol extensions to the TLS 1.3 handshake that enables the binding of the TLS authentication key to a remote attestation session. This enables an entity capable of producing attestation evidence, such as a confidential workload running in a Trusted Execution Environment (TEE), or an IoT device that is trying to authenticate itself to a network access point, to present a more comprehensive set of security metrics to its peer. These extensions have been designed to allow the peers to use any attestation technology, in any remote attestation topology, and mutually. Intuit Arm Limited Arm Limited Arm Limited Huawei Linaro The TLS handshake protocol allows authentication of one or both peers using static, long-term credentials. In some cases, it is also desirable to ensure that the peer runtime environment is in a secure state. Such an assurance can be achieved using attestation which is a process by which an entity produces evidence about itself that another party can use to appraise whether that entity is found in a secure state. This document describes a series of protocol extensions to the TLS 1.3 handshake that enables the binding of the TLS authentication key to a remote attestation session. This enables an entity capable of producing attestation evidence, such as a confidential workload running in a Trusted Execution Environment (TEE), or an IoT device that is trying to authenticate itself to a network access point, to present a more comprehensive set of security metrics to its peer. These extensions have been designed to allow the peers to use any attestation technology, in any remote attestation topology, and mutually. Internet Architecture Board The IETF process depends on peer review. However, IETF documents are generally written to be useful for implementors, not reviewers. In particular, while great care is generally taken to provide a complete description of the state machines and bits on the wire, this level of detail tends to get in the way of initial understanding. This document describes an approach for providing protocol "models" that allow reviewers to quickly grasp the essence of a system. This memo provides information for the Internet community. TU Dresden, Dresden, Germany Aalto University, Espoo, Finland Aalto University, Espoo, Finland ACM Vigil Security, LLC This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with certificates and provide confidentiality based on encryption with a symmetric key from the usual key agreement algorithm and an external pre-shared key (PSK). This Standards Track RFC (once approved) obsoletes RFC 8773, which was an Experimental RFC. China Telecom China Telecom Beijing Infosec Technologies Co., LTD. Palo Alto Networks Palo Alto Networks This draft proposes a service affinity solution between client and server based on Transport Layer Security (TLS). It defines a minimal extension to TLS 1.3 by which a server instance can authorize a client to resume an established session on a different instance of the same service (for example, another node of a load-balanced cluster) and request, in band, that the client do so. The relocation authorization is carried inside the server's own session ticket, so it inherits the security properties of TLS 1.3 ticket-based resumption. The relocation target is an opaque value that either directly carries the switchover address (for example, an IP address and port) or is an identifier resolved by the application or control plane. This document also introduces a Reliable Framing Layer that operates above the TLS record layer to provide message framing, sequence numbering, acknowledgment tracking, and automatic retransmission. The Framing Layer ensures zero application data loss during TLS session migration by buffering unacknowledged data frames and retransmitting them to the new server endpoint after migration completes. Intuit Nokia As the Internet transitions toward post-quantum cryptography (PQC), many TLS servers will continue supporting traditional certificates to maintain compatibility with legacy clients. However, this coexistence introduces a significant vulnerability: an undetected rollback attack, where a malicious actor strips the PQC or composite certificate and forces the use of a classical certificate once quantum-capable adversaries exist. To defend against this, this document defines a TLS extension that allows a TLS client to cache a server's declared commitment to present PQC or composite certificates for a specified duration. On subsequent connections, the client enforces that cached commitment and rejects traditional-only certificates that conflict with it. This mechanism, inspired by HTTP Strict Transport Security (HSTS) but operating at the TLS layer, provides PQC downgrade protection without requiring changes to certificate authority (CA) infrastructure. CVE Cryptography Consulting LLC Cloudflare, Inc. This document provides guidelines and best practices for writing technical specifications for cryptography protocols and primitives, targeting the needs of implementers, researchers, and protocol designers. It highlights the importance of technical specifications and discusses strategies for creating high-quality specifications that cater to the needs of each community, including guidance on representing mathematical operations, security definitions, and threat models. Faculty of Computer Science, Technical University of Dresden, Dresden, Germany Huawei Technologies Oy, Helsinki, Finland Department of Computer Science, University of Applied Sciences Bonn-Rhein-Sieg and Siemens, Sankt Augustin, Germany Linaro, Lausanne, Switzerland Institute of Electrical and Electronics Engineers (IEEE) This document describes a mechanism that builds on Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) and enables peers to provide proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out of band to the other peer, and verified by the receiving peer. This document defines a channel binding type, tls-exporter, that is compatible with TLS 1.3 in accordance with RFC 5056, "On the Use of Channel Bindings to Secure Channels". Furthermore, it updates the default channel binding to the new binding for versions of TLS greater than 1.2. This document updates RFCs 5801, 5802, 5929, and 7677. ENISA CVE CVE CVE CVE CVE CVE CVE ENISA ENISA IEEE CVE ENISA CVE ENISA CVE CVE CVE ENISA ENISA ENISA ENISA ENISA ENISA ENISA ENISA Global Alliance for Genomics and Health CoreWeave University of Namur Stevens Institute of Technology Independent Shanghai Guan An Information Technology Co., Ltd. Switch DPhil Oxford University Sureshot Labs Independent Independent Corporate Risk Consultant PHI-OMEGA HashCloak Inc and Stoffel Labs Inc EMILIA Protocol, Inc. Ecole Superieure Ingénieurs Léonard de Vinci Paris Birmingham City University Verily The draft aims to provide technical details of [CVE-2026-100833] of CVSS 9.6, [CVE-2026-108265] of CVSS 9.1, [CVE-2026-108266] of CVSS 9.1, [CVE-2026-108267] of CVSS 9.1, [CVE-2026-108268] of CVSS 9.1, [CVE-2026-108269] of CVSS 9.1, [CVE-2026-100835] of CVSS 9.1, [CVE-2026-92701] of CVSS 9.1, [CVE-2026-92702] of CVSS 9.1, [CVE-2026-108362] of CVSS 9.1, [CVE-2026-119344] of CVSS 9.1, [CVE-2026-33697] of CVSS 7.5, [CVE-2026-108361] of CVSS 7.2, [CVE-2026-119345] of CVSS 7.2, and 26+ GitHub Security Advisories (GHSAs) against early attestation in the process of getting CVE IDs, which provide substantial technical evidence of how early attestation, such as [I-D.fossati-seat-early-attestation], fails in practice, even *without physical access* to the desired machine. Moreover, since continuous attestation is generally required [CSA-eBPF] [MITRE-Continuous-Attestation], early attestation adds *unnecessary complexity*. The results are backed by the research [Intra-handshake.fail], [TLS-RA], [EarlyAttestationBleed], [EarlyAttestationTschuess] and the artifacts [Intra-handshake.fail-repo] in state-of-the-art formal analysis tool, ProVerif, under Apache-2.0 license for reproducibility, extensibility, and review, and have been acknowledged by the relevant stakeholders. Currently, there is *one CVE of CVSS 9.6, 11 CVEs of CVSS 9.1, one CVE of CVSS 8.2, one CVE of CVSS 7.5, one CVE of CVSS 7.2, and 26+ GHSAs published awaiting CVE IDs against the broader early attestation covering all layers of the ecosystem up to the application*. The research papers on these are currently either under submission or being prepared for submission. The artifacts of these papers will be shared with the community under Apache-2.0 license for reproducibility, extensibility, and review. Based on our work, all except two implementations of early attestation have been archived, withdrawn, or moved to post-handshake attestation. In our analysis [Intra-handshake.fail-repo], [ID-Crisis-repo], and [EarlyAttestationTschuess] (EAT) and based on discussions in the CCC Attestation SIG, IETF SEAT WG, IRTF UFMRG, and several other forums, the remaining two implementations of early attestation -- Edgeless Systems Contrast and Meta's AI -- remain vulnerable due to lack to binding to the underlying connection. We recommend users of these two implementations to carefully evaluate their systems and understand the risks. If you are aware of any open-source implementation of early attestation that is not yet covered in this draft, please let us know to responsibly disclose the vulnerabilities to them.

Appendix

Document History -11

• Refocus motivational CVEs

-10

• Added concrete CVEs for motivation

-09

• Template for threat model and informal security goals
• Added Songbo as co-author

-08

• Focused on document structure only
• Motivational examples

-07

• Failure of current process
• Students of FATT
• Lead FATT Person for Contact
• Feedback from the WG

-06

• Solution for ML-KEM: FATT analysis
• Solution for FATT contact: new mailing list
• Replaced responsibilities by expected contributions
• Clarified Verifier even further that it is just a WG member; no formal role
• s/pure/non-hybrid

-05

• Removed process-related stuff
• Moved discussion at meeting to solutions
• Added ML-KEM

-04

• Extended threat model
• Helpful discussions on formal analysis in meetings
• Pointer to formal analysis and costs

-03

• Limitations of formal analysis in security considerations
• Proposed solutions section
• More guidance for authors: Threat Model and Informal Security Goals

-02

• Added document structure
• FATT-bypass by Other TLS-related WGs
• FATT process not being followed

-01

• Pain points of Verifier
• Small adjustment of phrasing

Acknowledgments We thankfully acknowledge the following for their valuable input:

• Eric Rescorla for review of -02, -05, and -06.
• John Mattsson for proposing text for security considerations.
• David Benjamin for review of -06.
• Mike Ounsworth for review of -07.

We gratefully acknowledge the valuable contributions of co-authors of papers for their instrumental contributions in formal analysis: Mariam Moustafa, Tuomas Aura, Viacheslav Dubeyko, and Jean-Marie Jacquet. We sincerely thank the contributors of the formal analyses and mentioned in the respective repositories. We express our appreciation to Yaakov Stein and Ilari Liusvaara for their substantial technical guidance, valuable feedback, and contributions in early attempts to formally model ML-KEM. The research work is funded by German Research Foundation ("Deutsche Forschungsgemeinschaft.")