Early Attestation is Very Harmful. Why is it Required?#

Muhammad Usama Sardar, GA4GH

• Why: Attested TLS — binding remote attestation into the TLS handshake — is being standardized and deployed for confidential computing and workload identity; this talk shows the early-attestation variant carries critical-severity CVEs, directly relevant to workload/TEE identity design.
• What: Formal verification (ProVerif) surfaced a family of critical and high CVEs in early (intra-handshake) attestation: relay attacks from missing connection binding (CVE-2026-33697, CVSS 7.5), diversion attacks from missing hardware/machine-ID binding, and the EarlyAttestationBleed/EAT series at CVSS 9.1–9.6 — in deployments handling the health data of more than 40 million Germans. Still-vulnerable implementations include Cocos AI ≤ v0.8.2, Privasys rustls/Go, and code following the withdrawn early-attestation draft.
• How: Symbolic security analysis of the attested-TLS handshake, root-caused into two failures — no binding to the connection and no binding to the hardware — plus an architectural argument: early attestation leaks hardware-level information, can only express boot-time claims, adds handshake latency and failure modes, and every use case works with standard post-handshake attestation instead.
• Where applicable: Anyone building or procuring attested TLS, TEE-based workload verification, or confidential-computing pipelines; the talk feeds directly into IETF standardization (SEAT-adjacent) and explicitly invites operator feedback.