AttestedTLS

Formal Analysis and Verification of Attested TLS Protocols for Confidential Computing

Short description of the challenge

• Formally specify and verify the protocols combining TLS 1.3 and remote attestation for Confidential Computing use cases
• Most recent paper and artifacts

Research team/s involved (or communities)

• Team Lead/contact: Muhammad Usama Sardar
• Internet Engineering Task Force (IETF)
  • IETF SEAT (formerly IETF SEAL)
  • IETF RATS
  • IETF TLS
• Internet Research Task Force (IRTF)
  • IRTF UFMRG
  • IRTF CFRG
• Confidential Computing Consortium (CCC)
  • CCC Attestation SIG
  • CCC TAC
• Open Compute Project (OCP)
  • OCP Security
• GlobalPlatform
• Global Alliance for Genomics and Health (GA4GH)
  • GIF TRE Open Suite
  • Data Security Work Stream (DSWS)
• ELIXIR Europe
• GENXT, Cocos AI, Pacific Analytics, JetBrains, Nebius
• Industrial partners at Arm, Linaro, Huawei, Siemens, Intuit, Intel, Nokia, ...
• Researchers at TU Dresden, Universität der Bundeswehr München, Aalto University, University of Turku, ...

Main issues / open problems related to the challenge

The main challenge is the extraction of the attested TLS protocol to be formalized, as all the vendors (including Intel, Arm, AMD and IBM) describe the protocols informally. The main issue is that the protocols are either unspecified (leading to security through obscurity), or if specified, they fall in at least one of the following:

• Issue 1: Incomplete specs (e.g., see here)
• Issue 2: Vague and outdated specs (e.g., see here)

Open problems

Confidential Computing (CC) workload may refer to, for example, a container in Virtual Machine (VM)-based Trusted Execution Environments (TEEs).

1. What is the "long-term identity" of the CC workload? How is "long-term identity" assigned to the CC workload? Which entity supplies this "long-term identity"? How is that Identity Supplier trusted?
2. How is CA-certified Long-Term Key (LTK) injected in the Confidential Computing workload in the first place? Which entity generates the LTK and how is that entity trusted?
3. Can CSP really be out of TCB?
4. How to augment authentication with attestation rather than replacing authentication with attestation?
5. What does "freshness" mean for highly dynamic and long-lived workloads?
6. How to verify the Verifier?
7. How to bootstrap trust in the system?

Further questions in this proposal

Techniques and technologies related to the challenge

• Symbolic security analysis
• Architecturally-defined attestation
• TLS 1.3
• Confidential Computing

Other relevant information (external links, references, etc.)

• Latest Pre-prints

  • Technical Concepts
  • Validation of TLS 1.3 Key Schedule
  • General Approach

• Papers

  • Identity crisis
  • Pre-handshake attestation
  • Intra-handshake attestation
  • Attestation in Arm CCA and Intel TDX

• Code

  • Identity crisis
  • Attestation in Arm CCA and Intel TDX

• Internet-Drafts

  • TLS-attest
    • Informal description of discovered impersonation/diversion attacks
    • Formal analysis that discovered vulnerabilities in this proposal
    • Expoited in BadRAM, wiretap.fail and TEE.fail
  • Using exported authenticators (Latest editor's version)
  • Intra- vs. post-handshake attestation (Latest editor's version)
  • Security considerations of RATS

• Recent tutorial at IETF 122

• Some recent slides, videos etc.

---

Relay Attacks in Intra-handshake Attestation

• Disclosure to mailing lists
• Some recent talks

Detailed vulnerability disclosure timeline

• initial disclosure to vendor: 07 Oct, 2025
• acknowledgement by vendor: 14 Dec, 2025
• public announcement by vendor: 27 Feb, 2026
• security advisory issued: 23 March, 2026 [Severity = HIGH (7.8/10)]
• CVE published CVE-2026-33697 (NIST database): 26 March, 2026 [Severity = HIGH (7.5/10)]

---