Subject: [DNSOP] AD review of draft-ietf-dnsop-multi-provider-dnssec

From: Warren Kumari <[email-masked]>
Date: Sun, 12 Jan 2020 21:23:22 -0500

Hi there,

Firstly, thank you for a well written and easy to understand document.

I have some comments which I think should be addressed before I start
IETF LC, but they are small enough that if you'd much prefer you can
just address them after during / after LC (if changes are needed), or
during IESG review.
Please let me know LOUDLY which you'd prefer.

1: Section 3: 3. Validating Resolver Behavior
I think it would be very useful to mention that this document doesn't
require any changes to the behavior of validating resolvers
themselves. It might also be worth mentioning somewhere that this is
also largely true for authoritative servers - this isn't really a
protocol change, rather an operational / process set of changes.

2: " Zone owners will want to deploy a DNS service that responds as
   efficiently as possible with validatable answers only, and hence it
   is important that the DNSKEY RRset at each provider is maintained
   with the active ZSKs of all participating providers."
This is somewhat ambiguous - it sounds like the zone owner may want to
deploy a service that is only efficient with verifiable answers (and
might be inefficient with bogus ones :-))

3: A question -- "Authenticated Denial Considerations"
Some CDNs and similar do funny things with e.g CNAMEs, or may do
something like generate ACME records or similar. What happens if
provider A creates e.g _acme-challenge.example.com (or www.example.com
IN 600 CNAME some-long-account-number.cdn.net) and doesn't tell
provider B? I understand that the owner names *should* be consistent,
but I think it is worth adding some text here along the lines of "here
be dragons" or similar...

4: The document uses one inceanse of RFC2119 language (RECOMMENDED) -
please either drop this, or add the 2119 / 8174 boilerplate.

Again, I'm willing to start IETF LC, or wait till you've posted a new
version, but please let me know.
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Warren Kumari <[email-masked]>
Date: Sat, 18 Jan 2020 17:57:22 -0500

Checking in again...
W

---

From: Shumon Huque <[email-masked]>
Date: Sat, 18 Jan 2020 20:42:52 -0500

Hi Warren,

Sorry for the delay - I just got back from a vacation, and am catching up
with email.

I will respond to your comments in the next day or two. Thanks for your
patience!

Shumon.

---

From: Warren Kumari <[email-masked]>
Date: Sat, 18 Jan 2020 21:16:57 -0500

On Sat, Jan 18, 2020 at 8:43 PM Shumon Huque <[email-masked]> wrote:
>
> Hi Warren,
>
> Sorry for the delay - I just got back from a vacation, and am catching up with email.
>
> I will respond to your comments in the next day or two. Thanks for your patience!

No worries, I just wanted to make sure y'all had seen this, and that I
hadn't missed something / wasn't causing delay.

W

---

From: Shumon Huque <[email-masked]>
Date: Mon, 20 Jan 2020 15:21:40 -0500

Hi Warren,

Let's just address them now before IETF LC ..

> protocol change, rather an operational / process set of changes.

Okay, we'll mention this.

"largely true for authoritative servers" seems a bit imprecise. We could
probably clarify that although there are no changes to behavior/protocol
for authoritative servers, there is an operational change to how their
DNSKEY/CDS/CDNSKEY record sets are provisioned and managed.

> might be inefficient with bogus ones :-))

Fair enough. I will try to word this better.

> be dragons" or similar...

I'm not sure I see the dragons here - can you elaborate?

It is the zone owner's responsibility to make sure that all data records
(i.e. non DNSSEC metadata) in the zone are created identically on every DNS
provider, so I don't think we would expect this situation to occur. That
includes ACME challenge records.

> please either drop this, or add the 2119 / 8174 boilerplate.

Ok, I'm inclined to lowercase it, since we don't use 2119/8174 keywords
anywhere else in this document.

> version, but please let me know.

Will work on a revision (but please elaborate on 3).

Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Tue, 21 Jan 2020 10:05:56 -0500

Hi Matthijs,

Sorry, I did miss your original note on this point. Now that I've seen it,
I'm copying back [email-masked] to see if there are other comments on your
proposal.

