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. 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.) 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. This problem should have been dealt with years ago, and now it needs to be treated as an emergency. Tony. -- f.anthony.n.finch <d...@dotat.at> http://dotat.at/ fight poverty, oppression, hunger, ignorance, disease, and aggression _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
