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

Dave Garrett <davemgarrett@gmail.com> Thu, 21 May 2015 19:55 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 42B8B1A8993 for <tls@ietfa.amsl.com>; Thu, 21 May 2015 12:55:15 -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 HZA1dMvQCkR7 for <tls@ietfa.amsl.com>; Thu, 21 May 2015 12:55:13 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 8451D1A88D2 for <tls@ietf.org>; Thu, 21 May 2015 12:55:13 -0700 (PDT)
Received: by qkgv12 with SMTP id v12so64793489qkg.0 for <tls@ietf.org>; Thu, 21 May 2015 12:55:12 -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=6neTbUpVGs/sQ5h/Z1chnvESgOOt5O+rraIFBNcTQ1E=; b=PM2naoqH/Rfeq36QCdlgvxoL7TQReLtyDRowO+d+p8BdLKsXEfX9M8TIMrdxU6vk4w urIZobgaAkjm4k48ujg8ixcSZQLQJXGXE7HrWijgHaAnneQ6zv/YTj3TKE5BloD7E6yx qdj2SpN6yrsihcxgMUWkYQ3O/mCEnpP3ZxT2x2Bg7m2ewk2d8u6AdtAyM07br8OkwDrJ YZcP2RpbrLcgXKwilCzK15ue+dyPk7YGoTBnY8L6nIBSzrObmxSlkXdSyr/yzPn2/kuJ Hpgdx6byG0Sz+oh8WtfmHg8QjABGZHM+egljhAvTXUcZWNbNfldbHD0sDDx/GCtPxw2r /4HQ==
X-Received: by 10.140.233.14 with SMTP id e14mr4636268qhc.90.1432238112854; Thu, 21 May 2015 12:55:12 -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 o106sm13890963qgd.23.2015.05.21.12.55.12 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 May 2015 12:55:12 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: noloader@gmail.com
Date: Thu, 21 May 2015 15:55:11 -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> <CAH8yC8n6WieA5nv1fwdAuw+zdMdE68VfOW_j=m3wPuwra88Erw@mail.gmail.com>
In-Reply-To: <CAH8yC8n6WieA5nv1fwdAuw+zdMdE68VfOW_j=m3wPuwra88Erw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201505211555.11542.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ODC_OP4bi0LqFMqV7IDDA_cgq_s>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] 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: Thu, 21 May 2015 19:55:15 -0000

On Thursday, May 21, 2015 03:22:56 pm Jeffrey Walton wrote:
> Now might be a good time to add a (3) for TLS 1.3: have a client
> specify both the least TLS version they are willing to use, and the
> greatest TLS they desire to use.

The new version negotiation proposal I was working on has that capability.
https://github.com/tlswg/tls13-spec/compare/master...davegarrett:EVN

The similar system I proposed before that was exactly (3), but this one just does a simple list. I greatly prefer the list based approach because it's a total replacement and mistake resistant. (this was discussed quite a bit a while ago on list) If people keep screwing up the old system, tweaking it a bit doesn't seem like enough to deal with the problem, and this new route has other benefits. (there's no reason why TLS 1.2 servers couldn't use it too, if desired)

Ditching TLS 1.0/1.1 support from the list-based approach would be fine and simplify things slightly (I could drop one paragraph), but it doesn't address the fact that servers will still have the code loitering around for a downgrade attack of some unknown kind. The fact that technically clients didn't support EXPORT ciphers did not stop the FREAK attack. TLS implementations have a fairly sloppy track record in this area, as of late.

I don't want negotiations to avoid old junk, or signaling suites to check for junk, or config options, or build options. The obsolete code needs to be stripped from the codebase. Nuke it from orbit. It's the only way to be sure.


Dave