[Seat] Re: FW: New Version Notification for draft-fossati-seat-early-attestation-06.txt

[Song Haowen <[e-mail]>]

Dear all,

Without any stated assumptions, system model and threat model, Tiru's
statement is provably false. The real problem is in considering server as
honest, whereas in attestation, it is not. There is an attesting
environment which is trusted but there is target environment which is
untrusted. That is the whole point of attestation. Please read RFC 9334 to
understand this fundamental difference. Applying standard TLS 1.3 threat
model to attested TLS simply does not work. That's also why I appreciate
Usama et al.'s careful work in formalising all of this.

Tiru's statement about never discussed by the WG is also incorrect. For
example:
https://datatracker.ietf.org/meeting/125/materials/slides-125-seat-security-analysis-00

As intra-handshake.fail paper says, what we need is a connection-bound
secret for fully authenticated server in the evidence.
ClientHello...ServerHello transcript is publicly available to the attacker.
I agree with others that CVE-2026-33697 applies directly to this draft
version.

Regarding demonstrating relay for this draft, it is very simple (a million
thanks to Usama et al. for flexible artifacts). Substituting rdata =
(log_SH,pubEK) in
https://github.com/muhammad-usama-sardar/intra-handshake.fail/blob/819bb7f20ac458b27c9be2c91cce1e72b8b5f4f7/aggregate/tls-lib-simple.pvl#L692
 and
https://github.com/muhammad-usama-sardar/intra-handshake.fail/blob/819bb7f20ac458b27c9be2c91cce1e72b8b5f4f7/aggregate/tls-lib-simple.pvl#L795
in
accordance with section 5.1.1. of this draft proves that the property G3
fails. Hence, CVE-2026-33697 applies to this draft.

I am thunderstruck by Tiru's ask for "clearly stating the attacker
capabilities" for something which has been clearly stated to the extent of
being formally specified in
https://www.researchgate.net/publication/408219182_Intra-handshakefail_CVE-2026-33697_High-severity_CVE_in_Attested_TLS
 and https://doi.org/10.1145/3779208.3785387. Maybe a good starting point
for him is to state what is unclear in the threat models and formalisation
of these papers, or what precisely is his disagreement. As I said before,
ignoring several years of work which is peer-reviewed at top security
conferences and acknowledged by all vendors and instead starting from
scratch is wastage of WG time.

Do we want to develop a protocol which is exploited in the wild like
CVE-2026-33697?

Thanks

Haowen Song

tirumal reddy <[e-mail]> 于2026年8月10日周一 16:06写道：

> Hi Songbo,
>
> You haven't addressed my core point: *two TLS connections cannot share
> the same ClientHello...ServerHello transcript.* Without showing how an
> attacker can force an honest peer to repeat its random and ephemeral key
> shares, relaying Evidence bound to a transcript isn't possible.
>
> Regarding the papers you referenced:
>
>    -
>
>    *WG Consensus Needed:* The threat vectors and adversary models from
>    these papers were never discussed or agreed upon by the WG.
>    -
>
>    *State the Model Directly:* Rather than pointing to external papers,
>    please state the specific attacker capabilities you want the WG to
>    consider. The WG needs to evaluate whether this adversary model is in scope
>    before we assess any solutions against it.
>
> Let's focus the thread on these two points:
>
>    1.
>
>    Demonstrating how transcript collision/relay is possible in your model.
>    2.
>
>    Clearly stating the attacker capabilities for the WG to evaluate.
>
> -Tiru
>
> On Mon, 10 Aug 2026 at 13:09, Songbo Bu <[e-mail]> wrote:
>
>> Tiru,
>>
>> Thank you.
>>
>> I agree with the threat model explained in section 6.1 of
>> intra-handshake.fail (
>> https://www.researchgate.net/publication/408219182_Intra-handshakefail_CVE-2026-33697_High-severity_CVE_in_Attested_TLS)
>> and in more detail in section 4 of ID-Crisis (
>> https://doi.org/10.1145/3779208.3785387) So I am not sure what's the
>> point in repeating it here. Do you disagree with that threat model? If yes,
>> what narrowly?
>>
>> Breaking the single server is explained in Section 9 of ID-Crisis. Do you
>> disagree with that? If yes, what narrowly?
>>
>> On identity: I asked identity and proof-of-possession of the key of the
>> *cloud provider*, not the one with TEE. This too is demonstrated in
>> ID-Crisis.
>>
>> Best,
>> Songbo
>>
>>
>> tirumal reddy <[e-mail]> 于2026年8月10日周一 12:53写道：
>>
>>> Hi Songbo,
>>>
>>> It is not possible for two TLS connections to share the same
>>> ClientHello...ServerHello transcript. Each peer contributes a fresh random
>>> and a fresh ephemeral key share per connection, so the transcript is
>>> jointly determined by both peers. This holds even when one peer is the
>>> adversary: it cannot force the honest peer's independent per-connection
>>> random and key share to repeat. The transcript of one connection therefore
>>> cannot be reproduced in another, so Evidence bound to it cannot be relayed.
>>>
>>> If you disagree, please demonstrate how two TLS connections can have
>>> the same  ClientHello...ServerHello transcript.
>>>
>>> On identity: Section 5.1.1 binds the hash of the attester's TLS identity
>>> key (i.e., the public key of the attester's end-entity certificate used for
>>> authentication), and proof of possession of that key is provided by
>>> CertificateVerify in the same handshake.
>>>
>>> Please also explain *how compromising a single server breaks security
>>> for connections to other servers*.
>>>
>>> You may want to state the attacker capabilities directly rather than by
>>> reference to the paper, since the threat model is what is under discussion.
>>> I would like the WG to discuss this attack and decide which adversary model
>>> is in scope, so that it can be added to the use-cases draft as you proposed
>>> in the other thread, and each solution can then be assessed against the
>>> agreed attack model.
>>>
>>> Best Regards,
>>> -Tiru
>>> On Sat, 8 Aug 2026 at 19:21, Songbo Bu <[e-mail]> wrote:
>>>
>>>> tirumal reddy <[e-mail]> 于2026年8月7日周五 18:29写道：
>>>>
>>>>> The attestation binder in Section 5.1.1 binds the Evidence to the
>>>>> ClientHello...ServerHello transcript, which commits to both peers'
>>>>> ephemeral key shares. The binder additionally incorporates the hash of the
>>>>> attester's TLS identity key (the public key of the attester's end-entity
>>>>> certificate used for authentication).  The binding is therefore specific to
>>>>> the two endpoints of the TLS connection in which the Evidence was produced.
>>>>>
>>>> Hi Tiru,
>>>>
>>>> It is important to understand that:
>>>> partial transcript binding ≠ channel-secret binding
>>>> There is no secret in ClientHello...ServerHello transcript, and can
>>>> simply be relayed over by the target environment, analogous to the one
>>>> shown in intra-handshake.fail paper.
>>>>
>>>> Also, for example, it does not bind to is the identity and
>>>> proof-of-possession of the key of the cloud provider. So we do not know
>>>> which server it is and hence, it breaks if a single server in the whole
>>>> world breaks, as shown in the ID-Crisis paper.
>>>>
>>>> Best,
>>>> Songbo
>>>>
>>> _______________________________________________
> Seat mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>