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

Geoff Keating <> Sun, 24 May 2015 21:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5F2821A1B5A for <>; Sun, 24 May 2015 14:08:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5zR8qLzK7rEq for <>; Sun, 24 May 2015 14:08:09 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E07F1AD0BA for <>; Sun, 24 May 2015 14:05:37 -0700 (PDT)
Received: from [] ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 4289C33D061; Sun, 24 May 2015 21:05:36 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Geoff Keating <>
In-Reply-To: <>
Date: Sun, 24 May 2015 14:05:35 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <BAY180-W75D5FCD1F9DD4B5C4A729BFFC00@phx.gbl> <> <m2d21szfwh.fsf@localhost.localdomain> <>
To: Peter Gutmann <>
X-Mailer: Apple Mail (2.2098)
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: Sun, 24 May 2015 21:08:13 -0000

> On 24 May 2015, at 4:27 am, Peter Gutmann <> wrote:

> The overall rationale for not thinking too much about security is that there's
> a higher risk created when a critical device isn't working due to a particular
> security measure than through having some possible, often rather theoretical,
> security flaw present.
> -- Snip --
> So when given a choice of availability/reliability over security, availability
> wins every time (and quite rightly so).  The only time you can fiddle with it
> once it's in place, ever, is when there's a clear and present issue that
> affects availability.  "Race condition when reading vibration sensors is
> causing the rotor-imbalance safety cutout to trip and take turbine #3 offline"
> is a clear and present issue.  "Haxors might 0wn us" is not, so it'll be
> addressed in the 2018-2023 product cycle.

I guess there are two ways to interpret this.

One is that owners of some systems have carefully considered the relative danger of certain upgrades, decided that the necessary mitigation (testing, staged deployment, backup systems) for that danger is uneconomic, and have accepted the resulting risk.  Perhaps even computed the danger to the world as a whole and not just to them?

Another is that owners of some systems are reflexively against change without a clear and present danger and don’t care what the medium-term consequences might be.

I’m sure there are some of both, hopefully there are more of the first.

For both of these, it’s better to make a clear recommendation that early TLS versions are past their expiry date and are not to be used.  For the first kind of owner the costs of supporting the old versions will fall on them and not on the rest of the Internet, which will make their economic computation more accurate.  The second kind will discover that off-the-shelf products no longer talk to their ancient systems and will, slowly and painfully, eventually upgrade.