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

[Michael Richardson <[e-mail]>]

Serhii Nikolaichuk <[e-mail]> wrote:
    > One comment, offered as a question to work out after adoption rather
    > than a reason to hold it up.

Thank you for the review!

    > The draft is deliberately agnostic about how the Verifier came to
    > believe a location: "if a Verifier believes that information
    > trustworthy for the purpose intended, then it may use the format
    > described here to document it's conclusion." I think that scoping is
    > right. But it leaves a Relying Party unable to distinguish conclusions
    > of very different strength, and I have a measurement suggesting the
    > weak end of that range is the common case in clouds today.

Yes, you are correct that it could leave the RP wondering.
The thing is that AR are signed, and they have to signed by an entity that
the RP trusts.  That's not a trivial step!  It seems that some people
think that RFC9334 lets us mix and match any random set of evidence with any
random verifier, and it will satisfy all RP :-)   That's just not the case.

In (passport) situations where the geographic Verifier is distinct
from other Verifications, and the verifier could be chosen by the Attester,
then one could well get into a situation where the location is not trustworthy.

When geographic results are provided in the form an Endorsement (as a result
of a visit by a human auditor), then this endorsement might be evaluated by
the more general Verifier.
The NTP/timing mechanism described by draft-ramki-ptp-hardware-rooted-attestation-01
(oops, did that expire yesterday?), might take such an Endorsement as part of
the Verifier input: "Node W is <1.23ns away from node Q, and node Q is >HERE<"

    > I hold 26 hardware-signed attestation artifacts captured from a single
    > workload across three TEE families - AWS Nitro Enclaves, AMD SEV-SNP,
    > and Intel SGX via Microsoft Azure Attestation - in six cloud regions.

26?  One for each letter of the Alphabet?  :-)

    > I
    > searched every signed artifact for anything locational: region,
    > country, zone, datacenter, latitude, longitude. There is nothing in any
    > of them.  The only matches on "geo" were random substrings inside
    > base64.

Yeah, so none of the EK have anything about where they are.
I imagine that these are all VMs?  Is there any chain up to the physical
(hypervisor) TPM?   I wouldn't expect there to any visible details in your
virtual TPM or TEE.  Instead, I would expect a geo-result AR with perhaps as
little as jurisdiction-country.
(It's it amazing that no-matter the string, there is some base64 somewhere on
my laptop that repeats it.  It's like digits of PI)

    > So for these three formats a Verifier producing a geographic result
    > today has nothing locational in the Evidence to work from. Its basis
    > would be the region label an operator selected in a console. That may
    > well be accurate, but it is a different kind of thing from a GNSS fix
    > or the sub-nanosecond proximity measure in Section 4, and a Relying
    > Party reading the Result cannot tell which one it received.

draft-lkspa-rats-verifiable-geo-fence-03 section 6.2 _Location Spoofing_
applies!

    > I am not asking the draft to adjudicate between those sources -
    > Appendix A shows provenance is already on your mind. The question is
    > whether a geographic Result should be able to carry some indication of
    > the class of input it rests on, so that it is not read as stronger than
    > the evidence underneath it. If that belongs in a later revision or
    > nowhere at all, that is a fine answer.

I am mildly opposed to being too specific/proscription about the provence of
the calculation.  Mildly because I think that ideally RPs don't need to know,
but also that it's a potential leak of the underlying evidence which might be
very private.

However, https://github.com/mcr/geographicresult/issues/2
and:     https://github.com/mcr/geographicresult/pull/4

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

**       My working hours and your working hours may be different.         **
** Please do not feel obligated to reply outside your normal working hours **