[Seat] Re: Comments on formal analysis of relay attacks in attested TLS (CVE-2026-3369)

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

Hi Markus,

Thanks for sharing your concerns on the presentation. Just to clarify, 
there were three restrictions in the IETF 126 SEAT presentation you are 
mentioning:

 1. There are CVEs currently under responsible disclosure that I prefer
    not to talk about yet.
 2. One of SEAT chairs asked me not to talk about formal analysis. So I
    removed those parts from my presentation.
 3. Our request for slot on intra-vs-post which was supposed to talk
    about your point#1 was not accepted.

So admittedly my presentation [1] had gaps. However, I feel that the 
paper [0] shared already does not have any such gaps. So it would be 
really helpful if you can anchor your questions to the paper [0] rather 
than the short presentation [1]. I still cannot talk about #1, but I'll 
try to address the rest.

With that in mind, please see inline:

On 26.07.26 14:33, Markus Rudy wrote:
> In my opinion, the backing paper has proven to be very useful for refining the threat model of remote attestation in general, not restricted to attested TLS. The key insight (which was already present in the ID crisis paper) is that a single compromised machine can render any remote attestation vulnerable, unless this attack vector is mitigated explicitly.

Please see second paragraph of Sec. 8 in paper [0] which explains the 
difference in the two papers. In particular, identity crisis [2] does 
not analyze the binding mechanisms and practical implementations. [2] 
also did not have /correlation/ goals for /relay/ attacks.

On the other hand, [0] analyzes all(at the time of writing of paper) 
binding mechanisms used or under discussion andknown practical 
implementations of intra-handshake attestation. If someone thinks a 
specific binding mechanism is missing that might lead to different 
results for intra-handshake attestation, please let us know, and we will 
happily share the analysis with the WG. The analysis is fully automated 
and requires changing a single variable, and will (hopefully) be very 
fast. Unless the binder is really complicated (which I don't see why), 
we can share the results within a day for any desired binding mechanism.

> However, I want to challenge the following perspectives voiced by the authors in various forums:
>
> 1. Intra-handshake attestation can't be secure because it can't bind strongly enough to the TLS handshake.
> 2. All existing attested TLS implementations are vulnerable to relay attacks.
>
> Apologies if my understanding of these positions is wrong, I'm happy to be corrected. But these are the positions I understood, and I don't agree with.
>
> ad 1)
>
> The authors prove that binding to later stages in the handshake is (equally or) more secure than earlier stages (the G3 => G2 => G1 argument). The paper then concludes implicitly that the strongest binding is the obvious security goal,

Please see Sec. 6.4 in paper [0] which /explicitly/ proves it 
cryptographically, and let us know what specifically you disagree with. 
Just vaguely disagreeing is not very helpful.

Please see first paragraph of G_3 in Sec. 6.3 in paper [0], which 
explains explicitly why it is an /essential/ goal.

So we don't really understand why you call it 'implicitly.'

>   and that intra-handshake can never match that goal because the binding material is not available at that point in time.
The key points at an abstracted level were summarized in slide 2 of [1]. 
Which key do you think the security of TLS depends on: handshake traffic 
key or application traffic key?If the former, I would be interested in 
knowing the rationale.
>   I take objection to the assumption that G3 is the only secure binding mechanism. What the paper _does not show_ is that G3 is strictly stronger than G1. You can make a simple proof by contradiction, assuming G1 does not imply G3 and then reaching the contradiction that normal TLS is not secure against active MITM attacks. This is due to the fact that the binding material may not be present _during_ the handshake, but the entire handshake being authenticated _after the session is established_, including the handshake secret. I can share the verbose argument, if someone's interested.
We are looking into your argumentation and will share rigorous analysis 
later on.
> ad 2)
>
> The paper analyses attested TLS implementations, which are (mostly?) using an ephemeral key inside the TEE that is bound to the attestation. The argument of the paper is that, if that EK leaks, it can be used by an adversary. But why is the LEK vector something we need to take into account? The paper argues with implementation errors and attacks that are not covered by the CC threat model (i.e., physical).

Please see #4 in Sec. 7.1 of [0] for several practical reasons. Do we 
want that LEK in an unrelated server anywhere in the world breaks our 
connection? That is clearly too bad, and the world is probably better 
with standard TLS than have such a broken design of attested TLS.

> I don't see why the former should be considered for protocol design at all: how do you specify protocols while assuming that the implementation will inevitably leak the very secrets it ought to protect?
The same argument above applies here too.It's not necessarily the key of 
the /desired server/ which is leaked.
> The latter is true, and it's the key insight for me, but I think this is something to be addressed on the attestation level itself, not in the composition of attestation and TLS. The vector applies to remote attestation without TLS, for example a proof-of-possession for a decryption key used for data sent over an insecure channel (attested ACME might be an example). It can be closed by ensuring the extraction vectors are closed, for example through Intel's Platform Ownership Endorsement combined with the physical security guarantees of the endorsing cloud provider. This is the mitigation chosen by WhatsApp and Edgeless Systems, and I did not hear a convincing argument yet for why it's wrong.

First, the specs of Intel's Platform Ownership Endorsement are not 
precise and contradictory at places. We would be happy if you can share 
precisely what changes in Fig. 3 of [0] in the mitigations you have applied.

Second, this requires trusting the cloud provider, contrary to the whole 
claim of confidential computing.

Third, what we report is the binding weakness. We do not believe it can 
be reasonably eliminated by anything other than changes in the protocol.

Best regards,

Usama, Slava, and Jean-Marie

[0] 
https://www.researchgate.net/publication/408219182_Intra-handshakefail_CVE-2026-33697_High-severity_CVE_in_Attested_TLS

> [1]:https://datatracker.ietf.org/meeting/126/materials/slides-126-seat-binding-properties-of-expat-00
[2] 
https://www.researchgate.net/publication/398839141_Identity_Crisis_in_Confidential_Computing_Formal_Analysis_of_Attested_TLS 


[3] https://github.com/muhammad-usama-sardar/intra-handshake.fail