Subject: [DNSOP] Would you please review our draft on deploying new DNSSEC crypto algorithms?

From: Dan York <[email-masked]>
Date: Tue, 15 Nov 2016 12:41:01 +0000

As mentioned at the very end of DNSOP, Olafur Gudmundsson, Ondrej Sury, Paul Wouters and I have a draft published that aims to document the steps involved with deploying a new cryptographic algorithm for DNSSEC. The overall goal is to make it easier to get new DNSSEC crypto algorithms deployed, both through documenting existing steps - and then potentially building off of this  work with new documents to improve some of the steps.  Right now we'd like to get ECDSA out, but EdDSA is coming out soon and it would be great to get that deployed sooner rather than later.

As I said in the session, we'd like to get reviewers and then get the document adopted by the WG and moved along toward publication.

The draft is at either of:

https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-crypto-algs/
https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-04

Please send any comments to the list or to us as authors.

I also am maintaining this over in Github at: https://github.com/danyork/draft-deploying-dnssec-crypto-algs  If you are a Github user you are welcome to file an issue there or send text in a pull request.

Regardless, we'd just like any feedback (even if to say that it looks good).

Thanks,
Dan

--
Dan York
Senior Content Strategist, Internet Society
[email-masked]<mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked]<mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/

---

From: Shane Kerr <[email-masked]>
Date: Wed, 16 Nov 2016 00:05:30 +0900

Dan,

At 2016-11-15 12:41:01 +0000
Dan York <[email-masked]> wrote: 
> I also am maintaining this over in Github at:
> https://github.com/danyork/draft-deploying-dnssec-crypto-algs  If you
> are a Github user you are welcome to file an issue there or send text
> in a pull request.
> 

I'm curious about this section:

   Note that the key and signatures with the new algorithm will need to
   co-exist with the existing key and signatures for some period of
   time.  This will have an impact on the size of the DNS records.

   [NOTE(OS): Shouldn't we just update the language that requires the
   resolver to be so strict and finally be done with this requirement?
   Or just give a recommendation in the paragraph on resolver here?]

   One issue that has been identified is that not all commonly-used
   signing software releases include support for an algorithm rollover.
   This software would need to be updated to support rolling an
   algorithm before any new algorithms could be deployed.

Is there an RFC which says that you have to have multiple signatures?
In principle, shouldn't it be possible to (for example) add a new
DNSKEY record of a ZSK with a new algorithm, wait until you are sure
that all resolvers have the new DNSKEY, and then start signing using
only that key (as for a usual roll)?

So there would indeed need to be two copies of the key, but not double
signature, right?

I'm not sure if this is ever possible to do for a KSK roll, but honestly
that doesn't matter too much since extra signatures on the DNSKEY
RRSET is not going to affect much traffic in a usual case.

----

A possibly more important concern is that the RIPE NCC did an algorithm
roll last year, and discovered that Unbound and Verisign DNS require
that the algorithm used by the DS be used to sign the entire zone - not
just the DNSKEY RRSET:

https://labs.ripe.net/Members/anandb/dnssec-algorithm-roll-over

I think this deserves special merit and probably mention in the draft,
because it means that you have to do both the KSK and ZSK roll
together. The root cause of this is probably considered a bug in the
Unbound and Verisign DNS software and has been fixed... but also
consider that Unbound is a fairly popular DNS software and likely to
have lots of old versions lying around. That means basically that
unless you don't care about breaking a large portion of the Internet we
are stuck with this limitation. :(

Of course, rolling to a brand new algorithm (post-2015) that arrives in
the future should be fine, since it will only be implemented in newer
versions of the software which support rolling properly. :)

----

Finally, mostly as a whine, it's a pity that RFC 6975 forbids
authoritative servers from filtering RRSIG. From a client point of view
this would have been a real motivator to including this information,
since an authoritative server could provide the best signatures
possible (smallest/fastest/most secure/patent-free/whatever), and ONLY
those signatures.

As it is now, I doubt many (any?) resolvers actually include this
option since it will just add pointless bytes to query packets. If
clients included this it would be of great help to zone owners and
authority server operators in deciding whether a new algorithm is
deployable. :(

Cheers,

--
Shane

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Nov 2016 08:39:37 +1100

In message <[email-masked]>, Shane Kerr writes:
> > https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-cryptoalgs/

You either have double signature (new alg + old alg) or you go
insecure.  Adminstrators choice.  Remember that you have to have
the new signatures and DNSKEYs in place before the DS is published
for the new algorithm and you need to keep the old signatures and
DNSKEYs in place after the DS for the old algorithm is removed.

> that the algorithm used by the DS be used to sign the entire zone - not

That was always required.

> versions of the software which support rolling properly. :)

