Re: [TLS] TLS Charter Revision

Michael Sweet <> Thu, 12 December 2013 17:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1B9531AE0BE for <>; Thu, 12 Dec 2013 09:18:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m6oml7C3EmLN for <>; Thu, 12 Dec 2013 09:18:05 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 631181AE059 for <>; Thu, 12 Dec 2013 09:18:05 -0800 (PST)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_V6jKwnWlPpMEqAMOrOoHhQ)"
Received: from ([]) by (Oracle Communications Messaging Server 7u4-23.01 ( 64bit (built Aug 10 2011)) with ESMTP id <> for; Thu, 12 Dec 2013 09:17:59 -0800 (PST)
X-AuditID: 11807153-b7f396d00000722b-89-52a9efc4d483
Received: from [] (Unknown_Domain []) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by (Apple SCV relay) with SMTP id F0.23.29227.6CFE9A25; Thu, 12 Dec 2013 09:17:59 -0800 (PST)
From: Michael Sweet <>
In-reply-to: <>
Date: Thu, 12 Dec 2013 12:17:58 -0500
Message-id: <>
References: <> <> <> <> <> <>
To: Patrick McManus <>
X-Mailer: Apple Mail (2.1812)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUiOFP1oe7x9yuDDDoP81sc+RZrsX/PX3aL T+e7GB2YPbae/MHmsWTJTyaPvgNdrAHMUVw2Kak5mWWpRfp2CVwZr162MRec8K/omDubuYFx o3MXIyeHhICJxIWOeYwQtpjEhXvr2boYuTiEBHqZJJZfnQOU4OAQFlCX+NppDFLDK6AnceXx dhaQMLNAgsST5WEgYTYBNYnfk/pYQcKcAoESO+dpgoRZBFQlfv1sZgaxmQWUJWZ1LWeFmGIj 8WR/KzuILSTQySxx/o8kiC0ioCVxdOlEdpAxEgKyEp8Om01g5JuFZO8shL2zwIZqSyxb+JoZ wtaTeNn0jh1TXFfi4rpJjAsY2VYxChSl5iRWGuslFhTkpOol5+duYgQFa0Nh8A7GP8usDjEK cDAq8fC+OLgiSIg1say4MvcQowQHs5II7+vHK4OEeFMSK6tSi/Lji0pzUosPMUpzsCiJ897l BaoWSE8sSc1OTS1ILYLJMnFwSjUwWuSeWGF7L2hx78UN6ucvfarYvXqv00Q20+Bv03/VTDvx IlTb8nvdqVu7TzjIP/Q2eFHOwxn35YHLh2feS72Va+Z+YypNWhsh+Dm8Uel6zKRnE969/Lv+ /JK0n7e+TJyReGzuwjNSyStNGU5FpzZN0D67kOWh1MmbXWuXb33VZj+7yO7rJz2VIAklluKM REMt5qLiRABt9Qo5UgIAAA==
Cc: "<>" <>
Subject: Re: [TLS] TLS Charter Revision
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Dec 2013 17:18:08 -0000


While I agree that minimizing RTT is a laudable goal, I don't think it is a necessary goal for TLS/1.3.

Witness that browsers/servers that support Google's TLS-encrypted SPDY have already seen significant performance improvement without needing a 0 RTT version of TLS.  And as HTTP/2.0 shares some of the same design elements, we can expect to see similar improvements over TLS-encrypted HTTP/1.1 as well.

Minimizing RTT helps with initial response latency only.  And I would argue the primary factor against using TLS for everything is performance and resource usage and NOT latency.  If you can, by using SPDY or HTTP/2.0, reduce the number of connections a web browser makes to your server(s) by an order of magnitude, that will be a far greater factor in the decision making process than shaving maybe 250ms from the initial connection latency of each connection.

On Dec 12, 2013, at 10:59 AM, Patrick McManus <> wrote:

> Time to first byte is extremely important to web content - so any kind of latency-scaled overhead is viewed as a serious cost. TLS induced latency is one factor that currently weighs against deploying content over https:// -- That is a dynamic most on this list would like to change I am sure.
> Reducing setup overhead of all types is vitally important to that constituency. That's not just assertion - we see that reflected (sometimes indirectly) in ongoing efforts such as false start, snap start, stapling, session tickets, iw 10, tcp fast open, http/2, tail loss probe, and quic.
> A robust discussion can be had about cost-benefits of various approaches to RTT elimination, but the demand side of the ledger should be clear.
> On Thu, Dec 12, 2013 at 10:33 AM, Michael Sweet <> wrote:
> FWIW, one of the big features of HTTP/2.0 is the ability to run multiple simultaneous requests over a single connection which mitigates most of the effects of extra RTT. What's left is the initial connection setup time - important for benchmarks, perhaps, but definitely down in the noise for most web pages...
> On Dec 12, 2013, at 10:22 AM, Salz, Rich <> wrote:
> > I agree with Marsh that PFS should be included.
> >
> > I am concerned about the 'political' emphasis on reducing round trips. One of the arguments heard I hear against 'https everywhere' is that the extra round-trips' cause too much latency and impact customer's web experience. If we can work to reduce RTT without sacrificing security, then that's great and I would like to see "while maintaining security features" or some such added.
> >
> > I would like to add a bullet that says backward compatibility with previous  versions is not a requirement. Given all that downgrade fallback issues that continually arise here, we should strongly consider if the right thing to do is just break the chain.
> >
> >       /r$
> >
> > --
> > Principal Security Engineer
> > Akamai Technology
> > Cambridge, MA
> >
> > _______________________________________________
> > TLS mailing list
> >
> >
> _______________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> _______________________________________________
> TLS mailing list
> _______________________________________________
> TLS mailing list

Michael Sweet, Senior Printing System Engineer, PWG Chair