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
>