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

[Petr Menšík <[e-mail]>]

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 Hat

1. 
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 <[e-mail]> 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