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

[[e-mail]]

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-early-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" rel="noreferrer nofollow noopener">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" rel="noreferrer nofollow noopener">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" rel="noreferrer nofollow noopener">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-5779863014&source=gmail&ust=1790180231627000&sa=E" rel="noreferrer nofollow noopener">https://www.google.com/url?q=https://github.com/ietf-wg-seat/draft-ietf-seat-use-cases/issues/8%23issuecomment-5779863014&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" rel="noreferrer nofollow noopener">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" rel="noreferrer nofollow noopener">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" rel="noreferrer nofollow noopener">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