[CFRG] Re: Relay Attacks in Intra-handshake Attestation for Confidential Agentic AI Systems (CVE-2026-33697 of CVSS 7.5)

[Muhammad Usama Sardar <[e-mail]>]

Hi Songbo,

Thank you for your feedback [12]. Other than one point which we don't 
understand, we have tried to address the rest and improved the general 
presentation of README for new readers as you suggested. If you feel 
something can be improved further, please feel free to submit a PR. If 
you have multiple proposed changes, please propose multiple small PRs 
rather than a big one. Thank you!

> I also have a few README-level suggestions that may make the artifacts
> easier for new readers to follow:
>
> - Add a short "what this repository shows" summary at the beginning.
"Overview" section [13] has been moved to the top with a tabular 
presentation of what the repo contains.
> - Add a reader guide explaining which files to inspect first.
Table in [13] also gives a starting point.
> - Add a table mapping each binding level to the corresponding security
> goal, model file, and expected result.
A table has been added [14].
> - Add a minimal reproduction path with the main commands and expected outputs.
We don't understand this. We believe [15] is clear enough, which starts 
from basic execution all the way up to generation of Horn clauses.
> - Define the binding-level terminology before comparing it with
> related work or draft mechanisms.
We have slightly expanded binding levels [16].

We welcome any feedback from the RG, particularly on the paper-and-pen 
proof in Sec. 6.4 of paper [10], and some guidance on the next steps to 
a cryptographic proof.

Best regards,

Usama, Slava, and Jean-Marie


[12] https://mailarchive.ietf.org/arch/msg/cfrg/U5YHd91lYjiqCTt9BZyVDNFeUpM/

[13] https://github.com/muhammad-usama-sardar/intra-handshake.fail#overview

[14] 
https://github.com/muhammad-usama-sardar/intra-handshake.fail#expected-results

[15] 
https://github.com/muhammad-usama-sardar/intra-handshake.fail#running-automatic-proofs

[16] 
https://github.com/muhammad-usama-sardar/intra-handshake.fail#binding-levels



