]> Intuit

yaronf.ietf@gmail.com

Arm Limited

Ionut.Mihalcea@arm.com

Arm Limited

Yogesh.Deshpande@arm.com

Linaro

thomas.fossati@linaro.org

Nokia

k.tirumaleswar_reddy@nokia.com

Security SEAT attestation RATS TLS 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 remote 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 TLS extension that enables the negotiation and 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. This extension has been designed to allow the peers to use any attestation technology, in any remote attestation topology, and to use them mutually. 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 SEAT Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Remote Attestation (RA) is the process by which an entity produces evidence about itself that another party can use to evaluate the trustworthiness of that entity. This document describes an extension to the TLS handshake that enables the binding of the TLS connection and its authentication key to a remote attestation session. This enables an attester, 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. This, in turn, allows for the implementation of authorization policies at the relying parties that are based on stronger security signals. Given the variety of deployed and emerging attestation technologies (e.g., , , ) this extension has been explicitly designed to be agnostic to the attestation formats. This is achieved by reusing the generic encapsulation defined in for transporting Evidence and Attestation Results payloads in the remoteAttestation extension. This specification provides both one-way (server-only) and mutual (client and server) authentication using traditional TLS authentication combined with attestation, and allows the attestation topologies at each peer to be independent of each other. The proposed design supports both background-check and passport topologies, as described in Sections and of . This is detailed in . The protocol we propose is implemented completely at the TLS level, resulting in several related advantages:

• Implementation is within a single system component.
• Security does not depend on application-level code, which tends to be less secure than widely shared infrastructure components.
• It is easier to reason about the application's security, since the peers' identities and security postures are known as soon as the handshake completes and the TLS connection is established.
• Application code does not need to change. At most, some configuration is needed, similar to the current use of certificate trust stores.

This document does not mandate any particular attestation technology.

Conventions and Terminology The reader is assumed to be familiar with the vocabulary and concepts defined in . The following terms are used in this document:

The terms "appraise" and "verify" are used with distinctive semantics throughout the document:

"Appraise" covers the act of checking the validity of Attestation Results or Evidence, as per , performed by Relying Parties and Verifiers respectively. "Verify" covers all other checks performed by the two TLS peers, intended to assess the correctness of the cryptographic and protocol operations of the TLS layer.

TLS Identity Key (TIK):

A cryptographic key used by one of the peers to authenticate itself during the TLS handshake. The protocol's security is critically dependent on the provenance, lifetime and protection properties of the TIK. The TIK MUST be the X.509 certificate's end entity key and is maintained and protected by the TEE.

TIK-C, TIK-S:

The TIK that identifies the client or the server, respectively.

TIK-C-ID, TIK-S-ID:

An identifier for TIK-C or respectively, TIK-S. This may be a fingerprint (cryptographic hash) of the public key, but other implementations are possible.

Attestation binder:

A cryptographic nonce value provided by the TLS stack to the TEE. It is used for binding attestation Evidence to a specific TLS handshake and for providing freshness.

Two-sided uniqueness:

The property that each peer independently contributes fresh nonces and key-exchange material to the handshake, so that neither peer alone can determine the transcript hash. The attestation binder derived from that transcript is therefore guaranteed to be unique to the specific connection, even if one of the peers is adversarial.

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.

Overview The basic functional goal is to link the authenticated key exchange of TLS with an interleaved remote attestation session in such a way that the key used to sign the handshake can be proven to be residing within the boundaries of an attested TEE. The requirement is that the attester can provide Evidence containing the security status of both the signing key and the platform that is hosting it. The associated security goal is to obtain such binding so that no replay, relay or splicing from an adversary is possible. The protocol's security relies on the verifiable binding between the TLS Identity Key, the specific TLS session and the platform state through attestation Evidence or Attestation Results conveyed in the CMW (Conceptual Message Wrapper) payload.

Authentication vs. Attestation The protocol combines platform attestation with X.509 certificate authentication. Attestation when used alone is vulnerable to identity spoofing attacks, in particular when zero-day attacks exist for a class of hardware. (TODO: reference). Therefore it needs to be combined with traditional authentication, which in the case of TLS takes the form of CA-signed certificates. We RECOMMEND that regular applications use authentication and attestation in tandem, to gain the full security guarantees of an authenticated TLS handshake (for the peer/peers being authenticated) as well as guarantees of platform integrity.

Integration into the TLS Handshake The lightweight integration of attestation into the TLS handshake is designed to have minimal impact on the existing TLS security properties. The changes consist of:

• Negotiation extension: A new remoteAttestation TLS extension is added to ClientHello, EncryptedExtensions, CertificateRequest, and Certificate messages to negotiate the use of attestation, indicate supported attestation formats and Verifiers, and carry the attestation credential.
• Independent key derivation: Binder derivation for attestation (see ) is completely independent of the regular TLS key schedule. Attestation processing does not affect the standard TLS key derivation and security properties.

This minimal integration approach provides an intuitive explanation of why the addition of attestation does not adversely affect TLS security. The attestation components operate independently, leaving the core TLS handshake protocol and key derivation mechanisms unmodified. Nevertheless, formal validation of these security properties is still required.

Attestation Extension As typical with new features in TLS, the client indicates support for the new extension in the ClientHello message. The newly introduced extension allows attestation Evidence or Attestation Results to be exchanged. Freshness of the exchanged Evidence is guaranteed through an Attestation Binder mechanism (see ) when the Background Check Model is in use. In the Passport Model, freshness expectations are more relaxed and are governed by the lifetime of the signed Attestation Results. When the extension is successfully negotiated, attestation Evidence or Attestation Results are conveyed in a remoteAttestation extension (see ). The CMW payload in the Attestation extension contains the attestation Evidence or Attestation Results encoded according to . The attestation payload MUST contain assertions relating to the attester's TLS Identity Key (TIK-C for client attester, TIK-S for server attester), which associate the private key with the attestation information. The TEE's signature over the Evidence within the CMW MUST include an attestation binder derived from the message transcript (see ) and the attester's TLS identity public key, as specified in . The relying party can obtain and appraise the remote Attestation Results either directly from the Attestation extension (in the Passport Model), or by relaying the Evidence from the Attestation extension to the Verifier and receiving the Attestation Results. Subsequent verification of possession of the attested key in the CertificateVerify message remains unchanged from baseline TLS. When using the Passport Model, the remote Attestation Results obtained by the attester from its trusted Verifier can be cached and used for any number of subsequent TLS handshakes, as long as the freshness policy requirements are satisfied. This protocol supports both monolithic and split implementations. In a monolithic implementation, the TLS stack is completely embedded within the TEE. In a split implementation, the TLS stack is located outside the TEE, but any private keys (and in particular, the TIK) only exist within the TEE. In order to support both options, only the TIK's identity, its public component and a short generated binder are ever passed between the Client or Server TLS stack and its Attestation Service. While the two types of implementations offer identical functionality, their security properties often differ, see for more details.

