Early Attestation Considered Harmful (CVE-2026-92701 of CVSS 9.1, CVE-2026-92702 of CVSS 9.1, CVE-2026-33697 of CVSS 7.5, and 37 other CVEs of up to expected CVSS 10.0 upcoming)

1.1. Overview

[Intra-handshake.fail] presents the formal specification and analysis of the candidate binding mechanisms for binding in intra-handshake attestation for standardization for attested TLS protocols:¶

We provide a formal proof of insecurity of all the above candidate
binding mechanisms of intra-handshake attestation using the
state-of-the-art tool ProVerif and propose a mitigation for the
discovered security vulnerabilities. Our study reveals that it may
not be possible to achieve strong application-traffic (level 3)
binding using intra-handshake attestation alone. This can be exploited
for relay attacks, where an attacker makes a client accept an evidence
from a different machine. So the client cannot be sure that it connects
to its desired server.

We responsibly disclosed the vulnerability in intra-handshake attestation -- as noted in [GHSA-Cocos-AI] issued -- to the vendors, which resulted in [CVE-2026-33697] of CVSS 7.5.¶

1.2. 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 [Intra-handshake.fail] to select via comment and uncomment. Other folders contain one specific binding mechanism.¶

1.3. SEAT-Early-Attestation

The draft [I-D.fossati-seat-early-attestation] is an extension of the provably vulnerable (and withdrawn) draft [I-D.fossati-tls-attestation-10] with the following two main changes from a formal perspective:¶

1. Binder has been updated¶

2. Optional post-handshake attestation part has been added for re-attestation¶

The current binder in [I-D.fossati-seat-early-attestation] does not prevent relay attacks as there is no shared secret in the binder. In addition to the formal analysis in [Intra-handshake.fail], see [TLS-RA] 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.¶

1.4. Executive Summary of Current Status

Severity is based on NIST metrics. Scores of 13 more GHSAs is yet to be confirmed and will be added later in this table. For TLS reference, Heartbleed was CVSS 7.5.¶

3.1. Low-Level Mapping of the System Model

Figure 2 of [Intra-handshake.fail] 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.¶

The key material shown in the abstract model belongs to different implementation and trust domains. The following table provides a corresponding low-level view.¶

Per-VM memory-encryption key is used to encrypt confidential VM's RAM.¶

8.1. Archived/Mitigated Implementations

The following intra-handshake implementations were vulnerable and have been archived or moved to post-handshake attestation:¶

• CCC Attestation SIG's adopted project intra-handshake attestation: declared vulnerable to relay attacks and archived¶

• Cocos AI <= v0.8.2: [GHSA-Cocos-AI] [Severity = HIGH (CVSS 7.8)], [CVE-2026-33697] and [EUVD-2026-16488] [Severity = HIGH (CVSS 7.5)]; migrated to post-handshake attestation since v0.9.0¶

• Privasys rustls <= privasys-v0.2.0: [GHSA-Privasys-rustls] [Severity = HIGH (CVSS 7.4)], archived and Privasys migrated to post-handshake attestation¶

• Pirvasys go <= privasys-v0.3.0-go1.26.5: [GHSA-Privasys-go] [Severity = HIGH (CVSS 7.4)], archived and Privasys migrated to post-handshake attestation¶

12.1. Expected Results

13.1. 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) [I-D.fossati-seat-early-attestation] and [I-D.ritz-seat-facts] 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 [I-D.fossati-seat-early-attestation] and [I-D.ritz-seat-facts] remain vulnerable to CVE-2026-33697. We have also proved that [I-D.fossati-seat-early-attestation-04] and [I-D.fossati-seat-early-attestation] violate the security theorems in the computational model.¶

13.2. Implications of Findings for IETF LAKE WG

• Similar problems occur for protocol specification lake-ra.¶

13.3. Implications of Findings for IETF TLS WG

• [I-D.fossati-tls-attestation-09] is vulnerable to [CVE-2026-33697]. Thankfully, the authors have withdrawn [I-D.fossati-tls-attestation-10].¶

• 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 Section 6). For reference, Heartbleed was 7.5 CVSS.¶

Given the high- and critical-severity vulnerabilities, we recommend
that the developers and maintainers of intra-handshake attestation MUST
urgently move to post-handshake attestation.

13.4. Implications of Findings for Agent2Agent

The findings of published CVEs/GHSAs up to 9.1 (presented in Section 2) 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.¶

14.1. Tool

We use state-of-the-art symbolic security analysis tool ProVerif for the specification of the protocols.¶

14.2. 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 [ID-Crisis], and the discovered CVE ([CVE-2026-33697]) -- 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 [ID-Crisis]:¶

• 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.¶

