Re: [TLS] A new TLS version negotiation mechanism

Yuhong Bao <yuhongbao_386@hotmail.com> Thu, 12 March 2015 07:28 UTC

Return-Path: <yuhongbao_386@hotmail.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 6D7E91A1A15 for <tls@ietfa.amsl.com>; Thu, 12 Mar 2015 00:28:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.66
X-Spam-Level:
X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 OO9ecEJn9kWS for <tls@ietfa.amsl.com>; Thu, 12 Mar 2015 00:28:46 -0700 (PDT)
Received: from BLU004-OMC3S6.hotmail.com (blu004-omc3s6.hotmail.com [65.55.116.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2159F1A1B40 for <tls@ietf.org>; Thu, 12 Mar 2015 00:28:46 -0700 (PDT)
Received: from BLU177-W18 ([65.55.116.73]) by BLU004-OMC3S6.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 12 Mar 2015 00:28:45 -0700
X-TMN: [B5G3JTVQRi25upL/ikfo9/KwT1OLZdne]
X-Originating-Email: [yuhongbao_386@hotmail.com]
Message-ID: <BLU177-W18C43F38049A678CC4651BC3060@phx.gbl>
From: Yuhong Bao <yuhongbao_386@hotmail.com>
To: Dave Garrett <davemgarrett@gmail.com>, Stephen Checkoway <s@pahtak.org>
Date: Thu, 12 Mar 2015 00:28:45 -0700
Importance: Normal
In-Reply-To: <201503120326.38588.davemgarrett@gmail.com>
References: <201503081339.47927.davemgarrett@gmail.com>, <201503111456.38308.davemgarrett@gmail.com>, <D43A19CC-4559-4446-85F2-06A9B6468E07@pahtak.org>, <201503120326.38588.davemgarrett@gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 12 Mar 2015 07:28:45.0636 (UTC) FILETIME=[2C920040:01D05C96]
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/PpR7l2Opz-CCMNOu0gg212tGJZY>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] A new TLS version negotiation mechanism
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 Mar 2015 07:28:47 -0000

> On Thursday, March 12, 2015 01:01:27 am Stephen Checkoway wrote:
>>
>> On Mar 11, 2015, at 2:56 PM, Dave Garrett <davemgarrett@gmail.com> wrote:
>>
>>> On Tuesday, January 20, 2015 11:01:31 pm Xiaoyin Liu wrote:
>>>> (5) Number of sites that are tolerant to (TLS1.3, TLS1.3): 397,152 (93.1%)
>>>> (6) Number of sites that need to fallback to (TLS1.0, TLS1.3): 22,461 (5.3%)
>>>> (7) Number of sites that need to fallback to (TLS1.0, TLS1.2): 6,352 (1.5%)
>>>> (8) Number of sites that need to fallback to (TLS1.0, TLS1.0): 454 (0.1%)
>>>>
>>>> The total number of TLS enabled sites is 426,419. TLS 1.3 intolerant sites (7 and 8) are about 1.6%.
>>
>> Most of this is about the record layer version
>
> I just wanted to post the full data set here so it wasn't out of context.
>
>> The real data here is that 1.5% of servers are intolerant of 1.3 but tolerate 1.2. So that was (a) and (b) in my list but it's pretty hard to measure (c): servers that aren't maintained or can't be upgraded.
>>
>> I remain unconvinced, but others can weigh in.
>
> Let me put it to you this way: ~0.1% of servers are TLS 1.2 intolerant and browser vendors are STILL having trouble dropping insecure fallback, if they are attempting it at all. The TLS 1.3 intolerance problem is over an order of magnitude worse.
>
> To be precise, most of these servers are likely considered maintained and can technically be upgraded, but that doesn't mean they actually will. Starting out with this untamed mess could discourage TLS 1.3 adoption and will encourage browsers to do insecure fallback for TLS 1.3.
Personally, I'd be actually fine with insecure fallback with a deadline (of maybe a year) to drop it.

Yuhong Bao