When the Algorithm Considerations section was originally written, I
intentionally did not prohibit the use of multiple algorithms across
providers (even though we recommended against it) for a very
pragmatic reason: I was actually working with 2 DNS providers that
supported disjoint algorithms (one RSASHA256 and the other ECDSAP256), and
was seriously contemplating deploying such a multi-signer configuration in
production. It would be a bit strange to deploy a configuration on the one
hand, and at the same time write a document that explicitly forbid that
configuration.

You mention that authoritative servers cannot simply ignore the rule that
they must sign all RRsets in the zone with every algorithm in the DNSKEY
RRset. However, in practice it is clearly being ignored. Neither .SE or .BR
double signed their zone data during their algorithm rollovers and there
are other cases.

As it turns out, the provider that only supported RSASHA256 exited the
managed DNS provider business, and the only vendors we are working with
currently all support our preferred algorithm (ECDSAP256) in common. Hence,
I am now open to updating the document to prohibit it. But will such text
cause aggravation for other potential deployers that may run into a similar
situation with other providers, and do we care?

This also begs the question: should we (in another document) update RFC
4035, Section 2 (last paragraph) to relax or eliminate the rule, if in fact
it is being ignored?

Frankly, I've always been a bit perplexed by this text, since it has no
accompanying rationale. The only compelling rationale I see is downgrade
protection - to detect that someone hasn't stripped away the signatures of
a stronger algorithm and forced a validator to authenticate only the weaker
signatures. But that implies that validators have a documented procedure to
rank algorithms, which I haven't yet seen. Is a 3072-bit RSASHA256 key
stronger or weaker than an ECDSAP256SHA256 key for example, or Ed25519 vs
ECDSAP256SHA256?

Shumon.

On Tue, Jan 21, 2020 at 3:59 AM Matthijs Mekking <[email-masked]>
wrote:

> Hi Shumon,
>
> On 1/20/20 9:21 PM, Shumon Huque wrote:
> Did you see my mail related to this? If you are going with the lowercase
> approach, please use the word "must" instead of "should".
>
> Best regards,
>
> Matthijs
>
>
> -------- Forwarded Message --------
> Subject: Re: [DNSOP] Working Group Last Call for
> draft-ietf-dnsop-multi-provider-dnssec
> Date: Mon, 13 Jan 2020 09:57:50 +0100
> From: Matthijs Mekking <[email-masked]>
> To: [email-masked]
>
> Late to the party, I am sorry.
>
> I am positive about this document, and support publication. I do have
> one comment on the document, requesting an update.
>
> In section 4 it is said it is RECOMMENDED that providers use a common
> signing algorithm.  I think this is too weak and it must be a MUST.
>
> The reason given for RECOMMENDED is that the "liberal approach" works.
> The liberal approach says that authoritative zones MUST sign RRsets with
> every algorithm in the DNSKEY RRset, but validating resolvers don't have
> to enforce this requirement. However, that does not mean the
> authoritative server can simply ignore this rule.
>
> Also, if two different providers are using different algorithms, that
> means two DS records with different algorithms are distributed to the
> parent. And now the algorithm is signaled in the parent and a validator
> may execute the multiple algorithms protection check, expecting both
> chain of trusts to work.
>
> In other words, please adapt section 4 to be more strict when it comes
> to multiple algorithms. If you agree, I am happy to provide the
> suggested text.
>
> Again my apologies for bringing this up so late.
>
> Best regards,
>
> Matthijs
>

---

From: Steve Crocker <[email-masked]>
Date: Tue, 21 Jan 2020 10:17:11 -0500

Shumon,

You're asking the right questions:

On the face of it, absent a good counter argument, this does indeed seem
like an appropriate time to revise RFC 4035 as you suggest.  Strict
adherence to the rule would require a somewhat awkward multi-step process
for switching from a provider who only supports algorithm x to a provider
that supports -- or at least prefers -- algorithm y.  The transition would
first have to be to a provider that supports both x and y but is willing to
use just x.  After the transition, the new provider would then introduce
algorithm y, and then would eliminate algorithm x.  This seems like an
unnecessary and lengthy sequence.

Thanks,

Steve

On Tue, Jan 21, 2020 at 10:06 AM Shumon Huque <[email-masked]> wrote:

> I'm copying back [email-masked] to see if there are other comments on
> your proposal.
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Frederico A C Neves <[email-masked]>
Date: Tue, 21 Jan 2020 13:31:09 -0300

