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

David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Mon, 24 August 2015 22:10 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 42A981B3344 for <tcpinc@ietfa.amsl.com>; Mon, 24 Aug 2015 15:10:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.91
X-Spam-Level:
X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 2VCs3mxq3af2 for <tcpinc@ietfa.amsl.com>; Mon, 24 Aug 2015 15:10:35 -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 901111B3341 for <tcpinc@ietf.org>; Mon, 24 Aug 2015 15:10:35 -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 t7OMASSv027442; Mon, 24 Aug 2015 15:10:29 -0700 (PDT)
Received: (from dm@localhost) by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id t7OMASeE032451; Mon, 24 Aug 2015 15:10:28 -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: Watson Ladd <watsonbladd@gmail.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
In-Reply-To: <CACsn0ckqcprHGG=hQkrZ-_VpUVFf9g6stK_A3ywcre=PmPsT+A@mail.gmail.com>
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> <55DB8338.4060403@cs.tcd.ie> <CACsn0ckqcprHGG=hQkrZ-_VpUVFf9g6stK_A3ywcre=PmPsT+A@mail.gmail.com>
Date: Mon, 24 Aug 2015 15:10:27 -0700
Message-ID: <8737z8e3sc.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpinc/XX08DSEG0nQUiecx4XZKYTKfLmU>
Cc: tcpinc <tcpinc@ietf.org>, Stephen Kent <kent@bbn.com>
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-22 PST <mazieres-mmeax5v72kpw4vmv6uwzz5za6w@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: Mon, 24 Aug 2015 22:10:36 -0000

Watson Ladd <watsonbladd@gmail.com> writes:

> So this protocol negotiates how to negotiate?

It doesn't have to.  This may be one of the differences between tcpcrypt
and TCP-use-TLS, where tcpcrypt is in the process ditching its own
negotiation mechanism in favor of ENO, while TLS will just keep the TLS
mechanism.  This seems like the best way to capitalize on the relative
merits of the two protocols, where tcpcrypt's selling points are its
simplicity and custom fit with TCP, vs. TCP-use-TLS whose selling point
is reusing mechanisms and analysis from TLS.

David