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

[Serhii Nikolaichuk <[e-mail]>]

Waqas,

VCEK on the runs in the release: the GCP guests sign with the chip's VCEK,
fetched from AMD's KDS by CHIP_ID and path-validated to the ARK. The
verifier also takes VLEK-signed reports (the AWS captures in the
repository), chaining through the VLEK certificate the guest reads from the
host's certificate table, and refuses a VLEK report that arrives without
that leaf. Nothing in the continuity anchor rests on which key signed: the
instance is REPORT_ID, and the VLEK case is the reason -- one key per
region, CHIP_ID zeroed.

Yes, exporters: RFC 8446 Section 7.5, through the stack's standard call
(SSL_export_keying_material in OpenSSL; Go, rustls and BoringSSL have the
same), under two labels of our own, EXPERIMENTAL-hatls-continuity-exporter
for the chain and EXPERIMENTAL-hatls-session-context for the first link;
the working group's own post-handshake document binds the same way
(draft-fossati-seat-expat, EXPORTER-cmw-attestation). Each endpoint derives
both from its own key schedule; nothing that binds is sent on the wire. The
v0.1 client read the exporter off the wire instead -- that is the relay
defect recorded in docs/AUDIT.md and closed before v0.3.0. The limit that
comes with exporters: the endpoint that holds the TEE must also hold the
TLS session, so behind a TLS-terminating proxy there is nothing to bind.
That is a property of channel binding, not of this layer.

The review is welcome. Start with the test suite (PYTHONPATH=. python3 -m
pytest tests/ -q, no hardware needed) and docs/AUDIT.md, which lists every
defect I found in my own code first.

Serhii

On Thu, Sep 24, 2026 06:17 AM, [e-mail] wrote:

