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

[Songbo Bu <[e-mail]>]

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