Subject: [DNSOP] Fwd: DNSSEC algorithm used on ietf.org

From: Petr Menšík <[email-masked]>
Date: Wed, 23 Mar 2022 15:30:57 +0100

Is this workgroup more appropriate to drive possible change? Has it any
means to modify ietf.org infrastructure?

-------- Forwarded Message --------
Subject: 	DNSSEC algorithm used on ietf.org
Date: 	Wed, 23 Mar 2022 12:28:39 +0100
From: 	Petr Menšík <[email-masked]>
Organization: 	Red Hat
To: 	[email-masked]

Hello,

I work in Red Hat on DNS related products. We were analysing impact on
disabling algorithm RSASHA1. It is in a strange sitation, because IETF
itself deprecated this algorithm [1], but is using it for all documents
it publishes. For some reason site stats.dnssec-tools.org gives it as an
example [2]. It seems update of Key signing key (ksk) and algorithm
should be upgraded to more recent algorithm. There is also informational
RFC 7583 [3], which should help with it.

Is there already plan to upgrade DNSSEC algorithm? Is there any specific
reason why it stayed unchanged?

I were directed here by the support of ietf. Might be also interesting
topic for dnsop WG.

Were upgrade already considered?

Best Regards,
Petr Menšík

1. https://datatracker.ietf.org/doc/html/rfc8624#section-3
2. https://stats.dnssec-tools.org/explore/
3. https://datatracker.ietf.org/doc/html/rfc7583

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: [email-masked]
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

---

From: Paul Wouters <[email-masked]>
Date: Wed, 23 Mar 2022 15:50:25 +0100

This has come up before and has been relayed before. I will see about getting this unstuck.

Btw what do you mean with “disabling”? Letting it be treated as insecure or throwing a sha1 crypto library error and causing a bogus result leading to failure to access the sites ?

Paul

Sent using a virtual keyboard on a phone

> On Mar 23, 2022, at 15:31, Petr Menšík <[email-masked]> wrote:
> 
>  Is this workgroup more appropriate to drive possible change? Has it any means to modify ietf.org infrastructure?
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 23 Mar 2022 14:56:39 +0000

> Is this workgroup more appropriate to drive possible change? Has it any means to modify ietf.org infrastructure?

No and no.

Having said that, please see below for commentary on your reasoning.

> disabling algorithm RSASHA1.

The impact is clear: you will cause many validly-signed zones to be considered unsigned.

> It is in a strange sitation, because IETF
> itself deprecated this algorithm [1],

Where in RFC 8624 do you believe it says that RSASHA1 is deprecated? Searching for "depreca" in the document finds it used for other algorithms, but not RSASHA1.

Further, the chart clearly shows it is not deprecated:
   +--------+--------------------+-----------------+-------------------+
   | Number | Mnemonics          | DNSSEC Signing  | DNSSEC Validation |
   +--------+--------------------+-----------------+-------------------+
. . .
   | 5      | RSASHA1            | NOT RECOMMENDED | MUST              |

That is, "MUST" validate is clearly not deprecated.

--Paul Hoffman

---

From: Petr Menšík <[email-masked]>
Date: Wed, 23 Mar 2022 17:22:10 +0100

Of course no-one were ever considering making sha-1 signatures fail hard
with SERVFAIL. More below.

On 3/23/22 15:50, Paul Wouters wrote:
> Btw what do you mean with “disabling”? Letting it be treated as
> insecure or throwing a sha1 crypto library error and causing a bogus
> result leading to failure to access the sites ?

Insecure only. Yes, that would lead to valid resolution of
dnssec-failed.org for example, because it is also signed only by
RSASHA-1. Might surprise someone, it did surprise me. Disabled
algorithms are tested to pass as insecure. Only dnsmasq with GOST digest
needs fixing on Fedora and RHEL, at least according to test on
rootcanary.org.

