| Internet-Draft | TODO - Abbreviation | January 2026 |
| Sardar | Expires 18 July 2026 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://muhammad-usama-sardar.github.io/seat-intra-vs-post/draft-usama-seat-intra-vs-post.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-usama-seat-intra-vs-post/.¶
Discussion of this document takes place on the Secure Evidence and Attestation Transport Working Group mailing list (mailto:seat@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/seat. Subscribe at https://www.ietf.org/mailman/listinfo/seat/.¶
Source for this draft and an issue tracker can be found at https://github.com/muhammad-usama-sardar/seat-intra-vs-post.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 18 July 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Based on our extensive analysis of attested TLS [Tech-Concepts], we classify attested TLS into three main categories:¶
In pre-handshake attestation, the signing of Claims [Tech-Concepts] 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.¶
In this version, we analyze the three categories (without combinations) with a focus on the last two. 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 [Tech-Concepts].¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
We use terminology from [RFC9334] and [I-D.ietf-tls-rfc8446bis] slightly loosely (intentionally) for readability. Future versions will tighten it.¶
In addition, we define three temporal terms:¶
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 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.¶
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.¶
It avoids extra round trips for use cases which require remote attestation only once during Connection Establishment Time.¶
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.¶
To be made secure, it requires invasive changes in TLS protocol, as deep as key schedule and adding or modifying existing handshake messages [ID-Crisis].¶
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.¶
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.¶
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) [RFC9334] MUST not send any secure data until Evidence is successfully appraised.¶
In following subsections, we present the benefits and limitations of post-handshake attestation.¶
In general, it allows re-authentication and re-attestation without tearing down the connection.¶
Since all Claims are available at the time of post-handshake attestation (during Lifetime of Connection), it provides complete security posture of the Attester.¶
It does not require any change in TLS protocol.¶
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.¶
Since the signature in Evidence generation and verification of signatures during appraisal happen after Connection Establishment Time, there is no additional latency.¶
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).¶
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 [RFC9261]) 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.¶
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 include AI agents/agentic AI [I-D.jiang-seat-dynamic-attestation].¶
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.¶
[SEAT-Charter] 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 [MCR-LAKE]:¶
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.¶
Göran Selander observes [Goran-LAKE]:¶
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.¶
Prominent implementations of intra-handshake attestation are all vulnerable to relay attacks [RelayAttacks]. Some of them are abusing the extensions of TLS, such as SNI and ALPN, for conveyance of attestation nonce [RelayAttacks].¶
Google [Keith-STET-CCC], Microsoft [Stunes-vTPM-CCC], and SCONE [SoK-Attestation] are all using post-handshake attestation.¶
Most of the document is about security considerations. Also, Security Considerations of [RFC9334] and [I-D.ietf-tls-rfc8446bis] apply. In addition:¶
Pre-handshake attestation is vulnerable to replay [RA-TLS] and diversion [ID-Crisis] attacks.¶
Without significant changes to the TLS protocol: Intra-handshake attestation is vulnerable to diversion attacks [ID-Crisis]. It also does not bind the Evidence to the application traffic secrets, resulting in relay attacks [RelayAttacks].¶
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) [I-D.ietf-tls-rfc8446bis]. [RFC9261] and [RFC9266] provides mechanisms for such bindings.¶
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.¶
This document has no IANA actions.¶
We gratefully thank Peg Jones for review.¶
Pavel Nikonorov (GENXT / IIAP NAS RA) contributed text in Section 4.1.1 and Section 5.2.1.¶