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

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

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