Subject: [DNSOP] New Version Notification for draft-fanf-dnsop-sha-ll-not-00.txt (fwd)

From: Tony Finch <[email-masked]>
Date: Mon, 9 Mar 2020 23:16:48 +0000

The aim of this is to deprecate SHA-1 algorithms 5 and 7 more vigorously.
I've put in a fairly specific timetable for sake of argument, basically to
set up the death of SHA-1 as next year's DNS "flag day", unless some
clever cryptanalysis forces it to happen sooner.

I'm afraid it's a rough first pass: I haven't given it a read-through
and cleanup, because watching Flash Gordon was more fun.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
ALL CREATURES WILL MAKE MERRY UNDER PAIN OF DEATH

---------- Forwarded message ----------
Date: Mon, 09 Mar 2020 15:55:05 -0700
From: [email-masked]
To: Tony Finch <[email-masked]>
Subject: New Version Notification for draft-fanf-dnsop-sha-ll-not-00.txt

A new version of I-D, draft-fanf-dnsop-sha-ll-not-00.txt
has been successfully submitted by Tony Finch and posted to the
IETF repository.

Name:		draft-fanf-dnsop-sha-ll-not
Revision:	00
Title:		Hardening DNSSEC against collision weaknesses in SHA-1 and other cryptographic hash algorithms
Document date:	2020-03-09
Group:		Individual Submission
Pages:		18
URL:            https://www.ietf.org/internet-drafts/draft-fanf-dnsop-sha-ll-not-00.txt
Status:         https://datatracker.ietf.org/doc/draft-fanf-dnsop-sha-ll-not/
Htmlized:       https://tools.ietf.org/html/draft-fanf-dnsop-sha-ll-not-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-fanf-dnsop-sha-ll-not

Abstract:
   DNSSEC deployments have often used the SHA-1 cryptographic hash
   algorithm to provide authentication of DNS data.  This document
   explains why SHA-1 is no longer secure for this purpose, and
   deprecates its use in DNSSEC signatures.  This document updates RFC
   8624.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Mar 2020 00:11:00 +0000

On Mar 9, 2020, at 4:16 PM, Tony Finch <[email-masked]> wrote:
> I'm afraid it's a rough first pass...

This draft, as constituted, is not a clean update to RFC 8624. RFC 8624 was about Algorithm implementation requirements: it says so right in the title, and repeats that in many other places.

This draft is about discouraging people from signing with SHA-1 by directly harming them (implementations that will no longer be able to validate their signatures). While threats of direct harm are probably effective at getting to a desired outcome, they do not represent the way the IETF normally does its work. (I'm happy about that.)

A different draft would give the same guidance to signers, explain that their practices put themselves at risk, and show charts of how signatures using SHA-1 are decreasing (indicating that laggards are becoming part of an ever-smaller minority).

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Mon, 9 Mar 2020 21:42:33 -0400 (EDT)

> clever cryptanalysis forces it to happen sooner.

As authors of RFC 8624, this is the third such proposal we have now seen :)

RFC 8624 lists SHA-1 algorithms as NOT RECOMMENDED for signers and MUST
for resolvers. The only real change that Ondrey and I believe is
justified is for the signers to go from NOT RECOMMENDED to MUST NOT.

But this draft does a lot more.

The problem is nicely summarized in Section 2.4:

    Validating resolvers MUST treat algorithms 5 and 7 as unknown or
    insecure after the start of 2022, or earlier if SHA-1 becomes
    significantly weaker before then.

Obsoleting really takes time. And the path is to first stop producing
SHA1 signatures, and once that number goes down, to start discouraging
consuming SHA1 signatures. If you immediately say MUST NOT for validating,
you are making 2211449 + 287467 = 2.5M domains more insecure. That would
be very irresponsible, and serve no real purpose. Saying "start of 2022"
might be okay, but might not be okay. We don't know yet. That is why RFC
8624 does not put in specific dates. We need to push the market, but
not demand unrealistic speeds. If we do that, people will simply start
ignoring the RFC recommendations.

The document spells out a big doom day scenario, and then in section
5.4.1 admits that, oh btw, if you don't share private keys with other
zones, then you don't really have an issue. Note that the parties
sharing private keys for different domains are the large scale DNS
hosters, who already have no reason to still be on SHA-1.

RFC 8624 says NOT RECOMMENDED for producing SHA1 signatures. It says
MUST for consuming SHA1 signatures. It does so for good reasons. While
we could update the document to change signing from NOT RECOMMENDED
(which is really SHOULD NOT) to MUST NOT, it is a pretty light change. I
am not sure if it is worth updating RFC 8624 for, but numbers are cheap
so we could just do it.

