[Rats] Follow-up of draft-sardar-rats-sec-cons: Relay Attacks in Intra-handshake Attestation for Confidential Agentic AI Systems

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

Hi all,

# *Context*

Thank you for insightful discussion on my draft 
draft-sardar-rats-sec-cons at meeting 124, where I presented relay 
attacks as part of my presentation [0a].

Now, we (i.e., I, Dr. Viacheslav Dubeyko [IBM], and Prof. Jean-Marie 
Jacquet [University of Namur]) have results for a formalization of this 
concept for confidential agentic AI systems use case [1]. We extensively 
explored binding mechanisms in intra-handshake attestation and did 
formal analysis in state-of-the-art tool ProVerif. We would like to 
share a summary of our findings from our formal analysis to get some 
feedback and share some questions which folks may have something to add.

# *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 [0b] 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/: 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)

/Question//for WG/: 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]: Implementation of
    draft-fossati-tls-attestation
 4. Meta’s AI [0b]: uses binding mechanism *A1*

/Question//for WG/: 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
  * 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 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 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 add 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 have informed LAKE WG [9] 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 have informed the implementer (Moxie Marlinspike) about
    these attacks.


# *Feedback/Ideas*
We look forward to your thoughts and ideas on how we can mutually 
progress this work forward towards secure solutions.

-Usama

[0a] 
https://datatracker.ietf.org/meeting/124/materials/slides-124-rats-sessb-guideline-for-security-consideration-of-rats-00#page=6

[0b] 
https://ai.meta.com/static-resource/private-processing-technical-whitepaper

[1] https://datatracker.ietf.org/doc/draft-jiang-seat-dynamic-attestation/

[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

[9] https://mailarchive.ietf.org/arch/msg/lake/Tovtl7wgvzwJWT2I2ZwnhoIOnYQ/