Hi Shumon,

> double signed their zone data during their algorithm rollovers and there

Actually the algorithm rollover, following the liberal approach, is a
pure double signing process. With TTLs tuned it is during a short
interval but still double signing the zone.

ftp://ftp.registro.br/pub/gts/gts32/01-br-algorithm-rollover.pdf

> 4035, Section 2 (last paragraph) to relax or eliminate the rule, if in fact

I guess 6840 sec 5.11 already clarifies it. 4035 sec 2.2 is talking
about signers.

Fred

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 21 Jan 2020 17:41:46 +0100

Shumon,

On 1/21/20 4:05 PM, Shumon Huque wrote:
> Hi Matthijs,
> 
> Sorry, I did miss your original note on this point. Now that I've seen
> it, I'm copying back [email-masked] <mailto:[email-masked]> to see if
> there are other comments on your proposal.
> 
> supported disjoint algorithms (one RSASHA256 and the other ECDSAP256),
> and was seriously contemplating deploying such a multi-signer
> configuration in production. It would be a bit strange to deploy a
> configuration on the one hand, and at the same time write a document
> that explicitly forbid that configuration.
> 
> You mention that authoritative servers cannot simply ignore the rule
> that they must sign all RRsets in the zone with every algorithm in the
> DNSKEY RRset. However, in practice it is clearly being ignored. Neither
> .SE or .BR double signed their zone data during their algorithm
> rollovers and there are other cases.

If so, then technically they were not conform the RFC, but but I am not
sure how they executed the algorithm rollover precisely. Particularly,
were there ever two DS records in the root zone with different
algorithms for these zones?

>From what I could find, both rollovers did actually sign with double
algorithms though:

See https://static.ptbl.co/static/attachments/179548/1529933472.pdf:

    Aug 20 .br Algorithm Rollover Begin (all times UTC)at 06:00 Zones
    double signed with old and new algorithm

And on this blog
https://www.sidnlabs.nl/en/news-and-blogs/keep-m-rolling-monitoring-ses-dnssec-algorithm-rollover
it looks like .SE was following the RFC 6781 approach.

Please correct me if I am reading this wrong.

> currently all support our preferred algorithm (ECDSAP256) in common.
> Hence, I am now open to updating the document to prohibit it. But will
> such text cause aggravation for other potential deployers that may run
> into a similar situation with other providers, and do we care?
> 
> 4035, Section 2 (last paragraph) to relax or eliminate the rule, if in
> fact it is being ignored?
> 
> protection - to detect that someone hasn't stripped away the signatures
> of a stronger algorithm and forced a validator to authenticate only the
> weaker signatures. But that implies that validators have a documented
> procedure to rank algorithms, which I haven't yet seen. Is a 3072-bit
> RSASHA256 key stronger or weaker than an ECDSAP256SHA256 key for
> example, or Ed25519 vs ECDSAP256SHA256?

Yes, this is exactly the rationale, and it is a valid one. And this is
how unbound works, see
https://nlnetlabs.nl/documentation/unbound/info-algo/ for more information.

Best regards,

Matthijs

> Shumon.
> 
> On Tue, Jan 21, 2020 at 3:59 AM Matthijs Mekking <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hi Shumon,
> 
>     From: Matthijs Mekking <[email-masked]
>     <mailto:[email-masked]>>
>     To: [email-masked] <mailto:[email-masked]>
>

---

From: Tony Finch <[email-masked]>
Date: Tue, 21 Jan 2020 17:03:07 +0000

Matthijs Mekking <[email-masked]> wrote:

> I am not sure how they executed the algorithm rollover precisely.
> Particularly, were there ever two DS records in the root zone with
> different algorithms for these zones?

I can answer that :-)

Algorithm rollovers have to be double-KSK rollovers because DS records
have to have a subset of the algorithms of the DNSKEY records. Having both
algorithms in the DS record can only slow down the rollover so it's hard
to think of situations where it would make sense (other than Shumon's
multi-provider disagreement!)

[ For normal KSK rollovers I think double-DS is slightly better since it
allows smaller DNSKEY RRset sizes, tho it requires more parent zone
updates. ]

