Re: Structuring the BKK spin bit discussion

"Brian Trammell (IETF)" <> Mon, 29 October 2018 22:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9874513104F for <>; Mon, 29 Oct 2018 15:58:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2V11ms-HwmTB for <>; Mon, 29 Oct 2018 15:58:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A521131021 for <>; Mon, 29 Oct 2018 15:58:29 -0700 (PDT)
Received: from (localhost []) by localhost (Postfix) with ESMTP id C71F5341AD2; Mon, 29 Oct 2018 23:58:26 +0100 (CET)
X-Iway-Path: 0
Received: from localhost (localhost []) by localhost (ACF/20439.13183); Mon, 29 Oct 2018 23:58:26 +0100 (CET)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Mon, 29 Oct 2018 23:58:26 +0100 (CET)
Received: from [] (account HELO []) by (CommuniGate Pro SMTP 6.2.8) with ESMTPSA id 72030851; Mon, 29 Oct 2018 23:58:26 +0100
From: "Brian Trammell (IETF)" <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_3B29313A-2F60-4AA9-8FB6-13605538C7CF"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: Structuring the BKK spin bit discussion
Date: Mon, 29 Oct 2018 23:58:25 +0100
In-Reply-To: <>
Cc: Christian Huitema <>, Lars Eggert <>, QUIC WG <>, Dmitri Tikhonov <>
To: Martin Thomson <>
References: <> <20181029160802.GD7258@ubuntu-dmitri> <> <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Oct 2018 22:58:32 -0000

hi Martin, Christian, all,

> On 29 Oct 2018, at 23:29, Martin Thomson <> wrote:
> On Tue, Oct 30, 2018 at 3:54 AM Christian Huitema <> wrote:
>> 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.
> I had assumed that was part of the analysis and it was covered by the
> assumption that spinning could be disabled

+1. Probabilistically disabling spinning, which seems necessary if we want some grease to help us reserve the right to change the semantics of the bit at the spin bit's location in the wire image, should ensure that endpoints that want to disable spinning for their own reasons will have a large anonymity set to hide in, even in a future with perfect implementation and deployment of the spin bit.

>> 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.
> I've done a little thinking about this one, and it might conflict with
> the natural signals the transport emits, along the lines of what
> Andrew McGregor has mentioned on a couple of occasions.  If the spin
> bit is enabled, then privacy-sensitive endpoints will need to make a
> hard call regarding standing out.
> Note also that you probably can't hide the fact that you aren't at the
> same network location as the address you are using.  Spoofing a
> shorter RTT is impossible in general because you have to assume edges
> that haven't arrived yet.  If there are no edges you expose the
> charade.

You cannot reliably hide the fact that you're not at the same network location as the address you're using, spin bit or no. Most of the methods I know of for detecting people trying to hide where they're coming from don't rely on RTT at all. (Yes, I'm a Netflix customer who relies on Hurricane Electric's tunnel broker for IPv6 connectivity, why do you ask? ;) )

The recent academic work I'm aware of in this space (Weinberg et al "How to Catch When Proxies Lie", to appear at IMC this week) uses minimum RTT (with injected active measurement traffic) to conservatively draw exclusion circles to show that VPN providers that promise exits in certain countries probably don't actually deliver them. Not being vulnerable to this kind of exclusion analysis requires that you actually inject latency, not just in the spin bit, but over the entire flow (including the handshake).

RTT *higher* (even much higher) than an expected range for a given address pair isn't reliable enough to derive any sort of verdict from, due to the nature of delay and delay variability in the Internet.

So while I guess you can lie with the spin bit (even using rudimentary signal processing magic to take an assumed real RTT and make it look like a given lower target RTT, as long as you're not too worried about getting caught when your assumptions fail to hold), it's probably neither necessary nor sufficient to do so to hide a VPN exit. It's cheaper and more effective to just turn it off and hope.