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

[[e-mail]]

Dear Kayode,

The main flaw in early attestation is HUGE protocol bloat. Early attestation is absolutely unnecessary complexity and has harmful security implications. Brian Kernighan says "Controlling complexity is the essence of computer programming".

I like your statement "In early attestation, Evidence is generated during the handshake, before the application session keys even exist." Secure binding is clearly impossible in early attestation.

MITRE RFC quite clearly explains evidence without runtime attestation is useless. Early attestation makes no sense at all. It only helps attackers achieve their goals. All implementations of early attestation are proven insecure.

Thanks,

Waqas

On Mon, Oct 5, 2026 at 7:08 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.

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.