> e.g. as other OS vendors follow suit and SHA-1 support > disappears from crypto libraries.
As described by Mark Andrews, one thing that made the Redhat situation more complex is that they didn't just remove SHA1 signing support, they modified openssl to return bogus RSA valdation results at runtime. Which requires very specific detection techniques on the side of validation software. So the SHA1 support is there, it is just made unreliable. Going beyond Redhat, BGP is still using MD5. That's not going away. NSEC3 uses SHA1 that is also not going away soon, Git uses SHA1. So the risk of SHA1 getting removed from crypto libraries is extremely small. Even NIST, which recommends against using SHA1 in signing has carved out exceptions. So maybe we can wait until implementors speak up that is hard to support those old algorithms? > There are other reasons to deprecate SHA-1 in DNSSEC than mathematical > concern about the use of that particular digest algorithm in the > protocol. Problems with SHA-1 definitively exist in other places, > in protocols that are in much more widespread use than DNSSEC. For > example, a message that says "stop using SHA-1" might be more > effective at fixing TLS implementations than a message that says > "stop using SHA-1 unless you are using it in one of the following > ways, in which case it's totally fine". From the perspective of > DNSSEC, "stop using SHA-1" might be a much more effective message > to communicate at the same time that everybody else is saying it > than ten years later. There have been quite a number of non-technical arguments used in this discussion. I'll list a few. 1) It is already broken (because Redhat broke it). It don't see how it is better to break it some more. 2) We are late, we should have remove SHA1 support years ago. 3) The above quote, we need to lead the pack and remove SHA1 to help others. I find the combination of 2) and 3) quite funny. 4) We need to set an end date. We still have the WKS record which has not seen any use for decades and the presentation format is a pain to implement. But that one is still there. But we really need to get rid of something that is in active use. Maybe we can have a guideline that we first deprecate what has been obsolete by decades before we start with what is currenly in use? 5) People are using old software. We don't even know if people are old software to sign using SHA1. But even then, do we really want go and break protocols just to move people to newer software. Is that productive? 6) There are about 140k zones signed using SHA1. That's a small number we don't have to care. If find this confusing. The biggest problem we have is getting people to sign there zones in the first place (and adding transport security). But we have time to just kill 140k signed for no technical reasons? In the end the current draft has a strong negative effect on the direct and indirect users of about 140k zones. Indirect use might also be if there are DANE records in those zones and the use of DANE by the sender of an email will silently stop after a validator lists the domain as insecure. >From a technical point of view, there is no second preimage attack on SHA1, it will probably take a quantum computer to perform one. And if that's the case then we will have to deprecate RSA, rendering the issue moot. What are the positive points of this draft? Checking a box that there is now a little bit less SHA1? It doesn't seem to bring any meaningful increase in security. The impact on validation software may also be very annoying. Validation software will have to default to not support SHA1 in signing to implement this draft. But no doubt there will be customers who do need SHA1 support. So there will be a config option. And the config option will be there until the end of time. Effectively leading to more complexity. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
