Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)
Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 12 January 2016 11:05 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FF01A884E for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 03:05:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5ZLW4ainekm for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 03:05:08 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBEA1A8777 for <tls@ietf.org>; Tue, 12 Jan 2016 03:05:08 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EBBF9BE56; Tue, 12 Jan 2016 11:05:05 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N77SQVsg8m8o; Tue, 12 Jan 2016 11:05:05 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4F763BE55; Tue, 12 Jan 2016 11:05:05 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1452596705; bh=MBwgWLxxncf/Ls2Mq5nHRm0IAseVmE5fNpU91EFB8dw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=srHY/+r8I4TRQr4M5h9VcW9EqTsqMWox664FuJTxHXUCWfanDnr1C+uO98vf06KJ3 x6iMZ95AHXipvv1NUBLhDuktsKW4qTwwFtrVqXfuy6VIf0xHpF4GZx52++9fnEDr55 yOcJFlrimAxFh8hrseY1YbfG0pLEuECEOfqC9gU8=
To: Dave Garrett <davemgarrett@gmail.com>, tls@ietf.org
References: <20160111183017.GA12243@roeckx.be> <9A043F3CF02CD34C8E74AC1594475C73F4BC5FC6@uxcn10-5.UoA.auckland.ac.nz> <CAHOTMVK7JQ-UR1j=H3Rio4V-FgSvxgLdU3PDTZhLuA5bOMr+wg@mail.gmail.com> <201601112242.46115.davemgarrett@gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
X-Enigmail-Draft-Status: N1110
Message-ID: <5694DDE1.5040308@cs.tcd.ie>
Date: Tue, 12 Jan 2016 11:05:05 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <201601112242.46115.davemgarrett@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/rk-8W-bH4sZ5-Q3nbKuEHcYN7Ro>
Subject: Re: [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 11:05:10 -0000
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... - 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. - 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.) - 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). Cheers, S. [1] https://tools.ietf.org/wg/openpgp/ [2] https://tools.ietf.org/html/rfc2385 [3] https://tools.ietf.org/html/rfc5925 [4] https://tools.ietf.org/wg/curdle [5] https://tools.ietf.org/html/rfc6151 On 12/01/16 03:42, 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]. > > 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: > https://www.mitls.org/pages/attacks/SLOTH#disclosure > > _______________________________________________ TLS mailing list > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… David Benjamin
- [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature… Kurt Roeckx
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… Peter Gutmann
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… Tony Arcieri
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… David Benjamin
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… Peter Gutmann
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… Yuhong Bao
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… Andrei Popov
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… Viktor Dukhovni
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… Andrei Popov
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… Watson Ladd
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… Martin Thomson
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… Andrei Popov
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… Bill Frantz
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… Samuel Neves
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… Peter Gutmann
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… Watson Ladd
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… Peter Gutmann
- [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0,… Dave Garrett
- Re: [TLS] MD5 diediedie (was Re: Deprecating TLS … Yuhong Bao
- Re: [TLS] MD5 diediedie (was Re: Deprecating TLS … Loganaden Velvindron
- Re: [TLS] MD5 diediedie (was Re: Deprecating TLS … Viktor Dukhovni
- Re: [TLS] MD5 diediedie (was Re: Deprecating TLS … Dave Garrett
- Re: [TLS] MD5 diediedie (was Re: Deprecating TLS … Tony Arcieri
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… Karthikeyan Bhargavan
- Re: [TLS] MD5 diediedie (was Re: Deprecating TLS … Stephen Farrell
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… Martin Rex
- Re: [TLS] MD5 diediedie (was Re: Deprecating TLS … Hubert Kario
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… Karthikeyan Bhargavan
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… Hubert Kario
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… Peter Gutmann
- Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signa… Hubert Kario
- Re: [TLS] MD5 diediedie (was Re: Deprecating TLS … Dave Garrett