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

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

Hi Paul,

On 18.06.26 22:45, Paul Wouters wrote:
> On Jun 16, 2026, at 17:02, Muhammad Usama Sardar 
> <[e-mail]> wrote:
>>
>> Respectfully, just to clarify: as the email mentions, the work was 
>> requested by Paul, the AD at that time.
>>
> i have not requested any formal verification papers.

I meant to refer to the protocol design and analysis work, not the 
paper. This is what we (Slava, Jean-Marie, and I) understood you to be 
requesting.

I am not aware of any one beyond 2-3 participants who can review the 
code. Since this WG does not have the blessing of FATT, we believe 
writing paper and getting it reviewed at conferences helps in 
independent evaluation of the design approach and artifacts, in addition 
to WG participants' review.

> I have asked the WG in the past to seriously look at intra handshake 
> options with offering a straw man idea,
Formal (Symbolic and paper-and-pen) analyses is /the most/ serious thing 
we could do. Let us know if you had/have something else in mind.
> but you seem mostly interested in disproving your own versions of 
> intra-handshake in favour of your preferred solution.

I don't think they are /my/ versions. We have collected the binding 
mechanisms from existing real-world implementations of intra-handshake 
attestation, including:

 1. Meta's AI
 2. Cocos AI
 3. Edgeless Systems
 4. CCC proof-of-concept

and discussions with the community, i.e., several research and industry 
consortia [0], including the Confidential Computing Consortium.

Technically, we do not believe we have missed any binding mechanism for 
intra-handshake attestation that might lead to different results. We 
would be happy if you could tell from the email in the thread which 
binding mechanism or point us to any missing real-world implementation 
for intra-handshake attestation you would like us to check. Formal 
analysis artifacts are easily extensible. One can check additional 
binding mechanisms by just changing the value of a single variable: 
rdata. Everything else is automated.

I also do not believe post-handshake is /my/ preferred solution. It was 
recommended by TLS WG back then, and several developers have shown their 
preference because of security, privacy and unnecessary complexity 
issues with intra-handshake attestation [1].

> I still haven't seen, or missed in the many emails, of why binding TEE 
> PKI evidence and web server tls WebPKI cannot be done with some 
> DNS/SAN binding signed by the TEE, to ensure the integrity of the TLS 
> server by the TEE (even if that is not a confidential cloud computing 
> use case) and avoiding rebinding attacks by using a different 
> compromised TEE
> via the SAN reference of the TEE.

We did not understand how to formalize that. If you could write a draft 
clarifying the protocol spec, we'll happily do the analysis for you and 
help you move the idea forward.

Best regards,

-Usama



[0] 
https://github.com/CCC-Attestation/formal-spec-KBS#upcoming-and-recent-talks-and-research-visits

[1] https://datatracker.ietf.org/doc/draft-usama-seat-intra-vs-post/