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

[Stephen Farrell <[e-mail]>]

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 
> [e-mail] https://www.ietf.org/mailman/listinfo/tls
>