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

[Benjamin Kaduk via Datatracker <[e-mail]>]

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.