Re: [DNSOP] New Version Notification for draft-fanf-dnsop-sha-ll-not-00.txt (fwd)

[Paul Wouters <[e-mail]>]

On Mon, 9 Mar 2020, Tony Finch wrote:

> The aim of this is to deprecate SHA-1 algorithms 5 and 7 more vigorously.
> I've put in a fairly specific timetable for sake of argument, basically to
> set up the death of SHA-1 as next year's DNS "flag day", unless some
> clever cryptanalysis forces it to happen sooner.

As authors of RFC 8624, this is the third such proposal we have now seen :)

RFC 8624 lists SHA-1 algorithms as NOT RECOMMENDED for signers and MUST
for resolvers. The only real change that Ondrey and I believe is
justified is for the signers to go from NOT RECOMMENDED to MUST NOT.

But this draft does a lot more.

The problem is nicely summarized in Section 2.4:

    Validating resolvers MUST treat algorithms 5 and 7 as unknown or
    insecure after the start of 2022, or earlier if SHA-1 becomes
    significantly weaker before then.

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.

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. Note that the parties
sharing private keys for different domains are the large scale DNS
hosters, who already have no reason to still be on SHA-1.

RFC 8624 says NOT RECOMMENDED for producing SHA1 signatures. It says
MUST for consuming SHA1 signatures. It does so for good reasons. While
we could update the document to change signing from NOT RECOMMENDED
(which is really SHOULD NOT) to MUST NOT, it is a pretty light change. I
am not sure if it is worth updating RFC 8624 for, but numbers are cheap
so we could just do it.

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.

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

And speaking for myself now (and not Ondrey), I'm a strong opponent
of DNS "flag days", such as proposed in this draft by specifying a
die date. Software updates take time and there will never be a single
day where suddenly we live in a new world. Instead of marketing a
threat to users, we should improve the tools so people are more or less
automatically algorithm rolled to a new world without threats.

Paul