Intra-handshake Attestation Considered Harmful (CVE-2026-33697 of CVSS 7.5 and several other CVEs of up to expected CVSS 9.8 upcoming)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 24 February 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

[Intra-handshake.fail] presents a general approach to analyze the intra-handshake 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 in [Intra-handshake.fail-repo] under Apache-2.0 license for reproducibility and extensibility.¶

A complementary paper [ID-Crisis] presents the identity crisis in pre- and intra-handshake attestation. The formal analysis is available in [ID-Crisis-repo] under Apache-2.0 license for reproducibility and extensibility.¶

Another complementary paper -- currently under submission -- peforms a thorough formal analysis of the design options in intra-handshake attestation.¶

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.

2. Credits

3. Threat Model

The threat model is explained in Sec. 6.1 of [Intra-handshake.fail] and Sec. 4 of [ID-Crisis].¶

4. Detailed Vulnerability Disclosure Timeline and Public Acknowledgements by Affected Vendors

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

5. EU ENISA

European Union's ENISA has independently published [EUVD-2026-16488] with CVSS 7.5 to acknowledge this vulnerability.¶

6. Comparison with Other Vulnerabilities in Confidential Computing Literature

Severity is based on NIST metrics.¶

The comparison of the above with CVSS 7.5 for [Intra-handshake.fail] 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.¶

7. More CVEs

Further formal analysis has led to the following potential CVEs for intra-handshake attestation (currently under disclosure):¶

• 1 potential CVE of expected CVSS 9.8¶

• 2 potential CVEs of expected CVSS 9.1¶

• 1 potential CVE of expected CVSS 8.7¶

• 2 potential CVEs of expected CVSS 7.5¶

• 2 potential CVEs of expected CVSS 7.4¶

• 2 potential CVEs of expected CVSS 6.3¶

These are preliminary estimates of scores, not final assigned score. They are still under review.¶

8. Vulnerable Implementations

At least the following implementations are vulnerable:¶

• Meta's AI: [CVE-2026-33697] and [EUVD-2026-16488] [Severity = HIGH (CVSS 7.5)]¶

• Cocos AI: [GHSA-Cocos-AI] [Severity = HIGH (CVSS 7.8)], [CVE-2026-33697] and [EUVD-2026-16488] [Severity = HIGH (CVSS 7.5)]¶

• Edgeless Systems Contrast: [GHSA-Edgeless-Systems] [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 [CVE-2026-33697] [Severity = HIGH (CVSS 7.5)]¶

• Pirvasys go: Acknowledgment of applicability of [CVE-2026-33697] [Severity = HIGH (CVSS 7.5)]¶

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

9. Vulnerable Protocol Specifications

At least the following protocol specifications with intra-handshake attestation path are vulnerable to [CVE-2026-33697] and [EUVD-2026-16488]:¶

• [I-D.fossati-tls-attestation-09]: symbolic proof of insecurity; [I-D.fossati-tls-attestation-10] withdrawn after the CVE¶

• [I-D.fossati-seat-early-attestation]: 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 [CVE-2026-33697] and [EUVD-2026-16488] contain a link to [GHSA-Cocos-AI] that contains a link to [SEAT-vulnerability-report] that contains the G3 property (cf. Section 11) 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 [Intra-handshake.fail-repo] 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¶

• [I-D.ritz-seat-facts]: symbolic proof of insecurity¶

  • violates G3 property in our analysis¶

  • unnecessary complexity is itself a security concern¶

10. 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 (astc) used for encryption of application data¶

Please see Sec. 6.2 of [Intra-handshake.fail] for details.¶

11. 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 [Intra-handshake.fail] for details.¶

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

Please see Sec. 7.1 and Figure 5 of [Intra-handshake.fail] for details of attacks.¶

13. Implications of Findings

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.

14. Technical Details

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

• coderlegion¶

• Anjuna Security¶

• freenode¶

• (Chinese) csdn¶

• osintsights¶

• (Turkish) hardwaremania¶

• akber¶

• ad-hoc news¶

• AIMultiple¶

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.

16. Reviews

17. Security Considerations

All of this document is about the insecurity of intra-handshake 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.¶

18. 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, and Haowen Song) 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.¶

19. IANA Considerations

This document has no IANA actions.¶

20. References

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:¶

• Sammy Kerata Oina¶

• Drasko Draskovic¶

Intra-handshake.fail [Intra-handshake.fail]¶

We would like to thank our co-authors of paper [Intra-handshake.fail] for their valuable contributions:¶

• Viacheslav Dubeyko¶

• Jean-Marie Jacquet¶

We also gratefully acknowledge the following for insightful discussions and helpful reviews on [Intra-handshake.fail]:¶

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

• 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 [ID-Crisis]¶

We would like to thank our co-authors of complementary paper [ID-Crisis] 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 [refTLS]¶

We sincerely thank the following for the foundational formal model of draft 20 of TLS 1.3 in their work [refTLS] 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. A non-exhaustive list of contributors is here.¶

Muhammad Usama Sardar is funded by German Research Foundation ("Deutsche Forschungsgemeinschaft.")¶

Authors' Addresses