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

Reply via email to