Re: [TLS] TLS Charter Revision

Michael Sweet <msweet@apple.com> Thu, 12 December 2013 15:33 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 38CFE1AE32B for <tls@ietfa.amsl.com>; Thu, 12 Dec 2013 07:33:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 C7eKwJlIROY6 for <tls@ietfa.amsl.com>; Thu, 12 Dec 2013 07:33:18 -0800 (PST)
Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5561AE328 for <tls@ietf.org>; Thu, 12 Dec 2013 07:33:18 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; CHARSET="US-ASCII"
Received: from relay7.apple.com ([17.128.113.101]) 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 <0MXP00J7Q9VCTLY1@mail-out.apple.com> for tls@ietf.org; Thu, 12 Dec 2013 07:33:12 -0800 (PST)
X-AuditID: 11807165-b7f8e6d000004de8-cd-52a9d7381512
Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 65.3A.19944.837D9A25; Thu, 12 Dec 2013 07:33:12 -0800 (PST)
Received: from [17.153.105.143] by chive.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MXP00HOU9VAWC00@chive.apple.com> for tls@ietf.org; Thu, 12 Dec 2013 07:33:12 -0800 (PST)
From: Michael Sweet <msweet@apple.com>
In-reply-to: <2A0EFB9C05D0164E98F19BB0AF3708C711E42D63D8@USMBX1.msg.corp.akamai.com>
Date: Thu, 12 Dec 2013 10:33:10 -0500
Message-id: <3A9A4169-6B5E-453E-930A-F00291B541F4@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>
To: "Salz, Rich" <rsalz@akamai.com>
X-Mailer: Apple Mail (2.1827)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FDMr2txfWWQwcxr2hafzncxOjB6LFny kymAMYrLJiU1J7MstUjfLoEro+X2BZaC69wVsy5tY21gPMzZxcjJISFgInFhxxpGCFtM4sK9 9WxdjFwcQgLdTBIvPk1hh3D+MEocO3wCyOHgEBZQl/jaaQzSwCugJ7Fx3mxmEJtZQEti/c7j TCA2m4CaxO9JfawgNqdAmMT93YtZQFpZBFQl5vTYgoxkFpjPKNE4cQkTRK+2xJN3F1ghZtpI 3Dz6DWrvTCaJv9tfgSVEBJQljs98wAgySEJAVmL+6dIJjAKzkJwxC8kZs5CMXcDIvIpRoCg1 J7HSXC+xoCAnVS85P3cTIzjwClN3MDYutzrEKMDBqMTD++LgiiAh1sSy4srcQ4wSHMxKIrz3 tqwMEuJNSaysSi3Kjy8qzUktPsQozcGiJM57nxeoWiA9sSQ1OzW1ILUIJsvEwSnVwKhpVyN7 U0i5Sct1VoTdXNNspYpby0/ullCbFMt9epfb0u36bzNe+GzKej8l8ojdmY9zHgeduP7fy3jF 3iU7G67EeC92/KmbHP1z5jbrkG1NU1N59RU4vzF3/jPbeOKt+8qD9VMYnp4O3FR54Oya0wEC O1vv6cn+Tb4UsdzScLV18MYjuxROyrYpsRRnJBpqMRcVJwIA7O2GIzgCAAA=
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 15:33:22 -0000

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