Multi-Signer DNSSEC Models
RFC 8901

Note: This ballot was opened for revision 04 and is now closed.

Erik Kline Yes

Comment (2020-04-05 for -04)
No email
send info
{Yes}

Warren Kumari Yes

Comment (2020-03-31 for -04)
In general I try to include some background / context when putting documents up for IESG Eval, but in this case there isn't much that I can say that isn't already covered by the Abstract:
---
   Many enterprises today employ the service of multiple DNS providers
   to distribute their authoritative DNS service.  Deploying DNSSEC in
   such an environment may present some challenges depending on the
   configuration and feature set in use.  In particular, when each DNS
   provider independently signs zone data with their own keys,
   additional key management mechanisms are necessitated.  This document
   presents deployment models that accommodate this scenario and
   describe these key management requirements.  These models do not
   require any changes to the behavior of validating resolvers, nor do
   they impose the new key management requirements on authoritative
   servers not involved in multi signer configurations.
---

Deborah Brungard No Objection

Alissa Cooper No Objection

Roman Danyliw No Objection

Comment (2020-04-08 for -04)
Thank you for responding to the SECDIR review by Daniel Migault (and thanks for doing the review Daniel!)  The proposed clarifications would be helpful.

** Per Section 6.1, “Provider A would generate a new ZSK and communicate their intent to perform a rollover …”, how is that communication done? Just as the Security Considerations already talks about API security, is there an analogous thing to say here in Section 12?

** Section 12.  As key generation is invoked as a step in a number of these procedures, provide a pointer good practices for this step would be helpful, say Section 3.4.4 of RFC6781.

** Editorial Nits:
-- A few places.  Typo. s/Authentiated/ Authenticated/g

-- Section 5.1.  Typo. s/prefered/preferred/

-- Section 5.2. Typo. s/Aggresive/Aggressive/

Benjamin Kaduk No Objection

Comment (2020-04-08 for -04)
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.

Murray Kucherawy No Objection

Comment (2020-03-31 for -04)
Just a bunch of nits here:

Section 3:
Nits:
* "... a certain amount of delay.  Or that downstream ..." -- s/. O/, o/
* "Details of how the DNSKEY RRset itself is validated differs." -- s/differs/differ/

Section 5:
Nits:
* "Authentiated denial of existence ..." -- s/Authentiated/Authenticated/

Section 5.2:
Nits:
* "... different authentiated denial methods ..." -- s/authentiated/authenticated/
* "Resolver software may be however designed ..." -- s/may be however/may, however, be/ (or equivalent)
* "... more optimally than permanent setup ..." -- perhaps "more optimally than a permanent setup"?
* "... for a matching authentiated denial ..." -- s/authentiated/authenticated/

Section 7:
Nits:
* " A Combined Signing Key (CSK), is one ..." -- s/,//
* "i.e." should be "i.e.,"
* "In this case, any or all the providers could employ ..." -- s/all/all of/
* "... of all the other providers" -- s/all/all of/

Section 9:
Nits:
* "... with each others zone signing ..." -- s/others/other's/, and again later in the same sentence

Barry Leiba No Objection

Alvaro Retana No Objection

Éric Vyncke No Objection

Magnus Westerlund No Objection

Robert Wilton No Objection

Comment (2020-04-09 for -04)
My lack of domain knowledge made this document hard for me to understand, but given that this document as aimed at folks deploying DNS servers I don't really see that as a problem.

One note is that the draft does use quite a few acronyms and has no terminology section.  I'm not suggesting adding a terminology section but perhaps in the introduction it would be worth adding a sentence to point readers to  RFC 8499/BCP 219?  This should probably also be listed as an informative dependency (assuming that the terms used are formally defined elsewhere).