I'm not worried about old versions with broken validators.  Let
them break.  When the few reports come in tell them to upgrade to
a current version.  To work with those old, non RFC compliant,
versions you have to publish RRSIGs before you publish DNSKEYs and
ISC is not going to hack named to support such behaviour.

They don't interoperate and should have CVEs listed against those
versions.

> possible (smallest/fastest/most secure/patent-free/whatever), and ONLY

There are good reasons not to filter RRSIGs.  If validators want
to only use alg A when alg A and alg B are present in the DS records
they are free to write a validator that supports that.

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

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 24 Nov 2016 10:05:54 +0100

Dan,

I read your draft and I have a concern. The document makes a lot of 
observations about the current state of DNSSEC implementation, so I am 
afraid that this publication gets outdated quickly.

So I do think it's a good idea to highlight which pieces in the DNS 
infrastructure needs attention when deploying a new DNSSEC algorithm, I 
doubt that current limitations must be mentioned.

I am also not sure if the IETF is the appropriate place for this 
document, or that it would feel more at home within the RIPE/NANOG/... 
community.

Some more comments about the text:

In section 2.1.1 there is a note on an in 2016 standards non-compliant 
resolver. Having RFCs (to be) note that other RFCs are not safe to 
assume its implemented is a bit ridiculous to me. It is a given that 
there are bugs, and thus it can be said of any RFC that it is not safe 
to assume it is implemented correctly. I suggest to drop the paragraphs 
starting from "Note that at least one in 2016 case..."

In section 2.2 it says authoritative servers should be able to serve new 
crypto algorithms with no adjustment to the code, except for NSEC/NSEC3 
responses. If it's signing algorithms you are talking about, these 
should also be agnostic right? If it's the hashing algorithm you are 
talking about, then the "NSEC" mentioning should be removed. In other 
words, this paragraph needs clarification.

In section 2.3 there is an identified issue that not all signing 
software supports algorithm rollover. This is an observation that can 
quickly go out to date and I suggest removing it.

Best regards,
   Matthijs

On 15-11-16 13:41, Dan York wrote:
> As mentioned at the very end of DNSOP, Olafur Gudmundsson, Ondrej Sury,
> Paul Wouters and I have a draft published that aims to document the
> steps involved with deploying a new cryptographic algorithm for DNSSEC.
> The overall goal is to make it easier to get new DNSSEC crypto
> algorithms deployed, both through documenting existing steps - and then
> potentially building off of this  work with new documents to improve
> some of the steps.  Right now we'd like to get ECDSA out, but EdDSA is
> coming out soon and it would be great to get that deployed sooner rather
> than later.
>
> As I said in the session, we'd like to get reviewers and then get the
> document adopted by the WG and moved along toward publication.
>
> I also am maintaining this over in Github
> at: https://github.com/danyork/draft-deploying-dnssec-crypto-algs  If
> you are a Github user you are welcome to file an issue there or send
> text in a pull request.
>
> [email-masked] <mailto:[email-masked]>   +1-802-735-1624
> Jabber: [email-masked] <mailto:[email-masked]>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Thu, 24 Nov 2016 01:50:05 -0800

> On Nov 24, 2016, at 01:05, Matthijs Mekking <[email-masked]> wrote:
> 
> In section 2.1.1 there is a note on an in 2016 standards non-compliant resolver. Having RFCs (to be) note that other RFCs are not safe to assume its implemented is a bit ridiculous to me. It is a given that there are bugs, and thus it can be said of any RFC that it is not safe to assume it is implemented correctly. I suggest to drop the paragraphs starting from "Note that at least one in 2016 case..."

The title is "Observations on ..." so practical experiences with what might happen seem relevant.

If you look at it from the perspective of someone implementing a resolver then it provides an example of what not to do (I think). :-)

Ask

---

From: Shane Kerr <[email-masked]>
Date: Fri, 25 Nov 2016 11:58:23 +0800

Mark,

At 2016-11-16 08:39:37 +1100

> DNSKEYs in place after the DS for the old algorithm is removed.

Sorry for being stupid and ignorant here, but again, is there an RFC
which says you need multiple signatures?

I understand that you need multiple signatures on the DNSKEY RRset
itself, but surely you don't actually need to sign the whole zone with
multiple signatures? Once I am sure that every validator has the DNSKEY
RRset with the old and the new DNSKEY ZSK, then I should be able to
choose either ZSK and use that to sign, right? Why is this different in
an algorithm roll versus a normal roll?

> That was always required.

Sorry, I'm confused. So the algorithm used by the DS has to sign the
whole zone? Does that mean that Unbound and Verisign DNS had correct
behavior and it is now broken? Does that mean that BIND is broken? 

So confused...
 