But what really needs to happen is that we need to reduce the number of
SHA1 signatures present. We could push the signing software vendors to
refuse generating new DNSKEY's KSK's that use SHA1. This might delay a
KSK rollover unexpectedly, but it won't cause any outages or regressions
to insecure zones. And that process already mostly involves a human
interaction for an updated DS anyway. Slowing that down won't really
do any harm. It would give those using SHA1 a nudge to look at doing an
algorithm rollover for their new KSK instead. Similarly, we could nudge
TLDs to stop accepting SHA1 based DS records, or for those TLDs that
generate their own DS records, push them to no longer publish SHA1
based DS records.

Which brings me to my second point, upgrading. Moving away from SHA1
involves an algorithm rollover. A lot of currently deployed signers run
on software that is a few years old. For instance a few year old bind or
opendnssec does not even support an algorithm rollover. I believe the
main reason we still see so muc SHA1, is that people and their software
are not ready to do an algorithm rollover. And if they are not ready,
publishing a new RFC that mandates such a change will just be ignored.
We need to work on our tools and documentation to give confidence to
people that an algorithm rollover is easy

And speaking for myself now (and not Ondrey), I'm a strong opponent
of DNS "flag days", such as proposed in this draft by specifying a
die date. Software updates take time and there will never be a single
day where suddenly we live in a new world. Instead of marketing a
threat to users, we should improve the tools so people are more or less
automatically algorithm rolled to a new world without threats.

Paul

---

From: Tony Finch <[email-masked]>
Date: Tue, 10 Mar 2020 01:46:37 +0000

