]> Intra-handshake (aka Early) Attestation Considered Harmful (CVE-2026-33697 of CVSS 7.5 and several other CVEs of up to expected CVSS 9.8 upcoming) TU Dresden, Germany
muhammad_usama.sardar@tu-dresden.de
CoreWeave
slava@dubeyko.com
Shanghai Guan An Information Technology Co., Ltd., China
bluedognull@gmail.com
Independent
aurestarnull@gmail.com
Shanghai Guan An Information Technology Co., Ltd., China
havan12050544@gmail.com
Switch
kaya.ercihan@switch.ch
Independent, Netherlands
evac.m.willems@proton.me
PHI-OMEGA
phiomega.runtime@gmail.com
EMILIA Protocol, Inc.
team@emiliaprotocol.ai
SEAT AI agents Intra-handshake attestation CVE-2026-33697 The draft aims to provide technical details of CVE-2026-33697, EUVD-2026-16488, and several GitHub Security Advisories (GHSAs) which provide substantial technical evidence of how intra-handshake (aka early) attestation fails in practice, even without physical access. Moreover, since continuous attestation is generally required, intra-handshake attestation adds unnecessary complexity. The results are backed by the research , and the artifacts in state-of-the-art formal analysis tool, ProVerif, under Apache-2.0 license for reproducibility and review, and have been acknowledged by the relevant stakeholders. Currently, there are two CVEs of CVSS 7.5, two GHSAs of CVSS 9.1, one GHSA of CVSS 7.8, seven GHSAs of CVSS 7.4, and one GHSA of CVSS 6.3 published against intra-handshake (aka early) attestation. The research papers on these are currently either under submission or being prepared for submission. The artifacts of these papers will be shared with the community under Apache-2.0 license for reproducibility and review. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .
Introduction presents a general approach to analyze the intra-handshake (aka early) attestation proposals, regardless of whether they are within the scope of SEAT charter or not. From a security perspective, one of the key decision factors is the candidate binding mechanism. Some binding mechanisms are within scope of SEAT charter and others are not. The artifacts are available in under Apache-2.0 license for reproducibility, extensibility and further research. A complementary paper presents the identity crisis in pre- and intra-handshake attestation. The formal analysis is available in under Apache-2.0 license for reproducibility and extensibility. Another complementary paper -- currently under submission -- performs a thorough formal analysis of the design options in intra-handshake attestation.
Overview presents the formal specification and analysis of the candidate binding mechanisms for binding in intra-handshake attestation for standardization for attested TLS protocols: Binding mechanisms, implementations and ProVerif artifacts
No. Binding mechanism Used in Artifacts
1. Client’s TLS nonce - binder1
2. Client’s attestation nonce - binder2
3. Early exporter - binder3
4. Server’s public key - binder4
5. Combination of #2 and #3 - binder5
6. Combination of #2 and #4 Edgeless Systems Contrast; Cocos AI v0.8.2; CCC Attestation SIG's adopted project intra-handshake attestation; Meta's AI updated spec binder6
7. Combination of #2, #3, and #4 binder7
We responsibly disclosed the vulnerability in intra-handshake attestation -- as noted in issued -- to the vendors, which resulted in of CVSS 7.5.
Modeling Other Binding Mechanisms The artifacts are quite flexible for modification and testing of different intra-handshake attestation binding mechanisms by simply changing single rdata parameter in the Client and Server processes. Folder aggregate contains all analyzed and proposed binding mechanisms in to select via comment and uncomment. Other folders contain one specific binding mechanism.
SEAT-Early-Attestation The draft is an extension of the provably vulnerable (and withdrawn) draft with the following two main changes from a formal perspective:
  1. Binder has been updated
  2. Post-handshake attestation part has been added for re-attestation