--- root.db
+++ root.db
@@ -1,4 +1,4 @@
-.                                            86400 IN SOA      a.root-servers.net. nstld.verisign-grs.com. 2018082001 1800 900 604800 86400
+.                                            86400 IN SOA      a.root-servers.net. nstld.verisign-grs.com. 2018082002 1800 900 604800 86400
 .                                            518400 IN NS      a.root-servers.net.
 .                                            518400 IN NS      b.root-servers.net.
 .                                            518400 IN NS      c.root-servers.net.
@@ -2096,7 +2096,7 @@
 br.                                          172800 IN NS      d.dns.br.
 br.                                          172800 IN NS      e.dns.br.
 br.                                          172800 IN NS      f.dns.br.
-br.                                          86400 IN DS       45673 5 2 14369AD309CC59FD59C1A422BA93B71F2C522BF3672C2E067B2C53F5 3AE522DF
+br.                                          86400 IN DS       2471 13 2 5E4F35998B8F909557FA119C4CBFDCA2D660A26F069EF006B403758A 07D1A2E4
 a.dns.br.                                    172800 IN A       200.160.0.10
 a.dns.br.                                    172800 IN AAAA    2001:12ff::10
 b.dns.br.                                    172800 IN A       200.189.41.10

--- root.db
+++ root.db
@@ -1,4 +1,4 @@
-.                                            86400 IN SOA      a.root-servers.net. nstld.verisign-grs.com. 2017121400 1800 900 604800 86400
+.                                            86400 IN SOA      a.root-servers.net. nstld.verisign-grs.com. 2017121401 1800 900 604800 86400
 .                                            518400 IN NS      a.root-servers.net.
 .                                            518400 IN NS      b.root-servers.net.
 .                                            518400 IN NS      c.root-servers.net.
@@ -11638,6 +11638,7 @@
 ns3.pknic.net.pk.                            172800 IN A       199.192.75.54
 root-s.pknic.pk.                             172800 IN A       119.81.34.90
 pl.                                          172800 IN NS      a-dns.pl.
+pl.                                          172800 IN NS      b-dns.pl.
 pl.                                          172800 IN NS      c-dns.pl.
 pl.                                          172800 IN NS      d-dns.pl.
 pl.                                          172800 IN NS      e-dns.pl.
@@ -11648,6 +11649,8 @@
 pl.                                          86400 IN DS       14075 8 2 4D12B53E0A179C5E51719F606FC429EA03F444CDF5370FBBEEB6ECEB 21E99F2B
 a-dns.pl.                                    172800 IN A       194.181.87.156
 a-dns.pl.                                    172800 IN AAAA    2001:a10:121:1::156
+b-dns.pl.                                    172800 IN A       192.195.72.53
+b-dns.pl.                                    172800 IN AAAA    2001:7f9:c::53
 c-dns.pl.                                    172800 IN A       93.190.128.146
 c-dns.pl.                                    172800 IN AAAA    2a02:38:14::146
 d-dns.pl.                                    172800 IN A       81.15.133.186
@@ -13124,7 +13127,7 @@
 se.                                          172800 IN NS      i.ns.se.
 se.                                          172800 IN NS      j.ns.se.
 se.                                          172800 IN NS      x.ns.se.
-se.                                          86400 IN DS       59747 5 2 44388B3DE9A22CAFA8A12883F60A0F984472D0DFEF0F63ED59A29BE0 18658B28
+se.                                          86400 IN DS       59407 8 2 67A8E06FCEFDD9397F77F26C41ADE4EC142F299BCFA1827F0EF8FD87 F2F63022
 nsa.netnod.se.                               172800 IN A       194.58.192.33
 nsa.netnod.se.                               172800 IN AAAA    2a01:3f1:33::53
 nsp.netnod.se.                               172800 IN A       194.58.198.33

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Cape Wrath to Rattray Head including Orkney: Mainly westerly or southwesterly
3 or 4, occasionally 5 in north. Smooth or slight in east, moderate or rough
in north, occasionally very rough at first in far north. Fair then occasional
rain or drizzle, fog patches developing in north. Moderate or good, becoming
moderate, occasionally very poor in north.

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 21 Jan 2020 18:19:57 +0100

> multi-provider disagreement!)

As I suspected, in that case they were never candidate for the multiple
algorithms check.