Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients)

Yuhong Bao <yuhongbao_386@hotmail.com> Thu, 21 May 2015 21:30 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 F326E1ACE70 for <tls@ietfa.amsl.com>; Thu, 21 May 2015 14:30:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.04
X-Spam-Level: *
X-Spam-Status: No, score=1.04 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 N7Rmv13b0xk8 for <tls@ietfa.amsl.com>; Thu, 21 May 2015 14:30:54 -0700 (PDT)
Received: from BLU004-OMC3S23.hotmail.com (blu004-omc3s23.hotmail.com [65.55.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3103E1ACDE8 for <tls@ietf.org>; Thu, 21 May 2015 14:30:53 -0700 (PDT)
Received: from BLU177-W4 ([65.55.116.73]) by BLU004-OMC3S23.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 21 May 2015 14:30:52 -0700
X-TMN: [XEu/yNkdAlu8CrMYrNZ2MwSKWEd6Y5Bc]
X-Originating-Email: [yuhongbao_386@hotmail.com]
Message-ID: <BLU177-W43B228C6C40A3EFFF6D0AC3C10@phx.gbl>
From: Yuhong Bao <yuhongbao_386@hotmail.com>
To: Thijs van Dijk <schnabbel@inurbanus.nl>, Dave Garrett <davemgarrett@gmail.com>, "andrei.popov@microsoft.com" <andrei.popov@microsoft.com>, "maray@microsoft.com" <maray@microsoft.com>
Date: Thu, 21 May 2015 14:30:52 -0700
Importance: Normal
In-Reply-To: <CADGaDpEjG8RfKzwnKjtYun_TTo9ipctQwx9DsDOWfSkory65rg@mail.gmail.com>
References: <201505211210.43060.davemgarrett@gmail.com>, <CADGaDpEjG8RfKzwnKjtYun_TTo9ipctQwx9DsDOWfSkory65rg@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 21 May 2015 21:30:52.0943 (UTC) FILETIME=[6A1BB1F0:01D0940D]
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/P2OTtf1WQPKNg9SnZf5tVJp7y90>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] prohibit <1.2 support on 1.3+ servers (but allow clients)
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, 21 May 2015 21:30:56 -0000

> On 21 May 2015 at 18:10, Dave Garrett wrote: 
> Old versions of TLS need to be phased out at some point (even the one 
> we're designing now), however the current modus operandi is generally 
> to wait until a catastrophic breakage forces everyone into a panic 
> disable. I'd like to at least try to do better prior to the next time. 
> I'd like to propose giving servers & clients different expectations as 
> a transitional measure: 
> 
> 1) No general change to current TLS other than pointing to the UTA BCP 
> from time to time. 
> https://tools.ietf.org/html/rfc7525 
> 
> 2) For TLS 1.3, add a blurb to the effect of: 
> "Server TLS implementations supporting TLS 1.3 or later MUST NOT 
> negotiate TLS 1.0 or TLS 1.1 for any reason. 
> Client TLS implementations are RECOMMENDED to not support old TLS 
> versions, where possible." 
> 
> In an ideal world I'd be all for it, but in reality I think this would 
> do more harm than good in the sense that it would postpone deployment 
> of TLS1.3 rather than speed up the deprecation of 1.1 and 1.0. 
> 
> Case in point: as of last month, 15-20% of my employer's revenue still 
> comes from clients using IE6-8. (Mostly law firms and government 
> branches who don't care so much about security as they do about 
> liability - if at all. And barring the n'th catastrophic breakage, 
> TLS1.1 is not a liability yet.) 
> My boss isn't going to forfeit that amount of cash simply because his 
> IT guy says the BCP says he should. Nor should he! If it's an exclusive 
> choice between either supporting 1.0 and 1.1 but not the newest 1.3, OR 
> having 1.3 but having to make do without one-sixth of his revenue, this 
> is a no-brainer. 
> 
> Users and site operators alike would benefit the most from a 
> having-your-cake-and-eating-it-too scenario, where users with a modern 
> browser can enjoy the newest security features, while the soft-touch 
> deployment will make adopting the newer version more palatable for the 
> managers of this world, even if it does mean the odd panicky removal 
> every other month. 
> 
> -Thijs 

Andrei Popov: I think it would be trivial to release an update for IE8-10 for Win7 to enable TLS 1.1 and 1.2 by default, right?