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

Xiaoyin Liu <> Fri, 22 May 2015 05:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EEA651A9121 for <>; Thu, 21 May 2015 22:25:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.802
X-Spam-Level: *
X-Spam-Status: No, score=1.802 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sNVP7WqP1Atm for <>; Thu, 21 May 2015 22:25:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 599AA1A9120 for <>; Thu, 21 May 2015 22:25:42 -0700 (PDT)
Received: from BAY180-W75 ([]) by over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 21 May 2015 22:25:42 -0700
X-TMN: [gG61hqwFTjNpVUanVF2PIasW9L2v+ZwP]
X-Originating-Email: []
Message-ID: <BAY180-W75D5FCD1F9DD4B5C4A729BFFC00@phx.gbl>
Content-Type: multipart/alternative; boundary="_aa565fa2-068e-4367-8096-bec5cfd1356b_"
From: Xiaoyin Liu <>
To: Aaron Zauner <>, Dave Garrett <>
Date: Fri, 22 May 2015 01:25:41 -0400
Importance: Normal
In-Reply-To: <>
References: <>, <>, <>, <>, <>
MIME-Version: 1.0
X-OriginalArrivalTime: 22 May 2015 05:25:42.0510 (UTC) FILETIME=[BF36A0E0:01D0944F]
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients))
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 May 2015 05:25:44 -0000


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.