Re: Structuring the BKK spin bit discussion

[Mikkel Fahnøe Jørgensen <[e-mail]>]

Obviously some research effort has been put into this, but I find it hard
to believe that you cannot approximately geolocate within 3000km
considering that you derive an AES key based on remote timing attacks.


On 31 October 2018 at 19.25.45, Roland Zink ([e-mail]) wrote:


Am 31.10.2018 um 18:16 schrieb Brian Trammell (IETF):
> hi Praveen,
>
>> On 31 Oct 2018, at 17:32, Praveen Balasubramanian <pravb=
[e-mail]> wrote:
>>
>> Since the handshake exposes the RTT information, what is the geolocation
privacy issue resulting from the spin bit? Brian, what are the edge cases
you refer to where handshake latency will be different than what is
measured by spin bit?
> In the case that...
>
> - ...an end-to-end connection actually terminates at a location different
than the apparent location in the endpoint IP address, because the endpoint
IP address is a VPN tunnel endpoint
> - ...the "hidden" endpoint is very far (> ~3000-5000km) from the apparent
location
> - ...that VPN tunnel exists solely to make the end-to-end association
appear to originate from at or near the VPN tunnel endpoint (e.g.,
anti-geofencing)
>
> then the handshake RTT gives you one sample per flow, and on a per-flow
basis, that is not enough evidence to definitively classify that flow as
having a far hidden endpoint. The spin bit provides more evidence, since
the upper bound on network RTT is the minimum RTT over all samples, and the
spin bit gives you more samples per flow.

Often devices have patterns where the RTT can be determined. Android and
iOS devices (and the Chrome browser) for example keep connections to
push servers and may do periodic keep-alives. Similar when a video is
watched using adaptive bitrate like MPEG DASH then there are
periodically idle times followed by a new request and response. So when
it is only about the privacy of the users RTT then the privacy isn't
very high anyway and detection isn't restricted to the handshake.

Regards,

Roland


