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

Yuhong Bao <yuhongbao_386@hotmail.com> Thu, 11 June 2015 23:26 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 DABD81B2B60 for <tls@ietfa.amsl.com>; Thu, 11 Jun 2015 16:26:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.04
X-Spam-Level: **
X-Spam-Status: No, score=2.04 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 rsl5H7G5bFc0 for <tls@ietfa.amsl.com>; Thu, 11 Jun 2015 16:26:17 -0700 (PDT)
Received: from BLU004-OMC3S25.hotmail.com (blu004-omc3s25.hotmail.com [65.55.116.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C7341B2B5A for <tls@ietf.org>; Thu, 11 Jun 2015 16:26:17 -0700 (PDT)
Received: from BLU177-W45 ([65.55.116.74]) by BLU004-OMC3S25.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 11 Jun 2015 16:26:16 -0700
X-TMN: [4S8sKLXJvkMGX/5ygNXR+ArjiJarp+gn]
X-Originating-Email: [yuhongbao_386@hotmail.com]
Message-ID: <BLU177-W45C6CD3223F292922F2D51C3BC0@phx.gbl>
From: Yuhong Bao <yuhongbao_386@hotmail.com>
To: Xiaoyin Liu <xiaoyin.l@outlook.com>, Aaron Zauner <azet@azet.org>, Dave Garrett <davemgarrett@gmail.com>
Date: Thu, 11 Jun 2015 16:26:15 -0700
Importance: Normal
In-Reply-To: <BAY180-W75D5FCD1F9DD4B5C4A729BFFC00@phx.gbl>
References: <201505211210.43060.davemgarrett@gmail.com>, , <20150522025214.GA21141@typhoon.azet.org>, , <CAHOTMVJ1i+h3x8UShLhku5VcFiB4RRrUmPZL6cz7LnHMeHzAFA@mail.gmail.com>, , <201505212304.11513.davemgarrett@gmail.com>, , <20150522032029.GA24064@typhoon.azet.org>, <BAY180-W75D5FCD1F9DD4B5C4A729BFFC00@phx.gbl>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 11 Jun 2015 23:26:16.0336 (UTC) FILETIME=[03726100:01D0A49E]
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/twM7VHPPCqeWM3Z-2B63kBMQcBY>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] prohibit <1.2 on clients (but allow servers) (was: 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, 11 Jun 2015 23:26:19 -0000

I think disabling TLS 1.0 on servers is probably easier.
Remember that TLS 1.0 lasted for more than a decade. 
The reason disabling SSLv3 was trivial was that TLS 1.0 was already supported and enabled by default on most servers.
Even then there was the problem of extension intolerant and version intolerant servers that had to be upgraded.

Yuhong Bao
________________________________
> From: xiaoyin.l@outlook.com 
> To: azet@azet.org; davemgarrett@gmail.com 
> Date: Fri, 22 May 2015 01:25:41 -0400 
> CC: tls@ietf.org 
> Subject: Re: [TLS] prohibit <1.2 on clients (but allow servers) (was: 
> prohibit <1.2 support on 1.3+ servers (but allow clients)) 
> 
> Hi, 
> 
> Instead of prohibiting bad crypto on the server side, I would like to 
> propose a BCP which prohibits TLS 1.1- on the clients, but allows 
> servers to keep supporting TLS 1.0+. The simple reason is that we 
> should allow normal users to gradually upgrade their old 
> browsers/operating systems, but should encourage (or 
> require) webmasters to upgrade their servers as soon as possible in 
> order to protect their users' security and privacy. I believe phasing 
> out insecure web technology should be promoted by browsers. Microsoft's 
> plan to phase out SHA-1 certificates has been quite effective so far, 
> and I suggest we do the same for old TLS protocols and old cipher 
> suites. 
> 
> I do understand that, as many have pointed out, upgrading servers is 
> not an easy task for some companies. But if not now, they have to be 
> upgraded sometime. Is 2-3 years enough for all servers to be upgraded? 
> So what about specifying the following in tls1-diediedie doc: 
> 
> 1) (Already required in RFC 7525) TLS servers MUST support TLS 1.3 (if 
> TLS 1.3 RFC has been published, otherwise TLS 1.2). 
> 2) (Already required in RFC 7525) If ClientHello.client_version is 
> 0x0303 (TLS 1.2) or above, then TLS servers MUST negotiate that 
> version. 
> 3) TLS servers MAY support TLS 1.0 and TLS 1.1 to support old TLS clients. 
> 4) (New requirement!) Starting from January 1, 2018, TLS clients MUST 
> terminate the handshake if serverHello.server_version is 0x0302 (TLS 
> 1.1) or below. 
> 5) (New requirement!) Starting from January 1, 2018, TLS clients MUST 
> NOT include cipher suites that do not provide forward secrecy in the 
> ClientHello message. 
> 6) (Same as RFC 7525) The requirements above do not apply to 
> opportunistic encryptions, like STARTTLS. 
> 
> The date specified in 4) and 5) can be discussed later. It is 
> important that all major browser vendors agree to enforce 4) and 5) 
> after this specific date, and that this date is widely known by website 
> operators. The goal of my proposal is to eliminate TLS 1.0-only 
> and non-PFS TLS servers before the next decade. 
> 
> Best, 
> Xiaoyin 
> 
> _______________________________________________ TLS mailing list 
> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls