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

ianG <iang@iang.org> Wed, 26 August 2015 16:34 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 D370B1B29EF for <tcpinc@ietfa.amsl.com>; Wed, 26 Aug 2015 09:34:42 -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 vShS2uFa7YRH for <tcpinc@ietfa.amsl.com>; Wed, 26 Aug 2015 09:34:41 -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 6D8A41B29EB for <tcpinc@ietf.org>; Wed, 26 Aug 2015 09:34:41 -0700 (PDT)
Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 9FBA56D78D; Wed, 26 Aug 2015 12:34:39 -0400 (EDT)
Message-ID: <55DDEA9E.20909@iang.org>
Date: Wed, 26 Aug 2015 17:34:38 +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> <CACsn0cmna07KzCZme7pxRgCcAOJLXzup3KPJ+bRimL=n3mpPXg@mail.gmail.com> <87vbc5l8si.fsf@ta.scs.stanford.edu> <CACsn0c=cLj2F6JyFX848D1TuDt0A=kT7UMm8ZPRRu-X6ow4oTQ@mail.gmail.com> <55DB79BC.8040309@bbn.com> <CACsn0ckLiC-RCjFNjLx01kCV2pEW58_NqJyt2bfXoAgZL994cw@mail.gmail.com> <55DC764F.4000104@bbn.com> <CAJU8_nW2tkQ9kLL=oyfjiry+8zWO1YR=hP4xM8L6uujWT8AzcA@mail.gmail.com>
In-Reply-To: <CAJU8_nW2tkQ9kLL=oyfjiry+8zWO1YR=hP4xM8L6uujWT8AzcA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpinc/YRSFroZvFEMtHMDKQNG2Llkp_NE>
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:34:43 -0000

On 25/08/2015 15:11 pm, Kyle Rose wrote:
>> into the reality of comparing ciphersuites justifies exposing all
>> possible ciphersuites, and permitting specifying arbitrary preferences
>> among them?
>>
>> The preferences of others are "arbitrary" but yours are not?
>
> Touché.


Arbitrary is fair enough.  The experiences out in sysadmland support 
that (cite https://bettercrypto.org/ ).

> I don't hear a lot of opposition to maintaining agility in ciphersuite
> preference.

<cough>  It was discussed about 6 months to a year ago.

The alternate -- loosely known as 1TCS or one true cipher suite -- has 
been proposed on the basis that if it is ever going to be useful, then 
the place it will be most useful is TCPINC.  Because TCPINC is MITMable 
anyway, why worry so much about the purported benefits of algorithmic 
agility?

However basic IETF consensus or practice is that protocols maintain 
agility, and there is a coming draft on that.


> I am personally in favor of keeping some mechanism
> (whether this one or a different one) in place for that purpose,
> because it provides much more flexibility than it requires complexity.
>
> Kyle



iang