]> Technical University of Dresden

Dresden Germany muhammad_usama.sardar@tu-dresden.de

Stevens Institute of Technology

New York USA bluedognull@gmail.com

Independent

aurestarnull@gmail.com

Shanghai Guan An Information Technology Co., Ltd.

China havan12050544@gmail.com

RATS Working Group security considerations remote attestation This document aims to provide guidelines and best practices for writing security considerations for technical specifications for RATS targeting the needs of implementers, researchers, and protocol designers. In particular, it discusses some of the 'bottom turtle' issues. This is a work-in-progress, and the current version mainly presents an outline of the general security guidelines, baseline, or template for RATS that future versions will cover in more detail. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction

Need for Specialized Guidance in RATS Every Internet Draft needs to have a "Security Considerations" section. While general guidelines such as exist, the underlying threat model is that the endpoint is fully trusted (i.e., all software and hardware components in the device may access the keys). RATS has a primarily different threat model in the sense that only parts of the endpoint (called Attester) are trusted (i.e., only specific software and hardware components in the device may access the keys), and the goal is to establish the trustworthiness of the endpoint. In other words, deals with a network adversary, whereas RATS deals with an endpoint adversary, which may have root access or physical control over the device with which it can extract keys from software or hardware. Moreover, remote attestation has several distinguishing features that necessitate a separate document. One specific example of such a feature is the architectural complexity of the endpoint. While network protocols typically have 2 roles, RATS has additional roles, which complicates the picture. Unfortunately, no guidelines currently exist for remote attestation in RATS. This document aims to fill this gap.

Needs of the Target Audience of RATS Moreover, while the target audience of Internet Drafts is implementers, researchers, and protocol designers , RATS drafts generally do not fulfill these needs, in particular the needs of researchers and protocol designers. On the other hand, in our observation, implementers generally find it hard to relate the abstract concepts of RATS to the real-world systems. In general, implementers and protocol designers of RATS are thus left with little or no guidance.

Motivation Unverified protocol designs, imprecisely stated threat model and security goals have led to high and critical severity vulnerabilities related to remote attestation.

Concrete Motivational Example: Practical Exploits in Production Systems The formal analysis led to three orthogonal issues:

• Formal analysis found diversion attacks when unique hardware identifier is not included in Evidence. For technical details, please see the corresponding paper .
• Formal analysis of several production implementations of remote attestation led to the discovery of of CVSS 7.5 for relay attacks. For technical details, please see the corresponding paper .
• Further formal analysis of production implementation of remote attestation 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 precise threat model and formal analysis in the design of secure protocols to find subtle vulnerabilities, which could otherwise be missed. This draft aims to provide the baseline security considerations that other drafts can simply refer to.

Scope To improve the situation, this draft presents general security baseline that other drafts can simply point to, or guidelines or template that other drafts can use.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

General Hierarchy of Authentication Authentication is a term which is often ambiguous in RATS specifications. We propose general hierarchy of one-way authentication, which can help precisely state the intended level of authentication (in decreasing order):

• One-way injective agreement
• One-way non-injective agreement
• Aliveness

Recentness can be added to each of these levels of authentication. Details will be added in future versions.

Threat Modeling This section describes "What can go wrong?"

System Model See Section 4 of as an example.

Actors It has both legal and technical perspective.

Legal perspective

• Data subject is an identifiable natural person (as defined in Article 4 (1) of GDPR ).
• (Data) Controller (as defined in Article 4 (7) of GDPR ) manages and controls what happens with personal data of data subject.
• (Data) Processor (as defined in Article 4 (8) of GDPR ) performs data processing on behalf of the data controller.

Technical perspective

• Infrastucture Provider is a role which refers to the Processor in GDPR. An example of this role is a cloud service provider (CSP).

Threat Model See Section 6.1 of as an example.

Typical Security Goals See as an example.

Attacks Security considerations in RATS specifications need to clarify how the following attacks are avoided or mitigated:

(Evidence) Replay Attacks In this attack, a network or endpoint adversary -- with access to older Evidence -- can replay Evidence with stale Claims which no longer represent the actual state of the Attester, potentially resulting in exposure of confidential data . Replay of stale Evidence may be within the same connection or across multiple connections.

Diversion Attacks In this attack, a network adversary -- with Dolev-Yao capabilities and access (e.g., via Foreshadow ) to the attestation key of any machine in the world -- can redirect a connection intended for a specific Infrastructure Provider to the compromised machine, potentially resulting in exposure of confidential data . In the context of confidential computing and TLS as a transport protocol, we reported these attacks to the TLS WG in February 2025 . A formal proof is available for further research and development. Since reporting to TLS WG, these attacks have been practically exploited in TEE.fail, Wiretap.fail, and BadRAM.

Relay Attacks In this attack, a network or endpoint adversary -- with access to suitable binding material -- can relay an attestation request to a genuine Attester and present the genuine Evidence as its own, potentially resulting in impersonation of genuine Attester . Note that replay is about same Attester while relay attack is about different Attesters.

Concrete CVEs

Intra-handshake.fail presents relay attacks in early attestation. From a security perspective, one of the key decision factors is the candidate binding mechanism. The formal analysis 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 (aka early) 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 .

Potential Mitigations This section describes the countermeasures and their evaluation. To mitigate the above attacks, we propose post-handshake attestation. Post-handshake attestation avoids replay attacks by using a fresh attestation nonce. Moreover, considering TLS as the transport protocol, it avoids diversion and relay attacks by binding the Evidence to the underlying TLS connection, such as using Exported Keying Material (EKM) , as proposed in Section 9.2 of . and provide mechanisms for such bindings. Efforts for a formal proof of security of post-handshake attestation are ongoing.

Security Considerations All of this document is about security considerations.

IANA Considerations This document has no IANA actions.

References Normative References In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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) TU Dresden, Dresden, Germany Aalto University, Espoo, Finland Aalto University, Espoo, Finland ACM CVE 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. 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.

Acknowledgments The authors wish to thank Ira McDonald and Ivan Gudymenko for insightful discussions.

History -01

• Concrete text proposal for security and privacy considerations of multi-verifiers

-02

• Introduction and motivation
• Defined replay and relay attacks
• Added mitigations

-07

• Added CVEs

-08

• Explained architectural flaws