Remote Attestation Extension As defined in , the TLS Certificate message contains a certificate_list, which is a sequence of CertificateEntry structures. When attestation is negotiated via the extension defined in this document, the remoteAttestation extension defined in this document MUST appear only in the first CertificateEntry of the Certificate message and applies exclusively to the end-entity certificate. The extension MUST NOT appear in any other CertificateEntry. If the remoteAttestation extension is received in any other position, the receiver MUST abort the handshake with a fatal illegal_parameter alert. This message carries a CMW (Conceptual Message Wrapper) payload as defined in . The remoteAttestation extension structure is defined in . As per , a single extension is used across the entire handshake. The extension is used in ClientHello, EncryptedExtensions, and CertificateRequest messages for protocol negotiation (see ). The extension is used in Certificate messages for carrying attestation credentials.

TLS Extension Structure for Remote Attestation negotiation. ; }; } EvidenceType; struct { opaque verifier_identity<0..2^16-1>; } VerifierIdentityType; enum { evidence(0), result(1), (255) } AttestationMechanism; struct { AttestationMechanism mechanism; select (mechanism) { case evidence: EvidenceType; case result: VerifierIdentityType; } argument; } AttestationScheme; struct { select (Handshake.msg_type) { case client_hello: AttestationScheme server_attester_schemes<0..2^16-1>; AttestationScheme client_attester_schemes<0..2^16-1>; case encrypted_extensions: AttestationScheme chosen_server_scheme; case certificate_request: AttestationScheme chosen_client_scheme; case certificate: opaque cmw_payload<1..2^24-1>; }; } remoteAttestation; ]]>

The cmw_payload field contains a CMW structure as defined in . Both JSON and CBOR serializations are allowed in CMW, with the emitter choosing which serialization to use. The CMW payload MUST contain attestation Evidence (in Background Check Model) or Attestation Results (in Passport Model) that binds the TLS Identity Key (TIK) to the platform and workload state. The TEE's signature over the Evidence within the CMW MUST include a binder ensuring that the attestation is associated with this particular TLS connection, as well as the attester's TLS identity public key (TIK-C for client attester, TIK-S for server attester). This binding ensures that the attested key is the one used in the TLS handshake and provides freshness guarantees through derivation from both peers' randomness. See for details.

Use of Attestation in the TLS Handshake For both the Passport Model (described in Section 5.1 of ) and Background Check Model (described in Section 5.2 of ) the following modes of operation are allowed when used with TLS, namely:

• TLS client is the attester,
• TLS server is the attester, and
• TLS client and server mutually attest towards each other.

As noted, each peer's attestation is carried in the remoteAttestation extension within that peer's Certificate message. This section describes how the attestation is produced, bound to the TLS handshake and verified by the recipient.

Cryptographic Operations The cryptographic operations defined in this section bind attestation Evidence to a specific TLS handshake. This binding prevents replay and relay of attestation Evidence across different TLS connections, and ensures that attestation Evidence presented during a handshake corresponds to the authenticated TLS session in which it is conveyed. The attestation Evidence or Attestation Results are generated by a TEE and signed using an attestation key. The signed Evidence includes inputs originating from different trust domains. The attestation binder is provided by the TLS stack and serves as a nonce that ensures freshness and binding to a specific TLS handshake, as well as binding to the attester's TLS public key.

Attestation Binder Definition The attestation binder is computed using primitives defined in Sections and of . Both peers derive a single attestation base from the same transcript checkpoint through ServerHello. The transcript MUST be computed as Transcript-Hash through ServerHello, as defined in . When the handshake includes a HelloRetryRequest, the first ClientHello is not hashed as sent; the transcript uses the synthetic message_hash message specified in that section instead. TLS_Client_Public_Key and TLS_Server_Public_Key denote the DER-encoded SubjectPublicKeyInfo of the peer's end-entity certificate. Hash is the cipher suite hash function for the handshake (). We note that HKDF-Expand-Label is used to produce binding values rather than keying material. HKDF-Extract is not invoked, as there is no input key material to combine. The "0" parameter denotes a byte string of Hash.length zeroes. HKDF-Expand-Label is defined in , which builds on the HKDF construction ; its use here does not modify the TLS protocol or the TLS key schedule.

Verification Upon receipt of a remoteAttestation extension, the peer MUST compute the attestation binder. If the peer's Evidence is rejected (binder mismatch, failed Evidence appraisal, or malformed CMW), the receiver MUST send an attestation_failed fatal alert and abort the handshake (see ). Depending on the architecture (see also ), either the peer verifies the binding or else it delegates this responsibility to an external Verifier.

• In the former case, the peer MUST compare the computed binder value to the attestation binder included in the signed Evidence or signed Attestation Results. If the values do not match, the peer MUST treat the attestation as invalid.
• In the latter case, the RP MUST convey the binder to the Verifier. The Verifier MUST appraise that the conveyed binder is identical to the one that was signed in the Evidence or Attestation Results. If appraisal fails, the receiver MUST treat the attestation as invalid.

TODO: define a way to transport the binder to a remote Verifier. Possibly as a (new) conceptual message (CM) within a collection. This would provide the Verifier whatever information it cannot compute on its own, while not forcing the TLS stack to parse the Evidence.

Security Properties Binding attestation Evidence to the TLS handshake transcript hash provides the following security properties:

