On Mar 9, 2020, at 6:46 PM, Tony Finch <d...@dotat.at> wrote: > > Paul Hoffman <paul.hoff...@icann.org> wrote: >> >> This draft is about discouraging people from signing with SHA-1 by >> directly harming them (implementations that will no longer be able to >> validate their signatures). While threats of direct harm are probably >> effective at getting to a desired outcome, they do not represent the way >> the IETF normally does its work. (I'm happy about that.) > > I tried to address this in the security considerations section. The > aim is to avoid harm, specifically the harm of having to suddenly and > surprisingly disable SHA-1 validation via a mass CVE and security patch > when a collision attack improvement comes along that makes it dangerously > misleading to stick an AD bit on an answer from a SHA-1 zone.
This confuses a harm purposely caused by authorities (in this case, the IETF), with self-harm (in this case, a zone owner who didn't hear about the importance of doing an algorithm rollover, or did hear but didn't care). They are quite different. > Which is why > the timetable aims to stop the use of SHA-1 for signing before it stops > the use of SHA-1 for validating, assuming optimistically that we actually > have 2 years available. (I fear we don't.) Who is "we" there? Those of us who have seen the warnings now have all the time in the world to heed them, to plan to heed them Real Soon Now, or to prioritize other parts of our lives above this possible harm to us. It is only the people who have not heard whom have time issues before the attacks get easier. > WRT updating RFC 8624, my hope is that updated implementation requirements > will encourage better tools to make it easier to upgrade from SHA-1 before > SHA-1 becomes useless. My initial suggestions are probably ham-fisted, but > for software that is on an annual cycle of feature releases there isn't > time for a multi-stage deprecation. I don't think there's any point > addressing a draft to operators if the tooling still encourages the use of > SHA-1. Then consider writing a draft that strongly discourages implementations from encouraging or even being neutral about algorithms with SHA-1. That's much easier to justify than "we want to hurt people who are currently signing with DNSSEC". > This problem should have been dealt with years ago, and now it needs to be > treated as an emergency. Dealing with an emergency by purposely harming the people who didn't follow your earlier advice is an option, but not one that many of us would endorse. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