> This is a contrived example, but the additional marginal geoprivacy risk
in this specific instance is nonzero, if epsilon. I don't think it's a
practical additional marginal risk, though, because:
>
> - the (non-research) techniques I know of that are deployed to prevent
breaking of geofences don't rely on latency measurement, rather on lookups
in IP address geolocation databases *.
> - given that one sample per flow in the handshake RTT and the fact that
an endpoint will often generate multiple flows, it will eventually be found
out anyway. The answer to the question of using a VPN for robust endpoint
hiding is "don't do that". a far endpoint actually wants to remain hidden,
it should be using a transport-terminating proxy or an anonymity network
like Tor, as opposed to a simple L3.5 VPN.
>
> As I said, turning off the spin bit is about peace of mind and
information reduction; in my opinion, even in the absence of practical
threat, that's reason enough to provide the option.
>
> Cheers,
>
> Brian
>
> * one of the cool things hiding in that IMC paper I cited upthread is the
fact that there's at least one anti-geofencing VPN provider that sells the
ability to have your traffic appear to come from any country on earth.
While the authors do not come right out and say it, it appears that said
provider discovered it was sufficient for their business model to have the
traffic originate from one of three easy-to-get-to, near-an-IXP
datacenters, on three different continents, and to do some Layer 9 work to
have the specific IPs labeled as coming from the desired countries in the
commercial IP geolocation databases. Hacking the database is way easier
than hacking the speed of light. :)
>
>> -----Original Message-----
>> From: QUIC <[e-mail]> On Behalf Of Brian Trammell (IETF)
>> Sent: Wednesday, October 31, 2018 7:19 AM
>> To: Marcus Ihlar <[e-mail]>
>> Cc: Lars Eggert <[e-mail]>; IETF QUIC WG <[e-mail]>; huitema
<[e-mail]>; Dmitri Tikhonov <[e-mail]>;
Kazuho Oku <[e-mail]>
>> Subject: Re: Structuring the BKK spin bit discussion
>>
>> hi Kazuho, Marcus,
>>
>> +1 to this; the intra-network latency variation on the mobile segment of
the mobile networks we looked at via the MONROE in the testbed in our PAM
paper the followed from the RTT DT work (see
https://github.com/mami-project/rtt-privacy-paper/blob/master/rtt-privacy.pdf,
especially section 3.1 and figure 2(b)) makes RTT measurement on a mobile
network useless for geolocation.
>>
>> We did notice (not shown in the paper) that different carriers (n = 4,
if I recall correctly) had distinct latency distributions, so with traffic
from all Japanese mobile users you could probably use RTT data in the
aggregate to build a "carrier classifier". This is of course a useless
exercise because you can already tell which carrier a subscriber is coming
from by looking at the IP address of the CGNAT exit.
>>
>> IMO there are only a few edge cases where there are actual potential
geoprivacy issues raised by the spin bit with respect to tunneled VPN
traffic. All of these involve trans- or intercontinental tunnels (>30ms of
additional RTT, for 3000km of location uncertainty -- how far is it from
Okinawa to Hokkaido?). In every case the handshake latency gives you away
as well, but in every case long RTTs might also have non-distance related
causes. So while I see disabling the spin bit as a necessary feature,
especially for clients to have, IMO its utility is more useful for peace of
mind and information reduction than for actual information elimination.
>>
>> Cheers,
>>
>> Brian
>>
>>> On 31 Oct 2018, at 13:40, Marcus Ihlar <[e-mail]>
wrote:
>>>
>>> Hi Kazuho,
>>> I believe the biggest difference is the size of the hidden network
segment.
>>> In the NAT case the client and NAT are still in the same country or
continent.
>>> A quick glacne at distancecalculator.net shows that the city farthest
from Tokyo in Japan is Naha-Shi, at 1554 km.
>>> That translates to roughly 5ms at the speed of light, so the kinds of
measurements to determine distance from Tokyo based on RTT will be
extremely sensitive and error prone.
>>> Please note that the distance analyis can be performed on handshake RTT
as well, for connections where the initial handshake is visible at the
measurement point.
>>>
>>>
>>> Från: QUIC <[e-mail]> för Kazuho Oku
>>> <[e-mail]>
>>> Skickat: den 31 oktober 2018 11:20
>>> Till: Christian Huitema
>>> Kopia: Lars Eggert; IETF QUIC WG; Dmitri Tikhonov
>>> Ämne: Re: Structuring the BKK spin bit discussion
>>>
>>> 2018年10月30日(火) 1:54 Christian Huitema <[e-mail]>:
>>>>
>>>>
>>>>> On Oct 29, 2018, at 9:08 AM, Dmitri Tikhonov <
[e-mail]> wrote:
>>>>>
>>>>>> On Mon, Oct 29, 2018 at 05:26:34PM +0200, Lars Eggert wrote:
>>>>>> We'd specifically like to ask client and server implementors with
>>>>>> projected sizable deployments to indicate whether they intent to
>>>>>> implement and deploy, if the WG decided to include the spin-bit
>>>>>> in the spec.
>>>>> LiteSpeed Technologies will support the spin bit -- both in our
>>>>> server and client QUIC implementations -- if it make it into the
>>>>> draft.
>>>> My implementation is not used in any large scale deployment, but it
does support the spin bit. In fact, it has configuration options to support
spin bit variants: node, just spin, spin + vec, spin + QR.
>>>>
>>>> I think the strongest objection to the spin bit was put up by Marten
during the last interim: measuring the RTT with the spin bit discloses the
use of hidden path segments like VPN. This issue was not discussed during
the privacy analysis.
>>> May I ask if the VPN users are the only ones that lose some privacy
>>> with spin bits?
>>>
>>> I ask this because I live in a country where IIUC the mobile carriers
>>> place their nation-wide carrier-grade NAT near the capital city (i.e.,
>>> Tokyo). That means that for people living in the country, having spin
>>> bits turned on could reveal their distance from Tokyo.
>>>
>>> So the question is: if VPN users need special care, do some NAT users
>>> as well? Or if the answer is no, what is the difference from between
>>> the two groups?
>>>
>>> Generally speaking, I am not against giving users the freedom to
>>> expose spin bits, however I am wondering how the endpoints should
>>> provide the freedom of choice (UI question) as well as what the
>>> default should be.
>>>
>>>> The privacy issue could be mitigated by turning off the spin bit at
privacy sensitive clients, but this would make these clients "stick out".
>>>>
>>>> One solution would be to remove the spin bit from the spec, trading
off better privacy for worse management. I am considering another solution
in which privacy sensitive clients hide the RTT by controlling the spin,
for example spinning at fixed intervals. I plan testing that option in
Picoquic.
>>>>
>>>> -- Christian Huitema
>>>>
>>>>
>>>
>>> --
>>> Kazuho Oku