The current binder in does not prevent relay attacks as there is no shared secret in the binder. In addition to the formal analysis in , see for arguments why shared secret is necessary to prevent relay attacks. Post-handshake attestation part may prevent relay attacks, but then the additional complexity of intra-handshake attestation is unjustified.
Executive Summary of Current Status Severity is based on NIST metrics. Published CVEs/GHSAs for intra-handshake (aka early) attestation
CVSS Severity Number of Published CVEs/GHSAs
9.1 Critical 2
7.8 High 1
7.5 High 2
7.4 High 7
6.3 Medium 1
For TLS reference, Heartbleed was CVSS 7.5.
Credits GHSAs/CVEs for intra-handshake (aka early) attestation and finders in (roughly) chronological order of publishing
GHSA/CVE CVSS Finders
7.8 Muhammad Usama Sardar, Viacheslav Dubeyko, and Jean-Marie Jacquet
7.5 Muhammad Usama Sardar, Viacheslav Dubeyko, and Jean-Marie Jacquet
7.5 Muhammad Usama Sardar, Viacheslav Dubeyko, and Jean-Marie Jacquet
7.4 Muhammad Usama Sardar
9.1 Muhammad Usama Sardar and Songbo Bu
9.1 Muhammad Usama Sardar and Songbo Bu
7.4 Muhammad Usama Sardar, Viacheslav Dubeyko, and Jean-Marie Jacquet
7.4 Muhammad Usama Sardar, Viacheslav Dubeyko, and Jean-Marie Jacquet
7.4 Muhammad Usama Sardar, Viacheslav Dubeyko, and Jean-Marie Jacquet
7.4 Muhammad Usama Sardar, Viacheslav Dubeyko, and Jean-Marie Jacquet
7.4 Muhammad Usama Sardar, Viacheslav Dubeyko, and Jean-Marie Jacquet
7.4 Muhammad Usama Sardar
6.3 Muhammad Usama Sardar
TBA 9.1 Songbo Bu and Muhammad Usama Sardar
Threat Model The threat model is explained in Sec. 6.1 of and Sec. 4 of . Beyond post-generation leakage of privEK considered in , the same adversary capability may arise from failures during key generation or entropy provisioning. Platform-attestation keys and workload-controlled TLS keys belong to distinct key-generation domains: for example, in AMD SEV-SNP the VCEK is derived by SNP firmware from chip-unique secrets and a TCB version, while several other platform secrets are specified as CSRNG-generated; by contrast, privEK and TLS (EC)DHE private values are typically generated by software executing inside the confidential VM using the guest OS or cryptographic-library random subsystem. Furthermore, SEV-SNP REPORT_DATA is supplied by the guest and incorporated into the signed attestation report without being interpreted by SNP firmware; consequently, valid Evidence can authenticate a binding value without attesting the entropy provenance, generation procedure, or exclusive possession of the corresponding private key. The LEK(privEK) capability should therefore also encompass predictable or repeated key generation caused by deficient entropy, cloned or rolled-back DRBG state, defective software or firmware, or malicious provisioning. CVE-2025-62626 provides a concrete manufacturer-layer fault model: affected AMD Zen 5 processors could return insufficiently random values from certain RDSEED forms while incorrectly signaling success. This does not establish compromise of the AMD-SP-internal CSRNG or of a specific attested-TLS implementation, but demonstrates that ideal-randomness assumptions can fail below the protocol layer; software dependencies such as OpenSSL's --with-rand-seed=rdcpu (OpenSSL 3.5.0 INSTALL.md), which can use RDSEED or RDRAND as CSPRNG seed input, illustrate a possible propagation path from hardware entropy interfaces to workload TLS key generation.
Low-Level Mapping of the System Model Figure 2 of provides a TEE-agnostic protocol-level abstraction. For a low-level view, the following table maps the abstract components to representative Intel TDX and AMD SEV-SNP implementations. Mapping of the abstract system model to representative CC implementations
Fig. 2 element Intel TDX AMD SEV-SNP
Physical Machine TDX-capable Intel platform SEV-SNP-capable AMD platform
CC Platform CPU HW + TDX Module + attestation infrastructure CPU HW + AMD-SP/SNP (system) firmware + RMP/SEV machinery
Quoting Agent TD QE AMD-SP / SNP attestation (VM) firmware
Confidential VM Trust Domain (TD) Part of SNP confidential VM
Network stack Part of guest OS + TLS library inside TD Part of guest OS + TLS library inside SNP guest
HSM/TPM Secure element Secure element
privAK Attestation key of TD Quoting Enclave VCEK/VLEK signing key
privEK Workload/TLS-side ephemeral key Workload/TLS-side ephemeral key
privLTK Long-term key in secure element Long-term key in secure element
The key material shown in the abstract model belongs to different implementation and trust domains. The following table provides a corresponding low-level view. Low-level implementation and key-generation domains
Component/key Runs/lives where? Type Randomness/key source
TLS ECDHE Inside network stack Network stack OS/library CSPRNG
privEK Inside confidential VM Guest software OS/library CSPRNG
AK Quoting Agent Firmware/enclave/platform key hierarchy Platform-specific
Memory-encryption key CC Platform Hardware/firmware managed Platform RNG/KDF
REPORT_DATA Created by Guest Software Data binding No independent entropy requirement
Per-VM memory-encryption key is used to encrypt confidential VM's RAM.
Detailed Vulnerability Disclosure Timeline and Public Acknowledgements by Affected Vendors Detailed vulnerability disclosure timeline and acknowledgements
Event Date
Our initial responsible disclosure to vendor 07 Oct, 2025
Acknowledgement by vendor 14 Dec, 2025
Information to the IETF 11 Jan, 2026
Public announcement by vendor 27 Feb, 2026
Cocos AI published [Severity = HIGH (CVSS 7.8)] 23 March, 2026
CVE published [Severity = HIGH (CVSS 7.5)] 26 March, 2026
ENISA published EUVD [Severity = HIGH (CVSS 7.5)] 26 March, 2026
Acknowledgment by Privasys for rustls [Severity = HIGH (CVSS 7.5)] 9 July, 2026
Acknowledgment by Privasys for go [Severity = HIGH (CVSS 7.5)] 10 July, 2026
CCC implementation declared vulnerable to relay attacks 17 July, 2026
Vulnerable CCC implementation repo archived 22 July, 2026
Vulnerable draft withdrawn by authors 23 July, 2026
Edgeless Systems published [Severity = HIGH (CVSS 7.4)] 29 July, 2026
Cocos AI published [Severity = CRITICAL (CVSS 9.1)] 16 August, 2026
Cocos AI published [Severity = CRITICAL (CVSS 9.1)] 16 August, 2026
Privasys published [Severity = HIGH (CVSS 7.4)] 3 September, 2026
Privasys published [Severity = HIGH (CVSS 7.4)] 3 September, 2026
Privasys published [Severity = HIGH (CVSS 7.4)] 3 September, 2026
Privasys published [Severity = HIGH (CVSS 7.4)] 3 September, 2026
Privasys published [Severity = HIGH (CVSS 7.4)] 3 September, 2026
Privasys archived early attestation in rustls and moved to post-handshake attestation 4 September, 2026
Privasys archived early attestation in go and moved to post-handshake attestation 4 September, 2026
Privasys published [Severity = HIGH (CVSS 7.4)] 6 September, 2026
Privasys published [Severity = MEDIUM (CVSS 6.3)] 6 September, 2026
Neither the GHSAs nor the CVE has any dependency whatsoever on the considered threat model with WeakHash, WeakDH, or BadElement. They hold independent of those, i.e., with StrongHash and StrongDH and all good elements within a group.
EU ENISA European Union's ENISA has independently published with CVSS 7.5 to acknowledge this vulnerability.
Comparison with Other Vulnerabilities in Confidential Computing Literature Severity is based on NIST metrics. Comparison with other vulnerabilities in confidential computing literature
Vulnerability CVE CVSS Severity
wiretap.fail No CVE (Intel and AMD announcements) - None
TEE.fail No CVE - None
TDXdown Intel 2.5 Low
Staleus CVE-2025-54509 4.0 Medium
BreakFAST CVE-2025-61972 4.2 Medium
BadRAM AMD 5.3 Medium
BreakFAST CVE-2025-61971 5.9 Medium
Fabricked CVE-2025-54510 5.9 Medium
Intra-handshake.fail 7.5 High
The comparison of the above with CVSS 7.5 for indicates that attested TLS is not mature yet compared to the rest of the confidential computing stack, and is currently one of the weakest links in the ecosystem.
More CVEs Further formal analysis has led to the following potential CVEs for intra-handshake attestation (currently under review and disclosure): Expected CVEs for intra-handshake attestation under disclosure
CVSS Severity Number of CVEs
9.8 Critical 1
9.1 Critical 3 (confirmed by developers)
8.7 High 1
7.5 High 2
7.4 High 7 (5 confirmed by developers)
6.3 Medium 2
These are preliminary estimates of scores, not final assigned score. They are still under review.
Vulnerable Implementations At least the following implementations are vulnerable:
  • Meta's AI: and [Severity = HIGH (CVSS 7.5)]
  • Cocos AI: [Severity = HIGH (CVSS 7.8)], and [Severity = HIGH (CVSS 7.5)]
  • Edgeless Systems Contrast: [Severity = HIGH (CVSS 7.4)]
  • CCC Attestation SIG's adopted project intra-handshake attestation: declared vulnerable to relay attacks and archived
  • Privasys rustls: Acknowledgment of applicability of [Severity = HIGH (CVSS 7.5)] and archived
  • Pirvasys go: Acknowledgment of applicability of [Severity = HIGH (CVSS 7.5)] and archived
