Bug 1892704

Summary: domains with SHA1 DNSSEC algorithms SERVFAIL in Fedora 33
Product: [Fedora] Fedora Reporter: Petr Špaček <pspacek>
Component: knot-resolverAssignee: Petr Špaček <pspacek>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 33CC: dns-sig, dueno, jv+fedora, pspacek, pwouters, tkrizek, tmraz, vladimir.cunat
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-10-31 01:54:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Petr Špaček 2020-10-29 13:38:44 UTC
Description of problem:
DNS domains signed using DNSSEC algorithms involving SHA1 cannot be resolved in Fedora 33. DNSSEC validation fails for these sites and clients get SERVFAIL response, rendering domains inaccessible. This applies also to domain fedoraproject.org.

Version-Release number of selected component (if applicable):
knot-resolver-5.1.3-3.fc33
knot-libs-3.0.1-1.fc33.x86_64

How reproducible:
100 %

Steps to Reproduce:
0. docker run -ti fedora:33  # clean Fedora 33 state
1. dnf install knot-resolver knot-utils -y
2. kresd -v -a 127.0.0.1 -n &
3. kdig @127.0.0.1 fedoraproject.org


Actual results:
[15465.08][vldr]     >< bogus key: fedoraproject.org. DNSKEY (2 matching RRSIGs, 0 expired, 0 not yet valid, 0 invalid signer, 0 invalid label count, 1 invalid key, 1 invalid crypto, 0 invalid NSEC)
[15465.08][vldr]     <= bad keys, broken trust chain
...
[15465.00][resl] request failed, answering with empty SERVFAIL
[15465.08][resl]     finished: 8, queries: 1, mempool: 32800 B
;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 15465
;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; fedoraproject.org.  		IN	A

;; Received 35 B
;; Time 2020-10-29 13:29:32 UTC
;; From 127.0.0.1@53(UDP) in 1298.6 ms


Expected results:
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 20677
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 13; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; fedoraproject.org.  		IN	A

;; ANSWER SECTION:
... an IP address here ...

Additional info:
This failure is caused by default Fedora Crypto Policy which forbids SHA1. GnuTLS returns error when attempting to verify SHA1 signatures, which renders DNS domains which depend on SHA1 for their DNSSEC signing unverifiable.

Reference: https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 , bug 1821875.

Comment 1 Tomas Mraz 2020-10-29 15:44:15 UTC
Daiki, does the crypto policy configuration for gnutls affect all signature verifications not just signature verification within TLS sessions? Can it be somehow excepted?

Comment 2 Fedora Update System 2020-10-29 16:06:06 UTC
FEDORA-2020-a2d7d73f43 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-a2d7d73f43

Comment 3 Daiki Ueno 2020-10-29 16:44:17 UTC
(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.

Comment 4 Tomas Mraz 2020-10-29 17:00:55 UTC
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.

Comment 5 Fedora Update System 2020-10-30 01:17:04 UTC
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.

Comment 6 Petr Špaček 2020-10-30 08:23:57 UTC
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.

Comment 7 Fedora Update System 2020-10-31 01:54:15 UTC
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.

Comment 8 Paul Wouters 2021-01-12 14:22:49 UTC
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 9 Petr Špaček 2021-01-13 12:41:48 UTC
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 10 Paul Wouters 2021-01-13 14:54:31 UTC
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.

Comment 11 Petr Špaček 2021-01-15 07:28:57 UTC
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.

Comment 12 Vladimír Čunát 2021-01-15 08:50:09 UTC
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).