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

[Steve <[e-mail]>]

Dear all,

I have reviewed this draft. Since there is no connection-bound secret in
the binder in 5.1.1 and server is not yet fully authenticated, I agree with
others that CVE-2026-33697 is directly applicable to draft version -06.

I confirmed this by replacing existing `rdata` in [1] and [2] by `rdata =
(log_SH,pubEK)` for this draft. Property G3 evaluates to false, confirming
that it is prone to CVE-2026-33697.

I also agree that Tiru's blank cheque statement without any system and
threat model does not hold.

Given the precisely stated and formally specified threat models in [3,4]
with open-source ProVerif models [5,6] under Apache License v2.0, I am
open-eyed by the requirement for "clearly stating the attacker
capabilities". The request to re-state on the list, what is stated in the
papers and reviewed and accepted at top conferences, is not a good use of
time of the members and readers of this list. Someone who disagrees with
the threat model in these papers and formal models must precisely and
concisely clarify the concerns so that WG can evaluate and address those
concerns.

Also, diversion attacks [4] are applicable to this draft version because
there is no proof-of-possession of the key of the cloud provider.

We will discuss further at Cloud Security Alliance (CSA-GCR) community and
may provide more feedback later.

Best regards,

Steve Luo

Research Analyst, Cloud Security Alliance (CSA-GCR)

[1]
https://github.com/muhammad-usama-sardar/intra-handshake.fail/blob/819bb7f20ac458b27c9be2c91cce1e72b8b5f4f7/binder7/tls-lib-simple.pvl#L684

[2]
https://github.com/muhammad-usama-sardar/intra-handshake.fail/blob/819bb7f20ac458b27c9be2c91cce1e72b8b5f4f7/binder7/tls-lib-simple.pvl#L774

[3]
https://www.researchgate.net/publication/408219182_Intra-handshakefail_CVE-2026-33697_High-severity_CVE_in_Attested_TLS

[4] https://doi.org/10.1145/3779208.3785387

[5] https://github.com/muhammad-usama-sardar/intra-handshake.fail

[6] https://github.com/CCC-Attestation/formal-spec-id-crisis

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