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

[Serhii Nikolaichuk <[e-mail]>]

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
>
> #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-
> 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
>
> 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
>
>