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

Loganaden Velvindron <> Tue, 12 January 2016 04:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B5F451ACDE1 for <>; Mon, 11 Jan 2016 20:24:30 -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 41gWScT5hFSF for <>; Mon, 11 Jan 2016 20:24:29 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3EDD11ACDDB for <>; Mon, 11 Jan 2016 20:24:29 -0800 (PST)
Received: by with SMTP id e65so56058078pfe.0 for <>; Mon, 11 Jan 2016 20:24:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dJD8KusB3oslbB4l5qqfWn94FIKgmfCvxToonR8AAqE=; b=qOftzuFYNUlQrOiSx8XsyM/BoZJsuBJrYZ/GYHE2fy8F1csuGT/qDDDbm0I7YyEMaB YUvluMANG07YCC/VjQ0Fcx6evoX5dBmgTmFASNX0CjpdQcTJK8GTJ1tglZKbkVbl9u+q Rgow8xGsMKZDjY7PeT+vvarkBd/K/MlLOgk8K/SOjWolCpgSyqmMjFuuTK0NdjHbGtSm 3H+aPJfuOVh9Xe7zLjYF67mQoELQRWMiPC5SPNUBHRzlFip7u3wMHBowftCA8tTH81OT Bh3T1U+7urrEsERseEJZ0ENt6ykxvtS9ktyWuRXcvWzkAdJWBq2WFNmXgGXBDQvjx2/w ovGA==
MIME-Version: 1.0
X-Received: by with SMTP id b62mr778403pfj.59.1452572668933; Mon, 11 Jan 2016 20:24:28 -0800 (PST)
Received: by with HTTP; Mon, 11 Jan 2016 20:24:28 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 12 Jan 2016 04:24:28 +0000
Message-ID: <>
From: Loganaden Velvindron <>
To: Dave Garrett <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 04:24:30 -0000

On Tue, Jan 12, 2016 at 3:42 AM, Dave Garrett <>; wrote:
> 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].

I completely agree. At least one open source SSL/TLS implementation is
looking at purging their code of MD5 functions.

> 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.
> Dave
> PS
> To whomever came up with the "diediedie" term, thank you. ;)
> [0] Note the 3 disabled-but-accepted bugs listed here:
> _______________________________________________
> TLS mailing list