[Seat] Re: A continuity-and-revocation layer above attested TLS, with running code

[Serhii Nikolaichuk <[e-mail]>]

Three corrections to what I wrote this morning, and one question that
turned out
to matter more than the layer I was describing.

A review of the code found that my reference client defeated my own claims:
it
read the RFC 8446 exporter and the identity key out of the peer's message
rather
than deriving them from its own side of the session, which is exactly what a
relay forwards unchanged. Everything I said about relay resistance was
therefore
untested by the client that shipped. It is fixed, there is now a real TLS
relay
in the test suite, and I would rather say this here than have someone find
it.
It is also the same class of defect this list discussed in July under
"formal
analysis of relay attacks in attested TLS" (CVE-2026-33697) -- found this
time
by reading my own reference client rather than someone else's.

Two claims in that message were also stronger than the mechanism:

- I said a stolen key on a second genuine chip is caught "and the identity
revoked". Revoking on fork is an attack on the victim: anyone presenting a
stolen key from any genuine chip could destroy the identity being
impersonated. The impostor is now refused and the victim keeps serving;
revocation is an explicit operator act.

- I said I had measured the physical-insider window at "about 8 ms per
liveness beacon". That number is the beacon cadence, which bounds how finely
an interruption can be seen. It is not the attacker's window: while the key
is in cleartext in guest memory to sign at all, that window is the life of
the process.

I should also withdraw the framing. What I have is post-handshake: the
evidence
binds the exporter, which exists only after the handshake completes, so
calling
it a floor under both transports overstated it.

The question that turned out to matter

Continuity needs a claim that says "the same instance". Implementations
reach
for CHIP_ID, mine included. Measuring an archive of 93 SEV-SNP reports from
three clouds, and then two clouds live, says that is the wrong granularity:

- CHIP_ID identifies silicon. Five chips in the corpus each carried between
two and four distinct guests, so re-hosting between VMs on one socket is
invisible to it.

- Under a shared-tenancy VLEK it is absent. Six AWS instances report 64 zero
bytes, and MASK_CHIP_KEY is CLEAR in all of them: the platform hides the
identifier without setting the flag that says so. On the same platform the
VLEK signing key is shared region-wide, so neither the chip nor the
signature separates two machines.

- REPORT_ID does. It is present on all three clouds, distinct for every
instance including guests sharing a socket, and per the Firmware ABI 1.54
the AMD-SP generates it and it is not among the SNP_LAUNCH_START inputs, so
the hypervisor cannot choose it.

draft-deeglaze-amd-sev-snp-corim-profile states the ambiguity plainly --
"the
instance identifier can be argued as any of REPORT_ID, REPORT_ID_MA when
non-zero, CHIP_ID (for VCEK), or CSP_ID (for VLEK)" -- and chooses CHIP_ID,
which is right for the question it asks: the instance of the Attesting
Environment, and that is the AMD-SP. Continuity asks about the Target
Environment. The gap is not that the profile is wrong; it is that
implementations reuse the attester's identity as the target's, because only
one
of the two has been written down. The substitution is silent: a verifier
anchored on CHIP_ID under a masked platform compares 64 zero bytes to 64
zero
bytes and reports a match.

On TDX the answer appears to be that no such claim exists. Two TDs launched
from
one image differ in exactly one TDREPORT field, MROWNER, and the host VMM
supplies that one through KVM_TDX_INIT_VM. A design that anchors on SEV-SNP
does
not port to TDX by renaming a field.

One interoperability note worth its own line

AMD signs ASK and ARK with RSASSA-PSS and encodes trailerField=1 explicitly.
That is the DEFAULT value, which X.690 11.5 forbids in DER, so a strict
ASN.1
parser refuses to load the AMD certificate chain at all. A verifier that
treats
"cannot parse the root" as "skip the root" silently falls back to trusting
whatever key signed the report. I suspect this is one reason chain
validation is
so often absent in attestation code; mine was. Checked against the live KDS
endpoint on 21 September 2026.

What is and is not established

The code is at
https://www.google.com/url?q=https://github.com/nikolaichuk7/hatls&source=gmail&ust=1790120597741000&sa=E
with the audit of its own
defects, the hardware logs unedited including the runs whose conclusions no
longer hold, and the measurements above reproducible from the corpus. A
ProVerif
model covers the binder and one step of the mandate's appraisal; it does not
cover the transfer grant, revocation, the ledger, receipts, or TLS, and I
would
rather state that here than let "there is a formal model" do work it cannot
do.