• Replay protection: Evidence generated for a previous handshake cannot be reused in a later handshake.
• Relay protection: Evidence obtained from one TLS connection cannot be successfully presented in a different TLS connection, even in the presence of a MiTM attacker.

In typical deployments where the TLS handshake executes outside the TEE, a compromised host can execute the TLS handshake in the rich operating system and use the TEE as a signing oracle by presenting the attestation binder value to obtain valid-looking attestation Evidence. However an endorsed TEE (one that is operating as required by this protocol) is required to verify the binder against the TLS public key associated with the private key that it holds. This verification, in conjunction with the TEE's endorsement being appraised, ensures that relay attacks are prevented. The attestation binder prevents replay of Evidence across TLS connections. The binding to the TLS identity key ensures that Evidence produced by one endpoint cannot be replayed in a TLS connection involving a different endpoint, as the verifier checks that the binder matches the public key presented in the current TLS connection. The additional binding to the transcript through ClientHello and ServerHello ensures that Evidence cannot be replayed across TLS connections, as ClientHello.random and ServerHello.random are independently generated by each peer for every TLS connection.

Binding the TIK to the TEE This specification assumes that the TIK private key corresponding to the end-entity certificate used in the TLS handshake is generated inside a TEE and never leaves it. A platform could instead generate the TIK private key outside the TEE and compute the CertificateVerify signature using that external key. A relying party cannot detect this attack unless additional safeguards are in place. This risk is particularly relevant in split deployments, where the TLS stack does not reside inside the TEE. In such architectures, attesting the TEE alone does not prove that the TIK private key used by the TLS endpoint was generated, is stored, or is controlled by the TEE. To address this, the signed Evidence MUST include an Attestation Binder generated using the hash of the TIK public key (TIK_pub_hash) (see ). The Relying Party MUST compute the hash of the TIK public key extracted from the TLS end-entity certificate using the same hash algorithm and verify that it matches the TIK_pub_hash included in the Evidence. Successful verification binds the attestation Evidence to the TLS identity used for authentication. This verification is performed by the Relying Party, as the Verifier may not be co-located with the Relying Party and may not have access to the TLS handshake or the TLS end-entity certificate, consistent with the RATS architecture. Alternatively, in deployments where the Verifier is not co-located with the Relying Party, the Relying Party MAY supply the Verifier with the hash of the TIK public key. The Verifier then compares this value with the TIK public key hash included in the Evidence. If the values do not match, the attestation MUST be considered invalid. Without this binding, a non-Target-Environment TLS endpoint can obtain Evidence from a separate TLS endpoint that runs inside a Target Environment and relay that Evidence to the relying party while executing the TLS handshake itself. If the Evidence only attests that a TLS stack is running in a Target Environment, the relying party cannot determine whether the attested TLS stack is the one that actually performed the handshake. Binding the Evidence to the TIK public key prevents this relay attack. The proposed binding ensures that the relying party does not establish a TLS session with a TLS endpoint whose TIK is not generated and controlled by the TEE. It does not - in and of itself - ensure security of the TLS stack when the stack is outside the TEE, and see for a further discussion.

The TLS Stack's Interface to the TEE When the TEE signs the Evidence or Attestation Results, it also binds them to the TLS Identity public key and the TLS session. TEE implementations differ, and some only allow a single user-provided challenge value to be added to the Evidence with no associated checks. Architecturally we propose to add a thin shim between the traditional TLS stack and the TEE as shown in . Implementations will choose whether to incorporate the shim into the TEE (making for a "smarter" TEE and better protection for the remote attestation protocol), or in case of a legacy TEE that cannot be modified, the shim can be added to the TLS stack.

TLS Stack Interface with the TEE

We adopt a defense-in-depth approach:

• Separate attesting applications within the same TEE SHOULD NOT be capable of impersonating each other via Evidence or Attestation Results. Therefore, if multiple applications are expected to use attestation credentials, evidence/AR generation APIs SHOULD reflect identifiers for the calling contexts into the generated credential. These identifiers can be reflected as separate claims in the credential, or can be measured as part of more generic claims. A Relying Party SHOULD be capable of differentiating between the attesting applications based on their credentials.
• The RP SHOULD NOT base its trust decision only on the Attester's trust root. It SHOULD also ensure that the entire attested software stack is endorsed.
• The TEE itself, when possible, SHOULD generate the attestation secret by running the derivation operations defined in , and, if it holds the TIK, SHOULD validate the public key. The attestation secret can be generated by the TEE only if TLS is running inside the TEE.
• As shown in the diagram, the TEE itself as well as the TLS stack and the shim SHOULD all be measured and reported as part of the platform's remote attestation.

Reattestation Attestation Evidence or Attestation Results may become stale over time. For long-lived TLS connections, a relying party may need fresh Evidence or Attestation Results to reassess the trustworthiness of the peer. Similarly to the initial handshake, Early Attestation implements reattestation at the TLS layer, using Extended Key Update (EKU) . This document defines a new ExtendedKeyUpdate subtype, attestation_update, which carries a cmw_payload as defined in . Reattestation is available only when EKU is also negotiated. Either peer MAY initiate EKU per its own policy. Each completed EKU exchange triggers reattestation: a peer that attested in the handshake MUST send attestation_update, using the scheme chosen in the handshake. A peer that did not attest during the handshake MUST NOT send attestation_update. Each peer waits for attestation_update only from a peer that attested in the handshake. The two attestation_update messages are independent; no order between them is required. This document extends ExtendedKeyUpdateType and ExtendedKeyUpdate () as follows: ; } }; } ExtendedKeyUpdate; ]]>

Reattestation after EKU (DTLS ACKs omitted) <-------- [EKU(key_update_response)]N [EKU(key_update_finish)]N --------> (EKU complete, N+1 in use) [EKU(attestation_update)]N+1* --------> <-------- [EKU(attestation_update)]N+1* * Sent only by a peer that attested in the handshake. ]]>