Because NSEC3 algorithm still does not have any alternative to SHA-1,
hard crypto failure would be blocker for any our DNS products. I haven't
heard about it even being considered this way.

I know it might not be best time for it yet, but it has to come someday.

>>  Is this workgroup more appropriate to drive possible change? Has it
>> any means to modify ietf.org infrastructure?
>>

---

From: Petr Menšík <[email-masked]>
Date: Wed, 23 Mar 2022 18:04:24 +0100

> The impact is clear: you will cause many validly-signed zones to be considered unsigned.
I am aware this would be the result. It were done in very similar manner
with RSAMD5. It is questionable anyway how secure it is, when its
operator does not follow up-to-date recommendation.
> Further, the chart clearly shows it is not deprecated:

We are preparing RHEL 9 and we still have SHA-1 for DNS(SEC) as
exception. But we think it would happen when it would be under support.
Thank you for exact reference, it may be used in our internal discussion.

While it might not be required yet, it should be ready when that
happens. Is there expected timeline for that yet? Any required changes,
which may change validation to SHOULD or MAY? Is it just about DNSSEC
algorithms used on top level domains? Server configuration already makes
it possible to disable any algorithm, including RSASHA1. It must
implement it and it would. Question here is only whether it would be
disabled in default configuration or not.

We are not considering disabling its support at build time, it would be
always possible to enable later.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 23 Mar 2022 17:41:28 +0000

On Mar 23, 2022, at 10:04 AM, Petr Menšík <[email-masked]> wrote:
> with RSAMD5.

RSAMD5 has a very different status in RFC 8624 than RSASHA1 does.

> It is questionable anyway how secure it is, when its

If Red Hat believes that it can make that kind of judgement for its customers, that's fine, but you should make your customers aware of the implications of that decision: validly-signed zones will be treated as unsigned by Red Hat software. Your customers can then decide if they want to keep using that software from you, or switch to another vendor.

> exception.

What does "as exception" mean here?

> But we think it would happen when it would be under support.

Certainly. Anyone making such decisions should be reading the relevant RFCs carefully.

> happens. Is there expected timeline for that yet?

No. Everything that is known about the state of the recommendations is in the RFC itself.

> Any required changes,
> which may change validation to SHOULD or MAY?

Those are possibilities, as is leaving it a MUST.

> Is it just about DNSSEC
> algorithms used on top level domains?

No. RFC 8624 does not differentiate between levels in the DNS hierarchy. 

> Server configuration already makes

Given that RFC 8624 says that validation is "MUST", I think that answers it for you.

> always possible to enable later.

That sounds fine, as long as your customers understand when you are making choices to deviate from the Internet standards they expect you to be following.

--Paul Hoffman

---

From: Brian Dickson <[email-masked]>
Date: Wed, 23 Mar 2022 11:21:05 -0700

On Wed, Mar 23, 2022 at 9:22 AM Petr Menšík <[email-masked]> wrote:

> Because NSEC3 algorithm still does not have any alternative to SHA-1, hard
> crypto failure would be blocker for any our DNS products. I haven't heard
> about it even being considered this way.
>

I think this is a relatively common misconception. (I recently discovered
that I also misunderstood the situation.)

The first couple of algorithms specifically meant for NSEC3 use were
basically duplicates of algorithms that were NSEC-only, with new algorithm
numbers.
As I understand it, this was to ensure interoperability, in part due to
earlier implementations which would not be aware of NSEC3.
The new algorithms were a way of ensuring only updated software (which
could be guaranteed based on the algorithms being "new") would be expected
to understand (i.e. validate) NSEC3.

After that point, all new algorithms are both NSEC and NSEC3.

I believe that means you should be free to update to newer algorithms. I
would recommend both using Algorithm 13, and potentially moving away from
NSEC3 unless you have a strong reason for using it.

Or are you talking about what algorithms your software supports, in which
case this should be simple enough (to allow NSEC3 on newer algorithms).

Brian

---

