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

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