Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost

[Philip Homburg <[e-mail]>]

>It will also prevent ServFails when the system crypto SHA1 for
>authentication and signature purposes is blocked, and the DNS software
>sees this as a failure and returns BOGUS. I am not sure how many DNS
>implementations are now probing SHA1 and on failure put it in the
>"unsupported algorithm" class, to serve it as insecure instead of bogus.
>
>This issue did hit RHEL,CentOS, Fedora.

Bogus would be perfectly fine. The problem is that no operator is going to
deploy a system that returns bogus for a commonly used signing algorithm.

So what happens instead is that software is patched to return insecure if
SHA1 is not avaiable for signing and that is of course very risky.

>The IETF and its cryptographic policies are a careful interworking
>between market forces, reality and desire. Moving to fast leads to RFCs
>being ignored. Moving too slow means RFCs do not encourage
>modernization. Every other protocol has left SHA1 behind. It's time for
>DNS to follow suit. It's had its "exemption" for a few years already.

One thing that keeps showing up in this context is Redhat. RHEL and
CentOS are directly controlled by Redat, Fedora is strongly connected to
Redhat.

So it seems that one company is trying set policy. Not a policy that is
grounded in security analysis, a policy based on shipping products that
violate current DNSSEC standards.

Given that for a large number of zones, SHA1 does not pose a security risk,
there is no 'too slow'.

There is a general move to EC for signatures and that solves the SHA1
issue as well. For zones that are currently secure, just let them be
secure.

And let Redhat ship broken products if they want.