Paul Hoffman <[email-masked]> wrote:
>
> This draft is about discouraging people from signing with SHA-1 by
> directly harming them (implementations that will no longer be able to
> validate their signatures). While threats of direct harm are probably
> effective at getting to a desired outcome, they do not represent the way
> the IETF normally does its work. (I'm happy about that.)

I tried to address this in the security considerations section. The
aim is to avoid harm, specifically the harm of having to suddenly and
surprisingly disable SHA-1 validation via a mass CVE and security patch
when a collision attack improvement comes along that makes it dangerously
misleading to stick an AD bit on an answer from a SHA-1 zone. Which is why
the timetable aims to stop the use of SHA-1 for signing before it stops
the use of SHA-1 for validating, assuming optimistically that we actually
have 2 years available. (I fear we don't.)

WRT updating RFC 8624, my hope is that updated implementation requirements
will encourage better tools to make it easier to upgrade from SHA-1 before
SHA-1 becomes useless. My initial suggestions are probably ham-fisted, but
for software that is on an annual cycle of feature releases there isn't
time for a multi-stage deprecation. I don't think there's any point
addressing a draft to operators if the tooling still encourages the use of
SHA-1.

This problem should have been dealt with years ago, and now it needs to be
treated as an emergency.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
fight poverty, oppression, hunger, ignorance, disease, and aggression

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Mar 2020 13:10:15 +1100

> On 10 Mar 2020, at 12:42, Paul Wouters <[email-masked]> wrote:
> 

A so called "algorithm roll" is introduce a new algorithm and remove
a old algorithm with timing such that the zone is always treated as
secure for resolvers that support both algorithms.

BIND has supported introducing new algorithms from the word dot.
BIND has supported removing old algorithms from the word dot.

I fail to see how BIND or any other DNSSEC implementation can’t do
a “algorithm roll”.

If we stop talking about “algorithm roll” and start saying “introduce
a new algorithm and when that is complete remove the old algorithm”
people wouldn’t be scared.

> automatically algorithm rolled to a new world without threats.

Automatic is hard if not impossible.

> Paul
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Tony Finch <[email-masked]>
Date: Tue, 10 Mar 2020 02:15:52 +0000

> ignoring the RFC recommendations.

Right. I don't think we're pushing hard enough, so I'm trying to get
suggestions for how we can do better.

> zones, then you don't really have an issue.

There are several other dangerous situations. If you have shared hosting
within a zone, you have an issue. If you are a large enterprise you have a
privilege escalation issue. If you are a TLD with weak DS syntax checks,
you have an issue. (I spelled out a privilege escalation attack in more
detail in https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html)

> generate their own DS records, push them to no longer publish SHA1

Those are good ideas, thanks. WRT DS records, are you talking about
DNSKEY algorithm types or DS digest types? I'm not so worried about digest
type 1 because DS digests need to be secure against preimage attacks and
SHA-1 is still OK in that respect. (And digest types are easier to
upgrade.)

> people that an algorithm rollover is easy

Well, we had better get on with that quickly then. I think BIND is not as
bad as you say: my colleagues have done an algorithm rollover with 9.10
which is over 5 years old.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shetland Isles: South or southeast 5 or 6, veering west or southwest 5 to 7,
occasionally gale 8 later. Moderate at first in sheltered east, otherwise
rough or very rough. Occasional rain, squally showers later. Good occasionally
poor.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Mar 2020 02:17:58 +0000

On Mar 9, 2020, at 6:46 PM, Tony Finch <[email-masked]> wrote:
> misleading to stick an AD bit on an answer from a SHA-1 zone.

This confuses a harm purposely caused by authorities (in this case, the IETF), with self-harm (in this case, a zone owner who didn't hear about the importance of doing an algorithm rollover, or did hear but didn't care).  They are quite different.

> Which is why

Who is "we" there? Those of us who have seen the warnings now have all the time in the world to heed them, to plan to heed them Real Soon Now, or to prioritize other parts of our lives above this possible harm to us. It is only the people who have not heard whom have time issues before the attacks get easier.

> addressing a draft to operators if the tooling still encourages the use of

Then consider writing a draft that strongly discourages implementations from encouraging or even being neutral about algorithms with SHA-1. That's much easier to justify than "we want to hurt people who are currently signing with DNSSEC".

> This problem should have been dealt with years ago, and now it needs to be

Dealing with an emergency by purposely harming the people who didn't follow your earlier advice is an option, but not one that many of us would endorse. 

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Tue, 10 Mar 2020 02:24:49 +0000

> > Which is why the timetable aims to stop the use of SHA-1 for signing
> > before it stops the use of SHA-1 for validating, assuming
> > optimistically that we actually have 2 years available. (I fear we
> > don't.)
>
> Who is "we" there?

Mainly, people who don't want DNSSEC to be open to criticism for using
broken cryptography.

> > WRT updating RFC 8624, my hope is that updated implementation
> > requirements will encourage better tools to make it easier to upgrade
> > from SHA-1 before SHA-1 becomes useless. My initial suggestions are
> > probably ham-fisted, but for software that is on an annual cycle of
> > feature releases there isn't time for a multi-stage deprecation. I
> > don't think there's any point addressing a draft to operators if the
> > tooling still encourages the use of SHA-1.
>
> Then consider writing a draft that strongly discourages implementations
> from encouraging or even being neutral about algorithms with SHA-1.

That's what I tried to do.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall, Malin, Hebrides, Bailey: Cyclonic at first in north Bailey, otherwise
westerly or southwesterly 6 to gale 8. Very rough, occasionally high except in
Malin. Rain then squally showers. Moderate or good, occasionally poor.

---

From: Tony Finch <[email-masked]>
Date: Tue, 10 Mar 2020 02:40:54 +0000

Paul Hoffman <[email-masked]> wrote:

> This confuses a harm purposely caused by authorities (in this case, the
> IETF), with self-harm (in this case, a zone owner who didn't hear about
> the importance of doing an algorithm rollover, or did hear but didn't
> care).  They are quite different.

Also I think you have misunderstood an important point: the aim of my
draft is to disable validation for SHA-1 after it is no longer used for
signing. The first guess at a strategy might be a mess, but that's OK
because this is just a draft. So please stop accusing me of trying to hurt
people. It's extremely rude, especially when you repeat the accusation
after I told you I am trying to avoid it.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Northeasterly 4 or 5 in southeast, otherwise variable 3 or 4.
Moderate or rough. Fair. Good.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Mar 2020 22:10:10 +0000

On Mar 9, 2020, at 7:40 PM, Tony Finch <[email-masked]> wrote:
> signing.

Ah! I certainly missed that.

If we can determine when something in the realm of "almost all" DNSEC signing with algorithms that use SHA-1 is done, then it is reasonable for the WG to propose that software that validates DNSSEC can stop doing so.

>  The first guess at a strategy might be a mess, but that's OK

Our messages crossed in the mailing list processing, so I apologize for the repetition. 

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Tue, 10 Mar 2020 18:14:19 -0400

> If we can determine when something in the realm of "almost all" DNSEC signing with algorithms that use SHA-1 is done, then it is reasonable for the WG to propose that software that validates DNSSEC…

Which is quite different from the what this draft is trying to do now by setting an arbitrary deadline. That deadline _can_ be damaging.

Paul W

---

From: "John Levine" <[email-masked]>
Date: 11 Mar 2020 19:31:04 -0400

In article <[email-masked]> you write:
>If we can determine when something in the realm of "almost all" DNSEC signing with algorithms that use SHA-1 is
>done, then it is reasonable for the WG to propose that software that validates DNSSEC can stop doing so.

FWIW, the 2007 DKIM spec said that RSA keys SHOULD be at least 1024
bits but allowed 512 bits as what we intended as a short transition.
In fact, vast amounts of mail continued to have 512 bit signatures and
ignored all the pleas and warnings until 2012 when Google told the
world that they'd stop validating 512 bit signatures.  At that point
in about a week, everyone fixed their signers to use 1024.

The people who run DNS servers and the ones who run mail servers are often
not the same, but I don't see any reason to think DNS operators are any
less lazy.

What this tells me is that the IETF cannot make credible threats of
this kind, so don't try.  People will stop signing with SHA-1 when
large DNSSEC consumers stop accepting it.  Comcast, perhaps.
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly