[atlas] Feature request for Validated Timestamps

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.havern at geant.org> wrote:

> Couldn't this functionality be extended to the Atlas Anchors?
>
> Rick
>
> -----Original Message-----
> From: ripe-atlas <ripe-atlas-bounces at ripe.net> On Behalf Of Philip Homburg
> Sent: 07 April 2021 10:27
> To: ripe-atlas at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/ripe-atlas/attachments/20210413/7507b66e/attachment.html>