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

[Shumon Huque <[e-mail]>]

On Thu, Apr 9, 2020 at 1:09 AM Benjamin Kaduk via Datatracker <
[e-mail]> wrote:

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

Thank you for your review Ben.

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

Ok, will fix.


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

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
> sign responses?
>

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

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

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

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

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

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

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

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

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

Yes, ok. I will promote those references.

Thanks!
Shumon Huque