On 04.07.26 17:31, Muhammad Usama Sardar wrote:
>
> [ Already shared and thoroughly discussed at SEAT and UFMRG; sharing 
> here for wider opinion/review ]
>
> Hi CFRG,
>
> Following up on our previously reported results (see email below) and 
> my IETF 125 presentation [8], we would like to share ProVerif 
> artifacts under Apache-2.0 License [9] and paper [10] to facilitate 
> independent review and seek RG feedback on the next steps. The work 
> resulted in the discovery of CVE-2026-33697 [11] of CVSS 7.5 and is 
> accepted for ESORICS 2026.
>
> Particularly relevant for this RG is an initial paper-and-pen proof in 
> Sec. 6.4 of paper [10], and we are seeking cryptographer's feedback 
> and collaborations to move this work forward towards a cryptographic 
> proof.
>
> Concrete technical results and implications for binding mechanisms of 
> the intra-handshake attestation from our formal analysis include:
>
>      1. All analyzed binding mechanisms and the corresponding
>         implementations of intra-handshake attestation are vulnerable
>         to relay attacks.
>      2. Early exporter helps achieve level 1 binding.
>      3. Our proposed mechanism helps achieve level 2 binding.
>      4. It may not be possible to achieve level 3 binding in
>         intra-handshake attestation alone without additional assumptions.
>      5. The research suggests that recent hybrid proposals
>         (combination of intra-handshake attestation and post-handshake
>         attestation) draft-fossati-seat-early-attestation and
>         draft-ritz-seat-facts 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.
>
> We welcome any feedback from the RG and will be happy to address it.
>
> Best regards,
>
> -Usama
>
> [8] 
> https://datatracker.ietf.org/meeting/125/materials/slides-125-cfrg-relay-attacks-00
>
[9] https://github.com/muhammad-usama-sardar/intra-handshake.fail
>
> [10] 
> https://www.researchgate.net/publication/408219182_Intra-handshakefail_CVE-2026-33697_High-severity_CVE_in_Attested_TLS
>
> [11] https://www.cve.org/CVERecord?id=CVE-2026-33697
>
>
> On 21.02.26 18:29, Muhammad Usama Sardar wrote:
>>
>> [ Already shared at relevant lists like SEAT, RATS, UFMRG, SAAG; 
>> sharing here for wider opinion/review ]
>>
>> Hi all,
>>
>> # *Context*
>>
>> SEAT WG is working on attested TLS, i.e., extending TLS 1.3 with 
>> remote attestation (cf. RFC9334). Following up with more details on 
>> previous request for review [0]. We would like to hear the thoughts 
>> of cryptographers about this work. As we have observed, a quick look 
>> of cryptographers is very helpful.
>>
>> # *Summary*
>>
>> We (i.e., I, Dr. Viacheslav Dubeyko [IBM], and Prof. Jean-Marie 
>> Jacquet [University of Namur]) extensively explored binding 
>> mechanisms in intra-handshake attestation for confidential agentic AI 
>> systems. The way we define agentic AI system includes agent to agent 
>> (A2A) and agent to orchestrator (A2O) communication.
>>
>> We did formal analysis in state-of-the-art tool ProVerif and we would 
>> like to share a summary of our findings from our formal analysis with 
>> the hope to get some feedback and share some questions for which 
>> folks may have some insights to share.
>>
>> # *Key Finding*
>>
>> /All/ analyzed binding mechanisms and implementations are ad-hoc and 
>> /all/ of them result in relay attacks.
>>
>> Please note that this includes Meta's AI [1] for which a thorough 
>> security assessment [2] was carried out by /Trail of Bits/ and they 
>> were unable to capture the relay attacks but as kindly clarified by 
>> Tjaden Hess, no formal methods were used in their review process. Our 
>> analysis shows the value of formal methods in the review process.
>>
>> # *Fundamental Issue*
>>
>> Basically, there is no binding of Evidence to the TLS connection in 
>> all of these implementations.
>>
>> # *TEE-agnostic System Model*
>>
>>   * Layered Attester (e.g., Intel TDX)
>>   * Composite Attester (e.g., Arm CCA)
>>
>> # *Scope of Attested TLS*
>>
>>   * Intra-handshake attestation
>>
>> # *Formalization Approach*
>>
>>   * Symbolic security analysis
>>
>> # *Formalization Tool*
>>
>>   * ProVerif
>>
>>
>> # *Binding Mechanisms*
>>
>> *A*. We considered the following values for user-defined field 
>> "rdata" in TEEs
>>
>>  1. Client's TLS nonce
>>  2. Client's Attestation nonce
>>  3. Early exporter
>>  4. (Hash of) Server's public key
>>
>> /Question for discussion/: Is someone aware of any other value that 
>> folks use in "rdata"? If possible, please share a link to 
>> specification and/or implementation.
>>
>> *B*. Combinations:
>> We considered the following combinations of binding mechanisms from *A*:
>>
>>  1. Hash (Client's TLS nonce || Server's public key)
>>  2. Hash (Client's Attestation nonce || Server's public key)
>>  3. Hash (Client's Attestation nonce || Server's public key || Early
>>     exporter)
>>
>> /Question//for //discussion/: Is someone aware of any other 
>> combination that folks use in "rdata"? If possible, please share a 
>> link to specification and/or implementation.
>>
>>
>> # *Prominent Industrial Implementations*
>>
>>  1. Edgeless Systems Contrast [3]: uses binding mechanism *B2*
>>  2. Cocos AI [4]
>>  3. CCC proof-of-concept [5]: uses binding mechanism *B2*
>>     (Implementation of draft-fossati-tls-attestation)
>>  4. Meta’s AI [1]: uses binding mechanism *A1*
>>
>> /Question//for //discussion/: Is someone aware of any other 
>> intra-handshake attestation implementation? If possible, please share 
>> a link to specification and/or implementation.
>>
>>
>> # *Binding Levels*
>>
>>  1. Shared DH secret (g^xy)
>>  2. Client's handshake traffic key (htsc)
>>  3. Client's application traffic key (atsc)
>>
>>
>> # *Correlation Properties*
>>
>>   * G1: Correlation of Evidence to Shared DH Secret
>>   * G2: Correlation of Evidence to Client’s Handshake Traffic Key (htsc)
>>   * G3: Correlation of Evidence to Client’s Application Traffic Key
>>     (atsc)
>>
>>
>> # *Results*
>>
>> We proved the proposition: G3 => G2 => G1
>>
>> We discovered relay attacks in all above proposals for binding 
>> mechanisms as well as all implementations analyzed. We provide a 
>> formal proof of insecurity that all above binding mechanisms and 
>> implementations fail to even achieve G1 property (Level 1 binding).
>>
>> Any binding that involves server's public key needs additional 
>> assumption that server's private key does not leak.
>>
>> In general, all solutions fail when server's private key is leaked. 
>> In other words, extension of TLS with attestation in these 
>> implementations is not really bringing much benefit from a security 
>> perspective and rather giving a false sense of security.
>>
>> We believe that it is not possible to achieve level 3 binding for 
>> intra-handshake attestation alone without breaking other TLS properties.
>>
>>
>> # *Implementation Issues*
>>
>>   * Meta's AI uses client's TLS nonce (instead of attestation nonce),
>>     and hence does not provide Evidence freshness.
>>   * Cocos AI abuses the SNI extension to convey attestation nonce.
>>   * Edgeless Systems Contrast was abusing the SNI extension to convey
>>     attestation nonce, and currently abusing the ALPN extension to
>>     convey attestation nonce.
>>
>>
>> # *Proposed Mitigation*
>>
>>   * We propose a cryptographic binder and modify CertificateVerify
>>     message, which achieves level 2 binding.
>>
>>
>> # *Paper and Artifacts*
>> A paper is under submission and artifacts are well-documented. We 
>> will make the paper and artifacts public later on.
>>
>>
>> # *Contributors*
>> We thank Eric Rescorla, Juho Forsén, Markus Rudy, Mariam Moustafa, 
>> Tjaden Hess, Yuning Jiang, Pavel Nikonorov, Casey Wilson, and Martin 
>> Thomson for sharing their insights and providing valuable feedback.
>>
>>
>> # *Other related implementations within IETF*
>>
>>   * Attested EDHOC: Our intuition (no formal proof yet) is that the
>>     attacks should apply to attested EDHOC protocol in
>>     intra-handshake attestation [6] as well -- at least for the case
>>     of Responder as Attester. We have informed LAKE WG [7] about
>>     these
>>     attacks.https://mailarchive.ietf.org/arch/msg/cfrg/U5YHd91lYjiqCTt9BZyVDNFeUpM/
>>
>>
>> # *Feedback/Ideas*
>> We look forward to your thoughts and ideas on how we can mutually 
>> progress this work forward towards secure solutions.
>>
>> Best regards,
>> Usama, Slava (Viacheslav), and Jean-Marie
>>
>>
>> [0] 
>> https://mailarchive.ietf.org/arch/msg/cfrg/61SpXcv--YhcLbAvlcRog2J9S5s/
>>
>> [1] 
>> https://ai.meta.com/static-resource/private-processing-technical-whitepaper 
>>
>>
>> [2] 
>> https://github.com/trailofbits/publications/blob/master/reviews/2025-08-meta-whatsapp-privateprocessing-securityreview.pdf
>>
>> [3] 
>> https://github.com/CCC-Attestation/meetings/blob/main/materials/MarkusRudy.contrast-atls-ccc-attestation.pdf
>>
>> [4] https://docs.cocos.ultraviolet.rs/atls
>>
>> [5] https://github.com/ccc-attestation/attested-tls-poc
>>
>> [6] https://datatracker.ietf.org/doc/draft-ietf-lake-ra/
>>
>> [7] 
>> https://mailarchive.ietf.org/arch/msg/lake/Tovtl7wgvzwJWT2I2ZwnhoIOnYQ/
>>