Re: [Tcpcrypt] v3 of the charter

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 02 May 2014 04: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 226611A886B for <tcpcrypt@ietfa.amsl.com>; Thu, 1 May 2014 21:29:50 -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 f57pfdMjrqCN for <tcpcrypt@ietfa.amsl.com>; Thu, 1 May 2014 21:29:48 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 913681A8861 for <tcpcrypt@ietf.org>; Thu, 1 May 2014 21:29:48 -0700 (PDT)
Received: from [192.168.13.159] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id D84C8F984 for <tcpcrypt@ietf.org>; Fri, 2 May 2014 00:29:44 -0400 (EDT)
Message-ID: <53631F36.4050700@fifthhorseman.net>
Date: Fri, 02 May 2014 00:29:42 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: tcpcrypt@ietf.org
References: <536099A0.30900@it.uc3m.es> <23862F2E-9D56-4651-9202-FC676D15720B@netapp.com> <07C2D017-9342-4742-990C-7D3BC795049F@netapp.com> <536157E1.2060202@fifthhorseman.net> <53615A40.9050903@isi.edu> <536165C6.20909@fifthhorseman.net> <536167CC.8010703@isi.edu> <536168FA.2010800@fifthhorseman.net> <53616AD4.6010309@isi.edu> <53616D52.3090504@fifthhorseman.net> <5361824F.8080506@iang.org> <536187C1.3060009@isi.edu> <5361FCBD.6010509@it.uc3m.es> <87ha59zgjo.fsf@ta.scs.stanford.edu> <5362ABDA.9040608@isi.edu>
In-Reply-To: <5362ABDA.9040608@isi.edu>
X-Enigmail-Version: 1.6+git0.20140323
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="x9qNxloEB6v29BPfN4paDQgVNR80Td7MU"
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/icR1_yJRo1wQf4UKIqVgZDE94vc
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: Fri, 02 May 2014 04:29:50 -0000

On 05/01/2014 04:17 PM, Joe Touch wrote:

> - must not increase information available for fingerprinting: endpoints
> should be identified by their IP address and port and no additional
> information should be provided that indicates the persistence of an
> endpoint or identity other than the IP address and port.

I know i raised the fingerprinting concern earlier here, but i'm
concerned that this statement actually goes too far.  "must not increase
information available for fingerprinting" implies that peers basically
cannot cache state between subsequent connections, which seems like an
obvious opportunity for performance improvements.

When a client connects to a server a second time, it's entirely
reasonable in many cases for the client to presume that the server is
the same server it spoke with last time and be able to prove it by doing
some sort of abbreviated handshake that presumes the server has some
known keying material.  Indeed, the "hooks for authentication" angle
seems to explicitly require the possibility of some sort of persistent
fingerprintability.

How about:

The repeated use of TCP Inc between two peers may provide information to
one peer that could be used to re-identify or "fingerprint" the other
peer in subsequent transactions.  Peers should be able to use TCP Inc
while avoiding leakage of any additional "fingerprinting" information
about themselves if configured or built to do so.

	--dkg