[Rats] Re: Adoption call for draft-richardson-rats-geographic-results

[Serhii Nikolaichuk <[e-mail]>]

Usama,

One more, because it is a measurement rather than an argument; the rest
went into the PR.

On the CCC threat model: agreed on what it says; the distinction is what
it says it about. Section 5.1 of [3] states the goal as reducing "the
ability for the owner/operator/pwner of a platform to access data and
code inside TEEs", the conclusion says Confidential Computing "allows
for the protection of data against adversarial owners", and Section 5
leaves the trust model "with relation to the host, its owner, its
operator" to each deployment. That is a claim about data and code in
use. It is not a claim that the operator is outside the trust set for
where the platform is; your Section 1 says the operator has to be
trusted for that, and I agree. So this afternoon I measured how much of
that question the operator holds.

I rented a bare-metal EPYC Genoa for the afternoon (my own BIOS
settings, my own hypervisor) and set the host-side switches one at a
time, reading the guest's report after each:

- baseline: KEY_SEL 0 and 1 return a VCEK-signed report, KEY_SEL 2 is
refused (no VLEK loaded); the guest's CHIP_ID is byte-identical to the
host's SEV_GET_ID2, and KDS verifies all five reports with hwID equal
to it;
- guest launched with VCEK_DIS, no VLEK on the host: every key
selection is refused with INVALID_KEY (0x27); that is the AWS refusal
of KEY_SEL 1 reproduced with one launch flag (AWS also has a VLEK
loaded, which is why its KEY_SEL 0 and 2 succeed);
- SNP_CONFIG with MASK_CHIP_ID: still VCEK-signed, still verifies,
CHIP_ID all zeros, MASK_CHIP_KEY still 0; the guest cannot fetch its
own certificate, there is nothing to ask KDS with, while I, as the
operator, fetch it with the host's id and verify the same report;
- both: refused, the ABI's three INVALID_KEY conditions exactly.

Two consequences. The key domain and the chip's visibility are
independent operator choices, and the report shows neither except by
its effect; a zero CHIP_ID can accompany the per-chip key, so an
appraisal policy reads SIGNING_KEY and CHIP_ID separately. And to your
FAQ4, "no public cloud provider ... provides a list of legitimate
machines that it owns; a basement machine is thus indistinguishable":
the VLEK is that list, held by AMD rather than by the provider. Per the
ABI, Section 3.7, "each Cloud Service Provider (CSP) that enrolls with
AMD has dedicated VLEK seeds", the KDS derives the hashstick "for a
given TCB and machine identified by CHIP_ID" and wraps it "with a
transport key derived from a chip-unique secret". My basement Genoa
answers KEY_SEL 2 with INVALID_KEY, and since I am not an enrolled CSP
it stays that way. A VLEK-signed report therefore distinguishes a
machine AMD enrolled for that provider from a basement machine, and
does not distinguish machines within the provider's fleet; the VCEK
does the reverse. That was the point of the chained pair: both
distinctions in one Evidence. It does not add the CSP to the trust set
for location, because the CSP is already in it under every key
selection, holding both switches; for data in use nothing changes,
which is the CCC's claim.

On the binder: taken. My relay held a leaked key, and per your Section
7.1.4 the same holds for any other holder of privEK, runtime
provisioning included. The exporter binder does not depend on how the
relay came by the key; it rejects because the relay's session with the
client has a different handshake secret. PR #10 against main now cites
Intra-handshake.fail for the binder analysis (mechanisms 4 and 6),
keeps ID-Crisis for the diversion attack, and says the public key may
accompany the shared-secret-derived value so that the binding holds
while either is secret (your Section 7.2). The bare-metal runs are in
[6], baremetal/RESULTS.md.

Trust anchor attested: for one afternoon the signer was a Genoa in
Chicago, CHIP_ID unmasked and KDS-verified; the owner's location
remains an Endorsement. Dinner in Dresden accepted as appraisal policy.

Serhii

