Summary

  • At RIPE 93, Muhammad Usama Sardar challenged early attestation inside the TLS handshake. Cocos AI's own Intel TDX advisory records a tested path that accepted a reused or mismatched freshness value and released application bytes after the handshake.
  • A second Cocos advisory identifies a separate AMD SEV-SNP path: an omitted expected value could leave the current connection unbound. Cocos moved to post-handshake attestation in v0.9.0; the IETF SEAT charter requires per-connection freshness and parallel formal analysis.

The doorman checked the badge. The badge was tied to yesterday's coat. That is a useful way to read the Cocos AI Intel TDX advisory: the verifier received a value meant to identify the present session, but the tested path did not put it into the quote-body policy before checking the report. Its local release-gate test accepted an external report with a reused or mismatched value. Application bytes followed the TLS handshake. The trust ceremony had a very expensive missing comparison.

The flaw was one of the concrete cases behind Muhammad Usama Sardar's RIPE 93 Security presentation on 27 October. He argues that performing attestation early, inside the handshake, adds complexity and invites binding mistakes. His question lands with force because the vendor's own record names the comparison that failed. A handshake can complete neatly while the evidence says too little about the machine on the other side of this connection.

The second Cocos AI advisory concerns AMD SEV-SNP. Its v0.8.2 verifier set the expected reportData only when the caller supplied a nonempty value. A caller that omitted it could receive acceptance of unrelated evidence. A caller that supplied a nonempty value got a comparison; mismatches were rejected. The distinction matters: the failure sits in a specific path and input condition, where software turned absence of a binding value into permission to proceed. Cocos says v0.9.0 migrated to post-handshake attestation.

A separate Contrast advisory from Edgeless Systems shows another version of the same governance problem. Under its stated interception and report-forgery or secret-extraction conditions, a valid report from a different machine could satisfy the earlier verifier if its measurements matched. Version 1.16.0 added hardware-ID allowlists. The issuer, the machine and the live session each need a distinct answer; a green check alone supplies none of them.

The IETF SEAT working-group charter sets the public test: attestation evidence must bind to the TLS connection; the design must allow per-connection freshness; formal analysis runs alongside the specification. Those are measurable demands. A badge stamped “trusted” earns its place when an implementer can show what it was bound to, how fresh it was and whether failure kept application data behind the door.