[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

[Nathanael Ritz <[e-mail]>]

Please see comments below with [NR]:

On Mon, 5 Oct 2026 at 15:51, kayode Elekula <[e-mail]> wrote:

> 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.
>
> [snip] [...]
>
*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?*
>
[NR]: My current go-to example is EAP-TLS (RFC9190). Attested EAP-TLS could
augment the security properties of standalone EAP-TLS. For example, it's
possible that a device might have a valid certificate but an infected or
compromised OS deployment. With standalone EAP-TLS, the authenticator would
still issue an EAP-Success signal and install pairwise keys, whereas a
properly implemented deployment of Attested EAP-TLS could potentially catch
the compromise and fail the attestation challenge. However--RFC 9190
strictly prohibits post-handshake client authentication in EAP-TLS because
EAP-TLS has no ongoing application-data stream. I.e., in a very concrete
way for EAP-TLS, if attestation is not bound inside the handshake, it
cannot happen at all.

[NR]: Beyond that, this WG has debated whether or not post-handshake can
support TLS ressumption (which I have incidently argued /should be/
possible [5]), but it's a debate that doesn't exist with intra-handshake
approaches as far as I can see.

[NR]: Outside of even that, I think Serhii Nikolaichuk has demonstrated
(with concrete data points [6]) information that effectively affirms the
approach the SEAT Architecture draft takes: which is that intra- or post-
handshake is largely a matter of implementor preference, as "secure
evidence and attestation transport" is basically cryptographically
identical to each other regardless of attestation timing. Serhii is welcome
to provide further specificity here if I'm off-base.


> 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.
>
[NR]: So, when neither approach offers a distinct cryptographic advantage,
one might ask a correlary as such: "Since a handshake is required to convey
Evidence in *every* use case, when is the additional complexity [7] of
post-handshake attestation justified?" Even though I understand this
reversal of the underlying premise could be read as a base "gotcha", I
honestly think it's just a real question implementers can ask and answer
for themselves, depending on the use case!

Cheers,
Nathanael

> Cheers,
> Kayode
>

[5] https://mailarchive.ietf.org/arch/msg/seat/-J46kU9Sr5_RerIj0ucaSo1mlFY/

[6] https://mailarchive.ietf.org/arch/msg/seat/UVI1vgRUGqYaVzD4MesnN9XFeb4/

[7]
https://datatracker.ietf.org/doc/html/draft-reddy-seat-expat-transport#name-introduction


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