IETF Logo Mail Archive

Re: [tcpinc] Call for adoption of draft-rescorla-tcpinc-tls-option-05

David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Mon, 02 November 2015 22:07 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 44C0F1A8895 for <tcpinc@ietfa.amsl.com>; Mon, 2 Nov 2015 14:07:36 -0800 (PST)
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 4Vy1n-9QmrfA for <tcpinc@ietfa.amsl.com>; Mon, 2 Nov 2015 14:07:35 -0800 (PST)
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 9694F1A888E for <tcpinc@ietf.org>; Mon, 2 Nov 2015 14:07:35 -0800 (PST)
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 tA2M7U9X005630; Mon, 2 Nov 2015 14:07:30 -0800 (PST)
Received: (from dm@localhost) by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id tA2M7UqZ010037; Mon, 2 Nov 2015 14:07:30 -0800 (PST)
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: Matt Corallo <tcpinc@bluematt.me>, Eric Rescorla <ekr@rtfm.com>
In-Reply-To: <5636C4F6.7010809@bluematt.me>
References: <56267097.7060509@tik.ee.ethz.ch> <5636BE5A.9090408@bluematt.me> <CABcZeBPjvHuycOu-QtA6ScuvHErhyvHF+YLxd7Cd7LxfJtikZw@mail.gmail.com> <5636C31E.9060202@bluematt.me> <CABcZeBNztS5svgwjyVRoSSBRXy=uWh1+RSBsNckTGNfAxEiSNg@mail.gmail.com> <5636C4F6.7010809@bluematt.me>
Date: Mon, 02 Nov 2015 14:07:29 -0800
Message-ID: <877fm06ony.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpinc/HFfJgRi-WymUUVJZNArF66cYK1s>
Cc: tcpinc <tcpinc@ietf.org>
Subject: Re: [tcpinc] Call for adoption of draft-rescorla-tcpinc-tls-option-05
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: David Mazieres expires 2016-01-31 PST <mazieres-4wbr8ypze9avz842tdef8jqrds@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, 02 Nov 2015 22:07:36 -0000

Matt Corallo <tcpinc@bluematt.me> writes:

> Am I incorrect in reading that both tls-option and tcpcrypt require a
> full three-way-handshake, and then the client is unable to send data for
> another round-trip as it must wait for another response from the server
> before session keys have been agreed upon?

In tcpcrypt it's half an extra half round trip.  So for protocols where
the server speaks first (including only protocols like SMTP, NNTP, IMAP,
etc., where the server sends a greeting), there is no penalty.  But for
client-speaks-first protocols (such as HTTP), there is an extra round
trip.

> Moving client pubkeys into SYN is slightly crazy, but would shave off a
> RTT before client's first send.

We'd all love to do that, but it is unlikely to happen before we get
large option support for SYNs.  So if you want to make this happen, your
best bet is to support something like tcpm-tcp-syn-ext-opt in the TCPM
working group and TCP-ENO in TCPINC.  The nice thing about TCP-ENO is
that it will naturally be able to take advantage of large SYN options as
soon as we have them.

David

v2.23.0 | Report a Bug | By Email