14.3. Properties

Properties in [Intra-handshake.fail] are complemetary to properties in [ID-Crisis]. Sec. 8 of [ID-Crisis] mentions:¶

• We emphasize that both diversion and relay attacks are orthogonal and thus the two works are complementary.¶

14.4. Technical Vulnerability Report

Technical vulnerability report is available at [Intra-handshake.fail]. It is accepted for publication at ESORICS 2026.¶

14.5. Artifacts

Artifacts are available at [Intra-handshake.fail-repo] under Apache-2.0 License.¶

15.1. Security Researchers

Several credible security researchers, such as the following, have publicly attested to it.¶

• Michael Pak¶

• Rodrigo Branco¶

• Bart Preneel¶

• Thorsten Strufe¶

15.2. 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 alone cannot satisfy the requirements for digital sovereignty.

dependencies on other services, such as identity and key
management etc., are also not mitigated by CC.

CC refers to Confidential Computing, and attested TLS is the core trust mechanism of CC.¶

16.1. Conference Reviews

[Intra-handshake.fail] has been peer-reviewed and accepted for publication at ESORICS 2026.¶

16.2. 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 [Intra-handshake.fail]):¶

• 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/¶

• https://mailarchive.ietf.org/arch/msg/seat/a6c8D6PBDRe0x4DAqXM3t4EPc4c/¶

• https://mailarchive.ietf.org/arch/msg/seat/prB537Jht2kELVCSrTRktjbp7Y4/¶

• https://mailarchive.ietf.org/arch/msg/seat/RPnKYfUCD_MRw3hnA00zg684yGM/¶

• https://mailarchive.ietf.org/arch/msg/seat/nMH_0sLLU5MekoEnzWKJnIJmaSk/¶

• https://mailarchive.ietf.org/arch/msg/seat/GJCA31mgAehlgFPRu_yHA10lKPI/¶

• https://mailarchive.ietf.org/arch/msg/seat/9f-21JMK6s1Pdcob6mPo06rNwmQ/¶

• https://mailarchive.ietf.org/arch/msg/seat/8qq_GFT391IEbGZZQUtYMONX9U0/¶

• https://mailarchive.ietf.org/arch/msg/seat/xzu2UlClYMkG8gNSOClxGJgwnOI/¶

• Exploit: https://mailarchive.ietf.org/arch/msg/seat/MfxWpRtlTqPElX8vX4v8uiN65TU/¶

• https://mailarchive.ietf.org/arch/msg/seat/PkU0jW_xHAF18rZmtZJ2A2p_wHs/¶

• https://mailarchive.ietf.org/arch/msg/seat/jZmdYKQlfherbhowIEmZRw2HF1c/¶

• https://mailarchive.ietf.org/arch/msg/seat/-0j6UpsD_CebqPPMNkDJCjySqEI/¶

• https://mailarchive.ietf.org/arch/msg/rats/ssDrZRFW4s6CSaYeA9ImH0PPQ10/¶

• https://mailarchive.ietf.org/arch/msg/rats/OPBI_Wd-RoTzzdh5D0JZoWlNGI8/¶

• https://mailarchive.ietf.org/arch/msg/rats/nfrdr1T9Pdp6D_kj2Et3XZk-hOY/¶

• https://mailarchive.ietf.org/arch/msg/rats/gMMvtP1IXsXFfb0X5nMhRTaLLok/¶

• https://mailarchive.ietf.org/arch/msg/rats/yaGG4sVf4pCfJ0HNPPRv3Xg0cG8/¶

• https://mailarchive.ietf.org/arch/msg/rats/DaA1jDQNF-bdO5x-dkVbSzlHcD4/¶

• https://mailarchive.ietf.org/arch/msg/rats/ptkHZUDzSoYnD6R5zln6HcE1cv4/¶

16.3. 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.¶

18.1. 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 [I-D.fossati-tls-attestation-09], [I-D.fossati-seat-early-attestation], and [I-D.ritz-seat-facts] 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 Section 18.1.1 and the archives Section 18.1.2 below. We sincerely thank the authors of [I-D.fossati-tls-attestation-10] for withdrawing their draft to protect further exploits mentioned in Section 15.¶

21.1. Normative References

[CSA-eBPF]

Cloud Security Alliance, "MITRE's New Framework: Securing the eBPF Layer Your AI Depends On", September 2026, <https://cloudsecurityalliance.org/blog/2026/09/09/mitre-s-new-framework-securing-the-ebpf-layer-your-ai-depends-on>.

[CVE-2026-33697]

CVE, "CoCoS attested TLS is vulnerable to relay attacks via extracted ephemeral TLS keys", March 2026, <https://www.cve.org/CVERecord?id=CVE-2026-33697>.

[CVE-2026-92701]

CVE, "Cocos AI Intra-handshake attested TLS implementation is vulnerable to session-misbinding attacks for Intel TDX verifier path", September 2026, <https://www.cve.org/CVERecord?id=CVE-2026-92701>.

[CVE-2026-92702]

CVE, "Cocos AI Intra-handshake attested TLS implementation can accept Evidence with nil, empty, or omitted reportData in the AMD SEV-SNP path", September 2026, <https://www.cve.org/CVERecord?id=CVE-2026-92702>.

[EUVD-2026-16488]

ENISA, "CoCoS attested TLS is vulnerable to relay attacks via extracted ephemeral TLS keys", March 2026, <https://euvd.enisa.europa.eu/enisa/EUVD-2026-16488>.

[EUVD-2026-83192]

ENISA, "EUVD-2026-83192", September 2026, <https://euvd.enisa.europa.eu/enisa/EUVD-2026-83192>.

[EUVD-2026-83194]

ENISA, "EUVD-2026-83194", September 2026, <https://euvd.enisa.europa.eu/enisa/EUVD-2026-83194>.

[GHSA-Cocos-AI]

Ultraviolet Cocos AI, "CoCoS attested TLS is vulnerable to relay attacks via extracted ephemeral TLS keys", March 2026, <https://github.com/ultravioletrs/cocos/security/advisories/GHSA-vfgg-mvxx-mgg7>.

[GHSA-Cocos-AI2]

Ultraviolet Cocos AI, "Cocos AI intra-handshake attested TLS implementation is vulnerable to session-misbinding attacks for Intel TDX verifier path", August 2026, <https://github.com/ultravioletrs/cocos/security/advisories/GHSA-4px3-wj2x-xx47>.

[GHSA-Cocos-AI3]

Ultraviolet Cocos AI, "Cocos AI intra-handshake attested TLS implementation can accept Evidence with nil, empty, or omitted reportData in the AMD SEV-SNP path", August 2026, <https://github.com/ultravioletrs/cocos/security/advisories/GHSA-4r6g-mp48-j2rw>.

[GHSA-Edgeless-Systems]

Edgeless Systems, "Remote attestation is susceptible to relay attacks", August 2026, <https://github.com/edgelesssys/contrast/security/advisories/GHSA-hjgc-jc5v-fw7h>.

[GHSA-Edgeless-Systems2]

Edgeless Systems, "Generated policies don't detect all image substitutions", August 2026, <https://github.com/edgelesssys/contrast/security/advisories/GHSA-m2qg-wrxv-h898>.

[GHSA-Privasys-eom]

Privasys, "enclave-os-mini: RA-TLS challenge certificates were not bound to the TLS session", September 2026, <https://github.com/Privasys/enclave-os-mini/security/advisories/GHSA-49qm-4pj3-w2c6>.

[GHSA-Privasys-eov]

Privasys, "enclave-os-virtual: RA-TLS challenge certificates were not bound to the TLS session", September 2026, <https://github.com/Privasys/enclave-os-virtual/security/advisories/GHSA-p5fp-g94g-g9m9>.

[GHSA-Privasys-go]

Privasys, "Privasys Go fork: RA-TLS challenge mode did not bind attestation evidence to the TLS session", September 2026, <https://github.com/Privasys/go/security/advisories/GHSA-7jfw-53rm-phh2>.

[GHSA-Privasys-rtc]

Privasys, "ra-tls-clients: RA-TLS challenge verifier accepted quotes not bound to the TLS session", September 2026, <https://github.com/Privasys/ra-tls-clients/security/advisories/GHSA-5qrc-v874-mxvx>.

[GHSA-Privasys-rtc-da]

Privasys, "Privasys Intra-handshake attested TLS implementation is vulnerable to Diversion Attacks", September 2026, <https://github.com/Privasys/ra-tls-clients/security/advisories/GHSA-pj2x-5wqv-fh57>.

[GHSA-Privasys-rtc-tcu]

Privasys, "Privasys Intra-handshake attested TLS implementation is vulnerable to TOCTOU Attacks", September 2026, <https://github.com/Privasys/ra-tls-clients/security/advisories/GHSA-gg8q-mfhh-wrrc>.

[GHSA-Privasys-rustls]

Privasys, "Privasys RA-TLS challenge mode did not bind attestation evidence to the TLS session", September 2026, <https://github.com/Privasys/rustls/security/advisories/GHSA-j6qv-435v-r492>.

[ID-Crisis]

Sardar, M., Moustafa, M., and T. Aura, "Identity Crisis in Confidential Computing: Formal Analysis of Attested TLS", ACM, Proceedings of the ACM Asia Conference on Computer and Communications Security pp. 547-560, DOI 10.1145/3779208.3785387, June 2026, <https://doi.org/10.1145/3779208.3785387>.

[ID-Crisis-repo]

Sardar, M. U., Moustafa, M., and T. Aura, "Identity Crisis in Confidential Computing: Formal Analysis of Attested TLS", November 2025, <https://github.com/CCC-Attestation/formal-spec-id-crisis>.

[Intra-handshake.fail]

Sardar, M. U., Dubeyko, V., and J.-M. Jacquet, "Intra-handshake.fail (CVE-2026-33697): High-severity CVE in Attested TLS", June 2026, <https://www.researchgate.net/publication/408219182_Intra-handshakefail_CVE-2026-33697_High-severity_CVE_in_Attested_TLS>.

[Intra-handshake.fail-repo]

Sardar, M. U., Dubeyko, V., and J.-M. Jacquet, "Intra-handshake.fail (CVE-2026-33697): High-severity CVE in Attested TLS", July 2026, <https://github.com/muhammad-usama-sardar/intra-handshake.fail>.

[MITRE-Continuous-Attestation]

MITRE's Confidential Computing Layered Attestation Working Group, "Framework for Continuous Remote Attestation", July 2026, <https://www.mitre.org/news-insights/publication/framework-continuous-remote-attestation>.

[refTLS]

Bhargavan, K., Blanchet, B., and N. Kobeissi, "Verified Models and Reference Implementations for the TLS 1.3 Standard Candidate", IEEE, 2017 IEEE Symposium on Security and Privacy (SP) pp. 483-502, DOI 10.1109/sp.2017.26, May 2017, <https://doi.org/10.1109/sp.2017.26>.

[SEAT-vulnerability-report]

Sardar, M. U., "Relay Attacks in Intra-handshake Attestation for Confidential Agentic AI Systems", January 2026, <https://mailarchive.ietf.org/arch/msg/seat/x3eQxFjQFJLceae6l4_NgXnmsDY/>.

[TLS-RA]

Carsten Weinhold, Sardar, M. U., Ionuț Mihalcea, Yogesh Deshpande, Hannes Tschofenig, Yaron Sheffer, Thomas Fossati, and Michael Roitzsch, "Separate but together: integrating remote attestation into TLS", July 2025, <https://www.usenix.org/conference/atc25/presentation/weinhold>.

21.2. Informative References

[I-D.fossati-seat-early-attestation]

Sheffer, Y., Mihalcea, I., Deshpande, Y., Fossati, T., and T. Reddy.K, "Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Work in Progress, Internet-Draft, draft-fossati-seat-early-attestation-06, 5 August 2026, <https://datatracker.ietf.org/doc/html/draft-fossati-seat-early-attestation-06>.

[I-D.fossati-seat-early-attestation-04]

Sheffer, Y., Mihalcea, I., Deshpande, Y., Fossati, T., and T. Reddy.K, "Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Work in Progress, Internet-Draft, draft-fossati-seat-early-attestation-04, 27 May 2026, <https://datatracker.ietf.org/doc/html/draft-fossati-seat-early-attestation-04>.

[I-D.fossati-tls-attestation-06]

Tschofenig, H., Sheffer, Y., Howard, P., Mihalcea, I., Deshpande, Y., Niemi, A., and T. Fossati, "Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Work in Progress, Internet-Draft, draft-fossati-tls-attestation-06, 19 March 2024, <https://datatracker.ietf.org/doc/html/draft-fossati-tls-attestation-06>.

[I-D.fossati-tls-attestation-09]

Tschofenig, H., Sheffer, Y., Howard, P., Mihalcea, I., Deshpande, Y., Niemi, A., and T. Fossati, "Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Work in Progress, Internet-Draft, draft-fossati-tls-attestation-09, 30 April 2025, <https://datatracker.ietf.org/doc/html/draft-fossati-tls-attestation-09>.

[I-D.fossati-tls-attestation-10]

Tschofenig, H., Sheffer, Y., Howard, P., Mihalcea, I., Deshpande, Y., Niemi, A., and T. Fossati, "Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Work in Progress, Internet-Draft, draft-fossati-tls-attestation-10, 23 July 2026, <https://datatracker.ietf.org/doc/html/draft-fossati-tls-attestation-10>.

[I-D.ritz-seat-facts]

Ritz, N., "Factor-based Attestation and Credential Transport Scheme (FACTS) over TLS 1.3", Work in Progress, Internet-Draft, draft-ritz-seat-facts-00, 1 March 2026, <https://datatracker.ietf.org/doc/html/draft-ritz-seat-facts-00>.