If you are aware of any other intra-handshake attestation implementation, please let us know so that we can check and responsibly disclose the vulnerabilities to them.
Vulnerable Protocol Specifications At least the following protocol specifications with intra-handshake attestation path are vulnerable to and :
  • : symbolic proof of insecurity; withdrawn after the CVE
  • : symbolic and (paper-and-pen-based) computational proof of insecurity (originally done for -04 and applies also to -06)
    • As a SEAT WG participant pointed out, please note that both and contain a link to that contains a link to that contains the G3 property (cf. ) that this draft does not satisfy.
    • Some WG participants successfully reproduced the vulnerability by substituting the right value of rdata in the shared formal model that led to the CVE.
    • An informal reasoning is that binder is not directly derived from any shared secret in this draft.
    • Unnecessary complexity is itself a security concern
  • : symbolic proof of insecurity
    • violates G3 property in our analysis
    • unnecessary complexity is itself a security concern
Binding Levels
  1. DH shared secret (gxy) used as shared secret between client and server
  2. Handshake traffic key (htsc) used for encryption of handshake messages
  3. Application traffic key (atsc) used for encryption of application data
Please see Sec. 6.2 of for details.
Security Properties (Correlation Goals) We consider TLS Server as RATS Attester, which is typical in confidential computing.
  1. Correlation of Evidence to a DH Shared Secret (G1)
  2. Correlation of Evidence to Client’s Handshake Traffic Key (G2)
  3. Correlation of Evidence to Client’s Application Traffic Key (G3)
Please see Sec. 6.3 of for details.
Main Results
  • All analyzed binding mechanisms and the corresponding implementations of intra-handshake attestation are vulnerable to relay attacks.
  • Early exporter helps achieve level 1 binding.
  • Our proposed mechanism helps achieve level 2 binding.
  • It may not be possible to achieve level 3 in intra-handshake attestation alone without additional assumptions.
Main results
Property Mechanism #1,2,4,6 Mechanism #3,5,7 Proposed mechanism
G1 : Correlation of Evidence to gxy ❌ ✅ ✅
G2 : Correlation of Evidence to kch ❌ ❌ ✅
G3 : Correlation of Evidence to kc ❌ ❌ ❌
Please see Sec. 7.1 and Figure 5 of for details of attacks.
Expected Results Expected results
No. Binding mechanism Artifacts Expected results
1. Client’s TLS nonce binder1 binder1
2. Client’s attestation nonce binder2 binder2
3. Early exporter binder3 binder3
4. Server’s public key binder4 binder4
5. Combination of #2 and #3 binder5 binder5
6. Combination of #2 and #4 binder6 binder6
7. Combination of #2, #3, and #4 binder7 binder7
8. Proposed proposal proposal
Implications of Findings
Implications of Findings for IETF SEAT WG
  • We believe post-handshake attestation alone, such as draft-fossati-seat-expat, can achieve level 3 binding.
  • The research suggests that recent hybrid proposals (combination of intra-handshake attestation and post-handshake attestation) and may add unnecessary complexity of intra-handshake attestation without adding any security benefit compared to post-handshake attestation alone, such as draft-fossati-seat-expat. We are not aware of any security property that hybrid proposals can achieve that post-handshake attestation alone cannot achieve.
  • As demonstrated by our symbolic analysis using ProVerif, the protocol specifications and remain vulnerable to CVE-2026-33697. We have also proved that and violate the security theorems in the computational model.
Implications of Findings for IETF LAKE WG
  • Similar problems occur for protocol specification lake-ra.
