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

[Serhii Nikolaichuk <[e-mail]>]

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