[TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)

Dave Garrett <davemgarrett@gmail.com> Tue, 12 January 2016 03:42 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 []) by ietfa.amsl.com (Postfix) with ESMTP id B98BB1ACDA8 for <tls@ietfa.amsl.com>; Mon, 11 Jan 2016 19:42:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id zcv7ypzbzuir for <tls@ietfa.amsl.com>; Mon, 11 Jan 2016 19:42:49 -0800 (PST)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 F31661ACDA1 for <tls@ietf.org>; Mon, 11 Jan 2016 19:42:48 -0800 (PST)
Received: by mail-qk0-x22d.google.com with SMTP id q19so179666910qke.3 for <tls@ietf.org>; Mon, 11 Jan 2016 19:42:48 -0800 (PST)
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=R1AgmzRqF88/rbjL1Ld+JQ06YribtFiqV3wYlmc3JGo=; b=eopckfNhM3ncnBCABK3ec/LTIBU29Do79BzYzWZtjuxUQ0b6ozhDYzvdHgj3/Yqo3c mSxt2yjk+8uuYVIrXGLHFcfE7tnEC7TQ/uccyaKFbKvK7V648dLYgxGPOxOMszPug4d9 PCC8hIOiqk/inrYdaNP75TcdeBlOAfA6YFvrFquDN9YYmcsfsf6izYxmXcCFpXrpG8Ly MNK2anTeorDAsxhB1InKZpgkKfioB1wP7dy45wXoYF0wufmwGi2juVVVMRZRVGZ/84MA oOkXOR4wnQuR9doxUoL9gW+H6qqvmkU1q/+m908W7kAFlI5YrkL2DLrIIUhkRLLt1eLh sL3g==
X-Received: by with SMTP id x83mr41490961qka.89.1452570168116; Mon, 11 Jan 2016 19:42:48 -0800 (PST)
Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. []) by smtp.gmail.com with ESMTPSA id w71sm26715332qha.30.2016. (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 11 Jan 2016 19:42:47 -0800 (PST)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Mon, 11 Jan 2016 22:42:45 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <20160111183017.GA12243@roeckx.be> <9A043F3CF02CD34C8E74AC1594475C73F4BC5FC6@uxcn10-5.UoA.auckland.ac.nz> <CAHOTMVK7JQ-UR1j=H3Rio4V-FgSvxgLdU3PDTZhLuA5bOMr+wg@mail.gmail.com>
In-Reply-To: <CAHOTMVK7JQ-UR1j=H3Rio4V-FgSvxgLdU3PDTZhLuA5bOMr+wg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201601112242.46115.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ocLAqw9QcDJxkbgEJqauk2RNRt0>
Subject: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)
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: Tue, 12 Jan 2016 03:42:50 -0000

On Monday, January 11, 2016 06:13:37 pm Tony Arcieri wrote:
> My understanding is TLS 1.2 specifically was amended to allow MD5
> signatures even though this was not the case in previous TLS versions, or
> at least that was the claim of the miTLS presenters on SLOTH at
> RealWorldCrypto 2016.
> If this is the case, this seems like a big regression in TLS 1.2.

I'd like to propose killing the low hanging fruit first, and then continue to build on top of that.

No sane person disputes that MD5 needs to be eradicated ASAP. We're keeping MD5||SHA1 in old TLS for compatibility and we are well aware that needs to go eventually too. Thus, I suggest we publish an MD5 diediedie standards track RFC to prohibit ALL standalone MD5 use in ALL IETF protocols/standards. Constructions using MD5 with something else (namely MD5||SHA1) would also be explicitly recommended against in existing specifications, and explicitly prohibited in all new drafts (even if unlikely).

Also, when I say "prohibited" here, I mean _completely_. No MD5 function should remain in the relevant codebase; if MD5||SHA1 support is continued, there should be one function that does only that without any way to get a plain MD5 hash. (and no "it's fine for this" junk; non-broken hashes are also fine for that, and if you're wrong, it's safer) There are too many implementation bugs in this realm to not state this explicitly [0].

Note that continued support of trust anchors with MD5 hashes is not dependent on this, as we've already agreed they don't need to be validated. (they need to be phased out, but with less urgency) If used within this specific context, nothing even needs the ability to understand MD5 hashes at all in order to handle these; the certificate as a whole is trusted or not.


To whomever came up with the "diediedie" term, thank you. ;)

[0] Note the 3 disabled-but-accepted bugs listed here: