Re: [Tcpcrypt] v3 of the charter
Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 30 April 2014 21:29 UTC
Return-Path: <dkg@fifthhorseman.net>
X-Original-To: tcpcrypt@ietfa.amsl.com
Delivered-To: tcpcrypt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC681A0958 for <tcpcrypt@ietfa.amsl.com>; Wed, 30 Apr 2014 14:29:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 KRiGp3X6VJUH for <tcpcrypt@ietfa.amsl.com>; Wed, 30 Apr 2014 14:29:10 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id B711A1A0953 for <tcpcrypt@ietf.org>; Wed, 30 Apr 2014 14:29:10 -0700 (PDT)
Received: from [10.70.10.85] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 61AF9F984; Wed, 30 Apr 2014 17:29:07 -0400 (EDT)
Message-ID: <53616B23.501@fifthhorseman.net>
Date: Wed, 30 Apr 2014 17:29:07 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0
MIME-Version: 1.0
To: David Mazieres expires 2014-07-29 CEST <mazieres-n37rkn7y8d5xpuk5sgvuvmuzki@temporary-address.scs.stanford.edu>, marcelo bagnulo braun <marcelo@it.uc3m.es>, tcpcrypt@ietf.org
References: <536099A0.30900@it.uc3m.es> <8738gv5e67.fsf@ta.scs.stanford.edu>
In-Reply-To: <8738gv5e67.fsf@ta.scs.stanford.edu>
X-Enigmail-Version: 1.6+git0.20140323
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="scLRc3EXSgCB621VgLjejWQF5a6du2KO9"
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/kLRBbDlJj5jY3yYVeVtg2rchQUM
Subject: Re: [Tcpcrypt] v3 of the charter
X-BeenThere: tcpcrypt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for adding encryption to TCP." <tcpcrypt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpcrypt>, <mailto:tcpcrypt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpcrypt/>
List-Post: <mailto:tcpcrypt@ietf.org>
List-Help: <mailto:tcpcrypt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpcrypt>, <mailto:tcpcrypt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Apr 2014 21:29:16 -0000
On 04/30/2014 06:01 AM, David Mazieres wrote: > marcelo bagnulo braun <marcelo@it.uc3m.es> writes: >> - must allow client to avoid fingerprinting: some clients may want to >> avoid appearing as the same client when connecting to a remote peer on >> subsequent occasions. This should either be the default (clients >> cannot be "fingerprinted" by the server based on shared state) or some >> mechanism should be available for clients to drop or ignore shared >> state to avoid being fingerprintable any more than would be present >> for a cleartext session. > > Both your text above, and the following suggestion by Lars: > >> Makes sense. Suggest to express it this way, e.g., "the protocol extension >> must not increase the possibility for endpoint fingerprinting compared to what >> is possible already". > > seem problematic to me. The very fact that you are enabling a new TCP > extension is going to increase the ability to fingerprint (vs. hosts > that have not deployed TCP Inc. yet). decreasing the size of the client's anonymity set by a single bit (derived from whether or not the client uses TCP Inc) is obviously unavoidable. But by the same token, if TCP Inc was widely deployed, plain TCP sessions would also in an anonymity set of their own (just with that bit set differently), so TCP Inc itself doesn't come out worse than TCP. But we want to avoid TCP Inc decreasing the client's anonymity set further than that (e.g. we want a client using TCP Inc to be able to appear as a different client (based on TCP Inc parameters) to a given server on subsequent connections if it wants to). For the charter, i think Marcelo's text is reasonable. Lars' suggestion of "what is possible already" seems equivalent to "would be present for a cleartext session" -- maybe what they both mean is best described as "no more fingerprintable than a session without TCP Inc" > I think the right thing to do is for the informational RFC to suggest > APIs allowing hosts to be "virtualized" in some way, so that a single > physical host actively opening TCP connections through a NAT can appear > the same as an arbitrary number of hosts, subject to existing TCP > fingerprinting techniques and the fact that TCP Inc. is installed. But > I'm wary of trying to specify that in the charter. I agree that this level of technical detail belongs in the RFC, but not the charter. > Would it be possible to drop the requirement in favor of something more > open-ended to the effect that consideration should be given to the > anonymity of hosts that change IP addresses or reside behind NATs? This text sounds less open-ended to me than the text you're proposing to replace. In particular, i also care about machines that have a single (non-changing) IP address and are not behind a NAT. Those machines should also be able to avoid fingerprinting from TCP Inc. While it's true they can be fingerprinted by their IP address, it's entirely possible for multiple people to share a single IP address by time slices (consider roommates with a cable modem who each plug their computers in to the same plug at different times). I think we should keep the language in the charter about enabling clients to avoid any extra fingerprinting, since it identifies the goal we want. --dkg
- Re: [Tcpcrypt] v3 of the charter David Mazieres
- Re: [Tcpcrypt] v3 of the charter Daniel Kahn Gillmor
- Re: [Tcpcrypt] v3 of the charter Joe Touch
- Re: [Tcpcrypt] v3 of the charter Joe Touch
- Re: [Tcpcrypt] v3 of the charter Daniel Kahn Gillmor
- Re: [Tcpcrypt] v3 of the charter Joe Touch
- [Tcpcrypt] v3 of the charter marcelo bagnulo braun
- Re: [Tcpcrypt] v3 of the charter Eggert, Lars
- Re: [Tcpcrypt] v3 of the charter Eggert, Lars
- Re: [Tcpcrypt] v3 of the charter marcelo bagnulo braun
- Re: [Tcpcrypt] v3 of the charter Eggert, Lars
- Re: [Tcpcrypt] v3 of the charter Stephen Farrell
- Re: [Tcpcrypt] v3 of the charter marcelo bagnulo braun
- Re: [Tcpcrypt] v3 of the charter Daniel Kahn Gillmor
- Re: [Tcpcrypt] v3 of the charter Joe Touch
- Re: [Tcpcrypt] v3 of the charter Daniel Kahn Gillmor
- Re: [Tcpcrypt] v3 of the charter Joe Touch
- Re: [Tcpcrypt] v3 of the charter Daniel Kahn Gillmor
- Re: [Tcpcrypt] v3 of the charter Daniel Kahn Gillmor
- Re: [Tcpcrypt] v3 of the charter Joe Touch
- Re: [Tcpcrypt] v3 of the charter ianG
- Re: [Tcpcrypt] v3 of the charter Joe Touch
- Re: [Tcpcrypt] v3 of the charter Tony Arcieri
- Re: [Tcpcrypt] v3 of the charter Joe Touch
- Re: [Tcpcrypt] v3 of the charter Tony Arcieri
- Re: [Tcpcrypt] v3 of the charter Joe Touch
- Re: [Tcpcrypt] v3 of the charter marcelo bagnulo braun
- Re: [Tcpcrypt] v3 of the charter David Mazieres
- Re: [Tcpcrypt] v3 of the charter marcelo bagnulo braun
- Re: [Tcpcrypt] v3 of the charter Joe Touch
- Re: [Tcpcrypt] v3 of the charter ianG
- Re: [Tcpcrypt] v3 of the charter Daniel Kahn Gillmor
- Re: [Tcpcrypt] v3 of the charter Christian Huitema
- Re: [Tcpcrypt] v3 of the charter marcelo bagnulo braun
- Re: [Tcpcrypt] v3 of the charter Erik Nygren
- Re: [Tcpcrypt] v3 of the charter David Mazieres