Subject: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-multi-provider-dnssec-04: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 08 Apr 2020 22:09:47 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnsop-multi-provider-dnssec-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-multi-provider-dnssec/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this document; it's pretty clear and it's good to have these
procedures written down in a well-thought-out manner.

Section 3

   o  It may also be the case that a resolver is unable to provide an
      authenticated response because it gave up after a certain number
      of retries or a certain amount of delay.  Or that downstream
      clients of the resolver that originated the query timed out
      waiting for a response.

nit: sentence fragment.

Section 5

   Since authenticated denial responses are self-contained, NSEC and
   NSEC3 can be used by different providers to serve the same zone.
   Doing so however defeats the protection against zone enumeration
   provided by NSEC3.  A better configuration involves multiple

It might be worth a few more words about why this defeats the protection
against zone enumeration.

Section 6.1, 6.2

Should we say anything about when it's safe for a new ZSK to be used to
sign responses?

Section 8

nit: s/CDNS/CDS/

Also, this section feels a bit sparse compared to 6.1 and 6.2.

Section 9

   In model 2, once initially bootstrapped with each others zone signing
   keys via these API mechanisms, providers could, if desired,
   periodically query each others DNSKEY RRsets and automatically import
   or withdraw ZSKs in the keyset as key rollover events happen.

What kind of authentication would be needed for this
provider-to-provider API access?

Section 10

Shouldn't we have references for DoT and DoH?

Section 12

I think both import and export need to be strongly authenticated, though
the DNSSEC itself can provide for authentication of export in most
(all?) cases.  If (e.g.) the zone owner fetches bad data and then
strongly authenticates to shove that bad data into the other services,
you still end up with bad data in use.
(Also, integrity protection, though I expect this is implicit.)

This is the sort of operation that I'd want to have multi-factor
authentication for, too.

Section 14.1

RFCs 2136, 5731 don't currently seem to be cited in a manner that
requires a normative reference.

---

From: Shumon Huque <[email-masked]>
Date: Thu, 9 Apr 2020 11:44:30 -0400

> procedures written down in a well-thought-out manner.

Thank you for your review Ben.

Section 3
>       clients of the resolver that originated the query timed out

Ok, will fix.

> against zone enumeration.

Sure (the short summary is that the adversary can just trivially enumerate
the zone by querying the provider that employs NSEC). Will add some text.

Section 6.1, 6.2
> Should we say anything about when it's safe for a new ZSK to be used to

I think we were largely leaving these timing details to other documents
like RFC 6781, which we assume readers will be familiar with.

But since we describe pre-publish ZSK rollovers in some detail, we can
probably say something. Per 6781, you need to wait (1) propagation delay
of the ZSK update to all authoritative servers, plus (2) the TTL of the
DNSKEY
RRset. The only aspect that _may_ need to be highlighted, is that for multi
provider, propagation delay now includes the time to propagate to authority
servers of _all_ the providers (which now necessarily includes the
associated
ZSK import operations).

Section 8
> nit: s/CDNS/CDS/

Yup, thanks for catching that. There's actually an additional typo there.
So, we need to
replace "CDNS/DNSKEY" with "CDS/CDNSKEY".

Okay, let me ponder what might be useful to elaborate on here ..

Section 9
> provider-to-provider API access?

Post bootstrapping (i.e. after the providers were already deployed in a
multi-signer configuration), I don't think there any new authentication
mechanisms needed, since the DNSKEY RRset is already signed and
can be verified by anyone to confirm updated ZSK elements. So, they
could securely discover this using the DNS protocol (rather than vendor
proprietary APIs).

Section 10
> Shouldn't we have references for DoT and DoH?

Hmm, okay. This was almost a parenthetical comment about a possible
future state of the DNS ecosystem, so it didn't immediately occur to me
add references. But sure, we can add them.

Section 12

> (Also, integrity protection, though I expect this is implicit.)

Yes, DNSSEC could be used in many cases, post bootstrapping. But I
expect the zone owner will be using provider API for both export and
import. These are almost always REST/HTTPS so they are strongly
authenticated, and yes integrity protected (and confidentiality protected).
So maybe the easiest thing to do is to mention "import and export" here.

If using DNS UPDATE, then that is typically strongly authenticated
(e.g. TSIG with HMAC-SHA256 etc) and integrity protected (but not
confidentiality protected, unless using DNS over TLS, which isn't yet
common for UPDATE).

> authentication for, too.

I can see some more security conscious enterprises doing that, yes.
We can mention that.

Section 14.1
> requires a normative reference.

Yes, ok. I will promote those references.

Thanks!
Shumon Huque

---

From: Brian Dickson <[email-masked]>
Date: Thu, 9 Apr 2020 12:47:50 -0700

> Should we say anything about when it's safe for a new ZSK to be used to

I think, technically speaking, it is always safe to use a new ZSK, and the
only concern is when it's safe to remove and/or revoke the old ZSK (i.e.
that it is safe to use ONLY the new ZSK.)

Brian

---

From: Shumon Huque <[email-masked]>
Date: Thu, 9 Apr 2020 16:34:19 -0400

> that it is safe to use ONLY the new ZSK.)

Hi Brian,

Your statement is true for double signature ZSK rolls (which are less
common).

In the pre-publish ZSK rollover scheme (much more common), the new ZSK
starts signing new or modified data in the zone _exclusively_, and the
corresponding old ZSK signatures are yanked out, after "propagation time +
DNSKEY TTL time" has transpired. So if you do this too early, data in your
zone could become unvalidatable.

This is described in RFC6781, although the description is a quite dated --
since it talks about monolithic re-signing of zone data, and does not
contemplate incremental signing, which is becoming far more common these
days.

Shumon.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 9 Apr 2020 15:10:10 -0700

Hi Shumon,

> the zone by querying the provider that employs NSEC). Will add some text.

Oh!  I was misreading this sentence -- I thought that the loss of
protection was due to mixing NSEC and NSEC3 and some sort of cross-protocol
interaction, but of course this is just the inherent property of any use of
NSEC.  So maybe s/Doing so/Any use of NSEC/?

> So maybe the easiest thing to do is to mention "import and export" here.

That was my first thought, yes.

Thanks!

> Yes, ok. I will promote those references.

Thanks for the updates (and the follow-up discussion on ZSK-use timing that
I trust will resolve satisfactorily).

-Ben

---

From: Shumon Huque <[email-masked]>
Date: Fri, 10 Apr 2020 09:38:27 -0400

> NSEC.  So maybe s/Doing so/Any use of NSEC/?

Yup, that's correct. And your rewording makes it clearer. Will update.

> > Yes, ok. I will promote those references.

It seems it's my turn to misread. I see now that those are currently already
normative references, and the suggested action is to demote those to
informative.

The reason we had made those normative, is that UPDATE and EPP are
feasible key management APIs for these models, although I know of no
managed DNS provider that currently offers those options. So perhaps
your suggestion is fine.

Shumon.