The attester sends attestation_update after the EKU exchange completes (Sections and of ), under the N+1 application traffic secrets, not the old keys (). After the EKU exchange completes, the relying party expects attestation_update from the attester. Each relying party sets a timeout, per local policy, for receiving attestation_update. On expiry, it aborts with a fatal attestation_required alert. If appraisal fails, it aborts with a fatal attestation_failed alert, as in . No message is sent on success. A peer that receives attestation_update from a peer that did not attest in the handshake, or before the EKU exchange completes, MUST abort with an unexpected_message alert. Reattestation does not block application data. Until the relying party completes appraisal of attestation_update or aborts with an alert, it continues to rely on the outcome of the previous successful appraisal. While reattestation is in progress, a peer MUST NOT initiate another EKU exchange or post-handshake client authentication (). Reattestation completes at the attester when it sends attestation_update (TLS) or receives the ACK for it (DTLS), and at the relying party when appraisal completes. If both peers are attesting, reattestation completes after both independent exchanges have completed. A relying party that receives key_update_request or CertificateRequest before its appraisal completes defers its response until appraisal completes (Sections and of , ). An attester that receives key_update_request or CertificateRequest before it has sent attestation_update MUST abort with an unexpected_message alert. The binder is derived as in , with Transcript-Hash(ClientHello...ServerHello) replaced by transcript_hash_N+1 (): transcript_hash_N+1 covers the initial handshake, all prior EKU exchanges, and the key shares of the current exchange. Each reattestation therefore uses a fresh binder.

Session Resumption This specification targets long-lived TLS connections that use post-handshake mechanisms, in particular Extended Key Update and reattestation (). Session resumption (including early data) is not supported with this protocol: requires endpoints that enable EKU to disable resumption using PSKs established via NewSessionTicket, and reattestation depends on EKU. Endpoints that negotiate remoteAttestation as defined in this document MUST NOT offer or accept session resumption for the connection. Fresh attestation on a new connection requires a full handshake as in . Establishing an initial connection with a pre-shared key alone, without that certificate-based attestation exchange, is not supported.

Negotiating This Protocol This section defines the TLS extension used to negotiate the use of attestation in the TLS handshake. Both remote attestation topologies are supported: the Background Check Model, where Evidence is exchanged and appraised during the handshake, and the Passport Model, where pre-appraised Evidence in the form of Attestation Results are presented. The extension defined in allows peers to indicate their support for attestation and negotiate which attestation format and, if required, which Verifier to use. The remoteAttestation extension structure contains indicators for both remote attestation topologies, and allows both peers to act as attesters independently during the handshake. The client selects the remote attestation schemes it supports for both server- or client-as-attester. The client MUST populate at least one AttestationScheme structure. The server replies with its preferred schemes for both server- and client-as-attester. The selected server-as-attester scheme is sent in the EncryptedExtensions message. While for Background Check the server scheme can be extracted from the CMW sent by the server as part of its Certificate message, for Passport model the Verifier which issued the Attestation Results must be confirmed by the server explicitly. In order to preserve symmetry and aid the client in handling the server's attestation token, the server explicitly sends its scheme as part of EncryptedExtensions. The selected client-as-attester scheme is sent in the CertificateRequest message. The server MUST omit the remoteAttestation extension from EncryptedExtensions and CertificateRequest messages if it does not support the corresponding proposed schemes, or if it does not want the corresponding peer to engage in remote attestation. The remoteAttestation extension used to negotiate support for the protocol described in this document is defined in . Values for media_type are defined in . Values for content_format are defined in . The verifier_identity field can be used to carry an identifier for a Verifier instance. The identifier needs to be stable across the lifetime of the connection (potentially across Verifier credential rotation), for example a subjectAltName.

Negotiation Integrity The remoteAttestation extension is negotiated by both peers. Finished is computed and verified by both peers over the complete handshake transcript. Tampering with the extension changes that transcript, causing Finished to fail. Negotiation downgrade is therefore already detected by TLS 1.3's existing transcript integrity.

TLS Client and Server Handshake Behavior The high-level message exchange in shows the remoteAttestation extension added to the ClientHello, the EncryptedExtensions, the CertificateRequest, and the Certificate messages.

Early Attestation Handshake Overview ServerHello ^ Key + key_share* | Exch + pre_shared_key* v {EncryptedExtensions} ^ Server + remoteAttestation* | Params {CertificateRequest*} | + remoteAttestation* v {Certificate*} ^ + remoteAttestation* | {CertificateVerify*} | Auth {Finished} v <-------- [Application Data*] ^ {Certificate*} | + remoteAttestation* Auth | {CertificateVerify*} v {Finished} --------> [Application Data] <-------> [Application Data] ]]>

Client Hello The remoteAttestation extension defined in enables the two peers to use either the Background Check Model or the Passport Model for remote attestation. To indicate support for either Evidence (for Background Check) or Attestation Results (for Passport), the client includes schemes with either evidence or result as the AttestationMechanism in the ClientHello extension. For Evidence, the scheme indicates the expected Evidence type. For Attestation Results, the scheme indicates the identity of the Verifier from which results can be relayed. In both cases, whether the scheme is sent as server_attester_schemes or client_attester_schemes indicates which peer is expected to produce the attestation credential. The remoteAttestation extension carries a list of supported schemes, sorted by preference. If the client only supports one attestation credential type, it is a list containing a single element. The client MUST omit schemes from the client_attester_schemes field in the extension if it cannot respond to a request from the server to present an attestation credential of the proposed type, or if the client is not configured to use the proposed scheme with the given server. If the client chooses to include client_attester_schemes, it MUST be capable of authenticating itself with a certificate. For the Background Check Model, the client MUST omit Evidence types from the server_attester_schemes field in the extension if it is not able to pass the Evidence type to a Verifier.

Server Hello If the server receives a ClientHello that contains the remoteAttestation extension, then three outcomes are possible:

• The server does not support the extension defined in this document. In this case, the server returns the EncryptedExtensions without the remoteAttestation extension.
• The server supports the extension defined in this document, but it does not have any remote attestation scheme in common with the client. Then, the server terminates the session with a fatal alert of type "unsupported_attestation_schemes".
• The server supports the extension defined in this document and has at least one remote attestation scheme in common with the client. In this case, the processing rules described below are followed.

The remoteAttestation extension in the ClientHello indicates the attestation schemes for both peers to act as relying parties. For schemes conveyed under server_attester_schemes the server is expected to act as an attester, while the client is the relying party. For schemes conveyed under client_attester_schemes the server is expected to act as a relying party, while the client is the attester. If the server chooses to attest itself, it MUST select one of the schemes provided by the client in server_attester_schemes. The server MUST then also include the remoteAttestation extension in the EncryptedExtensions message, and MUST include the chosen attestation scheme in the chosen_server_scheme. The server MUST populate the Certificate message extension according to its chosen scheme. If the server has chosen an evidence scheme, the signed Evidence contained in the CMW payload MUST include an Attestation Binder as a nonce value (see ) in the TEE's signature. Both schemes selected for chosen_server_scheme and chosen_client_scheme MUST be selected from the schemes provided in the remoteAttestation extension sent in the ClientHello. If both server_attester_schemes and client_attester_schemes are empty, or if the server does not want to proceed with remote attestation, the server MUST terminate the session as described above, with a fatal alert of type "unsupported_attestation_schemes".

Certificate Request If the server chooses to request that the client attests itself, it MUST select one of the schemes provided by the client in client_attester_schemes. The server MUST then also send a CertificateRequest message that includes the remoteAttestation extension (see ), and MUST include the chosen attestation scheme in chosen_client_scheme.

Following Server Hello Upon receipt of the EncryptedExtensions and potentially of the CertificateRequest messages, the client can verify that the server's choices are valid. The client MUST check that at least one remote attestation scheme was returned, and that the returned schemes were among the corresponding proposed lists. If the server has rejected that one peer act as an attester by not selecting a corresponding scheme, and the client's policy demands that the remote attestation take place, the client MUST terminate the session with a fatal alert of type "attestation_required". If the server has selected a valid chosen_client_scheme, the client MUST populate the Certificate message extension according to that scheme. If the server has chosen an evidence scheme for the client, the signed Evidence contained in the CMW payload MUST include an Attestation Binder as a nonce value (see ) in the TEE's signature.

Security Considerations

Relay Resistance A relay attack succeeds when Evidence produced in one TLS connection can be presented by a different party in another TLS connection. Preventing it requires that Evidence be bound to a value that is unique to the TLS connection in which it is conveyed, so that Evidence generated in any one connection cannot be replayed in any other. This mechanism meets that requirement by binding Evidence to the handshake transcript checkpoint ClientHello...ServerHello (see ), a value that is unique to each connection. The binding does not rely on the application traffic secrets, nor on any value exported from the completed handshake such as the Exported Keying Material (EKM; ). EKM is an equally valid per-connection anchor; the remainder of this section shows that binding to the transcript checkpoint and binding to EKM provide equivalent relay resistance. The two approaches differ only in which connection-unique value the Evidence is anchored to:

• A post-handshake binding anchors Evidence to EKM, a value that becomes available only after the handshake completes.
• The mechanism in this document anchors Evidence to Transcript-Hash(ClientHello...ServerHello).

Both anchors are unique per connection. The transcript checkpoint commits to both peers' fresh ephemeral key-exchange contributions, that is, the client's and server's key_share entries in the transcript (whether (EC)DHE public keys or a PQC KEM public key and ciphertext), as well as ClientHello.random and ServerHello.random. After a HelloRetryRequest, these are the values from the updated ClientHello and the ServerHello, as included in Transcript-Hash (). Because each peer independently contributes fresh material, neither peer alone controls the transcript, and the resulting binder is unique to the specific connection (two-sided uniqueness). The two constructions therefore offer equal relay resistance. The relay resistance of this mechanism does not depend on the transcript being secret. It relies instead on the attestation binder, which is unique to the connection and bound to the attester's TLS identity key, being carried in Evidence signed by the TEE (see and ); the confidentiality of ClientHello and ServerHello is not required. Although ClientHello and ServerHello are visible to an on-path observer, an eavesdropper cannot reuse them to complete a new TLS connection, as it does not know the ephemeral private keys behind the key shares they carry. Nor can the client or server reproduce an earlier transcript: each contributes fresh key-exchange material to every handshake, so every connection yields a different transcript, and therefore a different binder. The rationale for anchoring to the transcript rather than to an exporter value is given in .

Worked Example: Relay Attempt Under Handshake-Secret Compromise The server holds a TLS authentication key (the TIK), certified by a CA. The client truststore has the CA and verifies the end-entity certificate chains to it. The client checks that the public key in the end-entity certificate matches the TIK and relies on CertificateVerify for proof of possession. Each handshake also uses a fresh ephemeral (EC)DHE key share, carried in ClientHello/ServerHello, from which the connection secrets are derived. This example is deliberately generic; it will be updated in future revisions based on the outcome of confidential-computing-specific discussions. Suppose an attacker obtains a connection's handshake secret (or the ephemeral private key from which it is derived). The attacker can then derive that connection's handshake traffic secrets and decrypt the handshake, including the Evidence carried in the encrypted Certificate message. This compromises the confidentiality of that single connection. It does not let the attacker replay the Evidence in a different TLS session: the Evidence is bound to this connection's ClientHello...ServerHello transcript and to the TIK, and any other TLS connection uses fresh key shares, yielding a different transcript and a different binder. The exposed Evidence therefore does not match any other connection and is rejected. Consistent with TLS 1.3 forward secrecy, the impact is confined to the compromised session. illustrates this case.

Even having read the Evidence from connection 1, the attacker cannot reproduce connection 1's transcript on connection 2: the client contributes fresh randomness and key share, so the binder does not match and the handshake is aborted Server =======================| | CH_1 { CR_1, cks_1 } ------>| | |<----- SH_1 { SR_1, sks_1 } | | | T1 = Hash(CH_1..SH_1) | | |<----- {Certificate: E} | | | E bound to T1 | | | | attacker has obtained | | | connection 1's handshake | | | secret: decrypts conn 1 | | | and reads Evidence E | | | | |== Connection 2 : Client <-> Attacker (posing as server) ==| | CH_2 { CR_2, cks_2 } ----------------------------------->| | CR_2 != CR_1 , cks_2 != cks_1 | | (client contributes fresh values; attacker | | cannot control them) | | | |<---------------------- SH_2 { SR_1, sks_1 } | | attacker replays connection 1's server values | | to try to reproduce T1 | |<-------------------- {Certificate: replayed E (bound T1)} | | | | T2 = Hash(CH_2..SH_2) | | CH_2 != CH_1 => T2 != T1 | | client computes binder over T2 ; | | E is bound to T1 => binder mismatch | | | |<-------------------- >> attestation_failed << | | handshake aborted | | | ]]>

