Paul Wouters <p...@nohats.ca> wrote: > > Obsoleting really takes time. And the path is to first stop producing > SHA1 signatures, and once that number goes down, to start discouraging > consuming SHA1 signatures. If you immediately say MUST NOT for validating, > you are making 2211449 + 287467 = 2.5M domains more insecure. That would > be very irresponsible, and serve no real purpose. Saying "start of 2022" > might be okay, but might not be okay. We don't know yet. That is why RFC > 8624 does not put in specific dates. We need to push the market, but > not demand unrealistic speeds. If we do that, people will simply start > ignoring the RFC recommendations.
Right. I don't think we're pushing hard enough, so I'm trying to get suggestions for how we can do better. > The document spells out a big doom day scenario, and then in section > 5.4.1 admits that, oh btw, if you don't share private keys with other > zones, then you don't really have an issue. There are several other dangerous situations. If you have shared hosting within a zone, you have an issue. If you are a large enterprise you have a privilege escalation issue. If you are a TLD with weak DS syntax checks, you have an issue. (I spelled out a privilege escalation attack in more detail in https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html) > But what really needs to happen is that we need to reduce the number of > SHA1 signatures present. We could push the signing software vendors to > refuse generating new DNSKEY's KSK's that use SHA1. This might delay a > KSK rollover unexpectedly, but it won't cause any outages or regressions > to insecure zones. And that process already mostly involves a human > interaction for an updated DS anyway. Slowing that down won't really > do any harm. It would give those using SHA1 a nudge to look at doing an > algorithm rollover for their new KSK instead. Similarly, we could nudge > TLDs to stop accepting SHA1 based DS records, or for those TLDs that > generate their own DS records, push them to no longer publish SHA1 > based DS records. Those are good ideas, thanks. WRT DS records, are you talking about DNSKEY algorithm types or DS digest types? I'm not so worried about digest type 1 because DS digests need to be secure against preimage attacks and SHA-1 is still OK in that respect. (And digest types are easier to upgrade.) > Which brings me to my second point, upgrading. Moving away from SHA1 > involves an algorithm rollover. A lot of currently deployed signers run > on software that is a few years old. For instance a few year old bind or > opendnssec does not even support an algorithm rollover. I believe the > main reason we still see so muc SHA1, is that people and their software > are not ready to do an algorithm rollover. And if they are not ready, > publishing a new RFC that mandates such a change will just be ignored. > We need to work on our tools and documentation to give confidence to > people that an algorithm rollover is easy Well, we had better get on with that quickly then. I think BIND is not as bad as you say: my colleagues have done an algorithm rollover with 9.10 which is over 5 years old. Tony. -- f.anthony.n.finch <d...@dotat.at> http://dotat.at/ Shetland Isles: South or southeast 5 or 6, veering west or southwest 5 to 7, occasionally gale 8 later. Moderate at first in sheltered east, otherwise rough or very rough. Occasional rain, squally showers later. Good occasionally poor. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
