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

Dave Garrett <> Tue, 12 January 2016 07:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 88AC51A034C for <>; Mon, 11 Jan 2016 23:30:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9H4ywy2yK4po for <>; Mon, 11 Jan 2016 23:30:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 71ADD1A033A for <>; Mon, 11 Jan 2016 23:30:23 -0800 (PST)
Received: by with SMTP id t64so7469293qke.1 for <>; Mon, 11 Jan 2016 23:30:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=nmLRaLzxboquzOGIEeh7c9XRNifWxPJCmMYNpdfZnHs=; b=S9YmLQ/RZh2DS7DgmmaIPWsjRe9yjcq88NWhSJ4aaA+SAHL9Mi3w5+mq9IrpQ1/iyq uZ3al1TF0wPLOWrjqJhgwxsRuI92dJLhLcuKI3Nu5ZURfstqlZVRj3J/Z+zEtsWVzbDQ MbVX5mqL0F3+25G2QPrFDX/wmGuu3ovyjaOO2ue1r13LkOocH9I9cDXfyBa+PQjbFmWV 2BmvzGjZ6BvpkpoWZKhvx7Jw/0Jaf22Ugrg08AZKs0ciWjWHI81++ndosfbaxiikE2AM uFiZ6UqDL2Tn4NnITcCLFeWq7ghS6g8UE825HWKTP/Zgal1Zj41ztGDenqOvcKqShGTf swbw==
X-Received: by with SMTP id g9mr30428283qkh.12.1452583822725; Mon, 11 Jan 2016 23:30:22 -0800 (PST)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id h14sm40208483qhc.33.2016. (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 11 Jan 2016 23:30:22 -0800 (PST)
From: Dave Garrett <>
To:, Viktor Dukhovni <>
Date: Tue, 12 Jan 2016 02:30:20 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
Subject: Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)
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: Tue, 12 Jan 2016 07:30:25 -0000

On Tuesday, January 12, 2016 12:32:08 am Viktor Dukhovni wrote:
> > Also, when I say "prohibited" here, I mean _completely_.
> There is no Internet police, and the IETF does not get to prohibit
> the use of MD5, we only get to write protocol standards.

Of course, but the IETF can state that MD5 is not considered secure, must not be used in any of its old specifications (I do agree that a short list of exceptions will be needed), and put forth a set of basic requirements to continue to use IETF specifications with any intent of considering them even slightly secure. The IETF can't directly enforce this, but plenty of organizations do take this sort of thing seriously, even if others ignore it completely. I would hope that lawyers that wish to reduce their companies' liability for ever-frequent data breaches might pay attention when a primary standards body officially disavows things they're still using as insecure.

> > No MD5 function should remain in the relevant codebase;
> In particular the IETF does not get to tell anyone which functions
> they get to include in their codebase.  So no IETF document saying
> such a thing makes much difference.

It's not a list of demands; it's basic specifications maintenance. It's just a matter of stating what's necessary to avoid well-known security problems when using IETF specs. We know it's a problem and should say so, loudly, on the standards track, as we are well aware that obsolete standards are still in regular use and are dangerous unless their implementations are properly handling all issues discovered since initial release.

I am of course aware that the IETF doesn't like to wade into implementation issues in this kind of detail, but just blaming implementations for screw ups isn't an answer. We should be reliably telling implementors what's needed to avoid them.

The disabled-but-accepted nonsense is a common enough high-risk issue that comes up way too often, and not prominently specifying how to deal with it is irresponsible. An argument could be made for coding/API safety issues like this being in a separate BCP RFC, especially if we actually wanted to cover other things like this, but that's a much larger proposal than what I'm currently talking about.

> > if MD5||SHA1 support is continued,
> > there should be one function that does only that without any way to get
> > a plain MD5 hash.
> This turns out to be a good idea anyway, thus, for example, OpenSSL
> 1.1.0-apha2 just recently added an EVP_md5_sha1() hash function.

Ah, good to hear. Thanks for the info.