The thing I would like the working group's view on is not my layer. It is
whether instance identity for a Target Environment should be specified at
all,
and if so which claim carries it on SEV-SNP, TDX and Nitro. Getting it
wrong is
not loud.

Serhii Nikolaichuk
The Capital Index, Austin, Texas

On Mon, Sep 21, 2026 10:02 AM, Serhii Nikolaichuk <[e-mail]>
wrote:

> Dear RATS, and SEAT in copy,
>
> Ned invited, in the KIA/GAR thread, drafts that show how continuity
> objectives
> can be achieved within RATS attestation infrastructure. This is one, with
> running code rather than a proposal, and I think it also lightens a choice
> the
> SEAT working group is weighing, so I have copied SEAT.
>
> The SEAT discussion is between binding attestation inside the TLS handshake
> (draft-fossati-seat-early-attestation) and after it
> (draft-fossati-seat-expat).
> Both are good and both bind a single moment. Neither is at fault for what
> draft-ietf-seat-use-cases states directly: Section 3.8.1 asks for
> "continuity
> with a particular platform instance ... a means to reject compromised
> authentication credentials" and leaves the mechanism open; Section 4.8 says
> current systems "do not achieve" continuous assurance. That missing layer
> is a
> RATS matter, not a transport one: it is enrolment (TACRA,
> draft-novak-rats-tacra), a continuity chain (the shape of
> draft-nikolaichuk-scitt-continuity-receipts), and revocation.
>
> So rather than argue intra versus post, I built the continuity layer and
> let
> both sit underneath it, unchanged:
>
> intra_link = f(transcript, identity key) # the early binder, in the
> handshake
> post_link_n = f(exporter, prev_link, counter) # the post binder, on the
> shared secret
> each link is carried in a hardware attestation report; a shared mandate
> admits
> one continuous, ordered, chip-consistent chain per identity, enrols the
> key to
> its birth chip, and revokes on fork.
>
> Measured on real AMD SEV-SNP hardware, not modelled:
>
> - a stolen identity key presented on a second genuine chip is caught and
> the
> identity revoked;
> - with enrolment, that stolen key is rejected on the FIRST message, no
> second
> observation needed (this is the 3.8.1 mitigation, made concrete);
> - the one case no key management can close, a physical insider on the
> enrolled
> chip, I did not claim to close; I measured its window instead, about 8 ms
> per
> liveness beacon on the chip.
>
> What this offers SEAT is not a third camp but a floor under both: early
> and post
> attestation are the two ends of the same continuity chain, and the choice
> between them stops carrying the whole security argument once the chain and
> the
> mandate are there.
>
> The continuity layer here is an independent implementation in that
> repository, not a
> wrapper over anything I keep private; every number above reproduces from
> the public
> code alone. Clone it, bring your own confidential VM, and run the full
> cycle, or run
> it locally against a mock chip. There is an attack playground for trying
> to defeat the
> mandate. If a measurement is wrong, it is wrong in a way you can show by
> running it,
> which is the point of putting it there rather than asserting it:
>
> https://www.google.com/url?q=https://github.com/nikolaichuk7/hatls&source=
> gmail&ust=1790089353332000&sa=E
>
> You can also compose it with either transport directly: early attestation
> and expat are
> open, the continuity layer is open, and the seam between them is the two
> links above, so
> a full end-to-end check needs nothing from me.
>
> One interest I should declare plainly, because it bears on why I am not
> taking a
> side. I am a co-author of draft-intra-handshake-fail, which analysed early
> attestation and found real weaknesses in it. That is exactly why I want to
> be clear
> that this layer is not built against either transport. It carries both
> unchanged as
> the two ends of one chain; it does not depend on the intra-versus-post
> choice and does
> not try to settle it. My neutrality here is structural, not diplomatic:
> the continuity
> layer sits above the binder, so it does not care which binder is
> underneath, and I
> would rather it strengthen whichever the working group prefers than argue
> that question
> again.
>
> I would rather this become one document with whoever wants to carry it
> than a draft
> standing apart, and I am just as interested in where it breaks as in where
> it holds.
>
> Serhii Nikolaichuk
> The Capital Index, Austin, Texas
>