> Serhii,
> You say SEV-SNP. Do you use VLEK or VCEK?
> Don't you require exporters? How do you do that? I will review your code
> next week.
>
> Thanks,
> Waqas
>
> @IETF Admin: I get three separate copies of Serhii's email. Is this my
> configuration problem or is it normal? Is it fixable?
>
>
>
> On Thu, Sep 24, 2026 at 2:55 AM Serhii Nikolaichuk <
> [e-mail]> wrote:
>
> Waqas,
>
> Nothing in HATLS adds early attestation. The layer starts where the
> handshake ends: every value it binds comes out of the completed TLS 1.3 key
> schedule, it runs over plain TLS 1.3 with no attestation extension
> underneath, and its README says so in as many words.
>
> What it adds is what the use-cases document asks for and leaves
> unspecified (3.8.1, 4.8): continuity across a connection's lifetime -- a
> re-attestation that cannot be answered with an earlier report, and a stolen
> identity key re-hosted on another chip refused on its first message --
> proved in ProVerif and measured on live SEV-SNP, reproducible from a clone
> of the tagged release.
>
> I signed the abstract you quote, and my numbers say what it says: with the
> 5.1.1 binder an earlier report is accepted at a later reattestation, which
> 8.4 concedes in prose and #60 shows with two AMD-signed reports carrying
> byte-identical REPORT_DATA; a TDX quote in the first flight costs an extra
> round trip against a long certificate chain and a post-quantum key share,
> while post-handshake conveyance leaves the first flight untouched. #74 and
> #75 are two more defects in the same document. I file measurements where
> the working group keeps its issues, whatever I think of the document; that
> is what a tracker is for.
>
> If you find a line in the release where the chain depends on early
> attestation, show me the line.
>
> Serhii
>
> On Wed, Sep 23, 2026 03:44 PM, [e-mail] wrote:
>
>> As you say in abstract of your draft and cite MITRE document, key point
>> separately from attacks is need for continuous attestation. Then why add
>> the complexity and attacks of early attestation at all?
>>
>> Cheers,
>> Waqas
>>
>>
>> On Tue, Sep 22, 2026 at 6:17 PM Serhii Nikolaichuk <
>> [e-mail]> wrote:
>>
>> Following up on my two notes of the 21st. The parts of this that belong
>> to the working
>> group's documents are now in their trackers rather than on the list, and
>> everything else
>> is in one tagged release with the raw hardware reports. Pointers, so the
>> list has them:
>>
>> On draft-fossati-seat-early-attestation (yaronf/draft-fossati-seat-ear
>> ly-attestation):
>>
>> #74 With a HelloRetryRequest, "Hash(ClientHello...ServerHello)" in 5.1.1
>> has four
>> defensible readings, and they give four different binders in 200 of 200
>> handshakes;
>> Appendix C steers toward the wrong ones and 5.1.2 makes the disagreement
>> a fatal
>> attestation_failed. A one-sentence fix is proposed.
>> https://www.google.com/url?q=https://github.com/yaronf/draft
>> -fossati-seat-early-attestation/issues/74&source=gmail&ust=
>> 1790180231627000&sa=E
>>
>> #75 A resumed TLS 1.3 handshake carries no Certificate message, so the
>> extension of
>> 4.1 has no carrier there; the only MUST about resumption is in the
>> document history
>> while 8.6 says a resumed connection inherits the appraisal.
>> https://www.google.com/url?q=https://github.com/yaronf/draft
>> -fossati-seat-early-attestation/issues/75&source=gmail&ust=
>> 1790180231627000&sa=E
>>
>> #60 Section 8.4 reproduced on a live SEV-SNP guest with the 5.1.1 binder
>> computed as
>> written from the real transcript: two genuine reports in one connection
>> carry
>> byte-identical REPORT_DATA and the stale one is accepted at
>> reattestation. ProVerif
>> finds that trace with a constant binder and proves order with a chained
>> one. Of the
>> 5.4 options, Extended Key Update would give order for free;
>> post-handshake auth and
>> CertificateUpdate would not.
>> https://www.google.com/url?q=https://github.com/yaronf/draft
>> -fossati-seat-early-attestation/issues/60%23issuecomment-
>> 5779862051&source=gmail&ust=1790180231627000&sa=E
>>
>> On draft-ietf-seat-use-cases (ietf-wg-seat/draft-ietf-seat-use-cases):
>>
>> #8 What "the identifier provided to the machine" actually is, read at the
>> ABI offsets
>> across 87 SEV-SNP reports from two clouds and two TDX guests: VCEK names
>> the chip,
>> VLEK the region, REPORT_ID the instance; CHIP_ID is all-zero on AWS while
>> the
>> report's MASK_CHIP_KEY flag reads 0; on TDX only the host-supplied
>> MROWNER differs,
>> unless the guest extends an RTMR, which I measured on two TDs.
>> https://www.google.com/url?q=https://github.com/ietf-wg-seat
>> /draft-ietf-seat-use-cases/issues/8%23issuecomment-577986
>> 3014&source=gmail&ust=1790180231627000&sa=E
>>
>> #60 On key migration between trusted environments: the firmware ABI marks
>> ReportID as
>> migrating with the guest, and an owner-authorised transfer, honoured only
>> toward an
>> instance the relying party has itself seen attest, measured on live
>> SEV-SNP.
>> https://www.google.com/url?q=https://github.com/ietf-wg-seat
>> /draft-ietf-seat-use-cases/issues/60%23issuecomment-
>> 5779864103&source=gmail&ust=1790180231627000&sa=E
>>
>> Section 4 of the use-cases draft asks proposals to state which of its
>> goals they meet and
>> how. That statement, goal by goal, with three goals not met and said so,
>> is here:
>> https://www.google.com/url?q=https://github.com/nikolaichuk7
>> /hatls/blob/v0.3.0/docs/SEAT-GOALS.md&source=gmail&ust=
>> 1790180231627000&sa=E
>>
>> Two corrections of my own from the same pass: the guest probe in my
>> repository had been
>> unable to answer a connection since v0.2.0 (recorded results predate the
>> defect; the
>> "clone it and run it" invitation did not), and a "7.96 ms beacon" I had
>> quoted as a rate
>> was one report's latency while my own file held a 10 s maximum: the host
>> throttles a
>> guest to about ten SEV-SNP reports per ten seconds. Both are fixed and
>> written up.
>>
>> Release, with every measurement reproducible from a clone:
>> https://www.google.com/url?q=https://github.com/nikolaichuk7
>> /hatls/releases/tag/v0.3.0&source=gmail&ust=1790180231627000&sa=E
>>
>> I will keep further detail on the issues rather than here.
>>
>> Serhii Nikolaichuk
>> The Capital Index, Austin, Texas
>>
>>
>