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