Summary

  • Revision 01 of the SEAT use-cases draft treats channel binding, evidence freshness, compound authentication, runtime attestation and state drift on long-lived or resumed connections as separate security goals.
  • A TLS or DTLS connection can remain cryptographically intact after the attested target environment changes. The handshake proves a bounded state and binding, not a permanent authorization claim.

At 09:00, a server completes a TLS handshake. Fresh remote-attestation evidence is bound to that connection. The verifier accepts the measured firmware, operating system, workload and security configuration. The relying party releases a secret.

At 14:00, the same encrypted connection is still alive. Its traffic keys work. Its record authentication passes. But the workload has loaded a new module, an AI agent has gained another tool, a security control has been disabled, or the platform has migrated. Nothing about the continued cryptographic health of the channel proves that the 09:00 target state still exists.

That time boundary is central to revision 01 of Security Goals and Use Cases for Integrating Remote Attestation with Secure Channel Protocols. The revision was updated on 15 September 2026 and expires on 19 March 2027. It is a SEAT Working Group Internet-Draft in I-D Exists. Its masthead says Informational, while Datatracker's Intended RFC status is blank. No document shepherd, responsible area director or telechat is recorded. The draft has no IANA actions. It supplies security goals and use cases as input to future protocol design; it does not specify the protocol mechanism, an appraisal policy, an implementation, a deployment or a measured outcome.

Channel identity and endpoint state answer different questions

TLS and DTLS normally authenticate a peer through a key and network identity. Remote attestation adds evidence about the Target Environment: hardware, firmware, software and security configuration. The relying party can then decide not only who holds the channel credential, but whether the measured environment is acceptable for a particular use.

The composition is valuable precisely because the two proofs are not interchangeable. A valid certificate and handshake do not establish that the private key remains non-exportable, that secure boot is enabled or that the intended application is running. Conversely, valid evidence about one platform does not prove that the platform owns the particular connection on which the evidence arrived.

Revision 01 therefore calls for cryptographic binding between Evidence or an Attestation Result and the specific secure connection. Without it, an attacker can relay valid evidence from a different endpoint or context. The draft also separates compound authentication, binding to a machine identifier, interaction with ordinary peer authentication and attestation-credential freshness. One successful check cannot be silently substituted for the others.

Freshness at the handshake does not make time stop

Fresh evidence resists replay of an old acceptable state. It may carry or be derived from a nonce, a challenge, a recent epoch or another freshness construction. Binding it to the current connection resists reuse on an unrelated channel. Together, those properties establish that a particular state assertion is recent enough under a stated policy and belongs to a particular connection context.

They do not guarantee that the state remains unchanged after appraisal. The draft explicitly identifies state drift on long-lived and resumed connections. It also calls for runtime attestation and distinguishes periodic from on-demand approaches. Those are not redundant goals. A connection-bound report can be perfectly authentic and still become stale.

This is easiest to see when the measured state can change more frequently than the transport. An AI agent may keep the same binary while its model selection, prompt template, enabled tools or external permissions change. A confidential workload may migrate. A patch may replace a component. A key-protection setting may be weakened. A verifier may revoke a reference value. None of those necessarily breaks the TLS record layer.

The correct claim is therefore bounded: acceptable evidence was appraised for a target environment and bound to a connection under a particular freshness and policy rule at a particular time. “This connection remains secure” and “this endpoint remains acceptable” are related operational questions, not synonyms.

Resumption preserves continuity selectively

Session resumption makes the boundary sharper. TLS can create a new connection using state derived from an earlier session. The resumed handshake may retain cryptographic continuity with the earlier relationship, but the organization still has to decide whether the old attestation remains young enough, whether the target environment is the same, whether the verifier and appraisal policy are unchanged and whether a privilege increase requires new evidence.

The use-cases draft requires designs to consider resumed connections; it does not choose one universal expiry rule. That restraint is appropriate. A telemetry reader, a secrets-provisioning service and a confidential-data collaboration may tolerate different evidence ages and failure modes. But leaving the number local does not remove the need to record it.

