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

[Song Haowen <[e-mail]>]

Dear all,

It's surely helpful for the WG to use Usama's artifacts which have been
deeply discussed in the Confidential Computing Consortium (I have watched
the recordings mentioned in the GitHub repository:
https://github.com/muhammad-usama-sardar/intra-handshake.fail#upcoming-and-recent-talks-and-research-visits
and
CCC list archives) and have gone through reviews from several top security
conferences that I trust, such as AsiaCCS and ESORICS. It is surely an
untiring effort of several years to go to the nitty gritty details of the
key schedule. Thus, I do not see value in Nathanael's artifacts to reinvent
the wheel from scratch.

I have reviewed Usama's paper and artifacts in thorough detail. ProVerif
artifacts provide the WG a concrete security property as a baseline for
evaluation of proposals. The system model and threat model are justified
for the confidential computing scenario, which is the fundamental use case
of attested TLS and which is where I would like to use it. All useful
binding mechanisms are considered. Other binding mechanisms will give
similar results, because intra-handshake is fundamentally limited unless we
change TLS 1.3 drastically. If someone disagrees, one has to show the
concrete value of rdata that I can put in ProVerif and check myself on
Usama's artifacts. I appreciate the flexibility of Usama's artifacts that
doing such an analysis is quite easy.

>From the GitHub repository, it is clear that all vendors and proponents of
intra-handshake have acknowledged vulnerabilities highlighted in the paper:

   - Ultraviolet Cocos AI:
   https://github.com/ultravioletrs/cocos/security/advisories/GHSA-vfgg-mvxx-mgg7
    and https://www.cve.org/CVERecord?id=CVE-2026-33697
   - Edgeless Systems:
   https://github.com/edgelesssys/contrast/security/advisories/GHSA-hjgc-jc5v-fw7h
   - Meta: https://www.cve.org/CVERecord?id=CVE-2026-33697
   - Confidential Computing Consortium reference implementation of
   intra-handshake attestation:
   https://github.com/CCC-Attestation/attested-tls-poc/pull/58
   - Vulnerable draft-fossati-tls-attestation withdrawn:
   https://datatracker.ietf.org/doc/draft-fossati-tls-attestation/10/

It is also clear that it is the most severe vulnerability, crossing all
other vulnerabilities in the literature of confidential computing, and
requiring no physical access:
https://github.com/muhammad-usama-sardar/intra-handshake.fail#comparison-with-other-vulnerabilities-in-confidential-computing-literature

I also agree with all the clarifications provided by Usama et al. The
distinction between handshake secret and handshake traffic secrets is
indeed critical in TLS 1.3 key schedule. Certificate is public information.
Anyone can have it. You can use my certificate. The private information
must be used to create proof-of-possession. Removing this, we have no
guarantee on the cloud provider and diversion attacks of AsiaCCS paper by
Usama et al. apply. Reuse of keys for multiple contexts is a well-studied
cryptographic problem and can only be seen in a computational analysis
tool. So I am completely unconvinced by Nathanael's proposal of using
secrets from key schedule directly in the binder. As authors clarified,
ProVerif code is not wired up in real implementation at all. Authors'
derivation of cryptographic exporter is cryptographically correct. As
others pointed out, we have used similar derivation for early and standard
exporters in TLS 1.3 for a decade, and no CVE is yet known to my knowkedge.
Nathanael has to show a concrete attack trace if he sees one. I haven't
seen that yet. Reading the paper title should make clear that the paper is
about intra-handshake, and thus Nathanael's point on standard exporters in
RFC9846 is moot. I confirm that early_exporter_secret ems0 is correctly
generated in ProVerif, and the authors' choice for the macro to return
early exporter value exp0 is perfectly valid because ems0 is never required
other than simply generating exp0. PSK input is indeed always there in the
key schedule of TLS 1.3 (Figure 5 of RFC9846), regardless of whether it is
PSK-based handshake or not. Of course, early_exporter_secret ems0 has
nothing to do with the standard exporter at all. Presenting a weird
"counter-example" to the paper's conclusion of 'may not be possible' does
not falsify the 'may' and is thus not a counter-example at all. Drastically
changing the system model and the threat model will surely lead to
different results. Authors are making claims in the context of confidential
computing.


Muhammad Usama Sardar <[e-mail]> 于2026年7月29日周三
04:37写道：

> Hi Nathanael,
>
> Markus kindly clarified what he would like to see in more detail. Could
> you please do the same to help keep this discussion more focused? Here is
> my understanding of the points where you disagree:
>
>    1. While the paper [6] claims it 'may not be possible' to achieve
>    level 3 binding in intra-handshake attestation, you believe it is possible.
>    Setting aside what you model and prove is correct or not, I don't see how
>    this contradicts the claim 'may not be possible' in the paper.
>    2. We haven't yet seen a property that the hybrid construction (intra-
>    + post-handshake attestation) *can* satisfy, but post-handshake
>    attestation alone *cannot* satisfy, unless you are implicitly implying
>    that level-3 binding cannot be achieved by post-handshake attestation.
>    Please clarify explicitly.
>
> Is there something I have missed? As mentioned before to Markus, I believe
> it is much more organized to have them answered in detailed technical
> report. So more important than the discussion below is the
> correction/addition/edits in above statements.
>
> Also, I believe it will be more constructive to respond point by point to
> [5] where you disagree, so we can do further working to share with the
> WG/RG.
>
> We will then work on it and share with the WG/RG.
>
> On 28.07.26 20:51, Nathanael Ritz wrote:
>
> On Tue, 28 Jul 2026 at 10:00, Muhammad Usama Sardar <
> [e-mail]> wrote:
>
>> This does not address any of the questions in [5] where your working was
>> shown to be not correct, and these inaccuracies still remain here too.
>>
> [NR}: I disagree, but the authors are welcome to cite my work and my words
> directly in relationship to any questions that are, in their opinion, left
> unanswered so that I can address them directly rather than guessing.
>
> For example, our responses to your #2 in [5].
>
> For clarity, nothing has changed in the key schedule of TLS 1.3 for quite
>> long time (I think draft-20 which became RFC8446). Saying that RFC9846 is
>> "new work" for key schedule is almost surely wrong. Maybe Ekr can confirm.
>>
> [NR]: If it is being stated that I am suggesting RFC9846 includes 'new
> work for key schedule', please quote me directly, as I am currently unclear
> to what context and statements are being referenced to right now.
>
> Thanks for clarifying. 'non-conformant Key Schedule' and then mention of
> RFC 9846 §7.5 was unclear for #2 in [5]; it has stayed the same for pretty
> much a decade. We believe that both points in your #2 about key schedule
> are not valid and we justified it technically in [5], to which we have seen
> no response.
>
> Best regards,
>
> Usama, Slava, and Jean-Marie
>
> [5]
>> https://mailarchive.ietf.org/arch/msg/seat/dKVqaL8RJSQLonIEmtzrDYEXEAU/
>>
> [6]
> https://www.researchgate.net/publication/408219182_Intra-handshakefail_CVE-2026-33697_High-severity_CVE_in_Attested_TLS
>
>
> _______________________________________________
> Seat mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>