]> Guidelines for Security Considerations of RATS TU Dresden
muhammad_usama.sardar@tu-dresden.de
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 topics that future versions will cover in more detail.
  • Corrections in published RATS RFCs
  • Security concerns in two RATS drafts
  • General security guidelines, baseline, or template for RATS
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.
Inaccuracies in Published RATS RFCs Unfortunately, many published RFCs of RATS provide inaccurate or ambiguous security and privacy considerations, which may lead to errors in design and implementation, and give a false sense of security. As an example, many proposed designs in are broken.
Aggregator in CoServ RATS has recently adopted , which has an ambiguous role Aggregator, for which -- in our assessment -- the authors have not yet provided a reasonable justification. To the best of our knowledge and understanding, a malicious Aggregator breaks the security of the RATS ecosystem and invalidates the formal proofs for RATS primitives. Surprisingly, during the three-week adoption call and one week discussion afterwards, one of the authors of the draft did not support adoption of the draft. Based on the above reasons, as researchers, we have genuine skepticism about this work. We request the authors to be transparent on this work and clarify the concerns raised at the adoption time (summarized to some extent in this draft). We will keep making good-faith attempts and requesting the authors to state the risks properly.
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 an outline of three topics that future versions will cover in more detail:
  • Corrections in published RATS RFCs , , and
  • Security concerns in one currently adopted RATS draft and one proposed for adoption RATS draft
  • 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.
Potential Mitigations This section describes the countermeasures and their evaluation. To mitigate the above attacks, we propose post-handshake attestation. We are not aware of any attacks on 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.
Examples of Specifications That Could Be Improved
RFC9334
Unprotected Evidence has:
A conveyance protocol that provides authentication and integrity protection can be used to convey Evidence that is otherwise unprotected (e.g., not signed).
Using a conveyance protocol that provides authentication and integrity protection, such as TLS 1.3 , to convey Evidence that is otherwise unprotected (e.g., not signed) undermines all security of remote attestation. Essentially, this breaks the chain up to the trust anchor (such as hardware manufacturer) for remote attestation. Hence, remote attestation effectively provides no protection in this case and the security guarantees are limited to those of the conveyance protocol only. In order to benefit from remote attestation, Evidence MUST be protected using dedicated keys chaining back to the trust anchor for remote attestation.
Missing definitions uses the term Conceptual Messages in capitalization without proper definition.
Missing Roles and Conceptual Messages
  • Identity Supplier and its corresponding conceptual message Identity are missing and need to be added to the architecture .
  • Attestation Challenge as conceptual message needs to be added to the architecture .
RFC9781 As argued above for RFC9334, security considerations in are essentially insufficient.
RFC9783 uses:
  • 3x epoch handle (with reference to and ) whereas RFC9334 never uses epoch handle at all!
  • 1x epoch ID with no reference and no explanation of how it is different from epoch handle
RFC9711
Inaccurate opinion has:
For attestation, the keys are associated with specific devices and are configured by device manufacturers.
The quoted text is inaccurate and just an opinion of the editors. It should preferably be removed from the RFC. For example, in SGX, the keys are not configured by the manufacturer alone. The platform owner can provide a random value called OWNER_EPOCH. For technical details and proposed text, see .
Inaccurate Privacy Considerations has:
The nonce claim is based on a value usually derived remotely (outside of the entity).
Attester-generated nonce does not provide any replay protection since the Attester can pre-generate an Evidence that might not reflect the actual system state, but a past one. See the attack trace for Attester-generated nonce at . For replay protection, nonce should always be derived remotely (for example, by the Relying Party).
Examples of Parts of Specifications That are Detrimental for Security We believe that the following parts of designs are detrimental for the RATS ecosystem and without proper security and privacy considerations, they put the community at risk.
Multi-Verifiers We believe this draft in its current form is doing disservice to the community by substantially degrading both the security and privacy of the systems, and not properly highlighting the security and privacy risks, and by implicitly promoting the blind trust in vendors. In summary:
  • From a security perspective, if one of the Verifiers breaks, it breaks the whole system.
  • From a privacy perspective, the current design also exposes Personally Identifiable Information (PII) to all the Verifiers.
