Bug 1892704

Daiki, does the crypto policy configuration for gnutls affect all signature verifications not just signature verification within TLS sessions? Can it be somehow excepted?

FEDORA-2020-a2d7d73f43 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-a2d7d73f43

(In reply to Tomas Mraz from comment #1)
> Daiki, does the crypto policy configuration for gnutls affect all signature
> verifications not just signature verification within TLS sessions? Can it be
> somehow excepted?

I'm afraid that's expected: if the hash algorithm is marked with "insecure-hash" in the system config, it cannot be used even outside of TLS.

Is it easy/possible to override the insecure-hash setting by application? If so, perhaps the right thing is to fix knot-resolver to override. However if that is not easily possible I am afraid we should workaround it in the policy generator. Unfortunately SHA1 signatures in DNSSec are too much prevalent to not allow them yet.

FEDORA-2020-a2d7d73f43 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-a2d7d73f43`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a2d7d73f43

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

SHA-1 nowadays has very doubtful security for DNSSEC as well, see https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html.

After internal discussion in Knot Resolver team we are going to follow the system-wide policy and treat domains with SHA1-only signatures as insecure/"unsigned" so they will resolve just fine but at the same time the resolver will not give false sense of security in DNS answers (by setting Authenticated Data bit in the answer). Update https://bodhi.fedoraproject.org/updates/FEDORA-2020-a2d7d73f43 should handle this.

Logic behind this is that "local policy is the king", and if it is bad policy then it is problem of subjects in that particular kingdom :-)
To make this less opinionated let me quote https://tools.ietf.org/html/rfc4033#section-3.1:
>    In the final analysis, however, authenticating both DNS keys and data is a matter of local policy, which may extend or even override the protocol extensions defined in this document set.

I would hate to hardcode an override for SHA-1 only to find out year later that it is CVE-worthy because it can be exploited.

FEDORA-2020-a2d7d73f43 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

I'm not sure if this is the right solution. RSASHA1 domains are now appearing as insecure and are now vulnerable to spoofing? Or is the chain still validated but then just the AD bit omitted ?

Comment 6 is what was implemented, i.e. insecure because system wide policy said us to treat it as such. If it is not what Fedora wants then Fedora's system-wide policy needs to be modified (possibly to be more fine grained?).

comment 6 does not make it clear what is done.

Are the RRSIGs still processed and validated and than only at the end is the AD bit omitted ?

or:

Are the RRSIGs ignored completely


The first option is better, it allows validating software using the resolver to make their own decisions and get all the records. It also prevents spoofing of the DNS server.
The second option would just be a reduction of security for no gain whatsoever.







The effects of treating SHA1 as not supported is:

- 2.1M domains out of 13.6M signed domains are signed using RSA with SHA1 who have their security removed.

- 682k domains only have their DNSKEY digest published in parent using SHA1 and have their security removed.

- 83 TLDs that use RSA-SHA1. Most are vanity/brand/island TLDs, but this set also includes TLDs of Armenia, Belarus, Greece, Kyrgyzstan, Sri Lanka and Namibia.

- Under those 83 TLDs there are 10k signed domains that would be affected due to their parent TLD only using SHA1

- In the DNS root zone, 3 TLDs only have SHA1 digests published


There is a very good reason for RFC-8624's recommendation to not create SHA1 signatures, but still validate SHA1 signatures. Fedora's policy should not override the worldwide DNS experts and IETF consensus about algorithms.

Just like the system-wide crypto policies have protocol exceptions for SHA1 for TLS-1.0/1.1, IKEv1 and openpgp/smime, there should be an exception for DNS validation.


The system wide crypto policies are meant to increase and secure our defaults. Most cases involve crypto parameter negotiation, where better parameters can be negotiated. For DNSSEC, there is no negotiation, so the DNS validator has no choice. SHA1 in DNSSEC is currently at 15% and dropping at 10% per year (and probably will go down faster in the next two years).


If knot decides to not allow hmac-sha1 for XFR protection, that is fine. There are alternatives, and the sysadmin can reconfigure both ends to use a more secure algorithm.

Current implementation already "allows validating software using the resolver to make their own decisions and get all the records" as you request. DNS resolver does not validate but gives all the records out so whoever wishes to re-validate using different parameters is free to do so. In other words DO bit is respected.

> Just like the system-wide crypto policies have protocol exceptions for SHA1 for TLS-1.0/1.1, IKEv1 and openpgp/smime, there should be an exception for DNS validation.

I agree that one-size-fits-all system-wide policy is wrong, but its still system-wide policy after all so it is respected. That's Fedora's problem and needs to be addressed in Fedora. If you like to change it then it is up to you to get the ball rolling, I have given up Fedora politics long ago.

> If knot decides to not allow hmac-sha1 for XFR protection, that is fine. There are alternatives, and the sysadmin can reconfigure both ends to use a more secure algorithm.

Knot decides nothing by itself, it just accepts error codes from GnuTLS library, which are in Fedora derived from system wide crypto policy.

I hope it clarifies the implementation.

The DNSSEC standards (and kresd code) only support two states for an algorithm from validator's point of view: supported and unsupported.  Zones that are (provably) possible to secure only by utilizing an unsupported algorithm are defined as insecure.

So yes, the result is getting no protection instead of (arguably) weak protection - and also signalling that it's insecure instead of assuming it's secure (e.g. via the AD bit).  Adding some "weakly secure" third state for everything might make sense, but I'd rather invest effort e.g. into convincing more people that signing with SHA1 is a bad idea.  From my point of view, Fedora could choose from those two options: secure and insecure (for each algorithm).