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

[Markus Rudy <[e-mail]>]

Hi Usama,

> 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 binding mechanism I have in mind is the handshake secret, or something derived from it. Would be nice to see how this breaks down under formal analysis - I've not seen an argument that would explain that intuitively.

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

I thought I was specific: you proved G3 => G2 => G1, but you don't prove it strictly, such that G1 =!> G3. I'm arguing that G1 <=> G2 <=> G3, which does not contradict your prove, but makes it more precise.

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

What I see in the paper is the following paragraph:

"After establishing an attested TLS connection, the client’s secrets (such as weights and context
data for inference) are encrypted using a key derived from the client’s application
traffic key atsc. Hence, an essential security goal is to analyze the correlation
of Evidence with atsc. The derivation of atsc includes handshake messages up
to the server’s F IN. Hence, G3 is at least as strong as G2."

That paragraph is entirely correct! However, it _does not rule out_ that you can _correlate_ to atsc by _binding_ to htsc. This is the same argument as above: (G1 <=> G3) would imply you can bind to any and correlate to atsc. Note that you are using "at least as strong" exactly as I mean it: it is as strong, but might not be strictly stronger.

> 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'm aware that the relay attack for the binding mechanisms you analyzed applies to any unrelated server being compromised. The mistake is the assumption that servers are cattle, and that you can't tell between a server compromised in someones basement and a server at your contractual $CSP. That, however, is not true: I can configure my evidence verification to only consider trusted (known) server hardware in the first place. This is independent of attested TLS, but a function of the verifier.

> We would be happy if you can share precisely what changes in Fig. 3 of [0] in the mitigations you have applied.

As I tried to explain several times, including in the post you responded to: this defect is _not part of the TLS key schedule_ - it's a shortcoming of remote attestation with current generation of TEEs! It arises due to the hardware vendors' threat model which does not cover everything that CC once advertised for. The mitigation removes the LEK attack vector, which the relay attack relies on. 

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

We agree on that in principle, but not everything is so black and white. Running in a TEE still reduces the attack surface by a lot. Physical attacks in a hyperscaler datacenter are much harder to perform than software attacks (bringing a suitcase onto the floor and hooking up a machine vs. SSHing into it remotely). TEEs still protect from co-tenants that managed to breach their containment and gain software root on the hypervisor.

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

My entire message was about that. I do think there is an option for binding securely - the handshake secret - and I made both intuitive and mathematical arguments for why that holds. These should be countered with examples, rather than beliefs.

> There are CVEs currently under responsible disclosure that I prefer not to talk about yet.

If these CVEs are related to the discussion at hand I'd like to remind you: Edgeless uses a scheme you publicly call broken (correct), and I explained the mitigation we're using and why I think this invalidates the claim, looking at the whole picture. If you think this mitigation is not enough, you are cordially invited to responsibly disclose the reason to me, too. 

Let me say one more thing: I deeply appreciate your work, I think you did the community a great service by publishing it and relentlessly insisting on driving the point home. I think I got the point by now, and what I'm trying to do is find the sweet spot between the conservative approach your paper takes and what is actually needed. Sharpening the inequalities, as my math department used to say, not sure if there's a good English idiom for this. Same as in G3 <=> G1, your paper and my argument can both be correct at the same time! If it turns out that my logic is flawed and there is a counterexample, I'd be very happy to hear it and move on with post-HS. 

Cheers, Markus

________________________________________
From: Muhammad Usama Sardar
Sent: Sunday, July 26, 2026 8:48 PM
To: Markus Rudy; [e-mail]
Cc: [e-mail]
Subject: Re: [Seat] Comments on formal analysis of relay attacks in attested TLS (CVE-2026-3369)


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:
There are CVEs currently under responsible disclosure that I prefer not to talk about yet.
One of SEAT chairs asked me not to talk about formal analysis. So I removed those parts from my presentation.
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 and known 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