Security Considerations What's important from the security standpoint is the TCB of the RP, and not the Attester. This is because it is the RP who has to make final trust decision, and not the Attester. Verifier is -- in any case -- in the TCB of RP. Say there are two Verifiers; how do they establish trust with each other? Who verifies the Verifier - Verifier attested TLS? Section 7.2 of falls apart on this. Hence, we believe the security considerations of multi-verifiers must say: Compared to a single verifier, the use of multi-verifiers increases security risks in terms of increasing the overall Trusted Computing Base (TCB) from the RP's perspective.
Privacy Considerations In addition to revealing the PII to the Lead Verifier (which say is kind of equivalent to monolithic verifier), the current proposal in draft reveals the PII to all those Component Verifiers as well. We believe the privacy considerations of multi-verifiers must say: Compared to a single verifier, the use of multi-verifiers may increase the privacy risks, as potentially sensitive information may be sent to multiple verifiers.
Open-source Besides, the rationale presented by the authors at meeting 124 -- appraisal policy being the intellectual property of the vendors -- breaks the open-source nature of RATS ecosystem. This requires blindly trusting the vendors and increases the attack surface.
Aggregator-based design Aggregator in is an explicit trust anchor and the addition of new trust anchor needs to have a strong justification. Having a malicious Aggregator in the design trivially breaks all the guarantees. It should be clarified how trust is established between Aggregator and Verifier in the context of Confidential Computing threat model. The fact that Aggregator has collective information of Reference Values Providers and Endorsers makes it a special target of attack, and thus a single point of failure. It increases security risks because Aggregator can be compromised independent of the Reference Values Providers and Endorsers. That is, even if Reference Values Providers and Endorsers are secure, the compromise of Aggregator breaks the security of the system. Moreover, if Aggregator is not running inside a TEE, it is relatively easy to compromise the secrets.
Security Considerations All of this document is about security considerations.
IANA Considerations This document has no IANA actions.
References Normative References Remote ATtestation procedureS (RATS) Architecture 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. A Concise Binary Object Representation (CBOR) Tag for Unprotected CBOR Web Token Claims Sets (UCCS) This document defines the Unprotected CWT Claims Set (UCCS), a data format for representing a CBOR Web Token (CWT) Claims Set without protecting it by a signature, Message Authentication Code (MAC), or encryption. UCCS enables the use of CWT claims in environments where protection is provided by other means, such as secure communication channels or trusted execution environments. This specification defines a CBOR tag for UCCS and describes the UCCS format, its encoding, and its processing considerations. It also discusses security implications of using unprotected claims sets. The Entity Attestation Token (EAT) An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. Arm's Platform Security Architecture (PSA) Attestation Token Arm's Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, along with open-source reference implementations, aimed at helping device makers and chip manufacturers integrate best-practice security into their products. Devices that comply with PSA can generate attestation tokens as described in this document, which serve as the foundation for various protocols, including secure provisioning and network access control. This document specifies the structure and semantics of the PSA attestation token. The PSA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes the claims used in an attestation token generated by PSA-compliant systems, how these claims are serialized for transmission, and how they are cryptographically protected. This Informational document is published as an Independent Submission to improve interoperability with Arm's architecture. It is not a standard nor a product of the IETF. Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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 The Transport Layer Security (TLS) Protocol Version 1.3 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 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Guidelines for Writing RFC Text on Security Considerations 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. Perspicuity of Attestation Mechanisms in Confidential Computing: Technical Concepts Perspicuity of Attestation Mechanisms in Confidential Computing: General Approach Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) (Text with EEA relevance) On the security of public key protocols Foreshadow Guidelines for Writing Cryptography Specifications 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. Remote Attestation with Multiple Verifiers Arm Ltd Huawei Technologies France S.A.S.U. Huawei Technologies France S.A.S.U. Fraunhofer SIT IETF RATS Architecture, defines the key role of a Verifier. In a complex system, this role needs to be performed by multiple Verfiers coordinating together to assess the full trustworthiness of an Attester. This document focuses on various topological patterns for a multiple Verifier system. It only covers the architectural aspects introduced by the Multi Verifier concept, which is neutral with regard to specific wire formats, encoding, transport mechanisms, or processing details. Concise Selector for Endorsements and Reference Values Arm Linaro Fraunhofer SIT Fujitsu AMD Alibaba Cloud In the Remote Attestation Procedures (RATS) architecture, Verifiers require Endorsements and Reference Values to assess the trustworthiness of Attesters. This document specifies the Concise Selector for Endorsements and Reference Values (CoSERV), a structured query/result format designed to facilitate the discovery and retrieval of these artifacts from various providers. CoSERV defines a query language and corresponding result structure using CDDL, which can be serialized in CBOR format, enabling efficient interoperability across diverse systems. Clarifications in draft-ietf-rats-eat Security considerations of remote attestation (RFC9334) Towards Validation of TLS 1.3 Formal Model and Vulnerabilities in Intel’s RA-TLS Protocol 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) Identity Crisis in Confidential Computing: Formal Analysis of Attested TLS TU Dresden, Dresden, Germany Aalto University, Espoo, Finland Aalto University, Espoo, Finland ACM Identity Crisis in Confidential Computing: Formal Analysis of Attested TLS Intra-handshake.fail (CVE-2026-33697): High-severity CVE in Attested TLS Intra-handshake.fail (CVE-2026-33697): High-severity CVE in Attested TLS CoCoS attested TLS is vulnerable to relay attacks via extracted ephemeral TLS keys CVE Impersonation attacks on protocol in draft-fossati-tls-attestation (Identity crisis in Attested TLS) for Confidential Computing The Transport Layer Security (TLS) Protocol Version 1.3 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. Exported Authenticators in TLS 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. Channel Bindings for TLS 1.3 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.
Acknowledgments The author wishes to thank Ira McDonald and Ivan Gudymenko for insightful discussions. The author also wishes to thank the authors of (in particular Thomas Fossati and Paul Howard) for several discussions, which unfortunately could not resolve the above concerns, and hence led to this draft.
History -01
  • Concrete text proposal for security and privacy considerations of multi-verifiers
-02
  • Introduction and motivation
  • Defined replay and relay attacks
  • Added mitigations