[3] Confidential Computing Consortium, A Technical Analysis of
Confidential Computing, v1.3, Sections 5, 5.1 and 7.
[6]
https://www.google.com/url?q=https://github.com/nikolaichuk7/geoar-verifier&source=gmail&ust=1789245138301000&sa=E

On Fri, Sep 11, 2026 02:56 PM, Muhammad Usama Sardar <
[e-mail]> wrote:

> Hi Serhii,
>
> On 11.09.26 20:02, Serhii Nikolaichuk wrote:
>
> three things, then I stop taking the list's time.
>
> I found it constructive and insightful exchange.
>
> Usama, on the chained pair: agreed. The VLEK half is a provider key
> domain, so the construction joins two identities, it does not take
> the CSP out of the trust set; that is the draft's point, not an
> exception to it.
>
> My point was that it conflicts the confidential computing threat model by
> the Confidential Computing Consortium (CCC), where CSP is claimed to be out
> of TCB.
>
> On the binder: you are right and I had it too easy. What my runs
> bound is a public key generated in the guest, and a key is not a
> session. Rather than argue it I measured it this afternoon on one
> Google SEV-SNP VM: a TLS 1.3 server in the guest takes the client's
> nonce and requests two reports per session, REPORT_DATA = SHA-512(nonce
> || the session's RFC 9266 exporter value) and REPORT_DATA =
> SHA-512(nonce || SPKI of its TLS key), and signs the nonce with that
> key. The client derives its own exporter and checks both. Direct: both
> accept. Through a relay on my machine that holds the guest's TLS key
> (your leaked-key attacker)
>
> Per [4], leakage itself -- per se -- is just one option but not the only
> option. Please see FAQ1 in [5].
>
> and terminates the client's session: the
> key binder accepts, every check passes, peer key equals the attested
> SPKI, signature valid, report genuine; the exporter binder rejects,
> client exporter 72b395fe..., guest exporter 361367e7.... Same chip,
> same REPORT_ID, equally genuine reports; only the shared-secret
> binding sees the relay. Files under gcp-cvm/exporter/runs in [6],
> write-up in PROTOCOLS.md.
>
> [Changed your reference to [6] because they are conflicting with my
> references]
>
> Great demonstration, that matches our formal analysis.
>
> The paragraph for Security Considerations now says exactly that:
> bind the Evidence to a value derived from the session's shared secret,
> the TLS exporter of RFC 9266, and a public key alone does not
> correlate the Evidence with the session, citing [0].
>
> Rather than [0], perhaps the most relevant citation for binding is [4],
> which makes formal arguments about public key alone (binder#4) and with
> nonce (binder#6).
>
> Serhii Nikolaichuk
> Austin, Texas (basis = endorsement, signer = the author; the trust
> anchor is available on request, one coffee in Austin)
>
> Fatal error: Owner and location of trust anchor unknown. GDPR violation is
> suspected. Attestation of trust anchor is requested. Dinner in Dresden 🙂
>
> Best regards,
>
> -Usama
>
> [0] https://doi.org/10.1145/3779208.3785387
>>>
>>> [1] SEV Secure Nested Paging Firmware ABI Specification.  Rev. 1.59.
>>> August 2026.  https://docs.amd.com/v/u/en-US/56860_PUB_SEV_SNP.
>>>
>>> [2] https://www.rfc-editor.org/info/rfc9711/#section-4.2.10.
>>>
>>> [3] The Confidential Computing Consortium.  “A Technical Analysis of
>>> Confidential Computing”.  V. 1.3.  November 2022.
>>> https://confidentialcomputing.io/wp-content/uploads/sites/10
>>> /2023/03/CCC-A-Technical-Analysis-of-Confidential-Computing-
>>> v1.3_unlocked.pdf.
>>>
>>> [4] https://www.researchgate.net/publication/408219182_Intra-
> handshakefail_CVE-2026-33697_High-severity_CVE_in_Attested_TLS
>
> [5] https://github.com/muhammad-usama-sardar/intra-handshake.fail#faqs
>
> [6] https://github.com/nikolaichuk7/geoar-verifier
>