[Seat] Re: Comments on formal analysis of relay attacks in intra-handshake attestation (CVE-2026-33697)

[Давид Nunhausen <[e-mail]>]

Hi everyone,
Following the recent discussions on the formal analysis of CVE-2026-33697 by Sardar et al., I would like to contribute some practical findings from my recent work. While the original "Intra-handshake.fail" paper rigorously identifies the vulnerability using formal methods, my focus has been on bridging the gap between theory and practice by developing a concrete, runnable Proof of Concept (PoC) for the attack.
I have successfully implemented an end-to-end Man-in-the-Middle (MitM) relay attack against an attested TLS 1.3 handshake.
Here are the key takeaways from the practical demonstration:
Executable PoC Environment: The attack was simulated in an isolated Docker Compose infrastructure utilizing a vulnerable version of the CoCoS library (v0.8.2).
Successful MitM: The PoC demonstrates that an attacker proxy can relay a ClientHello, forward valid Evidence, and complete the handshake by signing the CertificateVerify message using a compromised ephemeral private key (privEK). This allows the proxy to successfully intercept the connection and decrypt the client's plaintext (e.g., AI requests containing sensitive API keys).
Validation of Binding Failures: The implementation explicitly proves the theoretical finding that current attestation mechanisms fail to cryptographically bind evidence to the application traffic key (G3). It also provides a practical intuition for scenarios where Evidence is bound to the Diffie-Hellman shares but fails to authenticate the full context of the ongoing connection, thus breaking the handshake traffic key correlation (G2).
As Agentic AI systems from organizations like AWS, Microsoft, Google, OpenAI, and Anthropic rapidly move into production, they increasingly rely on Confidential Computing to ensure remote AI agents are trustworthy before transmitting sensitive data. Attested TLS is highly attractive for this use case. However, my PoC demonstrates that if evidence is not strictly bound to the live TLS session, a system that appears secure on paper can still end up trusting the wrong endpoint in practice.
I believe this practical artifact complements the formal models discussed in the WG and UFMRG by providing a reproducible, engineering-level view of the CVE. The real-world implications of this vulnerability are also beginning to gain media traction (for context, see recent coverage here <https://www.securitylab.ru/news/574545.php> or here <https://www.itsec.ru/news/issledovateli-nashli-kriticheskuyu-uyazvimost-v-attested-tls>). I will make the repository code public later and would be happy discuss the architectural details of the PoC further.
Best regards,
Davyd Okaianchenko