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

[Nathanael Ritz <[e-mail]>]

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/