]> Pre-, Intra- and Post-handshake Attestation TU Dresden
muhammad_usama.sardar@tu-dresden.de
Security Secure Evidence and Attestation Transport remote attestation TLS 1.3 attested TLS This document presents a taxonomy of extending TLS protocol with remote attestation, referred to as attested TLS. It also presents high-level analysis of benefits and limitations of each category, namely pre-handshake attestation, intra-handshake attestation and post-handshake attestation. 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 Secure Evidence and Attestation Transport Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .
Introduction Based on our extensive analysis of attested TLS , we classify attested TLS into three main categories:
  • pre-handshake attestation,
  • intra-handshake attestation, and
  • post-handshake attestation.
In pre-handshake attestation, the signing of Claims precedes the TLS handshake, while post-handshake attestation applies the reverse. Intra-handshake attestation requires the signing of Claims to be done within the TLS handshake protocol.
Scope In this version, we analyze the three categories (without combinations) with a focus on the last two, i.e., intra-handshake attestation and post-handshake attestation. The current scope of this draft is existing specifications and real-world implementations pointed in the given references. Any theoretical solutions are currently out of scope until some specification or implementation emerges. For simplicity, we consider simple Attester with only one Attesting Environment and only one Target Environment . That is, complicated scenarios such as Composite Device etc. are out of scope in this version. From RATS perspective, we consider Background Check Model . Future versions will add Passport Model . From TLS perspective, the scope is limited to TLS 1.3 as per . That is, older versions of TLS are explicitly out of scope.
Note Regarding remote attestation, we note that:
Remote attestation provides guarantees about the state of Attester only at the time at which signing of Claims is done to generate Evidence .
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. We use terminology from and slightly loosely (intentionally) for readability. Future versions will tighten it. In addition, we define three temporal terms:
  • Evidence Generation Time: Time when Evidence is generated (more specifically when Claims are signed)
  • Connection Establishment Time: Time at which TLS handshake is performed
  • Lifetime of Connection: Time period starting from Evidence Generation Time until the connection exists.
