Re: [TLS] TLS Charter Revision

Michael Sweet <msweet@apple.com> Thu, 12 December 2013 17:18 UTC

Return-Path: <msweet@apple.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9531AE0BE for <tls@ietfa.amsl.com>; Thu, 12 Dec 2013 09:18:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6oml7C3EmLN for <tls@ietfa.amsl.com>; Thu, 12 Dec 2013 09:18:05 -0800 (PST)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 631181AE059 for <tls@ietf.org>; Thu, 12 Dec 2013 09:18:05 -0800 (PST)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_V6jKwnWlPpMEqAMOrOoHhQ)"
Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MXP002UHEPWGDP1@mail-out.apple.com> for tls@ietf.org; Thu, 12 Dec 2013 09:17:59 -0800 (PST)
X-AuditID: 11807153-b7f396d00000722b-89-52a9efc4d483
Received: from [17.153.37.225] (Unknown_Domain [17.153.37.225]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id F0.23.29227.6CFE9A25; Thu, 12 Dec 2013 09:17:59 -0800 (PST)
From: Michael Sweet <msweet@apple.com>
In-reply-to: <CAOdDvNqQ_QaX4QjweRWuAQ=P83fXhew_diEWOp0Rq0amwW3OAQ@mail.gmail.com>
Date: Thu, 12 Dec 2013 12:17:58 -0500
Message-id: <4650BF20-FD1B-446D-97C7-BB4A33FCE258@apple.com>
References: <2F2286E3-7717-4E8F-B1EA-B2E4155F7C17@cisco.com> <CACsn0ckzA9hd3+zTH5FNNBbPAQqUqaXD8_Z35a8vKEG6WjXbTg@mail.gmail.com> <53edda7bf2804289817f54a8c2ecce33@BY2PR03MB074.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C711E42D63D8@USMBX1.msg.corp.akamai.com> <3A9A4169-6B5E-453E-930A-F00291B541F4@apple.com> <CAOdDvNqQ_QaX4QjweRWuAQ=P83fXhew_diEWOp0Rq0amwW3OAQ@mail.gmail.com>
To: Patrick McManus <pmcmanus@mozilla.com>
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: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] TLS Charter Revision
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 17:18:08 -0000

Patrick,

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 <pmcmanus@mozilla.com> 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 <msweet@apple.com> 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 <rsalz@akamai.com> 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
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> 
> _______________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair