To Rick's point: Providing a signed timestamp could be done on Atlas Anchors, and perhaps that's a better place to start than the software probes.
To Philip's point, the basic protocol I am hoping to enable looks as follows: (I'll describe the roughtime variant) * A machine wants to attest that it is in (e.g. Seattle). It picks a set of machines that are believed to be in Seattle (perhaps atlas machines, or more generally machines that the measurement system has agreed on locations of in advance.) * It generates a statement saying "i am doing a measurement", and signs it. * It requests the time with it's own signature as a nonce and receives a (timestamp, uncertainty, signature) from the server, per https://blog.cloudflare.com/roughtime/ * It then immediately req-requests the time, using the signature it received as the nonce this time, and receives a second timestamp, uncertainty, signature. The combination of this data can then be provided to any other machine to place a bound on the RTT between the machine and the chosen measurement machine (the difference between the two timestamps). This can be validated without trusting the machine claiming it's latency bound, since the results are signed by the anchor. There are some complexities - e.g could the machine attesting it's location delegate the request to a different machine closer to the anchor? Depending on the situation there are mitigations for this, like asking that some piece of data the machine that's attesting it's location be hashed into the nonce, in a way that's difficult for the attesting machine to predict ahead of time (so that it would need to move all of its data to the delegate machine at which point it's already in a sense also in that secondary location at that time.) But the ability to locate client software deployment via latency with some guarantee that someone running it isn't spoofing their location is useful. An equivalent to this protocol can be used against tls1.2 servers that include the timestamp in their server randomness, with the caveat that those timestamps are only at second granularity. To compensate, the client will repeat the hashing RTT process for 1 second, so that the validatable data that is presented shows that the client was able to do 'n' RTT's with the server within one second. --Will On Wed, Apr 7, 2021 at 4:12 AM Rick Havern <richard.hav...@geant.org> wrote: > Couldn't this functionality be extended to the Atlas Anchors? > > Rick > > -----Original Message----- > From: ripe-atlas <ripe-atlas-boun...@ripe.net> On Behalf Of Philip Homburg > Sent: 07 April 2021 10:27 > To: ripe-atlas@ripe.net > Subject: Re: [atlas] Feature request for Validated Timestamps > > On 2021/04/06 17:04 , Will wrote: > > I'm not sure if there's a process for this sort of feature request > > beyond this mailing list. Would it help if I propose a more concrete > > PR against https://github.com/RIPE-NCC/ripe-atlas-software-probe > > <https://github.com/RIPE-NCC/ripe-atlas-software-probe> > > To the extend that you would like secure geolocation in presence of a > malicious probe, it would make sense to me to start with documenting the > protocol you would like to use. > > The current way of geolocating probes works by having to probe report > round > trip times to a number locations. Obviously, a malicious probe could > report > any rtt value. > > I'm sure we can come up with a protocol if we have a sufficient number of > trusted servers. However, such a protocol would need to be documented and > deployed on those servers. > > Philip > >
