[Seat] Re: Early Attestation Considered Very Harmful (CVE-2026-100835 of CVSS 9.1, CVE-2026-92701 of CVSS 9.1, CVE-2026-92702 of CVSS 9.1, CVE-2026-100833 of CVSS 8.2, CVE-2026-33697 of CVSS 7.5, and 36 other CVEs of up to expected CVSS 10.0 upcoming)

[kayode Elekula <[e-mail]>]

I agree with the core argument of *Early Attestation Considered Very
Harmful*: early/intra-handshake attestation introduces unnecessary security
complexity because attestation Evidence must be sufficiently bound to the
intended cryptographic session and peer. The formal analysis demonstrates
that the examined binding mechanisms do not reliably provide the required
strong application-traffic binding and can therefore enable relay attacks
in which a client accepts valid Evidence originating from a different
machine.

I also agree with the broader conclusion that the problem extends beyond a
particular attestation protocol or implementation. Security depends on the
interaction of attestation, authentication, authorization, key generation,
runtime behavior, and other system components. Consequently, a valid
attestation statement must not be interpreted as establishing security
properties that fall outside the properties actually covered by the
attestation mechanism, its binding, and its trust domain.

The timing of the attestation Evidence is also important. In early
attestation, Evidence is generated during the handshake, before the
application session keys even exist. This creates a fundamental binding
question: can the Evidence be cryptographically correlated to the eventual
application-traffic context that will actually protect the session? The
draft formalizes this distinction through its three binding levels—DH
shared secret, handshake traffic key, and application traffic key—and
reports that the analyzed mechanisms do not achieve the required level-3
application-traffic binding.

I also agree with the draft's broader conclusion that continuous
attestation is required in most use cases, particularly because the
security state of a workload and its environment can change after
connection establishment. The draft itself frames continuous attestation as
required in most use cases and asks what justification exists for the
additional complexity of intra-handshake attestation when continuous
assurance is still necessary.

The MITRE Continuous Remote Attestation Framework makes this point
particularly clear. Section 4.3 explicitly defines runtime state as the
continuous attestation layer: unlike platform and image state, which are
primarily validated at boot or deployment events, runtime evidence is
gathered at regular intervals throughout the workload's lifetime. MITRE
therefore separates establishing the initial trust context from
continuously verifying whether the running workload and its execution
environment remain trustworthy.

This makes the architectural concern with early attestation even clearer:
an attestation performed during the initial handshake cannot by itself
provide the continuing runtime assurance that the system will subsequently
require. Adding it therefore risks introducing another layer of protocol
and binding complexity without eliminating the need for ongoing
attestation. The current draft consequently argues that post-handshake
attestation alone can achieve level-3 application-traffic binding while
avoiding unnecessary intra-handshake complexity.

The analysis also reinforces an important principle: valid attestation
Evidence must not be interpreted as establishing security properties beyond
those actually covered by the Evidence, its binding, and its trust domain.

Thus, I agree with the core conclusion: continuous attestation is required
in most use cases; early/intra-handshake attestation adds complexity to the
initial establishment of trust without eliminating the need for subsequent
runtime assurance; and post-handshake attestation provides the appropriate
mechanism for maintaining that assurance over the lifetime of the
connection.

On Mon, Oct 5, 2026, 6:06 PM kayode Elekula <[e-mail]> wrote:

> I agree with the core argument of *Early Attestation Considered Very
> Harmful*: early/intra-handshake attestation introduces unnecessary
> security complexity because attestation Evidence must be sufficiently bound
> to the intended cryptographic session and peer. The formal analysis
> demonstrates that the examined binding mechanisms do not reliably provide
> the required strong application-traffic binding and can therefore enable
> relay attacks in which a client accepts valid Evidence originating from a
> different machine.
>
> I also agree with the broader conclusion that the problem extends beyond a
> particular attestation protocol or implementation. Security depends on the
> interaction of attestation, authentication, authorization, key generation,
> runtime behavior, and other system components. Consequently, a valid
> attestation statement must not be interpreted as establishing security
> properties that fall outside the properties actually covered by the
> attestation mechanism, its binding, and its trust domain.
>
> The timing of the attestation Evidence is also important. In early
> attestation, Evidence is generated during the handshake, before the
> application session keys even exist. This creates a fundamental binding
> question: can the Evidence be cryptographically correlated to the eventual
> application-traffic context that will actually protect the session? The
> draft formalizes this distinction through its three binding levels—DH
> shared secret, handshake traffic key, and application traffic key—and
> reports that the analyzed mechanisms do not achieve the required level-3
> application-traffic binding.
>
> I also agree with the draft's broader conclusion that continuous
> attestation is required in most use cases, particularly because the
> security state of a workload and its environment can change after
> connection establishment. The draft itself frames continuous attestation as
> required in most use cases and asks what justification exists for the
> additional complexity of intra-handshake attestation when continuous
> assurance is still necessary.
>
> The MITRE Continuous Remote Attestation Framework makes this point
> particularly clear. Section 4.3 explicitly defines runtime state as the
> continuous attestation layer: unlike platform and image state, which are
> primarily validated at boot or deployment events, runtime evidence is
> gathered at regular intervals throughout the workload's lifetime. MITRE
> therefore separates establishing the initial trust context from
> continuously verifying whether the running workload and its execution
> environment remain trustworthy.
>
> This makes the architectural concern with early attestation even clearer:
> an attestation performed during the initial handshake cannot by itself
> provide the continuing runtime assurance that the system will subsequently
> require. Adding it therefore risks introducing another layer of protocol
> and binding complexity without eliminating the need for ongoing
> attestation. The current draft consequently argues that post-handshake
> attestation alone can achieve level-3 application-traffic binding while
> avoiding unnecessary intra-handshake complexity.
>
> The analysis also reinforces an important principle: valid attestation
> Evidence must not be interpreted as establishing security properties beyond
> those actually covered by the Evidence, its binding, and its trust domain.
>
> Thus, I agree with the core conclusion: continuous attestation is required
> in most use cases; early/intra-handshake attestation adds complexity to the
> initial establishment of trust without eliminating the need for subsequent
> runtime assurance; and post-handshake attestation provides the appropriate
> mechanism for maintaining that assurance over the lifetime of the
> connection.
>