From: Petr Menšík <[email-masked]>
Date: Wed, 23 Mar 2022 20:20:11 +0100

> RSAMD5 has a very different status in RFC 8624 than RSASHA1 does.
RSAMD5 must not be implemented since RFC 6944, year . So many domains do
not use any kind of DNSSEC signatures, would SHA-1 break everything so bad?
> If Red Hat believes that it can make that kind of judgement for its customers, that's fine, but you should make your customers aware of the implications of that decision: validly-signed zones will…
Red Hat creates stable Linux distribution, which our customers usually
start using 2-3 years after we release it. We have to make reasonable
guess what might be best practice at that time. It is hard. I know it is
not considered as broken as RSAMD5 is. That might change, we are trying
to prepare for that time ahead.
> What does "as exception" mean here?
We try to prepare strong algorithms only for TLS negotiated channels.
For example HTTPS connection would not accept RSASHA1 certificate.
Anywhere SHA-2 can be used, it has to be used instead. DNS is not so
simple, because no such on-demand negotiation is done. And RSASHA1 is
still considered strong enough for DNSSEC. It would not be allowed for a
web service. Therefore DNS has exception to keep using SHA-1 for
security purposes from our crypto people.
> Given that RFC 8624 says that validation is "MUST", I think that answers it for you.

Yes, it says so. It also says SHA-1 is not recommended for new
signatures and ietf.org signature was made at 20220318000627. Is there
reason why DNS is so better protected than TLS certificates? Is its
shorter message length a good protection? I don't understand the
difference between

There were thread two years ago:
https://mailarchive.ietf.org/arch/msg/dnsop/hA4Ur9qxRJIUo13Pjpmrm_va7cs/

I were not watching well enough, does that mean DNS(SEC) is not affected?

Is it required to wait for a new RFC?

> That sounds fine, as long as your customers understand when you are making choices to deviate from the Internet standards they expect you to be following.

It seems you take our consideration even personal. I am sorry for that.
I were not looking for a flame, but for a guidance. I did not know we
have to humbly wait for RFC approval for our configuration. We
understood still not a tiny amount of people is using RSASHA-1 in DNS.
But I am unsure how would people here conclude it is the right time to
make SHA-1 non-mandatory.

Our product undergoes security certification. That mandates strong
cryptography is used whenever it can be. I think if someone needs to
have secure domain then SHA-1 is not ideal way there. Even when RFC 8624
says it has to be supported. Okay, not yet ready. I just hope it would
not come too late.

Best Regards,

Petr

---

From: Petr Menšík <[email-masked]>
Date: Wed, 23 Mar 2022 20:39:14 +0100

I may not be guru working 10 years on DNS, but I know difference between
algorithm 5 and algorithm 7. I even think why 7 were required to keep
backward compatibility.

What I mean here is NSEC3 hash algorithm:

https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml#dnssec-nsec3-parameters-3

I thought it is not a problem, because it contains multiple iterations.
Yet popular TLD has iterations==0. This is about how hash of name is
created from original Next Hashed Owner Name. No other algorithm for
this is defined.

My conclusion is owner name hash is not security sensitive. But I never
saw that written in and RFC I read. I cannot say I read or know all
relevant drafts. Is it obvious to everyone but me?

This is primary reason why I cannot accept ever failing SHA-1 digest
from crypto library. RHEL7 in FIPS mode failed when MD5 were used. That
helped to catch whatever is using md5, thus might be insecure. This must
not happen with SHA-1, because NSEC3 does not have any equivalent and
cannot work without it. Regardless used key algorithm, unless I am mistaken.

