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

[Benjamin Kaduk <[e-mail]>]

Hi Shumon,

On Thu, Apr 09, 2020 at 11:44:30AM -0400, Shumon Huque wrote:
> 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.

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

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

That was my first thought, yes.

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

Thanks!

> 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 for the updates (and the follow-up discussion on ZSK-use timing that
I trust will resolve satisfactorily).

-Ben