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

["Nancy Cam-Winget (ncamwing)" <[e-mail]>]

Dear Usama,


This is an official warning from the SEAT working group chairs.


Your message to the SEAT list reads primarily as marketing for an external paper and its publication process. As explained in RFC 9945, off-scope discussion and announcements of non-IETF/non-ISOC conferences, events, or activities without prior administrator approval are considered disruptive behaviour.


The SEAT list is for technical discussion relevant to the working group. Technical contributions are welcome, including references to external work when they directly support a concrete technical point. Promotional material, conference status, rankings, publication process updates, and reputation-building claims should not be posted to the list. Further postings of this nature may result in moderation consistent with applicable IETF procedures.


Please keep future messages focused on specific technical issues relevant to SEAT to avoid future moderation.


Best Regards,

Yaroslav and Nancy (as SEAT chairs)

From: Muhammad Usama Sardar <[e-mail]>
Date: Sunday, June 14, 2026 at 6:38 AM
To: [e-mail] <[e-mail]>; UFMRG IRTF <[e-mail]>
Subject: [Seat] Re: Relay Attacks in Intra-handshake Attestation for Confidential Agentic AI Systems


Hi SEAT and UFMRG,

Since some WG participants have shown a lot of interest in our work and also recently brought it to RG as well and seem to be patiently waiting for it, we are happy to update that the peer-review for paper and artifacts is almost over.

The paper has been accepted with shepherding (see below) at ESORICS'26 [10], a CORE rank A security conference [11]. Yesterday we received three reviews, all of which are very encouraging. In our understanding, there are no technical objections to either the core methodology in the paper or the artifacts (both symbolic and paper-and-pen analysis). There appear to be some requests for a more clear presentation on a couple of items, and more clarity on the future work.

We would like to share our understanding of the next steps in the shepherding process at ESORICS'26:

  *   Within the next two days, the ESORICS shepherd will provide additional review and list of revision points.
  *   Latest by June 26 (11:59 p.m. AoE), we will work on the revisions and coordinate with the ESORICS shepherd to finalize the paper.

We intend to stay highly respectful of the community's time and thus release the artifacts and paper only after the ESORICS shepherd's confirmation. Based on that, here are the next steps that the WG/RG can expect:

  *   Artifacts: If the ESORICS shepherd's list of revision points does not include any concern on artifacts, WG/RG can expect the artifacts to be released under Apache-2.0 License, allowing the WG/RG to carry out further research on top of that. If there is any concern on artifacts, we will wait for the ESORICS shepherd's confirmation before releasing the artifacts. There are also other dependencies: we have already requested creation of a repo from the co-chairs of CCC Attestation SIG, where this is an adopted project [12].
  *   Preprint: We will share the paper preprint latest by June 26 (11:59 p.m. AoE).
  *   Presentation: Unfortunately, UFMRG is not meeting in Vienna [13]. We would ask for a slot in SEAT and likely present as follows:
     *   Insights from symbolic analysis: Usama
     *   Insights from Agentic AI use case: Slava (to be confirmed)
     *   Insights from paper-and-pen analysis: Jean-Marie (to be confirmed)

We hope the paper will provide a useful input for SEAT, and a great motivation for UFMRG on how formal methods can be used to find the high-severity vulnerabilities in apparently secure protocols.

We would like to thank Eric Rescorla, Juho Forsen, Markus Rudy, Mariam Moustafa, Tjaden Hess, Yuning Jiang, Pavel Nikonorov, and Casey Wilson for their insightful contributions. We also thank Paul Wouters, the responsible AD back then, who requested an exhaustive analysis of existing implementations of intra-handshake attestation, and this work aims to fulfill that requirement.

We will happily incorporate any feedback from the WG/RG in the follow-up work.

Best regards,

Usama, Slava (Viacheslav), and Jean-Marie


On 03.03.26 18:47, Muhammad Usama Sardar wrote:

Hi all,

Following up with supporting public evidence: Cocos AI has publicly acknowledged [9] the relay attacks last Friday.

# Context

As helpful context, Cocos AI [4] claimed their attested TLS to be the "best in the world" in the Confidential Computing Consortium and despite we having informed them repeatedly about the attacks after our formal analysis, they were continuing to misguide the community on social media. Anyway, we now respect their honesty and transparency, and we remain fully committed to helping them towards secure solutions.

# Cocos AI acknowledgment of attacks

Cocos AI (one of the implementers of the protocol) has publicly acknowledged [9] our email and the relay attacks we highlighted on their design and implementation in our email. Particularly, see the sections "Limitations and the Relay Attack" and "The Relay Attack Scenario" in [9]. Note that their description is almost a paraphrase of our email. There are some nits that we disagree with them but that doesn't matter much. They have essentially acknowledged the attacks and shared a short-term, medium-term and long-term roadmap for mitigations of the attacks. We believe this alone is sufficient supporting evidence.

Best regards,
Usama, Slava (Viacheslav), and Jean-Marie

On 11.01.26 02:17, Muhammad Usama Sardar wrote:

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 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 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

[9] https://web.archive.org/web/20260227160554/https://www.ultraviolet.rs/blog/tee-tls-privacy/

[10] https://sites.google.com/di.uniroma1.it/esorics2026/home

[11] https://portal.core.edu.au/conf-ranks/515/

[12] https://lists.confidentialcomputing.io/g/attestation/message/321

[13] https://mailarchive.ietf.org/arch/msg/ufmrg/0-gvfvCALhXbOEESkLuLCwMSXCM/