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

[Nathanael Ritz <[e-mail]>]

Top posting, I agree with Ionut and Tiru. I think that focusing efforts on
enhancing the WG’s use cases draft in this direction, as Tiru recently
suggested [0] is the productive way forward here.

Cheers,
Nathanael

[0]
https://mailarchive.ietf.org/arch/msg/seat/UbeWaEYQrF2eQRV-9u68DlVaxt4/

On Mon, Aug 10, 2026 at 6:51 AM Steve <[e-mail]> wrote:

> <snip>
>
> Ionut Mihalcea <[e-mail]> 于2026年8月10日周一 19:00写道：
>
>> I agree, we need to agree on the attacker models we're interested in
>> addressing within the WG. Don't think there's any point in continuing this
>> discussion before.
>>
>> Cheers,
>> Ionut
>>
>> *From: *Song Haowen <[e-mail]>
>> *Date: *Monday, 10 August 2026 at 11:36
>> *To: *tirumal reddy <[e-mail]>
>> *Cc: *Songbo Bu <[e-mail]>; Ionut Mihalcea <
>> [e-mail]>; Muhammad Usama Sardar <
>> [e-mail]>; [e-mail] <[e-mail]>; nd <
>> [e-mail]>
>> *Subject: *[Seat] Re: FW: New Version Notification for
>> draft-fossati-seat-early-attestation-06.txt
>>
>> <snip>
>>
>> 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]
>>
>> _______________________________________________
>> Seat mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> _______________________________________________
> Seat mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>