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

[Mark Andrews <[e-mail]>]

> On 10 Mar 2020, at 12:42, Paul Wouters <[e-mail]> wrote:
> 
> On Mon, 9 Mar 2020, Tony Finch wrote:
> 
>> 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.
> 
> 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

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.

> 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.

Automatic is hard if not impossible.

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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]