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