Re: [Tcpcrypt] v3 of the charter

Joe Touch <touch@isi.edu> Thu, 01 May 2014 20:18 UTC

Return-Path: <touch@isi.edu>
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 B33A41A6F8C for <tcpcrypt@ietfa.amsl.com>; Thu, 1 May 2014 13:18:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level:
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 KKM8Sz2KZD0K for <tcpcrypt@ietfa.amsl.com>; Thu, 1 May 2014 13:18:09 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9413F1A0974 for <tcpcrypt@ietf.org>; Thu, 1 May 2014 13:18:09 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s41KHVih009407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 1 May 2014 13:17:31 -0700 (PDT)
Message-ID: <5362ABDA.9040608@isi.edu>
Date: Thu, 01 May 2014 13:17:30 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: David Mazieres expires 2014-07-30 PDT <mazieres-n2dt28vgwbtr8c37tzs7uyb7fi@temporary-address.scs.stanford.edu>, marcelo bagnulo braun <marcelo@it.uc3m.es>, 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>
In-Reply-To: <87ha59zgjo.fsf@ta.scs.stanford.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/H--QsHhROQLzI3HGL91P7IO2qxE
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: Thu, 01 May 2014 20:18:10 -0000

On 5/1/2014 8:04 AM, David Mazieres wrote:
> marcelo bagnulo braun <marcelo@it.uc3m.es> writes:
>
>>> FWIW, mine too - IMO, the issue of anti-fingerprinting can be
>>> specified without reference to role, in which case whether
>>> simultaneous open is supported or not can be determined in a candidate
>>> solution.
>>>
>>
>> could you propose text?
>
> How about eliminating the paragraph about anti-fingerprinting, and
> instead changing this text:
>
>> - An extended API describing how applications can obtain further
>>    benefits of the proposed extensions. In particular, the hooks for
>>    supporting external authentication will be defined in this
>>    document. This will be an informational document.
>
> To the following:
>
>          ... In particular, the hooks for supporting external
>          authentication will be defined in this document.  In addition,
>          the document shall specify functions that allow control over any
>          session parameters such as accepted ciphers or re-use of
>          cryptographic material from prior sessions (if the protocol
>          supports such re-use) and that help prevent multiple TCP
>          Inc. connections from being linked to the same endpoint.

But that's not quite all of what fingerprinting implies.

I would suggest changing the current fingerprinting requirement:

- 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.

to:

- 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.

Joe