Hello Paul,I am aware Red Hat is not loved for the way, how the disabling of RSASHA1 algorithm were handled in our products, especially Red Hat Enterprise Linux 9.
While primary target of our crypto people were disallowing SHA-1 usage in TLS channels and signatures of documents, I think they were correct that it affects negatively also DNSSEC.
Because similar change to RHEL9 were done also on recent Fedora 41 release, let me share a nice public summary from them on page OpenSSLDistrustSHA1SigVer [1]. While this style of deployment is not ideal, especially because we violate a RFC by it, crypto library maintainers had not given us choice around that.
I would point to SHA-1 is a Shambles [2] page, which includes more information about the attack.
Tony Finch has correctly identified in SHA-1 chosen prefix collisions and DNSSEC [3] article that when a single record is usually safe, multiple records might allow creating fake signature even in DNSSEC. While you are somehow limited for A or AAAA records length, records like TXT or OPENPGPKEY may contain a lot of data. You can just generate random garbage at appended additional record. Which does not have to be ascii or even have expected PGP key format. Similarly you can forge additional SSHFP records with any content, just to have the same resulting digest. That would get first correct record accepted, just because random appending happens.
Correct me if I am wrong, but I think RRSIG wire-format [4] does not include length of signed RRset data, especially not at the start. Which may prevent append attack on signatures.
That leads me to conclusion our crypto team were correct, SHA-1 should not be relied on in DNSSEC. I agree, zones still signing with SHA-1 should upgrade ASAP. Verification of SHA1 based signatures is still better than nothing at all, but most implementations I have seen cannot do just fallback type of verification. They either verify and set AD bit or nothing. That is the case of bind9, unbound and dnsmasq, which can do validation in RHEL9.
I think relaxing from MUST validate would be better. I would propose adding similar formulation:
> Implementation SHOULD validate SHA1 signatures in the validator, unless supported algorithm with a better strength covers the same RRset. In that case AD bit SHOULD NOT be set in the response.
No implementation I know can behave like this, but it would provide at least partial protection, which you demand.
Best Regards, Petr Software Engineer at Red Hat1. https://fedoraproject.org/w/index.php?title=Changes/OpenSSLDistrustSHA1SigVer
2. https://sha-mbles.github.io/ 3. https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html 4. https://www.rfc-editor.org/rfc/rfc4034#section-3.1 On 01/05/2024 01:50, Paul Hoffman wrote:
On Apr 30, 2024, at 16:20, Wes Hardaker <wjh...@hardakers.net> wrote:3. The whole discussion, IMHO, is side-stepping the real issue: if not now, then when? IE, do we never put something at MUST NOT? Is there a usage threshold? Is it "must be zero"? Is it "known to be broken and everyone must have a flag day instead of a slower process"? These are not easy questions, and there does seem to be many different opinions. RedHat led the pack(ish), and maybe Paul and others will be the tail end at some very late value. There is no right or wrong, and the line of people are likely to spread out along the timeline.Thank you for asking the question about questions. But, please, don't simplify with the phrase "MUST NOT" given that the draft has that for two different parts of the DNS: signers and resolvers. My personal feeling is that "MUST NOT sign because RedHat" is an unfortunate position for us to be in, but one that is defensible. "MUST NOT validate because of some security issue that might never happen" is not defensible, at least to me. The argument "you signing something that we know many resolvers cannot validate is actively bad for security" is defensible. Until someone can show that a reduction in collision resistance can lead to a reduction in real-world security for DNSSEC, we can wait for "MUST NOT validate", possibly forever. There is no good reason for this group to say to a zone operator who signed their zone in good faith "we are now making your zone insecure"; it's even worse for us to say to zone owners "we're forcing you to pick a different TLD if you still want to be secure". And, to be clear: I don't support waiting for a usage threshold for "MUST NOT validate". If there is any noticeable chance that an attacker can create a key or signature for a zone they don't control, that is a good enough reason to go to "MUST NOT validate" and let the resolvers decide if they want to be compliant with the new standard. But we aren't there yet, and when we are, the RFC needs to say how we got to that conclusion. --Paul Hoffman
-- Petr Menšík Senior Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
