Multi-Signer DNSSEC Models
draft-ietf-dnsop-multi-provider-dnssec-05

[Ballot comment]
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).

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

[Ballot comment]
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/

[Ballot comment]
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

[Ballot comment]
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.
---

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-dnsop-multi-provider-dnssec-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior Services Specialist

The following Last Call announcement was sent out (ends 2020-03-31):

From: The IESG
To: IETF-Announce
CC: dnsop@ietf.org, dnsop-chairs@ietf.org, benno@NLnetLabs.nl, draft-ietf-dnsop-multi-provider-dnssec@ietf.org, Benno Overeinder , warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Multi Signer DNSSEC models) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Multi Signer DNSSEC models'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-03-31. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-multi-provider-dnssec/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-multi-provider-dnssec/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

Document Shepherd: Benno Overeinder
Area Director: Warren Kumari

Document Type: Informational

The draft documents operational models for deploying DNSSEC signed
zones across multiple DNS providers to distribute their authoritative
DNS service.  It presents challenges depending on the configuration
and feature set in use, and presents several deployment models that
may be suitable.

Informational status is appropriate for the document.  It outlines
possible deployment models and with these also the operational
considerations.  The document status is correctly indicated in the
title page header.


2. Review and Consensus

The document has been reviewed and discussed on the DNSOP mailing list
and during DNSOP workgroup meetings.  Contributions were done by a
relative small number of interested folks, feedback by the WG was
promptly integrated in the document.  No points of difficulty or
controversy appeared and consensus was quick.  There has been good
consensus during the WGLC period.

External parties (DNS zone owners and DNS providers) have architected
the DNSSEC multi-provider model in their operations and use it in
their daily job (e.g., see DNSOP mailing list, email thread “[DNSOP]
Working Group Last Call for draft-ietf-dnsop-multi-provider-dnssec”.)

The security section mentions the need for strong authentication to
protect DNSSEC key material, but although the usefulness of the
warning, this is beyond the scope of the document.

The document shepherd has no specific concerns or issues with the
document or with the WG process.  The shepherd stands behind the
document and thinks the document is ready for publication.


3. Intellectual Property

There is no IPR related material in the document.


4. Other Points

!Nits reports:

** The document seems to lack both a reference to RFC 2119 and the
    recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
    keywords.

    RFC 2119 keyword, line 248: '...  It is RECOMMENDED that the provider...'

We can address this during the final version of the document and ask
the authors how strongly they are attached to the term RECOMMENDED,
while all other text does not use RFC 2119 keywords.

IANA Considerations: N/A

There is no IPR related material in the document.

References are checked and all normative references are in a clear
state.

The publication of the document does *not* change the status of any
existing RFC.

1. Summary

Document Shepherd: Benno Overeinder
Area Director: Warren Kumari

Document Type: Informational

The draft documents operational models for deploying DNSSEC signed
zones across multiple DNS providers to distribute their authoritative
DNS service.  It presents challenges depending on the configuration
and feature set in use, and presents several deployment models that
may be suitable.

Informational status is appropriate for the document.  It outlines
possible deployment models and with these also the operational
considerations.  The document status is correctly indicated in the
title page header.


2. Review and Consensus

The document has been reviewed and discussed on the DNSOP mailing list
and during DNSOP workgroup meetings.  Contributions were done by a
relative small number of interested folks, feedback by the WG was
promptly integrated in the document.  No points of difficulty or
controversy appeared and consensus was quick.  There has been good
consensus during the WGLC period.

External parties (DNS zone owners and DNS providers) have architected
the DNSSEC multi-provider model in their operations and use it in
their daily job (e.g., see DNSOP mailing list, email thread “[DNSOP]
Working Group Last Call for draft-ietf-dnsop-multi-provider-dnssec”.)

The security section mentions the need for strong authentication to
protect DNSSEC key material, but although the usefulness of the
warning, this is beyond the scope of the document.

The document shepherd has no specific concerns or issues with the
document or with the WG process.  The shepherd stands behind the
document and thinks the document is ready for publication.


3. Intellectual Property

There is no IPR related material in the document.


4. Other Points

!Nits reports:

** The document seems to lack both a reference to RFC 2119 and the
    recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
    keywords.

    RFC 2119 keyword, line 248: '...  It is RECOMMENDED that the provider...'

We can address this during the final version of the document and ask
the authors how strongly they are attached to the term RECOMMENDED,
while all other text does not use RFC 2119 keywords.

IANA Considerations: N/A

There is no IPR related material in the document.

References are checked and all normative references are in a clear
state.

The publication of the document does *not* change the status of any
existing RFC.