On 3/23/22 19:21, Brian Dickson wrote:
>     Because NSEC3 algorithm still does not have any alternative to
>     SHA-1, hard crypto failure would be blocker for any our DNS
>     products. I haven't heard about it even being considered this way.
>
>
> I think this is a relatively common misconception. (I recently
> discovered that I also misunderstood the situation.)
>
> basically duplicates of algorithms that were NSEC-only, with new
> algorithm numbers.
> As I understand it, this was to ensure interoperability, in part due
> to earlier implementations which would not be aware of NSEC3. 
> could be guaranteed based on the algorithms being "new") would be
> expected to understand (i.e. validate) NSEC3.
>
> I believe that means you should be free to update to newer algorithms.
> I would recommend both using Algorithm 13, and potentially moving away
> from NSEC3 unless you have a strong reason for using it.
>
> Or are you talking about what algorithms your software supports, in
> which case this should be simple enough (to allow NSEC3 on newer
> algorithms).
>
> Brian

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 23 Mar 2022 15:39:54 -0400

On Wed, Mar 23, 2022 at 3:20 PM Petr Menšík <[email-masked]> wrote:
> signatures and ietf.org signature was made at 20220318000627.

It's more accurate to say that it's not recommended for new
deployments.  Operators are encouraged to migrate to more secure
algorithms, but given an existing deployment there's no MUST
associated with that migration, yet.

> Is there

It's to do with the expected lifetime of the signatures, and the fact
that we're dealing with signatures, not encryption.  There is no need
to have years of protection from a single key or signature, as there
is with encryption and privacy, as is intended for TLS.

---

From: Tony Finch <[email-masked]>
Date: Thu, 24 Mar 2022 11:50:00 +0100

> associated with that migration, yet.

That was a serious error in RFC 8624, that should have been called out
when it was being prepared. Arguably, the same could be said for its
predecessor RFC 6944.

The lifetime of the signature is not relevant for the kind of collission
attack demonstrated by the "SHA-1 is a shambles" paper, because the
structure of an attack is:

  * attacker predicts the the framing in the signature chosen by the
    victim, things like the inception and expiration times

  * attacker generates colliding plaintexts, superficially benign (to be
    signed by the victim) and malicious; this takes some time

  * attacker submits a DNS update containing the superficially benign
    RRset, which is signed by the victim

  * attacker re-attaches the signature to the malicious RRset and uses it
    in a DNS record substitution attack.

This is the same structure as previous successful attacks on X.509
certificates with MD5 signatures. As well as continuing to use a weak
hash function, DNSSEC has not adopted any mitigations, such as
hard-to-predict framing, that are used in the PKIX world.

I have explained how DNSSEC is vulnerable to SHA-1 collisions in detail,
but sadly I was not gentle enough about the way I said it, and various
people on this list got upset and accused me of trying to break the DNS.
Sheesh.

Anyway, I-D version:

https://datatracker.ietf.org/doc/html/draft-fanf-dnsop-sha-ll-not-00

Blog version:

https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html
https://www.dns.cam.ac.uk/news/2020-02-14-sha-mbles.html

Also republished at:

https://blog.apnic.net/2020/01/17/sha-1-chosen-prefix-collisions-and-dnssec/

-- 
Tony Finch  <[email-masked]>  https://dotat.at/
Lyme Regis to Lands End including the Isles of Scilly: East or
northeast, becoming variable for a time, 2 to 4. In west, slight or
moderate becoming slight later, in east smooth or slight. Fair. Good,
occasionally moderate.

---

From: Tony Finch <[email-masked]>
Date: Thu, 24 Mar 2022 11:58:11 +0100

> relevant drafts. Is it obvious to everyone but me?

Maybe not obvious, but it is sort of implied by RFC 5155, because if you
are not worried about zone enumeration then there's no point in heavy
hashing. And since then there has been plenty of academic work showing
how easy it is to enumerate a zone despite NSEC3. There is a fairly
straightforward discussion of the issue in section 2.3 of this draft:

https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-nsec3-guidance

-- 
Tony Finch  <[email-masked]>  https://dotat.at/
Fisher: West or southwest 2 to 4, occasionally 5 later. Smooth or
slight. Mainly fair. Moderate or good, occasionally poor.