Intra-handshake Attestation Considered Harmful (CVE-2026-33697 of CVSS 7.5 and several other CVEs of up to expected CVSS 9.8 upcoming)
draft-intra-handshake-fail-04
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Muhammad Usama Sardar | ||
| Last updated | 2026-08-09 (Latest revision 2026-08-05) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-intra-handshake-fail-04
SEAT M. U. Sardar
Internet-Draft TU Dresden, Germany
Intended status: Informational 9 August 2026
Expires: 10 February 2027
Intra-handshake Attestation Considered Harmful (CVE-2026-33697 of CVSS
7.5 and several other CVEs of up to expected CVSS 9.8 upcoming)
draft-intra-handshake-fail-04
Abstract
The draft aims to provide technical details of CVE-2026-33697
(https://www.cve.org/CVERecord?id=CVE-2026-33697) and EUVD-2026-16488
(https://euvd.enisa.europa.eu/enisa/EUVD-2026-16488), which is
substantial technical evidence of how *intra*-handshake 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 [Intra-handshake.fail] and the artifacts
[Intra-handshake.fail-repo] in state-of-the-art tool, ProVerif, under
Apache-2.0 license for reproducibility, and have been acknowledged by
the relevant stakeholders.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://muhammad-
usama-sardar.github.io/intra-handshake-fail/draft-intra-handshake-
fail.html. Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-intra-handshake-fail/.
Source for this draft and an issue tracker can be found at
https://github.com/muhammad-usama-sardar/intra-handshake-fail.
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/.
Sardar Expires 10 February 2027 [Page 1]
Internet-Draft Intra-handshake Attestation Considered H August 2026
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 10 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Detailed Vulnerability Disclosure Timeline and Public
Acknowledgements by Affected Vendors . . . . . . . . . . 5
4. EU ERISA . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Comparison with Other Vulnerabilities in Confidential Computing
Literature . . . . . . . . . . . . . . . . . . . . . . . 6
6. More CVEs . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Vulnerable Implementations . . . . . . . . . . . . . . . . . 8
8. Vulnerable Protocol Specifications . . . . . . . . . . . . . 9
9. Binding Levels . . . . . . . . . . . . . . . . . . . . . . . 9
10. Correlation Goals . . . . . . . . . . . . . . . . . . . . . . 10
11. Main Results . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Expected Results . . . . . . . . . . . . . . . . . . . . 11
12. Implications of Findings . . . . . . . . . . . . . . . . . . 12
12.1. Implications of Findings for IETF SEAT WG . . . . . . . 12
12.2. Implications of Findings for IETF LAKE WG . . . . . . . 13
12.3. Implications of Findings for IETF TLS WG . . . . . . . . 13
12.4. Implications of Findings for Agent2Agent . . . . . . . . 13
13. Technical Details . . . . . . . . . . . . . . . . . . . . . . 13
13.1. Tool . . . . . . . . . . . . . . . . . . . . . . . . . . 13
13.2. Modeling . . . . . . . . . . . . . . . . . . . . . . . . 14
13.3. Technical Report . . . . . . . . . . . . . . . . . . . . 14
13.3.1. Vulnerabilities . . . . . . . . . . . . . . . . . . 14
13.3.2. Mitigation . . . . . . . . . . . . . . . . . . . . . 14
Sardar Expires 10 February 2027 [Page 2]
Internet-Draft Intra-handshake Attestation Considered H August 2026
13.4. Artifacts . . . . . . . . . . . . . . . . . . . . . . . 15
14. Media Coverage . . . . . . . . . . . . . . . . . . . . . . . 15
14.1. Security Researchers . . . . . . . . . . . . . . . . . . 17
14.2. Germany's BSI . . . . . . . . . . . . . . . . . . . . . 18
15. Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
15.1. Conference Reviews . . . . . . . . . . . . . . . . . . . 18
15.2. IETF/IRTF . . . . . . . . . . . . . . . . . . . . . . . 18
15.2.1. Main Questions . . . . . . . . . . . . . . . . . . . 20
15.3. Researchers outside of IETF/IRTF . . . . . . . . . . . . 21
16. Security Considerations . . . . . . . . . . . . . . . . . . . 21
17. Ethical Considerations . . . . . . . . . . . . . . . . . . . 21
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
19. Normative References . . . . . . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
This draft presents the formal specification and analysis of the
candidate binding mechanisms for binding in intra-handshake
attestation for standardization for attested TLS protocols:
+===+===========+=========================================+=========================+
|No.|Binding |Used in |Artifacts |
| |mechanism | | |
+===+===========+=========================================+=========================+
|1. |Client’s |Meta's AI (https://ai.meta.com/static- |binder1 |
| |TLS nonce |resource/private-processing-technical- |(https://github.com/ |
| | |whitepaper) |muhammad-usama-sardar/ |
| | | |intra- |
| | | |handshake.fail/tree/main/|
| | | |binder1) |
+---+-----------+-----------------------------------------+-------------------------+
|2. |Client’s |- |binder2 |
| |attestation| |(https://github.com/ |
| |nonce | |muhammad-usama-sardar/ |
| | | |intra- |
| | | |handshake.fail/tree/main/|
| | | |binder2) |
+---+-----------+-----------------------------------------+-------------------------+
|3. |Early |- |binder3 |
| |exporter | |(https://github.com/ |
| | | |muhammad-usama-sardar/ |
| | | |intra- |
| | | |handshake.fail/tree/main/|
| | | |binder3) |
+---+-----------+-----------------------------------------+-------------------------+
|4. |Server’s |- |binder4 |
Sardar Expires 10 February 2027 [Page 3]
Internet-Draft Intra-handshake Attestation Considered H August 2026
| |public key | |(https://github.com/ |
| | | |muhammad-usama-sardar/ |
| | | |intra- |
| | | |handshake.fail/tree/main/|
| | | |binder4) |
+---+-----------+-----------------------------------------+-------------------------+
|5. |Combination|- |binder5 |
| |of #2 and | |(https://github.com/ |
| |#3 | |muhammad-usama-sardar/ |
| | | |intra- |
| | | |handshake.fail/tree/main/|
| | | |binder5) |
+---+-----------+-----------------------------------------+-------------------------+
|6. |Combination|Edgeless Systems Contrast |binder6 |
| |of #2 and |(https://github.com/CCC- |(https://github.com/ |
| |#4 |Attestation/meetings/blob/main/materials/|muhammad-usama-sardar/ |
| | |MarkusRudy.contrast-atls-ccc- |intra- |
| | |attestation.pdf); Cocos AI |handshake.fail/tree/main/|
| | |(https://www.sns-itrust6g.com/wp- |binder6) |
| | |content/uploads/2025/12/Webinar- | |
| | |Architecting-Trust-CONFIDENTIAL6G.pdf); | |
| | |CCC Attestation SIG (https://github.com/ | |
| | |CCC-Attestation)'s adopted project intra-| |
| | |handshake attestation | |
| | |(https://github.com/ccc-attestation/ | |
| | |attested-tls-poc) | |
+---+-----------+-----------------------------------------+-------------------------+
|7. |Combination|draft-fossati-tls-attestation-06 |binder7 |
| |of #2, #3, |(https://www.ietf.org/archive/id/draft- |(https://github.com/ |
| |and #4 |fossati-tls-attestation-06.html) |muhammad-usama-sardar/ |
| | | |intra- |
| | | |handshake.fail/tree/main/|
| | | |binder7) |
+---+-----------+-----------------------------------------+-------------------------+
Table 1: Binding mechanisms, implementations and ProVerif artifacts
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.
Sardar Expires 10 February 2027 [Page 4]
Internet-Draft Intra-handshake Attestation Considered H August 2026
We responsibly disclosed the vulnerability in intra-handshake
attestation -- as noted in security advisory
(https://github.com/ultravioletrs/cocos/security/advisories/GHSA-
vfgg-mvxx-mgg7) issued -- to the vendors, which resulted in
[CVE-2026-33697] of CVSS 7.5.
2. Credits
While not the editors of this draft, we discovered CVE-2026-33697
jointly with *Viacheslav Dubeyko* and *Jean-Marie Jacquet*.
3. Detailed Vulnerability Disclosure Timeline and Public
Acknowledgements by Affected Vendors
+============================================================================+======+
|Event |Date |
+============================================================================+======+
|Our initial responsible disclosure to vendor |07 |
| |Oct, |
| |2025 |
+----------------------------------------------------------------------------+------+
|Acknowledgement by vendor |14 |
| |Dec, |
| |2025 |
+----------------------------------------------------------------------------+------+
|Information to the IETF (https://mailarchive.ietf.org/arch/msg/ |11 |
|rats/6gbqx0XY8WYrH3Mx4vO8n2-uKgY/) |Jan, |
| |2026 |
+----------------------------------------------------------------------------+------+
|Public announcement |27 |
|(https://web.archive.org/web/20260227160554/https://www.ultraviolet.rs/blog/|Feb, |
|tee-tls-privacy/) by vendor |2026 |
+----------------------------------------------------------------------------+------+
|Cocos AI published security advisory |23 |
|(https://github.com/ultravioletrs/cocos/security/advisories/GHSA-vfgg-mvxx- |March,|
|mgg7) [*Severity = HIGH (CVSS 7.8)*] |2026 |
+----------------------------------------------------------------------------+------+
|CVE (CVE-2026-33697 (https://www.cve.org/CVERecord?id=CVE-2026-33697)) |26 |
|published [*Severity = HIGH (CVSS 7.5)*] |March,|
| |2026 |
+----------------------------------------------------------------------------+------+
|ERISA published EUVD (EUVD-2026-16488 (https://euvd.enisa.europa.eu/enisa/ |26 |
|EUVD-2026-16488)) [*Severity = HIGH (CVSS 7.5)*] |March,|
| |2026 |
+----------------------------------------------------------------------------+------+
|Acknowledgment (https://github.com/Privasys/rustls/releases/tag/privasys- |9 |
|v0.8.1) by Privasys for rustls CVE-2026-33697 (https://www.cve.org/ |July, |
|CVERecord?id=CVE-2026-33697) [*Severity = HIGH (CVSS 7.5)*] |2026 |
Sardar Expires 10 February 2027 [Page 5]
Internet-Draft Intra-handshake Attestation Considered H August 2026
+----------------------------------------------------------------------------+------+
|Acknowledgment (https://github.com/Privasys/go/releases/tag/privasys- |10 |
|v0.5.1-go1.26.5) by Privasys for go CVE-2026-33697 (https://www.cve.org/ |July, |
|CVERecord?id=CVE-2026-33697) [*Severity = HIGH (CVSS 7.5)*] |2026 |
+----------------------------------------------------------------------------+------+
|CCC implementation (https://github.com/ccc-attestation/attested-tls-poc) |17 |
|declared vulnerable to relay attacks (https://github.com/CCC-Attestation/ |July, |
|attested-tls-poc/pull/58) |2026 |
+----------------------------------------------------------------------------+------+
|Vulnerable CCC implementation repo (https://github.com/ccc-attestation/ |22 |
|attested-tls-poc) archived |July, |
| |2026 |
+----------------------------------------------------------------------------+------+
|Vulnerable draft draft-fossati-tls-attestation |23 |
|(https://datatracker.ietf.org/doc/draft-fossati-tls-attestation/10/) |July, |
|withdrawn by authors |2026 |
+----------------------------------------------------------------------------+------+
|Edgeless Systems published security advisory |29 |
|(https://github.com/edgelesssys/contrast/security/advisories/GHSA-hjgc-jc5v-|July, |
|fw7h) [*Severity = HIGH (CVSS 7.4)*] |2026 |
+----------------------------------------------------------------------------+------+
Table 2: Detailed vulnerability disclosure timeline and
acknowledgements
4. EU ERISA
European Union's ERISA has independently published EUVD-2026-16488
(https://euvd.enisa.europa.eu/enisa/EUVD-2026-16488) with CVSS 7.5 to
acknowledge this vulnerability.
5. Comparison with Other Vulnerabilities in Confidential Computing
Literature
Severity is based on NIST metrics (https://nvd.nist.gov/vuln-metrics/
cvss).
+==============================+=========================================+====+========+
|Vulnerability |CVE |CVSS|Severity|
+==============================+=========================================+====+========+
|wiretap.fail |No CVE (Intel |- |None |
|(https://wiretap.fail/files/ |(https://www.intel.com/content/www/us/en/| | |
|wiretap.pdf) |security-center/announcement/intel- | | |
| |security-announcement- | | |
| |2025-10-28-001.html) and AMD | | |
| |(https://www.intel.com/content/www/us/en/| | |
| |security-center/announcement/intel- | | |
| |security-announcement- | | |
Sardar Expires 10 February 2027 [Page 6]
Internet-Draft Intra-handshake Attestation Considered H August 2026
| |2025-10-28-001.html) announcements) | | |
+------------------------------+-----------------------------------------+----+--------+
|TEE.fail |No CVE |- |None |
|(https://tee.fail/files/ | | | |
|paper.pdf) | | | |
+------------------------------+-----------------------------------------+----+--------+
|TDXdown (https://dl.acm.org/ |Intel |2.5 |Low |
|doi/10.1145/3658644.3690230) |(https://www.intel.com/content/www/us/en/| | |
| |security-center/announcement/intel- | | |
| |security-announcement- | | |
| |2024-10-08-001.html) | | |
+------------------------------+-----------------------------------------+----+--------+
|Staleus (https://xca- |CVE-2025-54509 (https://www.cve.org/ |4.0 |Medium |
|attacks.github.io/staleus/ |CVERecord?id=CVE-2025-54509) | | |
|staleus_usenix26.pdf) | | | |
+------------------------------+-----------------------------------------+----+--------+
|BreakFAST (https://xca- |CVE-2025-61972 (https://www.cve.org/ |4.2 |Medium |
|attacks.github.io/breakfast/ |CVERecord?id=CVE-2025-6197) | | |
|breakfast_oakland26.pdf) | | | |
+------------------------------+-----------------------------------------+----+--------+
|BadRAM (https://badram.eu/ |AMD (https://www.amd.com/en/resources/ |5.3 |Medium |
|badram.pdf) |product-security/bulletin/amd-sb- | | |
| |3015.html) | | |
+------------------------------+-----------------------------------------+----+--------+
|BreakFAST (https://xca- |CVE-2025-61971 (https://www.cve.org/ |5.9 |Medium |
|attacks.github.io/breakfast/ |CVERecord?id=CVE-2025-61971) | | |
|breakfast_oakland26.pdf) | | | |
+------------------------------+-----------------------------------------+----+--------+
|Fabricked (https://xca- |CVE-2025-54510 (https://www.cve.org/ |5.9 |Medium |
|attacks.github.io/fabricked/ |CVERecord?id=cve-2025-54510) | | |
|fabricked_usenix26.pdf) | | | |
+------------------------------+-----------------------------------------+----+--------+
|Intra-handshake.fail |CVE-2026-33697 (https://www.cve.org/ |7.5 |High |
|(https://www.researchgate.net/|CVERecord?id=CVE-2026-33697) | | |
|publication/408219182_Intra- | | | |
|handshakefail_CVE-2026- | | | |
|33697_High- | | | |
|severity_CVE_in_Attested_TLS) | | | |
+------------------------------+-----------------------------------------+----+--------+
Table 3: Comparison with other vulnerabilities in confidential
computing literature
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.
Sardar Expires 10 February 2027 [Page 7]
Internet-Draft Intra-handshake Attestation Considered H August 2026
6. More CVEs
Further formal analysis has led to the following potential CVEs for
intra-handshake attestation (currently under disclosure):
* 1 CVE of expected CVSS *7.4*
* 2 CVEs of expected CVSS *7.5*
* 1 CVE of expected CVSS *8.7*
* 2 CVEs of expected CVSS *9.1*
* 1 CVE of expected CVSS *9.8*
These are preliminary estimates of scores, not final assigned score.
They are still under review.
7. Vulnerable Implementations
At least the following implementations are vulnerable:
* Meta's AI (https://ai.meta.com/static-resource/private-processing-
technical-whitepaper): CVE-2026-33697 (https://www.cve.org/
CVERecord?id=CVE-2026-33697) and EUVD-2026-16488
(https://euvd.enisa.europa.eu/enisa/EUVD-2026-16488) [*Severity =
HIGH (CVSS 7.5)*]
* Cocos AI (https://github.com/ultravioletrs/cocos): security
advisory
(https://github.com/ultravioletrs/cocos/security/advisories/GHSA-
vfgg-mvxx-mgg7) [*Severity = HIGH (CVSS 7.8)*], CVE-2026-33697
(https://www.cve.org/CVERecord?id=CVE-2026-33697) and EUVD-
2026-16488 (https://euvd.enisa.europa.eu/enisa/EUVD-2026-16488)
[*Severity = HIGH (CVSS 7.5)*]
* Edgeless Systems Contrast (https://github.com/edgelesssys/
contrast): security advisory
(https://github.com/edgelesssys/contrast/security/advisories/GHSA-
hjgc-jc5v-fw7h) [*Severity = HIGH (CVSS 7.4)*]
* CCC Attestation SIG (https://github.com/CCC-Attestation)'s adopted
project intra-handshake attestation (https://github.com/ccc-
attestation/attested-tls-poc): declared vulnerable to relay
attacks (https://github.com/CCC-Attestation/attested-tls-poc/
pull/58) and *archived*
Sardar Expires 10 February 2027 [Page 8]
Internet-Draft Intra-handshake Attestation Considered H August 2026
* Privasys rustls: Acknowledgment
(https://github.com/Privasys/rustls/releases/tag/privasys-v0.8.1)
of applicability of CVE-2026-33697 (https://www.cve.org/
CVERecord?id=CVE-2026-33697) [*Severity = HIGH (CVSS 7.5)*]
* Pirvasys go: Acknowledgment
(https://github.com/Privasys/go/releases/tag/privasys-
v0.5.1-go1.26.5) of applicability of CVE-2026-33697
(https://www.cve.org/CVERecord?id=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 disclose
the vulnerabilities to them.
8. Vulnerable Protocol Specifications
At least the following protocol specifications with intra-handshake
attestation path are vulnerable to CVE-2026-33697
(https://www.cve.org/CVERecord?id=CVE-2026-33697) and EUVD-2026-16488
(https://euvd.enisa.europa.eu/enisa/EUVD-2026-16488):
* draft-fossati-tls-attestation (https://datatracker.ietf.org/doc/
draft-fossati-tls-attestation/09/): symbolic proof of insecurity;
draft (https://datatracker.ietf.org/doc/draft-fossati-tls-
attestation/10/) *withdrawn*
* draft-fossati-seat-early-attestation
(https://datatracker.ietf.org/doc/draft-fossati-seat-early-
attestation/06/): symbolic and computational proof of insecurity
(orginially done for -04 and applies also to -06)
* draft-ritz-seat-facts (https://datatracker.ietf.org/doc/draft-
ritz-seat-facts/00/): symbolic proof of insecurity
9. 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.
Sardar Expires 10 February 2027 [Page 9]
Internet-Draft Intra-handshake Attestation Considered H August 2026
10. 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.
11. 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.
+====================+====================+===========+===========+
| Property | Mechanism #1,2,4,6 | Mechanism | Proposed |
| | | #3,5,7 | mechanism |
+====================+====================+===========+===========+
| G1 : Correlation | ❌ | ✅ | ✅ |
| of Evidence to gxy | | | |
+--------------------+--------------------+-----------+-----------+
| G2 : Correlation | ❌ | ❌ | ✅ |
| of Evidence to kch | | | |
+--------------------+--------------------+-----------+-----------+
| G3 : Correlation | ❌ | ❌ | ❌ |
| of Evidence to kc | | | |
+--------------------+--------------------+-----------+-----------+
Table 4: Main results
Please see Sec. 7.1 of [Intra-handshake.fail] for details.
Sardar Expires 10 February 2027 [Page 10]
Internet-Draft Intra-handshake Attestation Considered H August 2026
11.1. Expected Results
+===+===========+=========================+==================================+
|No.|Binding |Artifacts |Expected results |
| |mechanism | | |
+===+===========+=========================+==================================+
|1. |Client’s |binder1 |binder1 (https://github.com/ |
| |TLS nonce |(https://github.com/ |muhammad-usama-sardar/intra- |
| | |muhammad-usama-sardar/ |handshake.fail/tree/main/binder1/ |
| | |intra- |log.txt) |
| | |handshake.fail/tree/main/| |
| | |binder1/) | |
+---+-----------+-------------------------+----------------------------------+
|2. |Client’s |binder2 |binder2 (https://github.com/ |
| |attestation|(https://github.com/ |muhammad-usama-sardar/intra- |
| |nonce |muhammad-usama-sardar/ |handshake.fail/tree/main/binder2/ |
| | |intra- |log.txt) |
| | |handshake.fail/tree/main/| |
| | |binder2/) | |
+---+-----------+-------------------------+----------------------------------+
|3. |Early |binder3 |binder3 (https://github.com/ |
| |exporter |(https://github.com/ |muhammad-usama-sardar/intra- |
| | |muhammad-usama-sardar/ |handshake.fail/tree/main/binder3/ |
| | |intra- |log.txt) |
| | |handshake.fail/tree/main/| |
| | |binder3/) | |
+---+-----------+-------------------------+----------------------------------+
|4. |Server’s |binder4 |binder4 (https://github.com/ |
| |public key |(https://github.com/ |muhammad-usama-sardar/intra- |
| | |muhammad-usama-sardar/ |handshake.fail/tree/main/binder4/ |
| | |intra- |log.txt) |
| | |handshake.fail/tree/main/| |
| | |binder4/) | |
+---+-----------+-------------------------+----------------------------------+
|5. |Combination|binder5 |binder5 (https://github.com/ |
| |of #2 and |(https://github.com/ |muhammad-usama-sardar/intra- |
| |#3 |muhammad-usama-sardar/ |handshake.fail/tree/main/binder5/ |
| | |intra- |log.txt) |
| | |handshake.fail/tree/main/| |
| | |binder5/) | |
+---+-----------+-------------------------+----------------------------------+
|6. |Combination|binder6 |binder6 (https://github.com/ |
| |of #2 and |(https://github.com/ |muhammad-usama-sardar/intra- |
| |#4 |muhammad-usama-sardar/ |handshake.fail/tree/main/binder6/ |
| | |intra- |log.txt) |
| | |handshake.fail/tree/main/| |
| | |binder6/) | |
+---+-----------+-------------------------+----------------------------------+
Sardar Expires 10 February 2027 [Page 11]
Internet-Draft Intra-handshake Attestation Considered H August 2026
|7. |Combination|binder7 |binder7 (https://github.com/ |
| |of #2, #3, |(https://github.com/ |muhammad-usama-sardar/intra- |
| |and #4 |muhammad-usama-sardar/ |handshake.fail/tree/main/binder7/ |
| | |intra- |log.txt) |
| | |handshake.fail/tree/main/| |
| | |binder7/) | |
+---+-----------+-------------------------+----------------------------------+
|8. |Proposed |proposal |proposal (https://github.com/ |
| | |(https://github.com/ |muhammad-usama-sardar/intra- |
| | |muhammad-usama-sardar/ |handshake.fail/tree/main/proposal/|
| | |intra- |log.txt) |
| | |handshake.fail/tree/main/| |
| | |proposal/) | |
+---+-----------+-------------------------+----------------------------------+
Table 5: Expected results
12. Implications of Findings
12.1. Implications of Findings for IETF SEAT WG
* We believe post-handshake attestation alone, such as draft-
fossati-seat-expat (https://datatracker.ietf.org/doc/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) draft-
fossati-seat-early-attestation (https://datatracker.ietf.org/doc/
draft-fossati-seat-early-attestation/06/) and draft-ritz-seat-
facts (https://datatracker.ietf.org/doc/draft-ritz-seat-facts/00/)
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
(https://datatracker.ietf.org/doc/draft-fossati-seat-expat/). We
are not aware of any security property that hybrid proposals can
achieve that post-handshake attestation alone cannot achieve.
Sardar Expires 10 February 2027 [Page 12]
Internet-Draft Intra-handshake Attestation Considered H August 2026
* As demonstrated by our symbolic analysis using ProVerif, the
protocol specifications draft-fossati-seat-early-attestation
(https://datatracker.ietf.org/doc/draft-fossati-seat-early-
attestation/06/) and draft-ritz-seat-facts
(https://datatracker.ietf.org/doc/draft-ritz-seat-facts/00/)
remain vulnerable to CVE-2026-33697. We have also proved that
draft-fossati-seat-early-attestation-04
(https://datatracker.ietf.org/doc/draft-fossati-seat-early-
attestation/04/) and draft-fossati-seat-early-attestation-06
(https://datatracker.ietf.org/doc/draft-fossati-seat-early-
attestation/06/) violate the security theorems in the
computational model.
12.2. Implications of Findings for IETF LAKE WG
* Similar problems occur for protocol specification lake-ra
(https://datatracker.ietf.org/doc/draft-ietf-lake-ra/).
12.3. Implications of Findings for IETF TLS WG
* draft-fossati-tls-attestation-09
(https://datatracker.ietf.org/doc/draft-fossati-tls-
attestation/09/) is vulnerable to CVE-2026-33697. Thankfully, the
authors have withdrawn draft-fossati-tls-attestation-10
(https://datatracker.ietf.org/doc/draft-fossati-tls-
attestation/10/).
* Remote attestation _within_ the handshake is very dangerous, since
to our knowledge, it is one of the highest scored vulnerabilities
in confidential computing literature (see Section 5).
Given the high-severity vulnerabilities, we recommend that the
developers and maintainers of intra-handshake attestation MUST
urgently move to post-handshake attestation.
12.4. Implications of Findings for Agent2Agent
From a security perspective, intra-handshake attestation does more
damage than protection for AI agents.
13. Technical Details
13.1. Tool
We use state-of-the-art symbolic security analysis tool ProVerif
(https://ieeexplore.ieee.org/document/9833653) for the specification
of the protocols.
Sardar Expires 10 February 2027 [Page 13]
Internet-Draft Intra-handshake Attestation Considered H August 2026
13.2. Modeling
The formal model uses the fixed version of diversion attacks in
intra-handshake attestation (https://github.com/CCC-Attestation/
formal-spec-id-crisis/tree/main/TLS-a/fix) 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 (https://github.com/CCC-Attestation/formal-spec-id-
crisis/tree/main/TLS-a/fix) as the baseline, rather than showing the
same diversion attacks from ID-Crisis paper (https://dl.acm.org/
doi/10.1145/3779208.3785387), 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 (https://github.com/CCC-Attestation/formal-
spec-id-crisis/tree/main/TLS-a/fix) from our previous work, we model
non-PSK-based handshake. From ID-Crisis paper (https://dl.acm.org/
doi/10.1145/3779208.3785387):
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.
13.3. Technical Report
Technical report is available at [Intra-handshake.fail]. It is
accepted for publication at ESORICS 2026.
13.3.1. Vulnerabilities
Sec. 7.1 of [Intra-handshake.fail] presents the technical details
with actual attack traces of the vulnerabilities.
13.3.2. Mitigation
Sec. 7.2 of [Intra-handshake.fail] presents the technical details of
the proposed mitigation.
Sardar Expires 10 February 2027 [Page 14]
Internet-Draft Intra-handshake Attestation Considered H August 2026
13.4. Artifacts
Artifacts are available at [Intra-handshake.fail-repo] under Apache-
2.0 License.
14. Media Coverage
Several media enthusiasts have covered the vulnerabilities to protect
the community from the harm of intra-handshake attestation.
* The Register (https://www.theregister.com/security/2026/07/04/
confidential-computings-trust-mechanism-is-broken-the-fix-may-not-
exist/5266056)
* (Japanese) BlackHatNewsTokyo (https://blackhatnews.tokyo/
archives/119915)
* (Several languages) Hackernoon (https://hackernoon.com/attested-
tls-was-supposed-to-be-the-last-trust-boundary-it-isnt-formal-
methods-show-how)
* Apple podcast (https://podcasts.apple.com/eg/podcast/attested-tls-
was-supposed-to-be-the-last-trust/id1698517643?i=1000776623286)
* Information Security News (https://meterpreter.org/attested-tls-
vulnerability-cve-2026-33697/)
* TheNextGenTechInsider (https://thenextgentechinsider.com/pulse/
critical-flaw-discovered-in-confidential-computing-attestation-
protocols)
* DailySecurityReview (https://dailysecurityreview.com/resources/
cve-2026-33697-attested-tls-relay-flaw-hits-whatsapp-cocos-ai/)
* SC World (https://www.scworld.com/brief/confidential-computings-
remote-attestation-protocol-may-have-fundamental-flaw)
* 01 Quantum (https://blogs.groupware.org.uk/01-Quantum-Inc/the-
handshake-that-cant-keep-its-promise-why-confidential-computings-
flaw-changes-the-data-sovereignty-conversation/)
* (Russian) Security Lab (https://www.securitylab.ru/
news/574545.php)
* (German) blogspan (https://www.blogspan.net/confidential-
computing-attestierung-relay-luecke/)
Sardar Expires 10 February 2027 [Page 15]
Internet-Draft Intra-handshake Attestation Considered H August 2026
* (Chinese) Sina (https://finance.sina.cn/tech/2026-07-04/detail-
inifscxt9953361.d.html)
* data4biz (https://data4biz.com/articles/una-falla-rompe-la-
fiducia-del-confidential-computing)
* (Russian) ITSec (https://www.itsec.ru/news/issledovateli-nashli-
kriticheskuyu-uyazvimost-v-attested-tls)
* (Chinese) smzdm (https://post.smzdm.com/p/a82ol990/)
* (Chinese) donews (https://www.donews.com/news/
detail/4/6621022.html)
* (Chinese) ifeng (https://i.ifeng.com/c/8uUfy0PMmqE)
* dugganusa (https://www.dugganusa.com/post/confidential-computing-
s-whole-pitch-is-trust-the-proof-not-the-cloud-two-years-of-
formal-verifi)
* dugganusa repo (https://github.com/pduggusa/dugganusa-
ietf/tree/main/cve-2026-33697-attestation)
* spoitus (https://sploitus.com/exploit?id=92591A05-07BC-5015-BA3D-
B1347B35D684)
* lavx news (https://news.lavx.hu/article/attested-tls-research-
exposes-a-weak-link-in-confidential-computing)
* sohu (https://www.sohu.com/a/1045865934_122004016)
* (Persian) news.ditty (https://news.ditty.ir/news/attested-tls-
relay-flaw-formal-methods/019f6221-26ca-7293-9ee9-5557b3c0b8f8)
* (Russian) LiMP VPN (https://limpvpn.com/ru/news/attested-tls-
whatsapp-privacy-flaw-2026)
* daily.dev (https://daily.dev/posts/kI6PoNzPx)
* warden (https://warden.veritai.ch/news/researchers-find-attested-
tls-flaws-that-weaken-confidential-computing-trust-model)
* GCVE.eu (https://db.gcve.eu/sightings/?query=cve-2026-33697)
* coderlegion (https://coderlegion.com/24087/intra-handshake-
attestation-when-more-security-doesnt-mean-better-security)
Sardar Expires 10 February 2027 [Page 16]
Internet-Draft Intra-handshake Attestation Considered H August 2026
* Anjuna Security (https://www.anjuna.io/blog/attested-tls-flaw-
explained)
* freenode (https://freenode.net/digest/67)
* (Chinese) csdn (https://blog.csdn.net/weixin_42376192/
category_13096766.html)
* osintsights (https://osintsights.com/confidential-computing-flaws-
expose-trust-risks)
* (Turkish) hardwaremania (https://hardwaremania.com/haber/
arastirma-attested-tls-confidential-computing-icin-zayif-kaliyor/)
* akber (https://akber.com/sovereignty-in-the-cloud-is-an-illusion/)
* ad-hoc news (https://www.ad-hoc-news.de/wissenschaft/cloud-
souveraenitaet-red-hat-startet-reifegrad-assessments-
gegen/69691475)
* AIMultiple (https://aimultiple.com/privacy-enhancing-technologies)
If you have written an article on this and would like to be added
here, please send us a PR or an email with the subject "media
coverage of intra-handshake.fail"
14.1. Security Researchers
Several credible security researchers, such as the following, have
publicly attested to it.
* Michael Pak (https://www.linkedin.com/posts/
michaelpak_confidential-computings-core-trust-mechanism-activity-
7479415537836376064-q-A4/)
* Rodrigo Branco (https://www.linkedin.com/posts/rrbranco_one-more-
evidence-that-there-is-no-such-a-share-7479582122366615552-X0A5/)
* Bart Preneel (https://www.linkedin.com/posts/bart-preneel-
4451412_on-the-limits-of-confidential-computing-share-
7479549718294077440-wfi3/)
* Thorsten Strufe (https://www.linkedin.com/in/strufe/recent-
activity/all/)
Sardar Expires 10 February 2027 [Page 17]
Internet-Draft Intra-handshake Attestation Considered H August 2026
14.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
(https://www.theregister.com/security/2026/07/04/confidential-
computings-trust-mechanism-is-broken-the-fix-may-not-exist/5266056):
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.
15. Reviews
15.1. Conference Reviews
[Intra-handshake.fail] has been peer-reviewed and accepted for
publication at ESORICS 2026.
15.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:
* https://mailarchive.ietf.org/arch/msg/seat/
aEV9dUFotAQzHndk23qBcwBT3as/
(https://mailarchive.ietf.org/arch/msg/seat/
aEV9dUFotAQzHndk23qBcwBT3as/)
* https://mailarchive.ietf.org/arch/msg/seat/3Hv0E1sfXsvyBtl6AgY8j-
SHHiw/ (https://mailarchive.ietf.org/arch/msg/
seat/3Hv0E1sfXsvyBtl6AgY8j-SHHiw/)
* https://mailarchive.ietf.org/arch/msg/
seat/5LJ6i9svomnhpyPHWPejM7fMmXQ/
(https://mailarchive.ietf.org/arch/msg/
seat/5LJ6i9svomnhpyPHWPejM7fMmXQ/)
* https://mailarchive.ietf.org/arch/msg/seat/
V_YqGUY3fEwaFwwyfA9DshpHet0/
(https://mailarchive.ietf.org/arch/msg/seat/
V_YqGUY3fEwaFwwyfA9DshpHet0/)
Sardar Expires 10 February 2027 [Page 18]
Internet-Draft Intra-handshake Attestation Considered H August 2026
* https://mailarchive.ietf.org/arch/msg/seat/
JF_cwmHHEbrJ_W5V6yEetWWnii4/
(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/
P_CYTycg0KG7cbKauFA-kVgX2jo/)
* https://mailarchive.ietf.org/arch/msg/seat/
ZJjJXpYwZ5nCVmz_W4FK6XiFEY4/
(https://mailarchive.ietf.org/arch/msg/seat/
ZJjJXpYwZ5nCVmz_W4FK6XiFEY4/)
* https://mailarchive.ietf.org/arch/msg/
seat/4so3LxHOOXHS1wnvhuoeWWgeCHk/
(https://mailarchive.ietf.org/arch/msg/
seat/4so3LxHOOXHS1wnvhuoeWWgeCHk/)
* https://mailarchive.ietf.org/arch/msg/seat/
Q6Jmc58v0c1lDV3ujIY0AX_ofGA/
(https://mailarchive.ietf.org/arch/msg/seat/
Q6Jmc58v0c1lDV3ujIY0AX_ofGA/)
* https://mailarchive.ietf.org/arch/msg/seat/
n4Me5QPCvwhxcEJndWePyishcoo/
(https://mailarchive.ietf.org/arch/msg/seat/
n4Me5QPCvwhxcEJndWePyishcoo/)
* https://mailarchive.ietf.org/arch/msg/seat/
beRzNNvwMifkRfJPfxecGoHpTDs/
(https://mailarchive.ietf.org/arch/msg/seat/
beRzNNvwMifkRfJPfxecGoHpTDs/)
* https://mailarchive.ietf.org/arch/msg/cfrg/
U5YHd91lYjiqCTt9BZyVDNFeUpM/
(https://mailarchive.ietf.org/arch/msg/cfrg/
U5YHd91lYjiqCTt9BZyVDNFeUpM/)
* https://mailarchive.ietf.org/arch/msg/seat/
aFCo4BMRDSUynvN9AQJatPjnXag/
(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/
wb_Ys9MZd9u9oM2Bk-8tv7fvXGg/)
Sardar Expires 10 February 2027 [Page 19]
Internet-Draft Intra-handshake Attestation Considered H August 2026
* https://mailarchive.ietf.org/arch/msg/seat/ov8f-7cZKK5RZ-
Mmjc6IhVSB-Fk/ (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/2uUuaD1DygjNDM4GT_-rYbwTiJk/)
* https://mailarchive.ietf.org/arch/msg/seat/2_aGylmFHoLmqN7BBcYVoH-
rNJk/ (https://mailarchive.ietf.org/arch/msg/
seat/2_aGylmFHoLmqN7BBcYVoH-rNJk/)
* https://mailarchive.ietf.org/arch/msg/seat/
VyifG8zP5aworb_S1NR9FEUEXW0/
(https://mailarchive.ietf.org/arch/msg/seat/
VyifG8zP5aworb_S1NR9FEUEXW0/)
* https://mailarchive.ietf.org/arch/msg/seat/
CYwvM75z6rTId2A3ZZvZJmHxOig/
(https://mailarchive.ietf.org/arch/msg/seat/
CYwvM75z6rTId2A3ZZvZJmHxOig/)
* https://mailarchive.ietf.org/arch/msg/
ufmrg/29xFZX5C4oSGkpZAvXT_7YLW2Vc/
(https://mailarchive.ietf.org/arch/msg/
ufmrg/29xFZX5C4oSGkpZAvXT_7YLW2Vc/)
* https://mailarchive.ietf.org/arch/msg/seat/
u1HxYW9cJfVpi3Cf9q06ehwpYGE/
(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/
SG_A0016a-KMnXAkGtMUxokZmjc/)
* https://mailarchive.ietf.org/arch/msg/
seat/3w7-OW2CAVr0-QBz97eAMxB_nMI/
(https://mailarchive.ietf.org/arch/msg/
seat/3w7-OW2CAVr0-QBz97eAMxB_nMI/)
15.2.1. Main Questions
In short, three main questions have been raised by WG participants in
support of our work:
Sardar Expires 10 February 2027 [Page 20]
Internet-Draft Intra-handshake Attestation Considered H August 2026
* 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 (https://www.ietf.org/archive/id/draft-usama-
seat-intra-vs-post-04.html#section-6-2).
* What is the benefit of doing *signatures* of remote attestation
*within* the handshake (as this latency can be exploited)? See
reference (https://www.ietf.org/archive/id/draft-usama-seat-intra-
vs-post-04.html#section-4.2.4).
15.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.
16. 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 likely more vulnerable than the open-source ones,
since they cannot easily be reviewed. Even extensive security
reviews by cybersecurity firms often do not perform formal analysis,
and thus remain prone to the corner cases.
17. Ethical Considerations
We (i.e., the super set of all authors involved in this research) are
ethical researchers aiming to protect the community before the
attackers can exploit the vulnerabilities. We have responsibly
disclosed the vulnerabilities to the developers and maintainers and
provided them our proposed mitigations to take rapid action.
We have released only the formal analysis for published CVE. To
avoid exploit in the wild, we have not publicly released the proof-
of-concept exploit code.
Sardar Expires 10 February 2027 [Page 21]
Internet-Draft Intra-handshake Attestation Considered H August 2026
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.
To the best of our abilities, knowledge, and understanding, we have
tried to explain the vulnerabilities to the authors of vulnerable
drafts draft-fossati-tls-attestation
(https://datatracker.ietf.org/doc/draft-fossati-tls-attestation/09/),
draft-fossati-seat-early-attestation
(https://datatracker.ietf.org/doc/draft-fossati-seat-early-
attestation/06/), and draft-ritz-seat-facts
(https://datatracker.ietf.org/doc/draft-ritz-seat-facts/00/) for at
least half a year at several forums, including CCC Attestation SIG
and IETF/IRTF. Please see the (non-exhaustive) recordings
(https://github.com/muhammad-usama-sardar/intra-
handshake.fail#upcoming-and-recent-talks-and-research-visits) and the
archives (https://github.com/muhammad-usama-sardar/intra-
handshake.fail#community-service). Thankfully, the first one has
been withdrawn.
18. IANA Considerations
This document has no IANA actions.
19. Normative References
[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>.
[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>.
Acknowledgments
We would like to thank our co-authors of paper [Intra-handshake.fail]
for their valuable contributions:
Sardar Expires 10 February 2027 [Page 22]
Internet-Draft Intra-handshake Attestation Considered H August 2026
* Viacheslav Dubeyko
* Jean-Marie Jacquet
We gratefully acknowledge the following for insightful discussions
and reviews on this work:
* Eric Rescorla
* Juho Forsén
* Markus Rudy
* Mariam Moustafa
* Bruno Blanchet
* Steve Kremer
* Tjaden Hess
* Martin Thomson
* Yuning Jiang
* Pavel Nikonorov
* Casey Wilson
* Danko Miladinovic
* Songbo Bu
* John Preuß Mattsson
* Britta Hale
* Werner Staub
* Haowen Song
* Chengxin Huang
* Steve Luo
* Kubilay Ahmet Küçük
* Iman Schrock
Sardar Expires 10 February 2027 [Page 23]
Internet-Draft Intra-handshake Attestation Considered H August 2026
* Patrick Duggan
* Nathanael Ritz
* Deb Cooley
We also gratefully acknowledge the following who gave feedback on
previous state-of-the-art (https://github.com/CCC-Attestation/formal-
spec-id-crisis) that we utilize as the basis:
* Tuomas Aura
* Ionut Mihalcea
* Thomas Fossati
* Hannes Tschofenig
* Yaron Sheffer
* Laurence Lundblade
* Giridhar Mandyam
* Christopher Patton
* Jonathan Hoyland
* Richard Barnes
Several others at the IETF, IRTF, CCC, and GA4GH have contributed by
providing feedback.
We sincerely thank Karthikeyan Bhargavan, Bruno Blanchet, and Nadim
Kobeissi for the foundational formal model of draft 20 of TLS 1.3 in
their work (https://ieeexplore.ieee.org/document/7958594).
The research work is funded by German Research Foundation ("Deutsche
Forschungsgemeinschaft.")
Author's Address
Muhammad Usama Sardar
TU Dresden, Germany
Email: muhammad_usama.sardar@tu-dresden.de
Sardar Expires 10 February 2027 [Page 24]