Re: [Tcpcrypt] v3 of the charter

ianG <iang@iang.org> Fri, 02 May 2014 01:22 UTC

Return-Path: <iang@iang.org>
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 534FC1A09FA for <tcpcrypt@ietfa.amsl.com>; Thu, 1 May 2014 18:22:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.56
X-Spam-Level:
X-Spam-Status: No, score=-0.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34] autolearn=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 abAw3yhRTrqf for <tcpcrypt@ietfa.amsl.com>; Thu, 1 May 2014 18:22:00 -0700 (PDT)
Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id CACC61A09AC for <tcpcrypt@ietf.org>; Thu, 1 May 2014 18:21:59 -0700 (PDT)
Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 354806D581; Thu, 1 May 2014 21:21:52 -0400 (EDT)
Message-ID: <5360DC2A.1050100@iang.org>
Date: Wed, 30 Apr 2014 12:19:06 +0100
From: ianG <iang@iang.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: 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
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/xICbicK1EnbeeA17JbhU69Q4SkQ
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 01:22:01 -0000

On 30/04/2014 11:01 am, David Mazieres wrote:
> marcelo bagnulo braun <marcelo@it.uc3m.es> writes:
...
> There are just a couple of places where I think the charter is
> over-specifying things that might not be problems or that we might not
> understand, and this could potentially cause problems down the line.


I agree with all these points.  The goal is to get the designers to come
up with different attacks at the compromises possible.  It may be that
we accept a poorer performance if every other goal is met through a new
design;  conversely we may accept increased fingerprinting if the design
solves everything else...  I'd bet most will be happy to accept no
algorithm agility if there is a good version upgrade path ;)

We won't know until we see.

For this reason, I think most of the particular requirements should be
SHOULD, and should be rephrased in terms of "consideration be given
to..." or words to effect, as pointed out by David.  E.g.,

    "Consideration should be given to performance of latency, bandwidth
and CPU loading."

On the whole however, it's a lot better.  Thanks for removing the
requirement to turn it off!


iang


>> - The protocol must have acceptable performance.  For example, the
>> protocol may try to re-use existing cryptographic material for future
>> communication between the same endpoints to avoid expensive public key
>> operations on connection set up.
> 
> Saying "The protocol must have acceptable performance" is superfluous.
> By definition performance must be acceptable or we won't accept it,
> unless you want to invite a debate on what is and is not acceptable
> performance, which would then bifurcate into setup cost/latency and
> per-byte/packet overhead.
> 
> How about, "In order to minimize connection latency, the protocol may
> amortize the cost of public key operations over multiple connections
> between the same pair of hosts."
> 
>> - 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).
> 
> 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.
> 
> 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?
> 
> David
> 
> _______________________________________________
> Tcpcrypt mailing list
> Tcpcrypt@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpcrypt
>