Subject: Re: Spin bit discussion - where we're at

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 27 Nov 2017 08:11:59 +0000

Hi,

On 2017-11-26, at 20:26, MORTON, ALFRED C (AL) <[email-masked]> wrote:
> Question: Is there a privacy analysis of present ECN available?
> (a search yielded many results with Missing: privacy)

not that I'm aware of; CC'ing tsv-area@ for some broader input.

(On first glance, the - user - privacy aspects here seem to be much more contained, since ECN is mostly about the network exposing information to the end systems, and not vice versa.)

Lars

---

From: "Black, David" <[email-masked]>
Date: Tue, 28 Nov 2017 23:52:40 +0000

> (On first glance, the - user - privacy aspects here seem to be much more contained, since ECN is mostly about the network exposing information to the end systems, and not vice versa.)

That sounds like the right high-level summary.  The fact that a transport protocol implementation supports ECN does not intrinsically expose any information about the user to the network. The primary information flow is congestion information flowing from the network to the endpoints.

Thanks, --David

From: tsv-area [mailto:[email-masked]] On Behalf Of Eggert, Lars
Sent: Monday, November 27, 2017 3:12 AM
To: MORTON, ALFRED C (AL) <[email-masked]>
Cc: QUIC WG <[email-masked]>; [email-masked]
Subject: Re: Spin bit discussion - where we're at

Hi,

On 2017-11-26, at 20:26, MORTON, ALFRED C (AL) <[email-masked]<mailto:[email-masked]>> wrote:

Lars

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 29 Nov 2017 09:26:29 +0900

hi, David,

> On 29 Nov 2017, at 08:52, Black, David <[email-masked]> wrote:
> 

There are three possible states for an ECN negotiation: not attempted, failed, and succeeded. Each of these can add a fractional bit of information about the client and server TCP implementations. If a server negotiates ECN, you can be reasonably certain that it supports ECN, and can leverage the observations that sysadmins love defaults and servers are mostly Linux these days to figure out whether it's running a kernel before or after server side defaults were turned on.

Long-term observation of the ECN negotiation attempts of a client can be used to determine if the client is using probabilistic negotiation by default; i.e. is an Apple device of a certain vintage.

These are fractional bits of fingerprinting information, though, if that. I'm almost certain (but won't take the time to do the research now) that any of these observations would be useless. Anyone in a position to make them could also get much more information about the behavior of the TCP stacks at each end, such that the ECN bits add negligible information. cf. p0f, if that's still a thing.

Cheers, B

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 29 Nov 2017 07:09:06 +0000

Hi,

> These are fractional bits of fingerprinting information, though, if that. I'm almost certain (but won't take the time to do the research now) that any of these observations would be useless. Anyone…

this is certainly all true for TCP and ECN, where whether ECN is available and/or tried by default is tied to a certain kernel versions.

But for QUIC (= ECN with UDP), whether ECN is used or not is completely up to the app (= the QUIC stack), so you can't draw conclusions about whether a certain kernel or OS flavor is underneath (other than they less than about ten years old, i.e., have support for the IP_TOS/IP_RECVTOS socket options.)

So the fractional information leakage seems to be less than with TCP.

Lars