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

Dave Garrett <> Fri, 22 May 2015 06:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AF0981A9172 for <>; Thu, 21 May 2015 23:28:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K0fs68VuF-VL for <>; Thu, 21 May 2015 23:28:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CF4371A0155 for <>; Thu, 21 May 2015 23:28:04 -0700 (PDT)
Received: by qcir1 with SMTP id r1so4095185qci.3 for <>; Thu, 21 May 2015 23:28:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=QXklN0+yV1GIMjg+nPONHepEegF3vyQxGxG01LBkeUE=; b=WYtfRftQxJE3mSKFvDZwQJIL8/ay613FqINsqD3AvtFZYMa7fRzBxGyansqHEhldBZ /e2mE7ZbB1ffmt5x4Ecet4NVftVCKVBj0P7CsHYUkVSElADkMfEGfsR7u5WR0nAVP/lh 4gqWtQNsf3DagpfbMTtyFgA6SojF23qArtPYjv82brUfsDg5r6uQP/JLhEXi6dBi4bNH tXzw8CmirY5VoniGBo0CzaEHVrhQojWHAz53D4CTjQvzLuNv6d40D66IV5cmvL2rXZHa yEj/egC7ZCJSa82VAHPVFMrbMd03RyxghAfQtDeWW9IeHM9tzU0x5w8duHzaG9NA5F+9 syFg==
X-Received: by with SMTP id y189mr7639937qky.52.1432276082989; Thu, 21 May 2015 23:28:02 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id w73sm768155qkw.16.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 May 2015 23:28:02 -0700 (PDT)
From: Dave Garrett <>
To: Xiaoyin Liu <>
Date: Fri, 22 May 2015 02:26:04 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <> <> <BAY180-W75D5FCD1F9DD4B5C4A729BFFC00@phx.gbl>
In-Reply-To: <BAY180-W75D5FCD1F9DD4B5C4A729BFFC00@phx.gbl>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <>
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 06:28:06 -0000

On Friday, May 22, 2015 01:25:41 am Xiaoyin Liu wrote:
> 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.
> 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.

I'd knock a year off that if possible, but yes, this is the other route that I would support... if it could actually be agreed to and enforced with a hardcoded time-check, not a human-flipped switch on the date. (humans are weak and squishy and liable to hesitate)

(out of order quoting)
> 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.

I know the push back against dropping TLS 1.0 via the TLS 1.3 spec is strong, but just dropping non-FS might actually be relatively easy (in comparison). FS is available in TLS 1.0 and is relatively commonly supported overall (~65% of TLS servers & increasing at 1-2%/mo [0]). By the time TLS 1.3 is ready for final release, making FS totally mandatory might actually affect relatively few users. Giving servers a few months lead to reject before clients stopping to offer might make things go more smoothly.