Key Substitution Resistance A peer may hold an authentication private key that was generated and protected within an Attesting Environment, but has since been compromised via a side-channel attack and imported into a second Attesting Environment. Channel binding as defined in does not prevent this, since it is not relay or replay of Evidence across connections, but Evidence from an Attesting Environment vouching for a key it did not generate. Preventing this requires Evidence to assert that the TIK was generated within the Attesting Environment, has never existed outside it, and is non-exportable, not merely that it is currently protected. defines this key-provenance property via the local and never-extractable key-attributes conveyed alongside the Subject Public Key, and it applies equally to intra-handshake and post-handshake attestation. These attributes are therefore only as trustworthy as that environment itself, as established by appraisal against applicable reference values and endorsements and by the trust anchor for the Attestation Key (). A summary of the security properties this mechanism provides is given in .

Evidence Confidentiality After Compromise The relay-resistance analysis in shows that Evidence exposed by a handshake-secret compromise cannot be relayed on a different connection. It says nothing about Evidence sent later on that same connection. Suppose an attacker obtains a connection's handshake secret, as in , and new Evidence is subsequently carried on that same connection (see ). If that Evidence is protected under a compromised handshake secret, the attacker decrypts it too. Preventing this requires Post-Compromise Security (PCS): new Evidence is sent only after the connection has moved to fresh traffic secrets, independent of the compromised one. provides this via Extended Key Update (EKU). Reattestation () sends new Evidence only after EKU completes.

Reattestation Freshness Each reattestation is bound to transcript_hash_N+1 of the EKU exchange that precedes it (see ). Evidence generated for an earlier generation does not match the current binder and is rejected.

Security Guarantees We note that as a pure cryptographic protocol, attested TLS as-is only guarantees that the Identity Key is known by the TEE. A number of additional guarantees must be provided by the platform and/or the TLS stack, and the overall security level depends on their existence and quality of assurance:

• The Identity Key is generated by the TEE.
• The Identity Key is never exported or leaked outside the TEE.
• The TLS protocol, whether implemented by the TEE or outside the TEE, is implemented correctly and (for example) does not leak any session key material.

These properties may be explicitly promised ("attested") by the platform, or they can be assured in other ways such as by providing source code, reproducible builds, formal verification etc. The exact mechanisms are out of scope of this document.

Freshness Guarantees Evidence appraised at handshake time reflects the Target Environment's state at that moment. Cases that can cause that appraisal to go stale without the Relying Party being aware include:

• The connection remains open and continues to carry data after the Target Environment's state has changed and no reattestation has occurred.
• Some Claims describe configuration state that can change at runtime without a reboot. If the Attesting Environment does not re-collect such a Claim before each attestation, it keeps asserting a stale value even after reattestation.

The Relying Party cannot observe the Target Environment directly and so has no way to detect that its state has changed. A Relying Party that needs assurance about current state applies local policy for how long an appraisal remains acceptable and requests attestation once that interval elapses, using the mechanism in . Session resumption is not used to carry forward an appraisal to a new connection (see ).

Privacy Considerations In this section, we are assuming that the Attester is a TLS client, representing an individual person. We are concerned about the potential leakage of privacy sensitive information about that person, such as the correlation of different connections initiated by them. In background-check mode, the Verifier not only has access to detailed information about the Attester's TCB through Evidence, but it also knows the exact time and the party with whom the secure channel establishment is attempted (i.e., the RP). The privacy implications are similar to online OCSP . While the RP may trust the Verifier not to disclose any information it receives, the same cannot be assumed for the Attester, which generally has no prior relationship with the Verifier. Some ways to address this include:

• Client-side redaction of privacy-sensitive evidence claims,
• Using selective disclosure (e.g., SD-JWT with EAT ),
• Co-locating the Verifier role with the RP,
• Utilizing privacy-preserving attestation schemes (e.g., DAA ), or
• Utilizing Attesters manufactured with group identities (e.g., ).

The latter two also have the property of hiding the peer's identity from the RP. Note that the equivalent of OCSP "stapling" involves using a passport topology where the Verifier's involvement is unrelated to the TLS session.

Server Attestation to Unauthenticated Clients Due to the inherent asymmetry of the TLS handshake, when the Attester acts as the TLS server it produces attestation before the client has authenticated. As a result, any unauthenticated client that completes the handshake can read the Claims carried in the server's Evidence, without its own trustworthiness first being established by the server. The following considerations bound the impact of this exposure and offer mitigations.

• Passport model with selective disclosure: In the Passport topology (), the server presents a Verifier-signed Attestation Result instead of the Evidence, so the Evidence never reaches the client. As the signer, the Verifier can issue this result in selectively-disclosable form (SD-CWT or SD-JWT ), letting the server reveal only a subset of Claims.

See for a broader treatment of privacy in the RATS context.

IANA Considerations

TLS Extensions IANA is asked to allocate a new TLS extension, remoteAttestation, from the "TLS ExtensionType Values" subregistry of the "Transport Layer Security (TLS) Extensions" registry . This extension is used in the ClientHello, EncryptedExtensions, CertificateRequest, and Certificate messages. The values carried in this extension are defined in .

TLS Alerts IANA is requested to allocate values in the "TLS Alerts" subregistry of the "Transport Layer Security (TLS) Parameters" registry and populate it with the following entries:

• Value: TBD1
• Description: unsupported_attestation_schemes
• DTLS-OK: Y
• Reference: [This document]
• Comment:
• Value: TBD2
• Description: attestation_required
• DTLS-OK: Y
• Reference: [This document]
• Comment:
• Value: TBD3
• Description: attestation_failed
• DTLS-OK: Y
• Reference: [This document]
• Comment:

TLS ExtendedKeyUpdate Message Subtypes IANA is requested to add the following entry to the "TLS ExtendedKeyUpdate Message Subtypes" registry established by :

• Value: TBD4
• Description: attestation_update
• DTLS-OK: Y
• Reference: [This document]

Acknowledgements We would like to thank Serhii Nikolaichuk for his implementation and review of this document. We would like to thank Paul Howard, Arto Niemi, and Hannes Tschofenig for their contributions to earlier versions of this document.

References Normative References 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 obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. Fraunhofer SIT Independent Linaro University of Applied Sciences Bonn-Rhein-Sieg Google LLC The Conceptual Messages introduced by the RATS architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during remote attestation procedures. Conceptual Messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of Conceptual Messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated CBOR tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. This allows CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts like X.509 certificates. Additionally, the draft defines a media type and a CoAP content format to transport CMWs over protocols like HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, evolving message serialization formats without breaking compatibility, and avoiding the need to redefine how messages are handled within each protocol. Siemens Münster Univ. of Applied Sciences Nokia Siemens Zscaler TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie- Hellman key exchange during the initial handshake, protecting past communications even if a party's long-term keys (typically a private key with a corresponding certificate) are later compromised. While the built-in KeyUpdate mechanism allows application traffic keys to be refreshed during a session, it does not incorporate fresh entropy from a new key exchange and therefore does not provide post- compromise security. This limitation can pose a security risk in long-lived sessions, such as those found in industrial IoT or telecommunications environments. To address this, this specification defines an extended key update mechanism that performs a fresh execution of the key exchange negotiated during the initial handshake within an active session, thereby ensuring post-compromise security. By forcing attackers to exfiltrate new key material repeatedly, this approach mitigates the risks associated with static key compromise. Regular renewal of session keys helps contain the impact of such compromises. The extension is applicable to both TLS 1.3 and DTLS 1.3. 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 This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912. 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. Intuit Arm Limited Arm Limited Arm Limited Huawei Linaro This draft has been withdrawn. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-fossati-tls-attestation/. Source for this draft and an issue tracker can be found at https://github.com/yaronf/draft-tls-attestation. Security Theory LLC Mediatek USA Qualcomm Technologies Inc. Red Hound Software, Inc. An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, 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 JSON Web Token (JWT) with attestation-oriented claims. Fraunhofer SIT University of Surrey University of Surrey Ubitech Microsoft This document maps the concept of Direct Anonymous Attestation (DAA) to the Remote Attestation Procedures (RATS) Architecture. The protocol entity DAA Issuer is introduced and its mapping with existing RATS roles in DAA protocol steps is specified. Authlete Keio University Ping Identity This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims. mesur.io Tradeverifyd Fraunhofer SIT This specification describes a data minimization technique for use with CBOR Web Tokens (CWTs). The approach is inspired by the Selective Disclosure JSON Web Token (SD-JWT), with changes to align with CBOR Object Signing and Encryption (COSE) and CWTs. Cryptic Forest Software University of the Bundeswehr Munich University of Applied Sciences Bonn-Rhein-Sieg This document extends the RATS Architecture to consider "coercive uses of RATS" where a malicious Verifier or Relying Party uses RATS protocols to extract sensitive information from an Attester or a victim Verifier that it would not otherwise be inclined to disclose. This over-disclosure can include revealing sensitive measurements, stable identifiers, device fingerprints, vendor information, or conclusions derived from Evidence. This document defines a privacy framework for Remote Attestation that identifies this threat surfaces; classifies claims produced by Attesters and Presenters; restricts sensitive Evidence disclosure to authorized Trusted Verifiers using confidentiality protection; and describes privacy- preserving Attestation Results based on data minimization, Selective Disclosure, and Zero-Knowledge Proofs. Broadcom Arm Limited Microsoft Amazon A Trusted Execution Environment (TEE) is an environment that enforces the following: any code within the environment cannot be tampered with, and any data used by such code cannot be read or tampered with by any code outside the environment. This architecture document discusses the motivation for designing and standardizing a protocol for managing the lifecycle of Trusted Applications running inside such a TEE. Nokia University of the Bundeswehr Munich Linaro Arm Limited Fraunhofer SIT This document defines an Entity Attestation Token (EAT) profile and a new EAT claim that convey the subject public key and its protection properties within attestation evidence. Combined with protocol-level proof of possession from the surrounding protocol, this establishes a cryptographic binding between a private key and an attested execution environment. The subject public key is conveyed using the EAT cnf claim defined in [RFC8747] and [RFC7800], and freshness uses the EAT eat_nonce claim defined in [RFC9711]. The proof of possession of the subject key is obtained from the surrounding protocol, such as TLS certificate-based authentication or CSR signature verification. Because the EAT is signed by a hardware-backed Attestation Key (AK), successful verification of the EAT signature together with protocol-level proof of possession establishes a cryptographic binding between the private key and the attested platform state. This mechanism addresses key substitution attacks that arise when attestation evidence and the certificate private keys are validated independently. This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. Trusted Computing Group Trusted Computing Group IANA IANA IANA IANA This document specifies new identifiers and a challenge for the Automated Certificate Management Environment (ACME) protocol which allows validating the identity of a device using attestation. Trusted Computing Group

Document History

draft-fossati-seat-early-attestation-08

• Defined reattestation using Extended Key Update; removed other reattestation options. Appraisal failure is signalled with the attestation_failed alert.
• Defined attestation_update wire format and message flow; reattestation does not block application data.
• Added .
• Added : session resumption (and early data) not supported since it conflicts with EKU.

draft-fossati-seat-early-attestation-07

• Added relay resistance and key substitution resistance into separate sections.
• Added (Post-Compromise Security via EKU).
• Added .
• Filled in (was a TODO).
• Added .
• Adopted RFC 9334 terminology (Attesting Environment).
• Scoped to certificate-based auth; corrected to CertificateVerify.
• Reframed .

draft-fossati-seat-early-attestation-06

• Add a Security Considerations subsection on relay resistance, showing that transcript binding (ClientHello...ServerHello) and EKM binding offer equal relay resistance (see ).
• Expand Privacy Considerations to cover server attestation to unauthenticated clients, with mitigations (selective disclosure via SD-CWT, and the Passport model) (see ).
• Add an appendix with the design rationale for anchoring the binder to the transcript rather than to an exporter secret (see ).
• Add an appendix noting that the ClientHello...ServerHello transcript can be computed using existing TLS-stack APIs, requiring no new interface (see ).
• Clarify that HKDF-Expand-Label is the TLS 1.3 wrapper over HKDF-Expand () and that its use does not modify the TLS protocol or the key schedule.

