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

David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Wed, 26 August 2015 21:04 UTC

Return-Path: <dm-list-tcpcrypt@scs.stanford.edu>
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 EDD111B318E for <tcpinc@ietfa.amsl.com>; Wed, 26 Aug 2015 14:04:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.61
X-Spam-Level:
X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 1uxsen-BAqij for <tcpinc@ietfa.amsl.com>; Wed, 26 Aug 2015 14:04:41 -0700 (PDT)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 534AF1B3181 for <tcpinc@ietf.org>; Wed, 26 Aug 2015 14:04:41 -0700 (PDT)
Received: from market.scs.stanford.edu (localhost.scs.stanford.edu [127.0.0.1]) by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id t7QL4W0f029303; Wed, 26 Aug 2015 14:04:32 -0700 (PDT)
Received: (from dm@localhost) by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id t7QL4VqE018193; Wed, 26 Aug 2015 14:04:31 -0700 (PDT)
X-Authentication-Warning: market.scs.stanford.edu: dm set sender to dm-list-tcpcrypt@scs.stanford.edu using -f
From: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Mirja Kühl ewind <mirja.kuehlewind@tik.ee.ethz.ch>, tcpinc@ietf.org
In-Reply-To: <55DDFCED.2020103@cs.tcd.ie>
References: <CABcZeBNEFVkDi38y3G-C2nQF=dzW2mGDsj5DVK_OKVkPwK=G0g@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> <55DB8338.4060403@cs.tcd.ie> <877foke4yx.fsf@ta.scs.stanford.edu> <55DB93CD.4000701@cs.tcd.ie> <87zj1gcng8.fsf@ta.scs.stanford.edu> <55DC4A97.3000602@cs.tcd.ie> <877foje94q.fsf@ta.scs.stanford.edu> <55DC81F3.9090904@cs.tcd.ie> <871tere2b5.fsf@ta.scs.stanford.edu> <55DCCA26.1040803@cs.tcd.ie> <E93F1869-ACC3-4490-8280-94176227ECC4@tik.ee.ethz.ch> <55DDFCED.2020103@cs.tcd.ie>
Date: Wed, 26 Aug 2015 14:04:31 -0700
Message-ID: <87wpwhsqw0.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpinc/1rdZg9Lyeb7_IlX9pQ4xa7neqHo>
Subject: Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: David Mazieres expires 2015-11-24 PST <mazieres-e2xxg7h9ptrg94w7kdpcj5jybn@temporary-address.scs.stanford.edu>
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 21:04:42 -0000

Stephen Farrell <stephen.farrell@cs.tcd.ie> writes:

> Until the WG have selected between tcpcrypt and tcp-use-tls
> I don't think it makes any sense for tcp-eno to delve into
> ciphersuite or cryptographic algorithm details.

Okay, but I just want to clarify one thing:  We should separate TCP-ENO,
the draft, from my (possibly ill-advised) ramblings on this mailing
list, even though I'm an author of TCP-ENO.

TCP-ENO provides negotiation in the abstract.  That could be used to
negotiate between TCPINC v1 and v2, or TLS v1.3 and v2.0, or someday
TCPINC with and without large option/dedicate middlebox support, or
anything else.  ENO could also be used to negotiate between TCPINC with
one cipher suite and TCPINC with another cipher suite, *if TCPINC itself
does not negotiate cipher suites* (which means it's not TLS).  We can
debate whether or not the latter use of TCP-ENO is a good idea, but that
probably won't be a particularly useful debate at this point.

If the WG adopts TCP-ENO and TLS, I don't think anybody believes ENO
should specify cipher suites.  Rather, it should negotiate how to embed
TLS into TCP (especially if TCPM does something we can take advantage
of) or maybe what version of TLS to use (in the event that something
about TCP-use-TLS could benefit from a significant rearchitecting to
take advantage of TLS 2.0).

David