Implications of Findings for IETF TLS WG
  • is vulnerable to . Thankfully, the authors have withdrawn .
  • Remote attestation within the handshake is very dangerous, since to our knowledge, it is one of the highest scored published vulnerabilities in confidential computing literature (see ). For reference, Heartbleed was 7.5 CVSS.
Implications of Findings for Agent2Agent The findings of published CVEs/GHSAs up to 9.1 (presented in ) show that intra-handshake attestation can introduce significant security risks for AI agents when relied upon as a security mechanism. Attestation can provide evidence about an agent’s technical state, but such evidence should not be equated with governability. For a relying party, governability also depends on whether the agent’s identity, authority and permissions remain aligned with the intended interaction, whether responsibility for its actions can be attributed, and whether meaningful intervention remains possible. The findings in this draft reinforce that distinction by showing that even the binding between attestation evidence and the intended session can fail. Successful attestation should therefore be treated as one input into governance, rather than as sufficient evidence that an AI agent remains under effective control.
Technical Details
Tool We use state-of-the-art symbolic security analysis tool ProVerif for the specification of the protocols.
Modeling The formal model uses the fixed version of diversion attacks in intra-handshake attestation from our previous work as the starting point to focus on relay attacks in intra-handshake attestation in this work. The rationale is that we consider it more useful to show the added value of this contribution to the community by using the fixed version of diversion attacks in intra-handshake attestation as the baseline, rather than showing the same diversion attacks from , and the discovered CVE () -- which the previous analysis could not find -- practically demonstrates the added value. This modeling choice makes it clear that even with the diversion attacks fixed, high-severity relay attacks would still remain in intra-handshake attestation. Note: Similar to the fixed version of diversion attacks in intra-handshake attestation from our previous work, we model non-PSK-based handshake. From :
  • For modeling TLS 1.3, we consider handshakes based on Diffie-Hellman over either finite fields or elliptic curves, represented as (EC)DHE. This is because we are unaware of any publicly available specification or implementation of attested TLS with PSK-based handshakes.
While it would be nice to model PSK-based handshake, the rationale is that the correlation properties studied in this work do not necessarily require it. Note: The artifacts consider the case of server authentication only, as client authentication is optional in TLS 1.3. No claims are made about other configurations.
Properties Properties in are complemetary to properties in . Sec. 8 of mentions:
  • We emphasize that both diversion and relay attacks are orthogonal and thus the two works are complementary.
Technical Vulnerability Report Technical vulnerability report is available at . It is accepted for publication at ESORICS 2026.
Vulnerabilities Sec. 7.1 of presents the technical details with abstract attack traces of the vulnerabilities.
Mitigation Sec. 7.2 of presents the technical details of the proposed mitigation.
Artifacts Artifacts are available at under Apache-2.0 License.
Media Coverage Several media professionals and bloggers have covered the vulnerabilities to protect the community from the harm of intra-handshake attestation.
  • The Register
  • (Japanese) BlackHatNewsTokyo
  • (Several languages) Hackernoon
  • Apple podcast
  • Information Security News
  • TheNextGenTechInsider
  • DailySecurityReview
  • SC World
  • 01 Quantum
  • (Russian) Security Lab
  • (German) blogspan
  • (Chinese) Sina
  • data4biz
  • (Russian) ITSec
  • (Chinese) smzdm
  • (Chinese) donews
  • (Chinese) ifeng
  • dugganusa
  • dugganusa repo
  • spoitus
  • lavx news
  • sohu
  • (Persian) news.ditty
  • (Russian) LiMP VPN
  • daily.dev
  • warden
  • GCVE.eu
  • vuln.lu
  • coderlegion
  • Anjuna Security
  • Privasys
  • freenode
  • (Chinese) csdn
  • osintsights
  • (Turkish) hardwaremania
  • akber
  • ad-hoc news
  • AIMultiple
Security Researchers Several credible security researchers, such as the following, have publicly attested to it.
  • Michael Pak
  • Rodrigo Branco
  • Bart Preneel
  • Thorsten Strufe
Germany's BSI Germany's Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik) has attested to it. Carina Hilt, deputy press spokesperson at BSI, told The Register: CC refers to Confidential Computing, and attested TLS is the core trust mechanism of CC.
Reviews
Conference Reviews has been peer-reviewed and accepted for publication at ESORICS 2026.
IETF/IRTF Several participants of the IETF/IRTF have attested to the results by independently reproducing the results and reviewing the code. Some of the participants have independently reproduced the results by developing their own formal models and a proof-of-concept implementation of the vulnerabilities. Some of the messages are mentioned below (excluding the messages of authors of ):
  • https://mailarchive.ietf.org/arch/msg/seat/B7F1Dj_rjs8I0Kg3yCp3Rap0XeE/
  • https://mailarchive.ietf.org/arch/msg/seat/aEV9dUFotAQzHndk23qBcwBT3as/
  • https://mailarchive.ietf.org/arch/msg/seat/3Hv0E1sfXsvyBtl6AgY8j-SHHiw/
  • https://mailarchive.ietf.org/arch/msg/seat/5LJ6i9svomnhpyPHWPejM7fMmXQ/
  • https://mailarchive.ietf.org/arch/msg/seat/V_YqGUY3fEwaFwwyfA9DshpHet0/
  • https://mailarchive.ietf.org/arch/msg/seat/JF_cwmHHEbrJ_W5V6yEetWWnii4/
  • https://mailarchive.ietf.org/arch/msg/seat/P_CYTycg0KG7cbKauFA-kVgX2jo/
  • https://mailarchive.ietf.org/arch/msg/seat/ZJjJXpYwZ5nCVmz_W4FK6XiFEY4/
  • https://mailarchive.ietf.org/arch/msg/seat/4so3LxHOOXHS1wnvhuoeWWgeCHk/
  • https://mailarchive.ietf.org/arch/msg/seat/Q6Jmc58v0c1lDV3ujIY0AX_ofGA/
  • https://mailarchive.ietf.org/arch/msg/seat/n4Me5QPCvwhxcEJndWePyishcoo/
  • https://mailarchive.ietf.org/arch/msg/seat/beRzNNvwMifkRfJPfxecGoHpTDs/
  • https://mailarchive.ietf.org/arch/msg/cfrg/U5YHd91lYjiqCTt9BZyVDNFeUpM/
  • https://mailarchive.ietf.org/arch/msg/seat/aFCo4BMRDSUynvN9AQJatPjnXag/
  • https://mailarchive.ietf.org/arch/msg/seat/wb_Ys9MZd9u9oM2Bk-8tv7fvXGg/
  • https://mailarchive.ietf.org/arch/msg/seat/ov8f-7cZKK5RZ-Mmjc6IhVSB-Fk/
  • https://mailarchive.ietf.org/arch/msg/seat/2uUuaD1DygjNDM4GT_-rYbwTiJk/
  • https://mailarchive.ietf.org/arch/msg/seat/pB39abN1QrH4_ATM_E78vxPTuxk/
  • https://mailarchive.ietf.org/arch/msg/seat/PxKCxMHe-SAiR9uhOOllrK4mUA4/
  • https://mailarchive.ietf.org/arch/msg/seat/T1xupUBwqYEBSHCTXgSHXZtdqz8/
  • https://mailarchive.ietf.org/arch/msg/seat/hRw46FwgmVdi9fqZm2fjKbln_IA/
  • https://mailarchive.ietf.org/arch/msg/seat/UG7yE_klmRSxNy2HX6fzuFonDjM/
  • https://mailarchive.ietf.org/arch/msg/seat/2hpeIldeFfE6o9q6L9Vkt00ACKA/
  • https://mailarchive.ietf.org/arch/msg/seat/gc2ij0vboehS_-v10-SNslxaZC0/
  • https://mailarchive.ietf.org/arch/msg/seat/oO4mAfq5HJZptDDNrSnd7zDdX18/
  • https://mailarchive.ietf.org/arch/msg/seat/XuJc_yEJPCMIuYcv2OM7XDogRCU/
  • https://mailarchive.ietf.org/arch/msg/seat/nVHlnbFIEh-cPQeMuDVOqx5YvWQ/
  • https://mailarchive.ietf.org/arch/msg/seat/xVU3C7qUOngcip7B4ZO5MJUT9Xg/
  • https://mailarchive.ietf.org/arch/msg/seat/1gCcPw-7NopDRzzBzA3dFIgo3Rs/
  • https://mailarchive.ietf.org/arch/msg/seat/t8aobzB374lWiLzrVrORY7kGYyQ/
  • https://mailarchive.ietf.org/arch/msg/seat/m3UyB6XLQzxaucejE_o8Pn41uSI/
  • https://mailarchive.ietf.org/arch/msg/seat/gqHqcbbKva_oGE-jEDZu243gf-4/
  • https://mailarchive.ietf.org/arch/msg/seat/QD8QB1WVL-toNovGQ2Tk6DmmeEM/
  • https://mailarchive.ietf.org/arch/msg/seat/vXN2pifZ5GXcC1xLwSfLCnUcFUE/
  • https://mailarchive.ietf.org/arch/msg/seat/MGFXinb85XSaLkqjBEhmBZC7PcI/
  • https://mailarchive.ietf.org/arch/msg/seat/js9VI4PB8yYmhg2ObaZB1a22fL4/
  • https://mailarchive.ietf.org/arch/msg/seat/0RzORzX_VdlY5UQ_MWMmxZlnrjs/
  • https://mailarchive.ietf.org/arch/msg/seat/W3MH1BDSUbm1WUPxGQihaIc1zTk/
  • https://mailarchive.ietf.org/arch/msg/seat/2_aGylmFHoLmqN7BBcYVoH-rNJk/
  • https://mailarchive.ietf.org/arch/msg/seat/7SYSuB83Kmr9qCb1V1F94n9W33U/
  • https://mailarchive.ietf.org/arch/msg/seat/0SWfg2YNEAOtJQ7Zsf1xl4O-AOo/
  • https://mailarchive.ietf.org/arch/msg/seat/1mfNw-bw8KsdJbl4saL99Fz4iec/
  • https://mailarchive.ietf.org/arch/msg/seat/VyifG8zP5aworb_S1NR9FEUEXW0/
  • https://mailarchive.ietf.org/arch/msg/seat/CYwvM75z6rTId2A3ZZvZJmHxOig/
  • https://mailarchive.ietf.org/arch/msg/ufmrg/29xFZX5C4oSGkpZAvXT_7YLW2Vc/
  • https://mailarchive.ietf.org/arch/msg/seat/u1HxYW9cJfVpi3Cf9q06ehwpYGE/
  • https://mailarchive.ietf.org/arch/msg/seat/SG_A0016a-KMnXAkGtMUxokZmjc/
  • https://mailarchive.ietf.org/arch/msg/seat/3w7-OW2CAVr0-QBz97eAMxB_nMI/
  • https://mailarchive.ietf.org/arch/msg/seat/UnybcafvQ2D-IhUfTV228WQFNhA/
  • https://mailarchive.ietf.org/arch/msg/seat/rmVNeFbjax26l31n5pitHIxOQkk/
  • https://mailarchive.ietf.org/arch/msg/seat/DghJdG3ysbPFKMQe8czz-tcIMq0/
  • https://mailarchive.ietf.org/arch/msg/seat/rZLacid2wnEtaJwSbiIIft3T0FI/
  • https://mailarchive.ietf.org/arch/msg/seat/_kEBODNsTWjgadb5xnlj86dvhcs/
  • https://mailarchive.ietf.org/arch/msg/seat/qP3XC0MarFFA3SMbBpWWJtxACNA/
  • https://mailarchive.ietf.org/arch/msg/seat/kkjQhi4yvJ_iAwYrPw1crFh-m-0/
  • https://mailarchive.ietf.org/arch/msg/seat/vBkdKtKzTt4F91VprfKIndgmT2o/
  • https://mailarchive.ietf.org/arch/msg/seat/Huu_AFu11BTrdxK3I8hmw2jjp8Q/
  • https://mailarchive.ietf.org/arch/msg/seat/oOnioxkB__QZIvhFn5naW6jIXzg/
  • https://mailarchive.ietf.org/arch/msg/seat/iWsCCAl8YZ-pOTA7siNUGsfliHQ/
  • https://mailarchive.ietf.org/arch/msg/seat/-HGPUR5CvuVWcOAg37cSxwoATm0/
  • https://mailarchive.ietf.org/arch/msg/seat/LnLYE7bGQOmCxVXq6stiOtKwc1s/
  • https://mailarchive.ietf.org/arch/msg/seat/o_bIJhOdB4j1g0nczxPZwFXtCo8/
  • https://mailarchive.ietf.org/arch/msg/seat/hy4qVQJQGR82-bskQ_UGI6iel1Y/
  • https://mailarchive.ietf.org/arch/msg/seat/3J3s_YFnf9IQ87Tv2c1q4f36xKQ/
  • https://mailarchive.ietf.org/arch/msg/seat/JWKMYY1YG1E2iS_HyQ4rDmOsDGw/
  • https://mailarchive.ietf.org/arch/msg/seat/rK1nDSewAbVL_weOp98knYZcg6s/
  • https://mailarchive.ietf.org/arch/msg/seat/Wjuz0fIj8tjYocUmiZZXcSwwFHw/
  • https://mailarchive.ietf.org/arch/msg/seat/SYiV4KZNr20re6QkGmyWS3pPteA/
  • https://mailarchive.ietf.org/arch/msg/seat/ZYgxm1ibt6p4dL7xF1YNdl0XSpc/
  • https://mailarchive.ietf.org/arch/msg/seat/6LKgOp22YRxGTYb-i-BxiMGzMW4/
  • https://mailarchive.ietf.org/arch/msg/seat/3oHcKPtXLfBUYCZoN1nnO6e1F-s/
  • https://mailarchive.ietf.org/arch/msg/seat/aSybH9ihnNjN7SjdhhY_XtxhMtc/
  • https://mailarchive.ietf.org/arch/msg/seat/d_G8r7LMGjA45BPexZwsfmmAtJY/
  • https://mailarchive.ietf.org/arch/msg/seat/u-za86_YJ0spwBXBwTVQzwiOCrU/
  • https://mailarchive.ietf.org/arch/msg/seat/P4IMdvCx8lSEKrCiJIjbpBCRr4g/
  • https://mailarchive.ietf.org/arch/msg/seat/-AO9yFJoflV1wDwwch45dmqkmyo/
  • https://mailarchive.ietf.org/arch/msg/seat/H0LqHfBasQml69Y-9Zl_njfsE8s/
  • https://mailarchive.ietf.org/arch/msg/seat/3hOGlYyc_yntmvT0tjYxldlwaxM/
  • https://mailarchive.ietf.org/arch/msg/seat/JbwL9cdl6fiP0vBGgASUUDmaPy8/
  • https://mailarchive.ietf.org/arch/msg/seat/TtewHbMGKBQOKD2sqrgTrnpCOkI/
  • https://mailarchive.ietf.org/arch/msg/seat/UsIj6o7wf4hX_uCL51TCTv-wFxU/
