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

Viktor Dukhovni <> Tue, 12 January 2016 05:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CED611ACE1B for <>; Mon, 11 Jan 2016 21:32:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EEl_9N-tmQn5 for <>; Mon, 11 Jan 2016 21:32:09 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BAD151ACE1A for <>; Mon, 11 Jan 2016 21:32:09 -0800 (PST)
Received: by (Postfix, from userid 1034) id 9D74B284E5C; Tue, 12 Jan 2016 05:32:08 +0000 (UTC)
Date: Tue, 12 Jan 2016 05:32:08 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
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 05:32:12 -0000

On Mon, Jan 11, 2016 at 10:42:45PM -0500, Dave Garrett wrote:

> 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. 

With some exceptions, for example:

    * As you note in your last comment, X.509 self-signatures via
    MD5 may continue to be ignored, once MD5 is "banned" in the same
    way that they should have been ignored before it was "banned".

    * S/MIME parsers may continue to parse old S/MIME messages with
      MD/5 signatures.  More generally, Encrypted data at rest may
      need support for MD5 for the lifetime of the data (until
      re-encrypted, ...).

    * PEM files holding RSA private encrypted keys may continue
    to use the legacy MD5-based KDF so that the keys can be

> 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.

> 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.

> 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.