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

Dave Garrett <davemgarrett@gmail.com> Fri, 22 May 2015 17:13 UTC

Return-Path: <davemgarrett@gmail.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 6D7001A7011 for <tls@ietfa.amsl.com>; Fri, 22 May 2015 10:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXO49tf_gnDf for <tls@ietfa.amsl.com>; Fri, 22 May 2015 10:13:05 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 016311A6EE9 for <tls@ietf.org>; Fri, 22 May 2015 10:13:04 -0700 (PDT)
Received: by qkgv12 with SMTP id v12so16652635qkg.0 for <tls@ietf.org>; Fri, 22 May 2015 10:13:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=VoOLyLzRe7ci6fqaImkac0Nr5zgpJ0+lmyYYTLDFKhs=; b=WQ9XzW/PWQUH/gUkp1RlRYv75kj2GyDKP3o7tgd/g+EBes63mcWR02nAj4/Fa3or5s vPID9kzZ0bfbA3R+jSEPrsekcvXpMY2PHvK/nDtr3T2cfgrV9CQ1HyTnGAJ7VJzUQCxr zFXRbFlh/v29Rhoj1ZypqvdCk9W6IJElRdmVe54S9SWqyHl8bX9qP2+I3Mx07BlOTJvY e2HJsB1O/8XHe0gwLBdHRGI5Oj9Nam27/ehcSZjWQwXIR6j9sRzUlocF6p2honqKJzVz Bcd6C7IY70JUdYx0i0l+PsdYTL5tnlHvaqWcCL5iGpKQqJGcgRhJ2IM9XS5+Z9fVNDBk +7wg==
X-Received: by 10.140.40.39 with SMTP id w36mr11965144qgw.65.1432314784256; Fri, 22 May 2015 10:13:04 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id j66sm1680402qgj.8.2015.05.22.10.13.03 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 22 May 2015 10:13:03 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Date: Fri, 22 May 2015 13:13:01 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <201505211210.43060.davemgarrett@gmail.com> <BAY180-W75D5FCD1F9DD4B5C4A729BFFC00@phx.gbl> <9A043F3CF02CD34C8E74AC1594475C73AB029584@uxcn10-tdc05.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB029584@uxcn10-tdc05.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201505221313.02262.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/T9Txm3U7w9CN-ef1RL4x3nxBT4s>
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: Fri, 22 May 2015 17:13:06 -0000

On Friday, May 22, 2015 08:30:49 am Peter Gutmann wrote:
> So if some sort of BCP is published, it should explicitly target browsers and
> web servers where this kind of upgrade/change is possible.  Telling people to
> throw away their PLCs and replace them with new ones isn't going to fly.

To be clear, in case it was lost the noise, I did not propose mandating this in the TLS 1.3 spec. If you're going to be sticking with TLS 1.0 until the wheels fall off, you'll be sticking with other TLS 1.0 software to connect to it. (which might entail forking software into TLS 1.0-1.2 & TLS 1.2-1.3 variations, if you really have to) The proposals for the TLS 1.3 spec are intended to apply only to things that are actually updating. The idea is to drag the whole ecosystem kicking and screaming into the 21st century. If the ecosystem isn't moving at all, there's nothing we can do about that here. :(


Dave