draft-fossati-seat-early-attestation-05

• Change extension model to a single remoteAttestation extension that covers all handshake messages which need extending.

draft-fossati-seat-early-attestation-04

• Register the attestation_failed alert for Evidence verification failure after the attestation extension is processed; clarify roles of the three attestation-related alerts in .
• Hash TLS public keys in HKDF-Expand-Label context so HkdfLabel stays within the 255-octet limit (post-quantum public keys); see .
• Simplify attestation binder derivation to a single shared transcript checkpoint (ClientHello...ServerHello) for both peers (see ).
• Replaced Derive-Secret with HKDF-Expand-Label

draft-fossati-seat-early-attestation-03

• Replace the Attestation message by an Attestation (certificate) extension, to bring this protocol within the requirements of the SEAT charter.
• Define the attestation binder and decouple it from the TLS key schedule.
• List multiple design options for reattestation.
• Add architecture diagram for TLS stack interface with the TEE.
• Add defense-in-depth guidance for measuring TEE, TLS stack, and shim.
• Remove various outdated sections.

draft-fossati-seat-early-attestation-02

• Fix typo in key schedule. Clarify (again) that this is only adding to the schedule, not modifying any existing key derivations.

draft-fossati-seat-early-attestation-01 (Submitted by mistake.)

draft-fossati-seat-early-attestation-00 Initial version of draft-fossati-seat-early-attestation. This version represents a major architectural change from . The key changes include:

• Removed certificate extension mechanism for conveying attestation Evidence
• Introduced new Attestation handshake message for carrying CMW (Conceptual Message Wrapper) payload
• Attestation message sent after CertificateVerify when server is attester
• Attestation message sent after CertificateVerify message when client is attester
• Removed use cases section
• Removed KAT (Key Attestation Token) and PAT (Platform Attestation Token) references, using CMW directly
• Nonces (client and server) and attester's TLS identity public key are included in TEE-signed Evidence/AttestationResults within CMW
• CertificateVerify remains unchanged from baseline TLS (no proof-of-possession needed)
• Added session resumption discussion (resumption MUST be rejected if reattestation is required per local policy)
• Added reattestation

Design Rationale: Why the Transcript and Not the Exporter establishes that binding to the ClientHello...ServerHello transcript checkpoint and binding to an exported value (EKM) offers two independent methods to provide equal relay resistance. This appendix discusses the rationale behind anchoring the attestation binder to the transcript rather than to an exporter secret.

• Attestation happens during the handshake. When Evidence is produced and bound as part of the handshake, EKM does not yet exist: it is derived only after the handshake completes. Evidence produced during the handshake therefore cannot be anchored to EKM.
• TLS 1.3 defines an early_exporter_secret (), which is available earlier. However, it is only meaningful when a PSK is in use. With no PSK, the Early Secret is HKDF-Extract(0, 0), so the early_exporter_secret has no secret input; moreover, it is derived from the ClientHello alone and carries no contribution from the server side of the handshake. It therefore does not provide the two-sided uniqueness () the binder requires.

Design Rationale: Why Extended Key Update for Reattestation

• Post-handshake authentication () is client-only. TLS has no post-handshake server authentication.
• Reattestation without a key update sends Evidence under traffic secrets that may be compromised (). EKU moves the connection to fresh secrets first.
• Exported Authenticators operate at the application layer, while this document keeps attestation within TLS.

Computing the Handshake Transcript with Existing TLS APIs The attestation binder is computed over Transcript-Hash(ClientHello...ServerHello) (see ), using the transcript hash defined in (including HelloRetryRequest handling). Where the TLS stack exposes its handshake transcript hash at the ServerHello checkpoint, implementations use that value. Where it exposes only the handshake messages, for example through a message callback, the transcript can be rebuilt from them; the message_hash substitution MUST then be applied after a HelloRetryRequest, because concatenating the messages as sent does not give the transcript hash.

Summary of Security Properties This appendix summarizes the security properties relevant to binding attestation to the TLS handshake. Transcript integrity and cryptographic binding: While a MiTM can intercept the TLS handshake and replay arbitrary messages (including fake key shares, copied certificates, or spoofed Evidence), it cannot complete the TLS connection. The TLS peer's private key signs the handshake transcript via CertificateVerify. Because substituting key shares alters that transcript, a MiTM lacking the peer's private key cannot produce a valid signature over the tampered transcript or derive the correct Finished MAC, so the peer rejects the connection. Explicit key confirmation: Although the Certificate message is evaluated before the Finished MAC, TLS 1.3 enforces explicit key confirmation via the Finished MAC over the complete handshake transcript before the connection is established. No application data is exchanged until key confirmation succeeds, so a failed confirmation aborts the connection regardless of the earlier Certificate and Evidence processing. TLS connection uniqueness and replay resistance: As established in , TLS 1.3 generates fresh ephemeral key shares for every connection, and the signed attestation Evidence is bound, via the handshake transcript, to the connection's ephemeral key shares. The Evidence also binds the attester's public key used in the end-entity certificate for authentication (). Evidence is therefore bound to a single connection and to the identity key used in that handshake: an attacker cannot replay Evidence from a past connection, because the key share in the new handshake will not match the key bound in the old Evidence. Forward secrecy: Forward secrecy is inherited from TLS 1.3 and is not a property added by this mechanism. Because TLS 1.3 mandates ephemeral key exchange, compromise of a long-term authentication key does not compromise past session keys: an attacker cannot recompute past shared secrets or tamper with past encrypted handshake transcripts. Hardware-enforced execution isolation: This property is provided by the platform, not by this mechanism. When the target environment runs only measured, appraised code, isolation prevents an attacker from running arbitrary code inside it to make the TEE attest a key that was not generated locally within the environment and could be exported from it. Its strength depends on the platform's isolation and measurement assurances (see ), which are the subject of work in the RATS working group.