[Lake] Re: Fwd: [Ufmrg] Relay Attacks in Intra-handshake Attestation for Confidential Agentic AI Systems

[Paul Wouters <[e-mail]>]

That's a lot of words that doesn't really make clear to me why a two PKI
based system with an interlink using an extra SAN entry on the certificate
would not work? Can you tell me in plain English why that would not work?

Paul

On Mon, Jan 12, 2026 at 9:50 AM Yuxuan Song <[e-mail]> wrote:

> Hi Usama,
>
> Thanks for the information. We are currently working on it, we'll share
> our latest results in the next IETF meeting.
>
> BR,
> Yuxuan.
> ------------------------------
>
> *De: *"Muhammad Usama Sardar" <[e-mail]>
> *À: *"lake" <[e-mail]>
> *Envoyé: *Dimanche 11 Janvier 2026 02:58:26
> *Objet: *[Lake] Fwd: [Ufmrg] Relay Attacks in Intra-handshake Attestation
> for Confidential Agentic AI Systems
>
> Hi lakers,
>
> Sending this separately to keep the two discussions separate.
>
> We discovered relay attacks in intra-handshake attestation implementations
> of attested TLS. 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.
>
> Welcome any questions/thoughts/opinions.
>
> -Usama
>
> PS: For any follow-up, please keep me explicitly in To/CC.
>
>
> -------- Forwarded Message --------
> Subject: [Ufmrg] Relay Attacks in Intra-handshake Attestation for
> Confidential Agentic AI Systems
> Date: Sun, 11 Jan 2026 02:17:42 +0100
> From: Muhammad Usama Sardar <[e-mail]>
> <[e-mail]>
> To: [e-mail] <[e-mail]> <[e-mail]>, UFMRG IRTF
> <[e-mail]> <[e-mail]>
>
> Hi SEAT and UFMRG,
>
> # *Context*
>
> We (i.e., I, Dr. Viacheslav Dubeyko [IBM], and Prof. Jean-Marie Jacquet
> [University of Namur]) did an extensive exploration of binding mechanisms
> in intra-handshake attestation for confidential agentic AI systems, that
> was presented on mic at SEAT meeting 124 and later submitted as a draft [0]
> with focus on AI agent. In line with the scope of SEAT charter, we also 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 that
> the analysis provides important data points to WG for making informed
> decisions.
>
> # *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 WG/RG*: Is someone aware of any other value that folks use
> in "rdata"? If possible, please share a link to specification and/or
> implementation together.
> *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)
>
> *Question** for WG/RG*: Is someone aware of any other combination that
> folks use in "rdata"? If possible, please share a link to specification
> and/or implementation together.
>
>
> # *Prominent Industrial Implementations*
>
>    1. Edgeless Systems Contrast [3]: uses binding mechanism *B*.2
>    2. Cocos AI [4]
>    3. CCC proof-of-concept [5]: Implementation of
>    draft-fossati-tls-attestation
>    4. Meta’s AI [1]: uses binding mechanism *A*.1
>
> *Question** for WG/RG*: Is someone aware of any other intra-handshake
> attestation implementation? If possible, please share a link to
> specification and/or implementation together.
>
>
> # *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
>    - G3: Correlation of Evidence to Client’s Application Traffic Key
>
>
> # *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 public key does not leak.
>
> In general, all solutions fail when server's public 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 within the scope of SEAT charter.
>
>
> # *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 draft has been prepared and artifacts are well-documented. If you
> are interested in reviewing one/both of them and can provide some feedback
> until 19th Jan, please reach out to me off-list. If someone can
> substantially improve the paper and/or artifacts, we are very welcoming to
> adding you as co-author. We will make the paper and artifacts public later
> on.
>
>
> # *Contributors*
> We thank Juho Forsén, Mariam Moustafa, Markus Rudy, Tjaden Hess, Yuning
> Jiang, and Pavel Nikonorov for sharing their insights and providing
> valuable feedback.
>
>
> # *Other known related implementations*
>
>    - 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 will reach out to LAKE WG to inform them about these attacks.
>    - Attested Noise: Confer's private inference [7] uses binding
>    mechanism *A*.4 [8] for Noise protocol. This implementation started
>    just 3 weeks ago (with holidays in between) and is not mature yet. Anyway,
>    we will reach out to the implementer (Moxie Marlinspike) to inform him
>    about these attacks.
>
>
> # *Feedback/Ideas*
> We believe that we have explored all options in intra-handshake
> attestation within the scope of SEAT charter. We look forward to your
> thoughts and ideas on how we can mutually progress this work forward.
>
> -Usama
>
> [0] https://datatracker.ietf.org/doc/draft-jiang-seat-dynamic-attestation/
>
> [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://confer.to/blog/2026/01/private-inference/
>
> [8]
> https://github.com/ConferLabs/confer-proxy/blob/0f69f522f7597c6587741055e86ae802c10891ab/src/main/java/org/moxie/confer/proxy/attestation/AttestationService.java#L145
>
> --
> Lake mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> --
> Lake mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>