IETF Logo Mail Archive

[TLS] banning SHA-1 in TLS 1.3, a new attempt

Dave Garrett <davemgarrett@gmail.com> Sat, 10 October 2015 17:37 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 4E8821B4294 for <tls@ietfa.amsl.com>; Sat, 10 Oct 2015 10:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level:
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 xflnY8ws3AvF for <tls@ietfa.amsl.com>; Sat, 10 Oct 2015 10:37:31 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 B968A1B4282 for <tls@ietf.org>; Sat, 10 Oct 2015 10:37:31 -0700 (PDT)
Received: by qkht68 with SMTP id t68so44798299qkh.3 for <tls@ietf.org>; Sat, 10 Oct 2015 10:37:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=0W/7qjfin+VeVON1bE24J+0kcdzh1F2GKEeV9dorIg0=; b=A6TqsbxnCchGRSITDe3MaQK7PGxj6xv5JG45H6W7P2INEiOjqrAR2677JltWZjJPbC WM4sj8KzyVoN+cSj9+E4GYJfoBQRHt/GT9Hqe6/1/+DgkHY5D7pegdVs5zOz+uBVlY7N ZHCy6qeIIYeYrz+tPIZW6SjoJuHKblH+ISMAGLSdscohEOB10qqOAT7K0zBgHJFzK4dO bLJPpIWDv67rlQoY4ocjJnsr3OtvUi7pAF68FythbDPyo/IzsFn7frVf/Eux2rGA3PW9 +cPWU+yabHpT/P1VoJiQj2OBPsA+aaev4ThHKPVBRmcF1jHJk+6p/f2vgNxPQjiYLvOZ MLTA==
X-Received: by 10.55.41.165 with SMTP id p37mr22374782qkp.73.1444498650863; Sat, 10 Oct 2015 10:37:30 -0700 (PDT)
Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id h10sm3318293qgf.29.2015.10.10.10.37.30 for <tls@ietf.org> (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 10 Oct 2015 10:37:30 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Sat, 10 Oct 2015 13:37:28 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201510101337.29335.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/W1drv0Z3wFT0sYQ3C63987mhrT0>
Subject: [TLS] banning SHA-1 in TLS 1.3, a new attempt
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 10 Oct 2015 17:37:33 -0000

In light of completely unsurprising recent events [0], I think it's time to reconsider the current consensus on how to deal with SHA-1 in TLS 1.3. Currently, it's allowed if needed by servers that have nothing better [1]. I propose we stop playing around and just prohibit it under TLS 1.3+. Implementations that can negotiate nothing better would be permitted to fall back to TLS 1.2 with the security restrictions currently in the draft [2] (which is still a concession I'd rather not make, but it's currently needed). I have submitted a PR [3] to this effect in order to have specific text to discuss here, though WG consensus and chair approval is of course required to change the current status.

Please note that TLS 1.3 is not coming out tomorrow, nor will its deployment be instant. By the time servers even decide to consider an upgrade, SHA-1 will be in an even less secure state than it already is.

To answer the obvious question: Prohibiting it in new versions reduces the risk of mistakes, draws a clear line where support is killed, and puts an actual impetus on PKI to transition faster. TLS 1.2 is potentially vulnerable, depending on configuration (nothing new there), but TLS 1.3 should be known to be secure in all valid configurations. The discussion to have with non-experts should not be about specific algorithms to pick and choose (RC4, MD5, SHA1, EXPORT ciphers, non-AEAD, non-PFS, weak DH groups, etc. etc.); we should be able to point at the current version and say "use this, not the old thing", or we can't expect it to be understood and taken seriously.

[0] https://sites.google.com/site/itstheshappening/
[1] https://tools.ietf.org/html/draft-ietf-tls-tls13-09#page-60
[2] https://tools.ietf.org/html/draft-ietf-tls-tls13-09#appendix-C.3
[3] https://github.com/tlswg/tls13-spec/pull/287


Dave

v2.23.0 | Report a Bug | By Email