Subject: [quicwg/base-drafts] The spin-bit should be some times disabled (#1931)

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Oct 2018 21:04:03 -0700

For privacy reasons, and in a probabilistic way to grease the spin-bit, and to provide a sufficient anonymity set to the privacy conscious folks.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1931

-- Commit Summary --

  * Merge pull request #6 from quicwg/master
  * Merge pull request #7 from quicwg/master
  * Adding some text to define probabilistic disabling

-- File Changes --

    M draft-ietf-quic-spin-exp.md (29)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1931.patch
https://github.com/quicwg/base-drafts/pull/1931.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 21:15:09 -0700

martinthomson commented on this pull request.

This seems like a good idea.  I have a lot of suggestions here but they boil down to:

1. remove hyphen from "spin-bit"
2. allow for servers to disable the spin bit as well - we should probably adjust the 1/8 rate to 1/16 to account for this
3. allow for servers to be concerned about hiding their location equally

> @@ -238,6 +238,17 @@ and the observer and the client, respectively. It does this by measuring the
 delay between a spin edge observed in the upstream direction and that observed
 in the downstream direction, and vice versa.
 
+# Disabling the spin bit

```suggestion
# Disabling the Spin Bit
```

> @@ -238,6 +238,17 @@ and the observer and the client, respectively. It does this by measuring the
 delay between a spin edge observed in the upstream direction and that observed
 in the downstream direction, and vice versa.
 
+# Disabling the spin bit
+
+Implementation SHOULD allow users to disable the spin-bit either globally,

```suggestion
Implementations SHOULD allow users to disable the spin bit either globally,
```

> @@ -238,6 +238,17 @@ and the observer and the client, respectively. It does this by measuring the
 delay between a spin edge observed in the upstream direction and that observed
 in the downstream direction, and vice versa.
 
+# Disabling the spin bit
+
+Implementation SHOULD allow users to disable the spin-bit either globally,
+or on a per-connection basis. Even when the spin-bit is not disabled by

```suggestion
or on a per-connection basis. Even when the spin bit is not disabled by
```

> @@ -238,6 +238,17 @@ and the observer and the client, respectively. It does this by measuring the
 delay between a spin edge observed in the upstream direction and that observed
 in the downstream direction, and vice versa.
 
+# Disabling the spin bit
+
+Implementation SHOULD allow users to disable the spin-bit either globally,
+or on a per-connection basis. Even when the spin-bit is not disabled by
+the user, implementations SHOULD disable the spin-bit on a randomly chosen

```suggestion
the user, implementations SHOULD disable the spin bit on a randomly chosen
```

> @@ -238,6 +238,17 @@ and the observer and the client, respectively. It does this by measuring the
 delay between a spin edge observed in the upstream direction and that observed
 in the downstream direction, and vice versa.
 
+# Disabling the spin bit
+
+Implementation SHOULD allow users to disable the spin-bit either globally,
+or on a per-connection basis. Even when the spin-bit is not disabled by
+the user, implementations SHOULD disable the spin-bit on a randomly chosen
+fraction of connections. The random process SHOULD be designed so that
+on average the spin-bit is disabled for at least 1/8th of the connections.

```suggestion
on average the spin bit is disabled for at least 1/8th of the connections.
```

> @@ -238,6 +238,17 @@ and the observer and the client, respectively. It does this by measuring the
 delay between a spin edge observed in the upstream direction and that observed
 in the downstream direction, and vice versa.
 
+# Disabling the spin bit
+
+Implementation SHOULD allow users to disable the spin-bit either globally,
+or on a per-connection basis. Even when the spin-bit is not disabled by
+the user, implementations SHOULD disable the spin-bit on a randomly chosen
+fraction of connections. The random process SHOULD be designed so that
+on average the spin-bit is disabled for at least 1/8th of the connections.
+
+When the spin-bit is disabled, peers MUST set the spin bit value to zero,

```suggestion
When the spin bit is disabled, endpoints MUST set the spin bit value to zero,
```

Any sense in permitting different forms of disabling?  I mean, there are other ways to erode the signal.  Fixed to zero, fixed to one, random, alternating values on every packet.  I wouldn't prohibit any (or all) of these techniques from being used.

> @@ -251,7 +262,23 @@ same as those for passive RTT measurement in general. It has been shown
 {{PAM-RTT}} that RTT measurements do not provide more information for
 geolocation than is available in the most basic, freely-available IP address
 based location databases. The risk of exposure of per-flow network RTT to
-on-path devices is therefore negligible.
+on-path devices is in most cases negligible.
+
+There is however an exception, when parts of the path from client to server
+are hidden from observers. An example would be a server accessed through a
+proxy. The spin bit allows for measurement of the end-to-end
+RTT, and will thus enable adversaries near the client to discover that
+the connection does not terminate at the visible destination address, and
+that the client is probably accessing a hidden server through a proxy.
+
+Clients that want to hide their use of a proxy or a relay will want to
+disable the spin bit. However, if only privacy sensitive clients ever
+disabled the spin bit, they would stick out. The probabilistic disabling
+behavior explained in {#disabling-the-spin-bit} ensures that other clients

```suggestion
behavior explained in {{disabling-the-spin-bit}} ensures that other endpoints
```

> @@ -251,7 +262,23 @@ same as those for passive RTT measurement in general. It has been shown
 {{PAM-RTT}} that RTT measurements do not provide more information for
 geolocation than is available in the most basic, freely-available IP address
 based location databases. The risk of exposure of per-flow network RTT to
-on-path devices is therefore negligible.
+on-path devices is in most cases negligible.
+
+There is however an exception, when parts of the path from client to server
+are hidden from observers. An example would be a server accessed through a
+proxy. The spin bit allows for measurement of the end-to-end
+RTT, and will thus enable adversaries near the client to discover that
+the connection does not terminate at the visible destination address, and
+that the client is probably accessing a hidden server through a proxy.
+
+Clients that want to hide their use of a proxy or a relay will want to
+disable the spin bit. However, if only privacy sensitive clients ever
+disabled the spin bit, they would stick out. The probabilistic disabling
+behavior explained in {#disabling-the-spin-bit} ensures that other clients
+will also disabling the spin bit some of the time, thus hiding the

```suggestion
will also disable the spin bit some of the time, thus hiding the
```

> @@ -251,7 +262,23 @@ same as those for passive RTT measurement in general. It has been shown
 {{PAM-RTT}} that RTT measurements do not provide more information for
 geolocation than is available in the most basic, freely-available IP address
 based location databases. The risk of exposure of per-flow network RTT to
-on-path devices is therefore negligible.
+on-path devices is in most cases negligible.
+
+There is however an exception, when parts of the path from client to server
+are hidden from observers. An example would be a server accessed through a
+proxy. The spin bit allows for measurement of the end-to-end
+RTT, and will thus enable adversaries near the client to discover that
+the connection does not terminate at the visible destination address, and
+that the client is probably accessing a hidden server through a proxy.
+
+Clients that want to hide their use of a proxy or a relay will want to

```suggestion
Endpoints that want to hide their use of a proxy or a relay will want to
```

I don't think that we can assume that it is only clients that will be affected by this.

> @@ -251,7 +262,23 @@ same as those for passive RTT measurement in general. It has been shown
 {{PAM-RTT}} that RTT measurements do not provide more information for
 geolocation than is available in the most basic, freely-available IP address
 based location databases. The risk of exposure of per-flow network RTT to
-on-path devices is therefore negligible.
+on-path devices is in most cases negligible.
+
+There is however an exception, when parts of the path from client to server
+are hidden from observers. An example would be a server accessed through a
+proxy. The spin bit allows for measurement of the end-to-end
+RTT, and will thus enable adversaries near the client to discover that

```suggestion
RTT, and will thus enable adversaries near the endpoint to discover that
```

> @@ -251,7 +262,23 @@ same as those for passive RTT measurement in general. It has been shown
 {{PAM-RTT}} that RTT measurements do not provide more information for
 geolocation than is available in the most basic, freely-available IP address
 based location databases. The risk of exposure of per-flow network RTT to
-on-path devices is therefore negligible.
+on-path devices is in most cases negligible.
+
+There is however an exception, when parts of the path from client to server
+are hidden from observers. An example would be a server accessed through a
+proxy. The spin bit allows for measurement of the end-to-end
+RTT, and will thus enable adversaries near the client to discover that
+the connection does not terminate at the visible destination address, and

```suggestion
the connection does not terminate at the visible destination address.
```

> @@ -251,7 +262,23 @@ same as those for passive RTT measurement in general. It has been shown
 {{PAM-RTT}} that RTT measurements do not provide more information for
 geolocation than is available in the most basic, freely-available IP address
 based location databases. The risk of exposure of per-flow network RTT to
-on-path devices is therefore negligible.
+on-path devices is in most cases negligible.
+
+There is however an exception, when parts of the path from client to server
+are hidden from observers. An example would be a server accessed through a
+proxy. The spin bit allows for measurement of the end-to-end
+RTT, and will thus enable adversaries near the client to discover that
+the connection does not terminate at the visible destination address, and
+that the client is probably accessing a hidden server through a proxy.

```suggestion
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931#pullrequestreview-169605991

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Oct 2018 21:21:02 -0700

@huitema pushed 1 commit.

01545db  Update draft-ietf-quic-spin-exp.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931/files/caad83795f789cd0ecdb366f248a4dfcaea9cd14..01545db846f7ab34f98b95a005d89553055a25ba

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Oct 2018 21:21:18 -0700

9156224  Update draft-ietf-quic-spin-exp.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931/files/01545db846f7ab34f98b95a005d89553055a25ba..91562246ae5a6d18341f14afd514566e9e8b098b

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Oct 2018 21:21:36 -0700

eb5d7a1  Update draft-ietf-quic-spin-exp.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931/files/91562246ae5a6d18341f14afd514566e9e8b098b..eb5d7a189489ee4a271badee21ee96f9dc28014d

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Oct 2018 21:21:56 -0700

7bcfcab  Update draft-ietf-quic-spin-exp.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931/files/eb5d7a189489ee4a271badee21ee96f9dc28014d..7bcfcab63c557c4a0984c68706ae00e40d819aac

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Oct 2018 21:22:16 -0700

3ea6fff  Update draft-ietf-quic-spin-exp.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931/files/7bcfcab63c557c4a0984c68706ae00e40d819aac..3ea6fffa22d0628cd6a6c4b96fe3f71d88563539

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Oct 2018 21:22:28 -0700

e8b37d6  Update draft-ietf-quic-spin-exp.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931/files/3ea6fffa22d0628cd6a6c4b96fe3f71d88563539..e8b37d6c685cbbf61bc3d3fb83b4e9f3b20a209a

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Oct 2018 21:26:55 -0700

huitema commented on this pull request.

Yes, there is a reasonable case for saying SHOULD, and then adding a sentence that they MAY experiment with alternatives. But then these alternatives are going to stick out.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931#discussion_r229172741

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 21:30:25 -0700

I would rather say that the endpoint can set the value to any value then.  Providing a concrete suggestion means that anyone who diverges from that suggestion will stick out.  Not providing a concrete suggestion means that you might end up with the choice of method being used to identify an implementation, but that's probably a lost cause.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931#discussion_r229173173

---

From: Marten Seemann <[email-masked]>
Date: Mon, 29 Oct 2018 21:36:08 -0700

marten-seemann commented on this pull request.

For greasing it might be (slightly) better to just use random values for this bit, otherwise middleboxes might learn that this bit is either 0 all the time or contains a valid spin bit.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931#discussion_r229173757

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Oct 2018 21:37:21 -0700

0764e3a  Couple of edits, based on feedback from MT

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931/files/e8b37d6c685cbbf61bc3d3fb83b4e9f3b20a209a..0764e3a54eee6cca7bfe526f8454ad3a1021b0eb

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Oct 2018 21:38:05 -0700

f3b610c  Update draft-ietf-quic-spin-exp.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931/files/0764e3a54eee6cca7bfe526f8454ad3a1021b0eb..f3b610c0a3b6b01d3f992b603f9c0cec5cdd31ce

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Oct 2018 21:38:21 -0700

2433924  Update draft-ietf-quic-spin-exp.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931/files/f3b610c0a3b6b01d3f992b603f9c0cec5cdd31ce..2433924499e5c42a42bbe6ea86cc44b1ff51d588

---

From: janaiyengar <[email-masked]>
Date: Mon, 29 Oct 2018 21:40:04 -0700

janaiyengar approved this pull request.

LGTM; just a few nits

+# Disabling the Spin Bit
+
+Implementations SHOULD allow users to disable the spin bit either globally,

```suggestion
Implementations SHOULD allow users to disable the spin bit either globally
```

+# Disabling the Spin Bit
+
+Implementations SHOULD allow users to disable the spin bit either globally,
+or on a per-connection basis. Even when the spin bit is not disabled by
+the user, implementations SHOULD disable the spin bit on a randomly chosen
+fraction of connections. The random process SHOULD be designed so that

```suggestion
fraction of connections.  The selection process should be designed such that
```

+RTT, and will thus enable adversaries near the endpoint to discover that
+Endpoints that want to hide their use of a proxy or a relay will want to

```suggestion
disable the spin bit. However, if only privacy-sensitive clients ever
```

+on-path devices is in most cases negligible.
+
+There is however an exception, when parts of the path from client to server
+are hidden from observers. An example would be a server accessed through a
+proxy. The spin bit allows for measurement of the end-to-end
+RTT, and will thus enable adversaries near the endpoint to discover that
+the connection does not terminate at the visible destination address, and
+that the client is probably accessing a hidden server through a proxy.
+
+Endpoints that want to hide their use of a proxy or a relay will want to
+disable the spin bit. However, if only privacy sensitive clients ever
+disabled the spin bit, they would stick out. The probabilistic disabling
+behavior explained in {#disabling-the-spin-bit} ensures that other clients
+will also disabling the spin bit some of the time, thus hiding the
+privacy sensitive clients in a large anonymity set. It also provides

```suggestion
privacy-sensitive clients in a large anonymity set. It also provides
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931#pullrequestreview-169609232

---

From: janaiyengar <[email-masked]>
Date: Mon, 29 Oct 2018 21:41:17 -0700

janaiyengar commented on this pull request.

> @@ -251,7 +263,22 @@ same as those for passive RTT measurement in general. It has been shown
+the connection does not terminate at the visible destination address.
+disable the spin bit. However, if only privacy sensitive clients or servers ever

```suggestion
disable the spin bit. However, if only privacy-sensitive clients or servers ever
```

> @@ -251,7 +263,22 @@ same as those for passive RTT measurement in general. It has been shown
 {{PAM-RTT}} that RTT measurements do not provide more information for
 geolocation than is available in the most basic, freely-available IP address
 based location databases. The risk of exposure of per-flow network RTT to
-on-path devices is therefore negligible.
+on-path devices is in most cases negligible.
+
+There is however an exception, when parts of the path from client to server
+are hidden from observers. An example would be a server accessed through a
+proxy. The spin bit allows for measurement of the end-to-end
+RTT, and will thus enable adversaries near the endpoint to discover that
+the connection does not terminate at the visible destination address.
+
+Endpoints that want to hide their use of a proxy or a relay will want to
+disable the spin bit. However, if only privacy sensitive clients or servers ever
+disabled the spin bit, they would stick out. The probabilistic disabling
+behavior explained in {#disabling-the-spin-bit} ensures that other endpoints
+will also disable the spin bit some of the time, thus hiding the
+privacy sensitive endpoints in a large anonymity set. It also provides

```suggestion
privacy-sensitive endpoints in a large anonymity set. It also provides
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931#pullrequestreview-169610136

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Oct 2018 21:43:45 -0700

c96a037  Update draft-ietf-quic-spin-exp.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931/files/2433924499e5c42a42bbe6ea86cc44b1ff51d588..c96a037276b9d4a29ba894cfc2182df6f7085746

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Oct 2018 21:44:14 -0700

4b04bff  Update draft-ietf-quic-spin-exp.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931/files/c96a037276b9d4a29ba894cfc2182df6f7085746..4b04bffecb6bfc02af8f52a992818afbca610802

---

From: Marten Seemann <[email-masked]>
Date: Tue, 30 Oct 2018 04:51:01 +0000 (UTC)

It seems like this PR is absolutely essential to fulfill our charter (assuming that we standardize the spin bit, that is), which requires us to design a protocol that has privacy properties as least as good as TLS1.3 over TCP.

I'm still wondering if this is good enough though. If 1/8 of connections opt out of the spin-bit, this will provide a large anonymity set, if peers using VPN are rare. 
Consider however a situation where 50% of the peers are using a VPN, and don't want to expose their RTT. 80% of all connections that disable the spin bit are then VPN clients, which would certainly make them stick out.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931#issuecomment-434171180

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Oct 2018 22:02:33 -0700

0410802  Making sure that all online edits are taken into account.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931/files/4b04bffecb6bfc02af8f52a992818afbca610802..04108029a36ea53ba678fe8896a53b6e2f1cdced

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Oct 2018 22:07:48 -0700

In order of complexity, I can see:

1) Always zero. Simple, people won't mess up.
2) Pick either 0 or 1 randomly at the beginning of the connection. Simple enough, somewhat better than always zero for preventing ossification.
3) Pick a random value each time. I don't like that too much. Implementation will mess up and generate a fingerprint.

I could specify flip a coin at the beginning of each connection if that's what you want.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931#discussion_r229177336

---

From: Marten Seemann <[email-masked]>
Date: Mon, 29 Oct 2018 22:10:16 -0700

In New York we discussed the proposal to grease whatever bits are left in the first octet by just encrypting 0s. I assumed that peers opting out of the spin bit would use the same algorithm they use for greasing the other bits.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931#discussion_r229177555

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Oct 2018 22:18:46 -0700

@marten-seemann Yes, encryption is better than just randomization, especially if we specify it completely so there are no differences between implementations. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931#discussion_r229178613

---

From: MikkelFJ <[email-masked]>
Date: Tue, 30 Oct 2018 08:05:39 +0000 (UTC)

It is easy to detect the same user after multiple visits, and also easy to detect an IP range as serving as a VPN, so it is this complexity really worthwhile?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931#issuecomment-434206927

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Oct 2018 02:07:46 -0700

You can't encrypt using the same technique because the value you choose will be input to the packet protection AEAD and so might alter the header encryption sampling.  If the intent is to appear random, a CSPRNG would be fine.  If the value can be predicted, then you risk undoing packet number encryption, promoting linkability, or something worse.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931#discussion_r229223666

---

From: Brian Trammell <[email-masked]>
Date: Tue, 30 Oct 2018 19:29:44 +0000 (UTC)

britram approved this pull request.

LGTM, thanks for this! 

(Specifics might change after Bangkok discussion, but this covers the broad lines)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931#pullrequestreview-169957636

---

From: Brian Trammell <[email-masked]>
Date: Wed, 31 Oct 2018 01:39:22 -0700

Merged #1931 into master.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1931#event-1937209040