> ISC is not going to hack named to support such behaviour.

Mark, I certainly encourage you to not worry about broken resolvers in
your own systems. I don't for my own vanity domains.

But surely you can see how this might not be acceptable to other
people, right? Surely? Like people may actually have reasons why they
want to make sure their sites are available to as many people as
possible? Surely?

> they are free to write a validator that supports that.

Again, I am confused.

If a validator says "I only support algorithm A", then what reason is
there to send it signatures for algorithm B?

I can't think of a good reason not to filter RRSIGs, although I fully
admit that my imagination may just not be up to the task.

Cheers,

--
Shane

---

From: Mark Andrews <[email-masked]>
Date: Fri, 25 Nov 2016 15:45:08 +1100

In message <[email-masked]>, Shane Ker
> which says you need multiple signatures?

Yes.  RFC4035 and RFC6840.  Note the words "entire zone".  You can't
have two algorithm is use without multiple signatures for each RRset
in the zone.

5.11.  Mandatory Algorithm Rules

   The last paragraph of Section 2.2 of [RFC4035] includes rules
   describing which algorithms must be used to sign a zone.  Since these
   rules have been confusing, they are restated using different language
   here:

      The DS RRset and DNSKEY RRset are used to signal which algorithms
      are used to sign a zone.  The presence of an algorithm in either a
      zone's DS or DNSKEY RRset signals that that algorithm is used to
      sign the entire zone.

      A signed zone MUST include a DNSKEY for each algorithm present in
      the zone's DS RRset and expected trust anchors for the zone.  The
      zone MUST also be signed with each algorithm (though not each key)
      present in the DNSKEY RRset.  It is possible to add algorithms at
      the DNSKEY that aren't in the DS record, but not vice versa.  If
      more than one key of the same algorithm is in the DNSKEY RRset, it
      is sufficient to sign each RRset with any subset of these DNSKEYs.
      It is acceptable to sign some RRsets with one subset of keys (or
      key) and other RRsets with a different subset, so long as at least
      one DNSKEY of each algorithm is used to sign each RRset.
      Likewise, if there are DS records for multiple keys of the same
      algorithm, any subset of those may appear in the DNSKEY RRset.

   This requirement applies to servers, not validators.  Validators
   SHOULD accept any single valid path.  They SHOULD NOT insist that all
   algorithms signaled in the DS RRset work, and they MUST NOT insist
   that all algorithms signaled in the DNSKEY RRset work.  A validator
   MAY have a configuration option to perform a signature completeness
   test to support troubleshooting.

> an algorithm roll versus a normal roll?

The aim of the rules are to ensure that if the validator only supports
a single algorithm in the validator that you will have the data
necessary to validate the response if it has cyptographic proof (DS)
that the zone is signed with a algorithm it supports and it has a
chain of trust.

> behavior and it is now broken? Does that mean that BIND is broken?

No.  Unbound and Verisign DNS over stepped the mark.  There is the
supply side and the consumption side.  The rules are for the supply
side only.  RIPE NCC failed to follow the supply side rules.

You can follow all the rules in RFC 4035 and because the DNS is a
loosely coherent system, you can get a DNSKEY RRset and some other
RRset from the same zone (but not instance) where there are not
RRSIGs for one or more of the algorithms in the DNSKEY RRset.  As
a zone in only deemed to be signed by a algorithm when it is listed
in the DS RRset (or published trust anchors) this is not (or should
not have been) a issue.  It was only when Unbound and Verisign DNS
started enforcing supply side rule in the validator that it became
a issue.

> want to make sure their sites are available to as many people as

For how many years should we continue to pander operators using
broken software that has been fixed by the vendor years ago.

Mark

---

From: Shane Kerr <[email-masked]>
Date: Fri, 25 Nov 2016 17:21:40 +0800

Mark,

At 2016-11-25 15:45:08 +1100
>    test to support troubleshooting.

Thanks Mark! That's very clear. :)

> that the zone is signed with a algorithm it supports and it has a

Well, presumably those validators will have to treat the zone as
insecure once you finish the algorithm roll.

But thinking about it more I can see why you need to double-sign to
avoid the zone failing validation for those validators during the roll.

Thanks again for putting up with me. :)
 
> started enforcing supply side rule in the validator that it became

Got it.
 
> broken software that has been fixed by the vendor years ago.

As long as those operators have users that we want to be able to
connect to us.

Probably this will be until DNS moves to JavaScript and we actually
send the code to the resolvers that we want them to run. ;)

> > admit that my imagination may just not be up to the task.

Actually if we added DS and DNSKEY to the filtering rules, then we
could perform an algorithm roll without double-signing. :) (Well,
except that nobody implements RFC 6975...)

Cheers,

--
Shane