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

[Serhii Nikolaichuk <[e-mail]>]

Waqas,

Three answers.

Why the labels. RFC 5705, Section 4: a label beginning with EXPERIMENTAL
may be used without registration; every other label must be registered, and
a registered label should begin with EXPORTER -- RFC 9847 now has the
expert check that. The draft you implement did exactly this on 19
September: -03 said "Attestation", -04 says EXPORTER-cmw-attestation and
asks IANA for the entry in 9.2. HATLS's two exporters are neither TLS
key-schedule secrets nor registered, so they live under
EXPERIMENTAL-hatls-. They are also not expat's value: expat exports 32
bytes under certificate_request_context to bind one exchange; HATLS exports
a 48-byte session context and a separate 32-byte continuity exporter that
seeds a counter-chained sequence of links. Different inputs, lengths and
meanings need different names; one name is how two protocols end up
deriving the same bytes for different purposes. My first commit on the 21st
got this wrong -- it borrowed RFC 9266's EXPORTER-Channel-Binding and TLS's
own "tls13 " prefix -- and commit 0f51084 replaced both the same day,
before the first tag, with the reason in the message.

What the code solves. expat answers "is this endpoint a genuine TEE, on
this connection, now", and 7.4 re-asks with a fresh context each time. 5.2
states its assumption: the AIK is generated in the TEE and never leaves it.
AIK_pub_hash then proves that the TEE which signed the Evidence claims the
key, not that it is the TEE the key was born on; a thief's own TEE vouches
for a stolen key as readily as the owner's does. HATLS is for the case
where that assumption has failed. The mandate enrols the identity on one
instance -- REPORT_ID, bound to a CSR the chip's report covers -- and from
then on the same key from any other instance is refused on its first
message; every later link chains from the last one accepted, so a report
cannot be replayed, reordered or moved across sessions.

How that was measured, since you ask what the conclusions rest on. Two live
SEV-SNP guests on GCP, one identity key deliberately shipped to both
(scripts/launch.sh), the mandate enrolled on guest A: guest B refused on
its first message, guest A still served (evidence/enroll-20260921T144800Z/;
the same on AWS, where the reports are VLEK-signed). The counts -- 0 missed
in 500 stolen-key presentations, 0 false rejects in 500 reconnects, 0
relayed exporters accepted in 500 -- are bench/benchmark.py against the
same mandate code with a mock TEE, no hardware needed. The same properties,
plus order, hold in ProVerif against a thief who holds the key, whose own
TEE signs whatever it asks, and who is the TLS peer of both ends; the model
with the v0.1 defect put back fails exactly the property the defect broke,
so the check is not vacuous (formal/). All of it is in the tag:
https://www.google.com/url?q=https://github.com/nikolaichuk7/hatls/releases/tag/v0.3.0&source=gmail&ust=1790354345203000&sa=E

If your expat implementation is public, point me to it. The chain does not
care what carried the first report, and I would rather run it above your
code than describe it.

Serhii

On Thu, Sep 24, 2026 09:33 AM, [e-mail] wrote:

> Serhii, inline with [WN]
>
> On Thu, Sep 24, 2026 at 2:12 PM Serhii Nikolaichuk <
> [e-mail]> wrote:
>
> 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).
>
> [WN] I already implemented this draft. I matched label this week. What
> problem does your code solve? Why you change the labels?
> Thanks,
> Waqas
>
> 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=1
>>> 790180231627000&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=1
>>> 790180231627000&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-577
>>> 9862051&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-577986301
>>> 4&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-57798641
>>> 03&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=17901
>>> 80231627000&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
>>>
>>>
>>
>