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

[Songbo Bu <[e-mail]>]

Hello Nathanael,

Ironically, the approach to keep working on the solution without knowing
the property is ad-hoc approach. As clarified before, the constructive
purpose is to judge whether the complexity of intra-handshake attestation
is required to satisfy some property. If we do not know the goal we are
trying to achieve, how can we ever achieve it? So property is critical to
SEAT success and this is surely a technical approach. Several members have
supported this approach.

Formally, attestation binder in section 5.1.1 of the draft-06 does not
introduce anything new that needs a new formal analysis.
Intra-handshake.fail and CVE-2026-33697 apply as is.

The fundamental misunderstanding you are having is that the book by Boneh
and Shoup does not talk about attestation at all. The threat model for
attestation is different from traditional authentication mechanisms. Part
of the server is untrusted in attestation, which is not the case in
traditional authentication mechanisms and hence your citation of the book
and protocol 'AKE4' is completely irrelevant to this technical discussion.

Both papers ID-Crisis and intra-handshake.fail present concrete
counter-examples with complete technical details with open-source code,
which apply to this draft. Would we like to design a protocol that breaks
if any single machine in the whole world breaks? It is unclear what you are
trying to achieve by raising these questions.

Best,
Songbo

Ionut Mihalcea <[e-mail]> 于2026年8月6日周四 18:49写道：

> Hi,
>
> Agree with Tiru, quoting from the CVE: "Because the attestation evidence
> is bound to the ephemeral key *but not to the TLS channel*, possession of
> that key is sufficient to relay or divert the attested TLS session"
> (emphasis mine), and also from Tiru's initial email: "the resulting binder
> is unique to the connection (two-sided uniqueness). Evidence generated in
> one connection therefore cannot be replayed in another."
>
> I also continue to disagree with the assumption that binding to or
> correlation with the application traffic secret is the only possible secure
> construction.
>
> Thanks,
> Ionut
>
> *From: *tirumal reddy <[e-mail]>
> *Date: *Thursday, 6 August 2026 at 10:27
> *To: *Muhammad Usama Sardar <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>
> *Subject: *[Seat] Re: FW: New Version Notification for
> draft-fossati-seat-early-attestation-06.txt
>
> Hi Usama,
>
> CVE-2026-33697 was not established against this draft. The binders
> analyzed in your paper differ from the one specified in Section 5.1.1 of
> this draft, and the models in your paper seem to add a dual
> CertificateVerify that this draft does not specify. The CVE is therefore
> not demonstrated against draft-fossati-seat-early-attestation.
>
> If you maintain that it applies, please demonstrate the relay attack
> against the binder as specified in Section 5.1.1: the
> ClientHello...ServerHello transcript checkpoint plus the hash of the public
> key of the attester's end-entity certificate used for authentication with a
> standard CertificateVerify specified in TLS 1.3.
>
> We will review any concrete demonstration.
>
> Best Regards,
> -Tiru
> _______________________________________________
> Seat mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>