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 > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
