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

Jeffrey Walton <> Fri, 22 May 2015 17:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5B5771A8838 for <>; Fri, 22 May 2015 10:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 HPBvgFdSm1I2 for <>; Fri, 22 May 2015 10:56:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4D9C81A87E4 for <>; Fri, 22 May 2015 10:56:46 -0700 (PDT)
Received: by igbyr2 with SMTP id yr2so41736469igb.0 for <>; Fri, 22 May 2015 10:56:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qI8sd9jr3hDSsg3X9+qKeSK2I6pHjxaUBKrcGznvi+o=; b=hCRSdO8PFmWP0LvCOcTe4HM/zAZhNc1aVNEaP/zux0JChYLV7Dnf3fZ9ZEzimaMpxE 9+eddrjKFepiCl+smtXbYBje+EiD9MEQYI71pBh4+kEhKp+Fz//fX1HTvnXd39Z0QP2z DzgctmimZcfSEloCLGbhgfw5cTfy2ep0YwDx2IvF3E51ELyBJpSihG81VGKmhWgmilKG o9XdJh3oRn6DGsKKMlt4D2LTlK1WW7gdK6i9xI+uGorzwXliZxZUtM30lKgr5lteIj8y p2LoWCtJVVm8HEwl5KHfxcuc5zeZ/727aOfkgC+j0Xhuk/sKT5QAZNYiOT3p9kNUBscF 2WZw==
MIME-Version: 1.0
X-Received: by with SMTP id g124mr12610783ioe.11.1432317405843; Fri, 22 May 2015 10:56:45 -0700 (PDT)
Received: by with HTTP; Fri, 22 May 2015 10:56:45 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <BAY180-W75D5FCD1F9DD4B5C4A729BFFC00@phx.gbl> <>
Date: Fri, 22 May 2015 13:56:45 -0400
Message-ID: <>
From: Jeffrey Walton <>
To: Peter Gutmann <>
Content-Type: text/plain; charset=UTF-8
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 17:56:59 -0000

On Fri, May 22, 2015 at 8:30 AM, Peter Gutmann
<> wrote:
> Xiaoyin Liu <> writes:
>>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.
> This comment again shows the rather myopic browser-centered view of TLS that
> I've complained about in the past.  For most of the users of TLS that I work
> with, there is no browser, no OS upgrade, and no web.  TLS is used for
> machine-to-machine communications, with no human intervention.  You know the
> PLC I used as an example in an earlier message, the one that rejects any
> attempt at connecting with a version number set to greater than TLS 1.0?
> The
> "upgrade" procedure for that is to replace it when the hardware dies, with a
> minimum (minimum, not maximum) lifetime of around ten years (I've seen
> refridgerator-sized PLCs dating from the 1960s still in active use today,
> but
> that's because they're practically indestructible compared to modern
> versions).

+1. That toxic browser thinking and its polluted security model is
making its way into non-browser areas, too.

For example, browsers apparently embrace user phishing, claiming
"there's nothing we can do when a user make a configuration change
like adding a CA to the trust store." Then, in a
life-is-stranger-than-fiction moment, we get a standard like Public
Key Pinning with Overrides, where adversaries are allowed to break
known good pinsets because a user was phished.