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

Dave Garrett <> Tue, 12 January 2016 16:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 26C801A21A5 for <>; Tue, 12 Jan 2016 08:45: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 SRyjCwXtfZls for <>; Tue, 12 Jan 2016 08:45:28 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BF5881A1E0E for <>; Tue, 12 Jan 2016 08:45:27 -0800 (PST)
Received: by with SMTP id t64so24576692qke.1 for <>; Tue, 12 Jan 2016 08:45:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=ZT9vUiIFdUzaZbmf7GjTdVbG6/XjU2uNuenzw2K1eeM=; b=qGj3DMzWsDoIl0NURRENb5/NZV1I4GcgyA4R9WLeqOQGLXJh8r/eULn7VxLq31WYu2 qK+0xc9ME3nbFCnfSDKGuS6MujIOX8KXKLakuWH5wu/1vIQvft+QfY0J8FRdXYvGYhHm vsTxUZS70wS28u/SuZ4iZvqa4Jwc/Xtw4oOkMUYX1Xfnm+NCs44JqYyPEszwtOVZTZm8 XKZdabrCHLtSheLGZ7O9CCoKFuboz9JsC9LrvsdYfRePare19ul/Mfr//d3rl/SF2Uim vV9s6e/RB2rg53hEgi601c0q6phMZvl7B50lfE/sv3UtDPUZyi9aH+mCXrpxvq8V07Bq jVgw==
X-Received: by with SMTP id u129mr175212782qka.26.1452617127022; Tue, 12 Jan 2016 08:45:27 -0800 (PST)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id x79sm57177594qka.37.2016. (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 12 Jan 2016 08:45:26 -0800 (PST)
From: Dave Garrett <>
To: Stephen Farrell <>
Date: Tue, 12 Jan 2016 11:45:25 -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="utf-8"
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 16:45:30 -0000

On Tuesday, January 12, 2016 06:05:05 am Stephen Farrell wrote:
> A few notes on this:
> - Calling for the IETF to do something isn't how it works. People
> who want thing X to be done need to write the draft and then see
> if it gets support. I suspect an md5-die-die-die draft would get
> quite a bit of support but...

I'm just bringing up the idea to see what kind of support there is. I don't particularly want to write up a draft in full on my own without discussing it first.

> - The points Victor made about long-term stored data are valid.
> In various cases it simply wouldn't be a good plan to re-encrypt
> or re-sign old data. Yes, that stored data may not be as secure
> as it once was, but it may be impractical to re-encrypt it all.
> The openpgp wg [1] are dealing with this particular issue as they
> work to do updates, so feel free to get involved in that debate
> there if it's of interest.

Yes, decryption of long term storage would have to be one notable exception. The main concern is is with real time (or near) security protocols like TLS, SSH, & etc.

It's also important to note that just because we shouldn't be doing obsolete and risky things in modern software, that doesn't mean that old software (even if maintained) shouldn't be allowed to exist at all. However, doing both in the same application has proven to be very dangerous. On the client side, having separate legacy clients with no modern support and modern clients with no legacy support would drastically improve security, not to mention force users to actively acknowledge when they're doing something risky. (yes, the server side isn't as simple, nor is this always viable on the client side, either)

> - If your envisaged scope is for all IETF protocols, then I'm sad
> to say there may be "fun" ahead wrt TCP-MD5 [2] which some routing
> folks just won't let die it seems, even though we formally obsoleted
> that [3] 5 years ago. (And yes, that really is sad.)

Yeah... stuff like that is why I kinda don't want to write up a whole draft to change the world on my own. ;)

> - Lastly, and again if your envisaged scope is to deprecate MD5 for
> all IETF protocols then that might better fit the charter of the new
> curdle wg. [4] And your draft might be an update to RFC6151 [5] I
> guess, depending on how you wrote it.
> So by all means, write the draft and post a link to the curdle
> list (maybe cc'ing this).

Yes, I am aware of the new CURDLE WG. Brining up the idea here first simply made more sense, as MD5 was already coming up in discussion here again. Rich Salz also suggested CURDLE being the ideal place to deal with this topic, and I don't disagree. Near as I can tell, though, TLS isn't directly within its charter and a consensus on what to do for it would have to come out of the TLS WG first before CURDLE would be able to include it in any widespread MD5 I-D.

> Cheers,
> S.
> [1]
> [2]
> [3]
> [4]
> [5]