Main Questions In short, five main questions have been raised by WG participants in support of our work:
  • What security property hybrid (intra- + post-handshake attestation) provides that post-handshake attestation alone cannot provide?
  • Since continuous attestation is required in most use cases, how is additional complexity of intra-handshake attestation justified? Use cases with one-time attestation can be covered by doing attestation round immediately after Connection Establishment Time: see reference.
  • What is the benefit of doing signatures of remote attestation within the handshake (as this latency can be exploited)? We add that verification of signatures is also time consuming, which can be exploited too. See reference.
  • How evidence is bound to the secure channel without involving any shared secret? See .
  • How does a verifying relying party get the legitimate PIIDs and CHIP_IDs?
Researchers outside of IETF/IRTF Some researchers have approached us confirming the proof-of-concept of the vulnerabilities in intra-handshake attestation. More information will be added once their pre-prints/papers are public.
Security Considerations All of this document is about the insecurity of intra-handshake (aka early) attestation. By no means should the vendors mentioned in this draft be considered less secure than any other vendors implementing intra-handshake attestation solutions. In particular, those who have closed-source implementations are most likely more vulnerable than the open-source ones, since the former cannot easily be reviewed by the security community. Even extensive security reviews -- of closed-source implementations -- by cybersecurity firms often do not perform formal analysis, and thus such reviews may miss corner cases and subtle vulnerabilities.
Ethical Considerations We (i.e., the super set of all authors involved in this research, including but not limited to Muhammad Usama Sardar, Mariam Moustafa, Tuomas Aura, Viacheslav Dubeyko, Jean-Marie Jacquet, Songbo Bu, Chengxin Huang, Haowen Song, Kaya Ercihan, Massimiliano Brighindi, and Iman Schrock) are ethical researchers aiming to protect the community from the potential harm caused by the exploitability of the vulnerabilities in intra-handshake attestation. We have responsibly disclosed the vulnerabilities to the respective developers and maintainers following their respective disclosure processes and provided them our proposed mitigations and requested them to take rapid action. We have released only the formal analysis for published CVE. To minimize exploit in the wild, we have not publicly released the proof-of-concept exploit code. We have not retrieved any real data from any real system. We have not released any key to any public forum or to any person.
Evidence of Explanation of Vulnerabilities to the Authors of Vulnerable Drafts To the best of our abilities, knowledge, and understanding, we have tried to explain the vulnerabilities to the authors of vulnerable drafts , , and first privately in several meetings and then later on publicly for at least half a year at several forums, including but not limited to CCC Attestation SIG and IETF/IRTF. Please see the (non-exhaustive list of) recordings and the archives below. We sincerely thank the authors of for withdrawing their draft to protect further exploits mentioned in .
Recordings Evidence of several explanations of vulnerabilities to the authors of vulnerable drafts
Event/Host Venue Date(s) Evidence
Linux Plumbers Conference 2026 Prague, Czechia 5-7 Oct, 2026 slides, video
GA4GH 14th Plenary Meeting Singapore 28 Sept-2 Oct, 2026 slides, video
ESORICS 2026 Rome, Italy 14-18 Sept, 2026 slides
IETF RATS Interim meeting Virtual 14 Sept, 2026 slides, video
Hackathon @ RIOT Summit 2026 Grenoble, France 4 September, 2026 topic synopsis
RIOT Summit 2026 Grenoble, France 2-4 September, 2026 abstract, slides, video
Data Security Work Stream (DSWS) at the Global Alliance for Genomics and Health (GA4GH) Virtual 24 Aug, 2026 slides, video
Confidential AI Public Side Meeting @ IETF 126 Vienna, Austria 21 July, 2026 plan, slides
SEAT @ IETF 126 Vienna, Austria 21 July, 2026 slides, video
IETF 126 Hackdemo Happy Hour Vienna, Austria 20 July, 2026 Hackathon project, demo
Confidential Computing Public Side Meeting @ IETF 126 Vienna, Austria 20 July, 2026 plan, slides
HotRFC @ IETF 126 Vienna, Austria 19 July, 2026 slides, video
IETF 126 Hackathon Vienna, Austria 19 July, 2026 Hackathon project, slides, video
IEPG @ IETF 126 Vienna, Austria 19 July, 2026 slides, video
Workshop @ Dresden Science Night 2026 Dresden 26 June, 2026 demo
Output 2026 Dresden 25 June, 2026 demo
Confidential Computing Summit 2026 (presented by Jens Albers) San Francisco, USA 23-24 June, 2026 poster
Confidential Containers Community Meeting @ Cloud Native Computing Foundation Virtual 30 April, 2026 slides, video around timestamp 00:27:00
GIF Project showcase @ GA4GH April Connect 2026 Montreal, Canada (virtual) 17 April, 2026 slides, video, report
NSA Symposium on Hot Topics in the Science of Security (HotSoS) 2026 Virtual 16 April, 2026 abstract, slides, video
PET-CON 2026.1: 15th Privacy Enhancing Techniques Convention Karlsruhe, Germany 16-17 April, 2026 slides, poster
GTMFS 2026: Annual Meeting of the WG "Formal Methods in Security" Luz-Saint-Sauveur, France 24-26 Mar, 2026 slides
CFRG @ IETF 125 Shenzhen, China (virtual) 19 Mar, 2026 slides, video
SEAT @ IETF 125 (relay) Shenzhen, China (virtual) 17 Mar, 2026 slides, video
Side meeting @ IETF 125 Shenzhen, China (virtual) 16 Mar, 2026 slides
LAKE @ IETF 125 Shenzhen, China (virtual) 16 Mar, 2026 slides, video
HotRFC @ IETF 125 Shenzhen, China (virtual) 15 Mar, 2026 slides, video
IETF 125 Hackathon Shenzhen, China (virtual) 14-15 Mar, 2026 Hackathon project, slides, video
CCC Attestation SIG Virtual 10 Feb, 2026 slides; video
IETF RATS Interim meeting Virtual 9 Feb, 2026 slides, video
Confidential Computing devroom at FOSDEM 2026 Brussels, Belgium 31 Jan-1 Feb, 2026 abstract, slides, video
CCC Attestation SIG Virtual 27 Jan, 2026 slides; video
CCC Attestation SIG Virtual 13 Jan, 2026 slides; video
CCC Attestation SIG Virtual 16 Dec, 2025 slides; video
CCC Attestation SIG Virtual 2 Dec, 2025 slides; video
Archives Since January, we have publicly informed the authors of vulnerable drafts , , and and shared our results with the community for review and to raise awareness on high-severity vulnerabilities and apply appropriate mitigations for the safety of their users:
IETF
  • SEAT WG
  • RATS WG
  • TLS WG
  • LAKE WG
  • SAAG
  • Practical Cybersecurity list
  • Agent2agent list thread1 and thread2
  • DSMC list
  • Hackathon
  • 126attendees