TLS KeyUpdate provides another instructive contrast. Refreshing traffic keys can limit exposure and extend a secure channel without repeating the full handshake. It does not, by itself, re-measure firmware, re-check an AI-agent tool set or renew an Attestation Result. Transport-key freshness, evidence freshness and authorization freshness need separate receipts.

Passport and background-check models trade different risks

The RATS architecture distinguishes a Passport model, in which an Attester obtains an Attestation Result and presents it to a relying party, from a Background Check model, in which the relying party works with a verifier. Revision 01 says Background Check is important for use cases demanding maximum freshness, while Passport can be better for scale, performance and cases where the verifier is offline or unreachable.

Neither model erases time. A passport needs validity and replay policy. A background check needs verifier availability, latency and a decision for timeout. A short validity period reduces the stale-state window but can increase load and denial-of-service exposure. A long period improves continuity but extends the period during which changed state may inherit an earlier approval.

Freshness also interacts with privacy. Evidence can reveal detailed platform composition, configuration or workload identity. More frequent or broadly visible evidence may improve state currency while increasing linkability and disclosure. Revision 01 separately considers privacy loss after ephemeral-key or traffic-secret compromise and calls for verifier trust. “Attest more often” is not a complete design until the evidence audience and retention policy are bounded.

Key compromise changes which binding still matters

The draft distinguishes authentication-key compromise from attestation-key compromise. If a TLS authentication key is stolen, an attacker may re-host it on another machine. Attestation can help only if the evidence binds the current authentication key, target environment and connection tightly enough to expose that substitution. If the attestation key itself is compromised, the attacker may be able to forge apparently acceptable evidence; stronger channel binding cannot make a dishonest attester truthful.

Evidence relay sits between those cases. An attacker does not need to forge a valid report if it can transplant an authentic report from a compliant machine onto its own connection. Binding the evidence to the handshake prevents that class of substitution. It still does not make yesterday's compliant state a property of today's process.

Certificate-enrolment-time key attestation illustrates the same limit. The draft notes that evidence collected when a certificate is issued can show where a private key was generated and stored at that time. It does not establish the continued module state when a later connection is opened, much less throughout the connection's lifetime.

Authorization remains a local decision

Remote attestation produces Evidence and Attestation Results. It does not produce a universal command to authorize. The relying party applies local policy to the result, the requested operation and its current risk. Revision 01 deliberately leaves appraisal policy out of scope.

This separation matters during drift. A new measurement may remain cryptographically valid but fail a changed policy. An unchanged measurement may be acceptable for read access but insufficient for secret release or migration. An attestation timeout may justify degraded service rather than immediate channel termination in one system and require fail-closed behavior in another.

Leadership should resist a single green “attested” badge. The operational state needs at least the connection identity, target identity, evidence freshness basis, verifier and policy generation, last accepted measurement, granted authorization, next refresh deadline and the action taken when refresh fails.

Keep a state-change receipt beside the secure channel

Heng Lu's minimum-initial-specification doctrine supports a small interoperable contract for connection binding, freshness and result semantics while leaving device technology and local appraisal open. Running-code primacy asks whether the deployed system actually requests new evidence, invalidates inherited approval and withdraws authorization when the trigger arrives.

Operators should record the handshake transcript binding, evidence and result identifiers, nonce or freshness basis, verifier identity, appraisal-policy generation, target-environment identity, resumption lineage and last accepted time. They should define re-attestation triggers for resumption, migration, privilege increase, tool-set change, policy update, key rotation, security alert, verifier revocation and maximum evidence age. They should predefine fail-open, fail-closed or degraded behavior for verifier unavailability.

Those are editorial operating recommendations, not requirements imposed by revision 01. Their purpose is to stop one valid handshake-era observation from becoming an indefinite statement about an evolving machine.

The secure channel can continue doing exactly what its transport specification promises while the endpoint has ceased to satisfy the reason access was granted. Binding closes the substitution gap. Re-attestation and authorization withdrawal close the time gap. Leadership needs both receipts before it can call a long-lived connection continuously trustworthy.

Sources