Re: [DNSOP] Questions before adopting must-not-sha1

[Philip Homburg <[e-mail]>]

> 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.