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

[Paul Hoffman <[e-mail]>]

On Apr 29, 2024, at 13:30, Paul Wouters <[e-mail]> wrote:
> 
> On Mon, 29 Apr 2024, Paul Hoffman wrote:
> 
>> If the purpose of deprecating validation that involves SHA-1 is the decision by RedHat to make that entire section of the DNS insecure, the documents should say that explicitly. Conflating the pre-image weaknesses of SHA-1 and actual useful attacks on DNSSEC, and then using that conflation as the reason for the WG adopting these documents, is not useful.
> 
> Redhat is not the source of this. It is the certification people that say you
> cannot use SHA1 in cryptographic functions related to authentication,
> encryption, or digital signatures. And that these requirements are
> getting centrally codified in an OS that cannot take DNS into account.

It is still RedHat's choice to read those certification requirements the way that they did; others read them differently.

But, regardless of whether we agree with RedHat's decision, if it is that decision that is driving the drafts, the drafts should say that instead of saying that it is some vague concern that has not been substantiated.

> Tony Finch and Viktor Dukovhny believe an attack with SHA1
> is possible. I have not yet been convinced by them. See:
> https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html

I too am not convinced that an attack that needs >250 bytes of identical preamble can apply to DNSSEC-relevant records such as DS, DNSKEY, NSEC, and NSEC3. More than four years after it was published, the original paper (https://sha-mbles.github.io/) has not been updated with any more detail related to DNSSEC, nor do others seem to have followed up. (Note: I could totally have missed such followups; if so, I'm quite interested to hear of them!)

--Paul Hoffman