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

[Chengxin Huang <[e-mail]>]

Hello everyone,

I agree that this draft uses a naive binder, and CVE-2026-33697 is
trivially applicable on this draft, because there is no secret in the
binder of Sec. 5.1.1. So even without doing any formal analysis, it is
obvious to me.

But since it was requested by the authors to "demonstrate" it, I went ahead
and tried `rdata = (pubEK,log_SH)` in [client] and [server] for this draft
in the commit `819bb7f` in [repo]. Property G3 returns false, confirming
the correctness of formal models.

A bigger question in my mind is: isn't this draft more suitable for TLS
than SEAT?

Regarding the attacker capabilities, Section 6.1 of [intra-fail] is
"clearly" stating those and [repo] is even formalizing it. What is the
ambiguity in it?

It seems that Nathanael is probably the only one denying the vulnerability
CVE-2026-33697 that all vendors and draft authors have publicly
acknowledged [intra-fail-id], and widely accepted and was being wildly
exploited. I am yet to see any technical substance in his potential denial.

I have also not seen any technical substance for his conclusion
"draft-fossati-seat-early-attestation-06 was applied to binder 7" and
"README was updated to suggest that draft-fossati-seat-early-attestation-06
is represented by what the page labels as "binder 7""

Best regards,
Chengxin Huang


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

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

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

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

[intra-fail-id]
https://www.ietf.org/archive/id/draft-intra-handshake-fail-04.html#section-5

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

> 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]
>>
> _______________________________________________
> Seat mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>