[Ufmrg] Re: [Seat] Re: Comments on formal analysis of relay attacks in intra-handshake attestation (CVE-2026-33697)

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

Hi Nathanael,

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

On 28.07.26 16:48, Nathanael Ritz wrote:
> In Usama's July 6 email [0], I was invited to present a formal 
> counter-example to Section 9 of the paper. The `binder6` model 
> (`tls-lib-simple.pvl`) provides that exact counter-example by 
> addressing the core architectural requirements:

Following the requests of many other WG/RG participants (e.g., [7]), the 
email [0] clearly asks for a *property* that:

 1. the hybrid construction (intra- + post-handshake attestation) /can/
    satisfy, but
 2. post-handshake attestation alone /cannot/ satisfy

What you are changing is the model and not presenting a property. So 
either the link [0] is wrong or else this needs a clarification. So is 
your claim that the three binding properties /cannot/ be achieved by 
post-handshake attestation alone? I think that claim is very easily 
falsifiable. So I am not sure what new information you are bringing on 
the table.

Which specific statement in Sec. 9 of the paper [6] do you claim to have 
found a counter-example?

> 2. Infrastructure identity is preserved in `rdata`: Binding `pubLTK` 
> and `ID_S` directly inside the hardware-signed quote payload (`rdata`) 
> anchors infrastructure identity through the Attestation Key (`privAK`) 
> itself. This secures identity without altering `CertificateVerify` or 
> modifying the TLS 1.3 state machine.
The problem here is that this does not provide proof-of-possession of 
privLTK, while CertificateVerify does exactly that.
> 3. Key schedule compliance: Using the standard handshake traffic write 
> keys `(ksh, kch)` inside `rdata` binds the evidence to the handshake 
> state at `ServerHello` while leaving the HKDF derivation tree 100% 
> compliant with RFC 9846 §7.1.

I am not sure reusing the keys intended for a specific purpose is 
helpful. This will not be visible in ProVerif but I think this will 
probably break the computational proofs of TLS 1.3. I think we would 
need to check with TLS WG if they are fine with it.

Best regards,

Usama, Slava, and Jean-Marie

> [0] 
> https://mailarchive.ietf.org/arch/msg/seat/T78G1TFWqcj3O9vrCvNihcn8QeU/
>
> [1] 
> https://mailarchive.ietf.org/arch/msg/seat/S3l-tc-pnfHs9rcAfeuMGyVzW1Q/
>
> [2] 
> https://mailarchive.ietf.org/arch/msg/seat/RhYelVXkqUDKa3CKLvkqQU4Z23M/
>
> [3] 
> https://github.com/nathanaelritz/intra-handshake-paper/tree/3719fddd7cf0be930d1c256bac1096f7c53494f0/proposal
>
> [4] 
> https://github.com/nathanaelritz/intra-handshake-paper/commit/3719fddd7cf0be930d1c256bac1096f7c53494f0#diff-8ffc30d09ebb6bc1fd9df2ae48d0a0bc0289582ea40c99f6c2ea66ee738f189d
>
[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

[7] https://mailarchive.ietf.org/arch/msg/seat/2_aGylmFHoLmqN7BBcYVoH-rNJk/