[Seat] Re: Regarding comprehensive mitigations for CVE claims such as CVE-2026-100835, CVE-2026-92701, CVE-2026-92702, CVE-2026-33697, and other resolutions of related claims

[kayode Elekula <[e-mail]>]

Hi ,

Thanks for the detailed technical feedback. I have reviewed the cited SEAT
drafts, the current architecture work, and the formal analysis referenced
in the discussion.

I think there is agreement on an important point: the current SEAT work
does address session/channel binding, and the formal symbolic analysis
provides a security analysis of the specified mechanisms against the
modeled relay scenarios. I am not disputing that result.

The distinction I am trying to examine is what security property is
uniquely obtained by placing attestation inside the TLS handshake.

The current SEAT architecture explicitly considers both intra-handshake and
post-handshake attestation, including a combined model. It also describes a
post-handshake deployment in which application data can be withheld until
attestation has completed.

That creates a more precise question regarding the fail-closed argument.

The claim that relying on post-handshake attestation necessarily breaks
fail-closed transport behavior does not appear to follow from the
architecture alone if the post-handshake mechanism enforces:

*TLS established → attestation pending → no authorization / no
application-data release → attestation accepted → authorization →
application-data release*

If that gate is correctly enforced, the relevant security question becomes
whether there is some security property provided by intra-handshake
attestation that cannot be reproduced by this model.

I therefore propose the following research question:

*Under what security conditions does intra-handshake attestation provide a
security guarantee that cannot be equivalently achieved by post-handshake
attestation combined with an enforced authorization and application-data
release gate?*

This can be tested rather than argued rhetorically.

The relevant attack surface includes:

   1. premature application-data release;
   2. premature secret release;
   3. attestation-result substitution;
   4. state changes while attestation is pending;
   5. authorization races;
   6. session-binding failures;
   7. failed-attestation recovery;
   8. behavior after previously accepted Evidence becomes stale.

The existing SEAT work already provides important mechanisms for several of
these, including session binding, relay resistance, runtime attestation,
and re-attestation. Those mechanisms should therefore be treated as the
baseline rather than as gaps.

I also agree that early and ongoing attestation should not be presented as
mutually exclusive. The current architecture explicitly allows their
combination where both initial trust establishment and durable session
integrity are required.

The question I would like to resolve is therefore narrower:

*Is there a security property that requires attestation to occur inside the
TLS handshake, or can the same property be achieved by correctly enforcing
authorization and data-release semantics after the handshake?*

I am not presenting a new mechanism or claiming a novel contribution at
this stage. The next step is to formalize the competing models and attack
the distinction directly, including the assumptions required for each model.

That should allow the discussion to move from architectural preference to a
falsifiable security-property comparison.

Cheers,
Kayode


On Mon, Oct 5, 2026, 7:56 PM Nathanael Ritz <[e-mail]> wrote:

> Hi,
>
> Some of the technical arguments and CVE identifiers raised in the recent
> (duplicated) thread(s) appear to conflate third-party software bugs,
> requirements already satisfied by the working group drafts, and
> platform-level hardware vulnerabilities outside the scope of transport
> protocols.
>
> For recent subscribers or newer readers, the relevant points break down
> into these categories:
>
> A). Implementation Flaws and Scope Boundaries
>
> The published attestation CVEs cited in the subject represent critical
> defects, but they highlight the necessity of correct integration between
> the RATS layer and the transport protocol, rather than an inherent failure
> of attestation itself. While vulnerabilities like CVE-2026-33697
> demonstrate the severe risks of cross-session relay and diversion, the SEAT
> working group's use-cases document explicitly incorporates these lessons by
> mandating cryptographic binding to the communication channel.
>
>
> B). Protocol Work Already Addressed by Named Drafts
>
> The normative mechanics in `draft-fossati-seat-early-attestation-07` and
> the structural patterns in `draft-many-seat-architecture-00` already
> directly eliminate the relay vectors raised in the thread:
>
> - Transcript-Bound Relay Resistance: Section 5.1 of
> `draft-fossati-seat-early-attestation-07` defines `attest_base` derived
> from `Hash(ClientHello...ServerHello)`. Because both endpoints supply
> independent ephemeral key shares and random nonces, two-sided uniqueness
> prevents transcript reproduction, and binder mismatches terminate the
> session with a fatal `attestation_failed` alert (Section 5.1.2). Recent
> formal symbolic verification of this exact mechanism using ProVerif
> confirms that transcript-bound attestation deterministically binds the
> connection to the application-traffic keys (kc) via standard TLS 1.3 key
> confirmation (Finished), proving that strong session binding is achieved
> without modifying the standard TLS 1.3 key schedule [0][1].
>
> - Public Key Binding vs. Key Provenance: Section 5.2 mandates that the
> attestation binder cryptographically tie the Evidence to the TLS Identity
> Key public key hash (`TLS_Client_Public_Key` / `TLS_Server_Public_Key`).
> While this secures the channel against relay attacks by binding it to the
> authenticating identity, preventing quote substitution (Key Substitution
> Resistance) relies on the complementary RATS-layer platform guarantees
> (e.g., that the key was generated inside the TEE and is non-exportable), as
> noted in Section 8.2.
>
> - Attestation Timing: Pitting "early attestation" against "continuous
> attestation" presents a false dichotomy. Handshake-time attestation
> provides essential fail-closed behavior before application data flows,
> preventing leaks to workloads compromised at launch. As referenced in the
> individual architecture draft, initial attestation establishes baseline
> trust, while long-lived connection state drift is a separate dynamic
> addressed via re-attestation mechanisms [3].
>
> Furthermore, Section 5.1.1 of `draft-ietf-seat-use-cases-01` (Runtime
> Secret Provisioning) [2] provides an illustration of why handshake-time
> attestation is helpful: secrets must not be released to a workload whose
> integrity has not yet been established. Relying exclusively on
> post-handshake attestation breaks native transport-level fail-closed
> guarantees and forces applications to implement custom, potentially
> error-prone gating mechanisms simply to prevent data from flowing
> prematurely.
>
> ---
>
> In brief, the protocol mechanics required to guarantee relay resistance
> and channel binding are already specified in existing proposed documents
> for the SEAT WG, and the formal proofs supporting their security properties
> are available for review [1]. The working group has been encouraged to
> engage with the existing official work-item of the SEAT WG, the SEAT
> use-cases document [*] on GH to help us further contribute positively [4].
>
> Cheers,
> Nathanael
>
> [*] https://github.com/ietf-wg-seat/draft-ietf-seat-use-cases
>
> [0] "SEAT Architecture: Community models for intra- and post- TLS 1.3
> handshake attestation using symbolic formal analysis"
> https://mailarchive.ietf.org/arch/msg/seat/upV8i1kPT-3jHTAYkUOjUA92sZE/
>
> [1] "SEAT Architecture Symbolic Models (aTLS/intra)":
> https://github.com/tls-attestation/seat-architecture/tree/main/symbolic-models/aTLS/intra
>
> [2] "Runtime Secret Provisioning, Security Goals and Use Cases for
> Integrating Remote Attestation with Secure Channel Protocols"
> https://www.ietf.org/archive/id/draft-ietf-seat-use-cases-01.html#name-runtime-secret-provisioning
>
> [3] "Timing Models, SEAT Architecture"
> https://www.ietf.org/archive/id/draft-many-seat-architecture-00.html#name-timing-models
>
> [4] "SEAT Use Cases Rewrite"
> https://mailarchive.ietf.org/arch/msg/seat/PbeZ9mH6mX0NNpAxWjkWx5bInNg/
> _______________________________________________
> Seat mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>