Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

ianG <iang@iang.org> Wed, 26 August 2015 16:03 UTC

Return-Path: <iang@iang.org>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC771A0145 for <tcpinc@ietfa.amsl.com>; Wed, 26 Aug 2015 09:03: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 whkZ0bIigqIe for <tcpinc@ietfa.amsl.com>; Wed, 26 Aug 2015 09:03:14 -0700 (PDT)
Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D84841A038C for <tcpinc@ietf.org>; Wed, 26 Aug 2015 09:03:11 -0700 (PDT)
Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id DE0E86D783; Wed, 26 Aug 2015 12:03:10 -0400 (EDT)
Message-ID: <55DDE33D.8030803@iang.org>
Date: Wed, 26 Aug 2015 17:03:09 +0100
From: ianG <iang@iang.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: tcpinc@ietf.org
References: <CABcZeBNEFVkDi38y3G-C2nQF=dzW2mGDsj5DVK_OKVkPwK=G0g@mail.gmail.com> <878u92oadf.fsf@ta.scs.stanford.edu> <CACsn0ckQskjLqo0=YfJrmBEsyCaq0jpcSzGUwKhRo0BzzQ=wDA@mail.gmail.com> <871teuo7nu.fsf@ta.scs.stanford.edu> <CACsn0ckn-QdoXmTgjW8gYQyVqZ0x9JHEYvZO5VHQkG9nKA3-Ew@mail.gmail.com> <87wpwmnenv.fsf@ta.scs.stanford.edu> <CACsn0cnq9cZdkn=yp8-GJfXDGMP8r1sib3qrQQEQYhF25kYZPg@mail.gmail.com> <87twrpokpz.fsf@ta.scs.stanford.edu> <CACsn0ck2PfKQ8pkDLiSmuLH+81s2GzsBnKYH7e=5ga5nSJvo1Q@mail.gmail.com> <87io85ofkl.fsf@ta.scs.stanford.edu>
In-Reply-To: <87io85ofkl.fsf@ta.scs.stanford.edu>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpinc/gQVeYsUlLG2Ljuqsnvz792-32b4>
Subject: Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for adding encryption to TCP." <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Aug 2015 16:03:15 -0000

On 23/08/2015 22:33 pm, David Mazieres wrote:
> Well, hypothetically, say the US prefers spec X and the EU prefers spec
> Y.  The goal is that two hosts in the US would always choose spec X and
> two hosts in the EU would always chose spec Y.  But when a host in the
> US communicates with a host in the EU, we don't really care as
> much--they could choose X or Y, so we might as well base it on the
> preferences of the passive opener.  However, hard-coding the spec
> rankings risks delaying standardization to argue over which specs should
> take priority.


Again, this argument doesn't apply to TCPINC.  If someone (anyone) 
specifies a certain algorithm at management level, they can and should 
use TLS.  And, that especially applies to the banks in Russia...

The notion that someone is both specifying TCPINC and specifying 
algorithm suite XXX appears too constructed to get much credence.



iang



ps; The argument doesn't apply generally either:

a. We here are far better placed to choose the Internet's crypto suite 
for the general case than any manager, committee, or sysadm.
b. If the Russians don't trust it, they are entirely at liberty to write 
their own crypto protocol and back-fit it into their software.  It's not 
that hard, and if they care - which they do for natsec - they'll be 
backfitting software anyway.
c. the deployment argument wins over for the banks.
d. Unlike the WB/IMF/UN, IETF isn't a subsidy organisation to deliver 
solutions to governments.  It delivers to the masses, not any particular 
squeaky wheel.
e.  etc...