IRTF
  • UFMRG: thread1 and thread2
  • CFRG thread1 and thread2
  • DINRG
CCC
  • Attestation SIG: thread1 and thread2
  • TAC: thread1 and thread2
OCP
  • OCP Security: message1, message2, message3 and message4
If you know any other relevant mailing list that we should inform for protection of users, please let us know.
Contributions Contributions to the draft are welcome at https://github.com/muhammad-usama-sardar/intra-handshake-fail.
IANA Considerations This document has no IANA actions.
References Normative References Intra-handshake.fail (CVE-2026-33697): High-severity CVE in Attested TLS Intra-handshake.fail (CVE-2026-33697): High-severity CVE in Attested TLS CoCoS attested TLS is vulnerable to relay attacks via extracted ephemeral TLS keys CVE CoCoS attested TLS is vulnerable to relay attacks via extracted ephemeral TLS keys ENISA CoCoS attested TLS is vulnerable to relay attacks via extracted ephemeral TLS keys Cocos AI intra-handshake attested TLS implementation is vulnerable to session-misbinding attacks for Intel TDX verifier path Cocos AI intra-handshake attested TLS implementation can accept Evidence with nil, empty, or omitted reportData in the AMD SEV-SNP path Remote attestation is susceptible to relay attacks Relay Attacks in Intra-handshake Attestation for Confidential Agentic AI Systems Privasys RA-TLS challenge mode did not bind attestation evidence to the TLS session Privasys Go fork: RA-TLS challenge mode did not bind attestation evidence to the TLS session enclave-os-virtual: RA-TLS challenge certificates were not bound to the TLS session enclave-os-mini: RA-TLS challenge certificates were not bound to the TLS session ra-tls-clients: RA-TLS challenge verifier accepted quotes not bound to the TLS session Privasys Intra-handshake attested TLS implementation is vulnerable to Diversion Attacks Privasys Intra-handshake attested TLS implementation is vulnerable to TOCTOU Attacks Identity Crisis in Confidential Computing: Formal Analysis of Attested TLS TU Dresden, Dresden, Germany Aalto University, Espoo, Finland Aalto University, Espoo, Finland ACM Identity Crisis in Confidential Computing: Formal Analysis of Attested TLS Verified Models and Reference Implementations for the TLS 1.3 Standard Candidate IEEE Separate but together: integrating remote attestation into TLS Informative References Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Intuit Arm Limited Arm Limited Linaro Nokia 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. Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Intuit Arm Limited Arm Limited Linaro Nokia 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 series of TLS extensions that enable the 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. These extensions have been designed to allow the peers to use any attestation technology, in any remote attestation topology, and to use them mutually. Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Intuit Arm Limited Arm Limited Arm Limited Huawei Linaro 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 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 series of protocol extensions to the TLS 1.3 handshake that enables the 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. These extensions have been designed to allow the peers to use any attestation technology, in any remote attestation topology, and mutually. Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Intuit Arm Limited Arm Limited Arm Limited Huawei Linaro 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 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 series of protocol extensions to the TLS 1.3 handshake that enables the 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. These extensions have been designed to allow the peers to use any attestation technology, in any remote attestation topology, and mutually. Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 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. Factor-based Attestation and Credential Transport Scheme (FACTS) over TLS 1.3 Independent This document describes FACTS (Factor-based Attestation and Credential Transport Scheme) over TLS 1.3. Conceptually acting as "multi-factor authentication" for machine identities, factor-based attestation derives session trust from multiple independent cryptographic inputs rather than a single point of failure. Specifically, it utilizes a dual-key scheme that binds identity to attestation evidence through the use of key encapsulation material keys (KEM) and traditional identity signing keys (IK), establishing per-session freshness.
Acknowledgments Acknowledgment does not necessarily imply attestation. It implies that the authors found the feedback and discussion useful in improving the formal analysis, the corresponding paper, or this draft. This draft benefits from several years of research on attested TLS, in particular some of the recent works mentioned below: We wish to express our sincere appreciation to the following for their review of our latest work:
  • Bertrand Foing
  • Sammy Kerata Oina
  • Drasko Draskovic
Intra-handshake.fail We would like to thank our co-author of paper for his valuable contributions:
  • Jean-Marie Jacquet
We also gratefully acknowledge the following for insightful discussions and helpful reviews on :
  • Eric Rescorla
  • Juho Forsén
  • Markus Rudy
  • Mariam Moustafa
  • Bruno Blanchet
  • Steve Kremer
  • Tjaden Hess
  • Martin Thomson
  • Yuning Jiang
  • Pavel Nikonorov
  • Casey Wilson
  • Anonymous ESORICS 2026 reviewers
  • Danko Miladinovic
  • John Preuß Mattsson
  • Britta Hale
  • Werner Staub
  • Songbo Bu
  • Haowen Song
  • Chengxin Huang
  • Steve Luo
  • Andrew Miller
  • Kubilay Ahmet Küçük
  • Iman Schrock
  • Sophie Schmieg
  • Davyd Okaianchenko
  • Alistair Woodman
  • Göran Selander
  • Tom Sato
  • Jakub Maria Plutowski
  • Martin Friedrich
  • Patrick Duggan
  • Deb Cooley
Identity Crisis We would like to thank our co-authors of complementary paper for their valuable contributions:
  • Mariam Moustafa
  • Tuomas Aura
We also gratefully acknowledge the following for insightful discussions and helpful feedback:
  • Ionut Mihalcea
  • Jean-Marie Jacquet
  • Thomas Fossati
  • Eric Rescorla
  • Hannes Tschofenig
  • Yaron Sheffer
  • Laurence Lundblade
  • Giridhar Mandyam
  • Christopher Patton
  • Jonathan Hoyland
  • Richard Barnes
refTLS We sincerely thank the following for the foundational formal model of draft 20 of TLS 1.3 in their work that we have used as the foundation of all of this work:
  • Karthikeyan Bhargavan
  • Bruno Blanchet
  • Nadim Kobeissi
General Several others at the IETF, IRTF, CCC, and GA4GH have contributed by providing feedback over the years. A non-exhaustive list of contributors is here. Muhammad Usama Sardar is funded by German Research Foundation ("Deutsche Forschungsgemeinschaft.")