Pre-handshake Attestation Since the Evidence Generation Time could be at any arbitrary point of time in the past compared to the connection establishment time, pre-handshake attestation provides no guarantees about the state of Attester at the Evidence Generation Time and during the Lifetime of Connection.
Intra-handshake Attestation Intra-handshake attestation improves the situation where Evidence Generation Time is the same as Connection Establishment Time. In following subsections, we present the benefits and limitations of intra-handshake attestation.
Benefits
No Additional Application-Level Protocol Intra-handshake attestation does not require a new application-layer protocol or message exchange. Evidence and related metadata are conveyed within handshake via TLS extensions. TLS is responsible for conveyance of the Evidence; it does not perform appraisal of Evidence or authorization. Appraisal of Evidence, policy evaluation, and trust decisions are performed by application-level components that consume the attestation properties exposed by the TLS stack. As a result, while no new application-layer protocol is required, applications do incorporate additional trust logic to interpret attested connection properties and make security-relevant decisions.
Avoid Extra Round Trips for One-time Attestation It is claimed that intra-handshake attestation avoids extra round trips for use cases which require remote attestation only once during Connection Establishment Time. However, this may only be valid in cases when the Connection Establishment Time without remote attestation is significantly higher than the time for generation and appraisal of Evidence. For instance, Markus Rudy shares his practical experience :
I don't think saving extra roundtrips is an appropriate design goal when attestation is required. Generating evidence alone takes much longer than normal network roundtrip times, not even speaking of verification.
Our experiments also support his practical experience. In our experience, the generation of Evidence for Infineon Optiga SLB 9670, a discrete hardware TPM (dTPM) implementing TPM 2.0, takes around 210 ms. In our experience, the generation of Evidence for AMD SEV-SNP takes around 6 ms.
Limitations
Limited Claims Availability Since limited Claims are available at the Evidence Generation Time, it does not provide complete security posture of the Attester, such as runtime integrity of Attester.
Invasive Changes in TLS To be made secure, it requires invasive changes in TLS protocol, as deep as key schedule and adding or modifying existing handshake messages .
State After Connection Establishment Not Covered It provides no guarantees about the state of Attester during the lifetime of connection. This is a security concern in long-lived connections where state of Attester may change after Connection Establishment Time. Note that session resumption is a new connection .
High Handshake Latency Because of signature in Evidence generation and verification of signatures during appraisal, this leads to high handshake latency. This may not be desirable for some applications. Markus Rudy shares his practical experience :
Conveying the evidence is not enough, it needs to be verified as well in order to end up with a trustworthy channel. We decided to integrate verification into the handshake, too, but that has massive drawbacks: Verification can take orders of magnitude longer than normal TLS handshakes, and usually involves remote calls, affecting all sorts of timeouts. However, doing the verification at the application level would require forwarding information from the handshake (e.g. nonce), at which point the application needs to be fully aware of the handshake protocol in order to verify it, breaking the intended layering.
Maturity of TEEs With several attacks (see ), attestation in TEEs may not yet be mature enough to be integrated within TLS handshake. Ayoub Benaissa remarks :
TLS might not be well suited to include this in its protocol. Not sure TEEs are even as mature for the people to see that it should be included right now. The plan to make it a post-handshake protocol makes more sense right now. A future where it's incorporated into TLS might exist, but I don't think there is enough motivation right now.
Amount of Effort Markus Rudy shares his practical experience :
"Keeping attestation out of the application logic" is not as straightforward as it sounds. In the background-check model, the attester needs to collect evidence in response to the relying party's challenge (nonce). We were lucky that the Golang TLS stack can be supplied with arbitrary closures that are called during the handshake, but in my experience this is a rare design choice and may also be difficult to implement in other languages.
Ayoub Benaissa remarks :
An intra-handshake requires much more work compared to a post-handshake. People need to agree on how to add this as optional in TLS (we can't force everyone to use it of course), the standard needs to be implemented by major libraries, and then it will be available in major client/server applications. If any of the prior steps doesn't go through, it means you have to patch your components to make it work, which is not convenient / less secure.
Difficulty of Debugging Attestation Markus Rudy shares his practical experience :
There's only so much information in a TLS alert message, and it's definitely not enough to understand remote verification failures. While I understand this to be a deliberate design choice by TLS, I found this to be a hindrance for operating and debugging a large number of services in practice.
Post-handshake Attestation Post-handshake attestation improves the situation further by signing the Claims during Lifetime of Connection, i.e., at the time when it is actually required. Hence, together with use cases requiring one-time attestation, it covers the use cases of long-lived connections requiring re-attestation. For post-handshake attestation, first round of remote attestation MUST be done immediately after Connection Establishment Time, and Relying Party (RP) MUST not send any secure data until Evidence is successfully appraised. In following subsections, we present the benefits and limitations of post-handshake attestation.
Benefits In general, it allows re-authentication and re-attestation without tearing down the connection.
Full Claims Availability Since all Claims are available at the time of post-handshake attestation (during Lifetime of Connection), it provides complete security posture of the Attester.
No Change in TLS It does not require any change in TLS protocol.
State After Connection Establishment Is Covered It provides guarantees about the state of Attester during the Lifetime of Connection. This is particularly helpful in long-lived connections where state of Attester may change after Connection Establishment Time.
Standard Handshake Latency Since the signature in Evidence generation and verification of signatures during appraisal happen after Connection Establishment Time, there is no additional latency.
Avoid Extra Round Trips Except for first round of remote attestation, post-handshake attestation outperforms the intra-handshake attestation (one round trip), which requires re-establishing the connection (1.5 round trip).
Ease of Implementation Ayoub Benaissa remarks :
We already implemented a post-handshake protocol and have a full demo working. We were able to do this in a matter of weeks. That's because you don't need to modify any TLS implementation, but only add a few verification steps after the usual TLS handshake. This is almost the same on the client and server side.
Ease of Verification and Audit Post-handshake attestation has relatively easier formal analysis and verification. The same may apply to audit. Markus Rudy remarks :
(Formal) verification of a protocol and audit of its implementations might be much easier if it ran on top of TLS. Existing proofs and certifications would not need to be reevaluated.
General Solution for Other Protocols In post-handshake attestation, design, verification and audit effort will be one-time and any protocol (e.g., Noise) which has support for exporters can then use it without changing each and every protocol. Markus Rudy shares this requirement :
It should be possible to port the general shape of a post-handshake attested TLS protocol to other protocols that provide secure channels and session binding (Noise comes to mind).
Limitations
Impact on Application Layer Post-handshake attestation may require changes at the application layer. However, changes at the application layer do not necessarily imply modifications to application business logic or data exchange protocols. Attestation-related functionality may be realized via application-level signalling (Exported Authenticators ) and trust logic, which may be implemented in intermediary components (e.g., proxies, sidecars, or middleware) on both client and server sides. These components are responsible for exchanging and appraising attestation evidence and enforcing trust or authorization decisions before application data is processed. This is analogous to common production deployments in which TLS termination and certificate handling are performed by a fronting proxy, while the application itself remains unchanged and resides behind it.
Need for Post-handshake Attestation We argue that post-handshake attestation is unavoidable (e.g., re-attestation to track changes after Connection Establishment Time for long-lived connections). Use cases where pre-handshake attestation and intra-handshake attestation are insufficient include AI agents/agentic AI . Intra-handshake attestation only adds unnecessary complexity which is avoidable. All use cases of intra-handshake attestation can be covered by post-handshake attestation (by doing attestation round immediately after Connection Establishment Time) but not the other way around.
IoT Constraints includes TLS client as RATS Attester. Client could be a low-power IoT device. There are use cases where periodic or on-demand attestation is required, such as periodic attestation for long-lived, low-power IoT devices or in IoT swarms that need to synchronize software versions before coordinated operations or after configuration updates. Moreover, we note some observations from LAKE WG: Michael Richardson shares his insight :
I have a half-written document on putting EAT into the full BRSKI protocol. A reason that I stopped is that I realized that doing security posture evaluation at onboarding time (only) wasn't enough. It has to be done regularly. So having a protocol used at onboarding time and another one during normal operation meant that the onboarding one would have bugs that never get fixed, since the code only runs once.
He further shares :
My contention, which I think the group agreed with, is that one probably wants to do continuous assurance, that is, to repeat the remote attestation.
Do you want to have two protocols and two code paths? (redundant code in a constrained device?). I suggested that maybe the remote attestation should use it's own /.well-known Path, and that it would just occur after onboarding, and regularly onwards. Maybe it's weird to onboard a device only to kick it out again immediately because it failed remote attestation, but given continuous assurance, this could happen at any time.
Göran Selander observes :
Indeed, if the authentication procedure is repeated at a later stage, for whatever reason, e.g. key rotation, it should be possible to repeat the attestation procedure.
Existing Implementations
Intra-handshake Attestation Prominent implementations of intra-handshake attestation are all vulnerable to relay attacks . Some of them are abusing the extensions of TLS, such as SNI and ALPN, for conveyance of attestation nonce .
Post-handshake Attestation Google , Microsoft , and SCONE are all using post-handshake attestation.
Security Considerations Most of the document is about security considerations. Also, Security Considerations of and apply. In addition:
  • Pre-handshake attestation is vulnerable to replay and diversion attacks. Moreover, pre-handshake attestation leads to a single point of failure.
  • Without significant changes to the TLS protocol: Intra-handshake attestation is vulnerable to diversion attacks . We reported these attacks to 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. More recently, we found that intra-handshake attestation also does not bind the Evidence to the application traffic secrets, resulting in relay attacks .
  • No attacks on post-handshake attestation are currently known. Post-handshake attestation avoids replay attacks by using fresh attestation nonce. Moreover, 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.
Exploit of Sensitive Hardware-level Information From the view of the TLS server, post-handshake attestation offers better security than intra-handshake attestation when the server acts as the Attester. In intra-handshake attestation, due to the inherent asymmetry of the TLS protocol, a malicious TLS client could potentially retrieve sensitive hardware-level information from the Evidence without the client's trustworthiness (i.e., authentication) first being established by the server. This information (e.g., vulnerable firmware version) can be exploited for attacks. In post-handshake attestation, the server can ask for client authentication and only send the Evidence after successful client authentication.
IANA Considerations This document has no IANA actions.
References Normative References 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 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. 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. Perspicuity of Attestation Mechanisms in Confidential Computing: Technical Concepts 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. Identity Crisis in Confidential Computing: Formal Analysis of Attested TLS Towards Validation of TLS 1.3 Formal Model and Vulnerabilities in Intel's RA-TLS Protocol Relay Attacks in Intra-handshake Attestation for Confidential Agentic AI Systems Dynamic Attestation for AI Agent Communication This document describes a use case for conveying remote attestation information in association with Transport Layer Security (TLS) sessions in the context of AI agent communication. It focuses on long-lived secure channel sessions where an AI agent runtime posture, covering the platform Trusted Computing Base (TCB), agent manifest (models, tools and policies) and committed runtime context, can change frequently and unpredictably. The document highlights requirements for dynamic attestation so that relying parties can base authorization decisions on the current runtime posture of the communicating agent. Secure Evidence and Attestation Transport (SEAT): Charter for Working Group Re: Comments for remote attestation over EDHOC Evaluation of attestation results by EDHOC clients Re: Comments for remote attestation over EDHOC Split-Trust Encryption Tool Attested Session Handling Azure vTPM Attestation and Binding SoK: Attestation in Confidential Computing Re: New Version Notification for draft-usama-seat-intra-vs-post-00.txt Re: New Version Notification for draft-usama-seat-intra-vs-post-00.txt Impersonation attacks on protocol in draft-fossati-tls-attestation (Identity crisis in Attested TLS) for Confidential Computing Identity Crisis in Confidential Computing: Formal analysis of attested TLS protocols
Acknowledgments We gratefully thank the following:
  • Peg Jones for review of early draft before submission
  • Paul Wouters for review of section 4 of -00
  • Ayoub Benaissa for review of -00 and sharing his practical experiences
  • Markus Rudy for review of -00 and sharing his practical experiences
Contributors Pavel Nikonorov (GENXT / IIAP NAS RA) contributed text in and .
History -01
  • Added scope section to address comments of Paul Wouters
  • Added comments of Ayoub Benaissa as quotes
  • Added some subsections to incorporate practical experiences of Markus Rudy
  • Extended security considerations