Re: Spin bit discussion - where we're at

"Brian Trammell (IETF)" <ietf@trammell.ch> Wed, 29 November 2017 00:26 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71224127735; Tue, 28 Nov 2017 16:26:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZICJcyyawul; Tue, 28 Nov 2017 16:26:39 -0800 (PST)
Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6BA1127136; Tue, 28 Nov 2017 16:26:38 -0800 (PST)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id DFB0234096A; Wed, 29 Nov 2017 01:26:36 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.6335); Wed, 29 Nov 2017 01:26:33 +0100 (CET)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 29 Nov 2017 01:26:33 +0100 (CET)
Received: from [114.175.86.34] (account ietf@trammell.ch HELO [192.168.1.183]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 37572338; Wed, 29 Nov 2017 01:26:32 +0100
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
Message-Id: <E67F3C59-19E5-4B8C-8B63-422A80F27D99@trammell.ch>
Content-Type: multipart/signed; boundary="Apple-Mail=_1F2F7D2B-855A-4955-93C0-24173DC72004"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Spin bit discussion - where we're at
Date: Wed, 29 Nov 2017 09:26:29 +0900
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362FD920D9@MX307CL04.corp.emc.com>
Cc: "Eggert, Lars" <lars@netapp.com>, Al Morton <acmorton@att.com>, QUIC WG <quic@ietf.org>, "tsv-area@ietf.org" <tsv-area@ietf.org>
To: "Black, David" <David.Black@dell.com>
References: <AFEE7BBA-E5DC-4064-AA19-33921EAF4C01@mnot.net> <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <fd09b775-4c0e-9d99-e49c-421212f2e5e4@cs.tcd.ie> <F4F7A438-F30F-406B-9971-DA05DA458B44@netapp.com> <C8DDB9E3-C8F9-49CB-8C6D-E381C00AC02D@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> <791D0F33-4CB7-4049-AF29-174E41C1FD2E@netapp.com> <CE03DB3D7B45C245BCA0D243277949362FD920D9@MX307CL04.corp.emc.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Bie1Vi6PlXvBv7SDE-c4Y8YQRJ0>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Nov 2017 00:26:42 -0000

hi, David,

> On 29 Nov 2017, at 08:52, Black, David <David.Black@dell.com> wrote:
> 
> > (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.

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

> 
> Thanks, --David
> 
> From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Eggert, Lars
> Sent: Monday, November 27, 2017 3:12 AM
> To: MORTON, ALFRED C (AL) <acmorton@att.com>
> Cc: QUIC WG <quic@ietf.org>; tsv-area@ietf.org
> Subject: Re: Spin bit discussion - where we're at
> 
> Hi,
> 
> On 2017-11-26, at 20:26, MORTON, ALFRED C (AL) <acmorton@att.com> 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