Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2020-09-18
05 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-08-31
05 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-05-26
05 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-04-20
05 (System) RFC Editor state changed to EDIT
2020-04-20
05 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-04-20
05 (System) Announcement was received by RFC Editor
2020-04-20
05 (System) IANA Action state changed to No IANA Actions from In Progress
2020-04-20
05 (System) IANA Action state changed to In Progress
2020-04-20
05 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed
2020-04-20
05 Cindy Morgan IESG has approved the document
2020-04-20
05 Cindy Morgan Closed "Approve" ballot
2020-04-20
05 Cindy Morgan Ballot approval text was generated
2020-04-19
05 Shumon Huque New version available: draft-ietf-dnsop-multi-provider-dnssec-05.txt
2020-04-19
05 (System) New version accepted (logged-in submitter: Shumon Huque)
2020-04-19
05 Shumon Huque Uploaded new revision
2020-04-09
04 Cindy Morgan IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2020-04-09
04 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-04-09
04 Robert Wilton
[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 …
[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).
2020-04-09
04 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-04-08
04 Benjamin Kaduk
[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

  …
[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.
2020-04-08
04 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2020-04-08
04 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-04-08
04 Roman Danyliw
[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 …
[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/
2020-04-08
04 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-04-08
04 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2020-04-08
04 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-04-08
04 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-04-08
04 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2020-04-05
04 Erik Kline [Ballot comment]
{Yes}
2020-04-05
04 Erik Kline [Ballot Position Update] New position, Yes, has been recorded for Erik Kline
2020-03-31
04 Murray Kucherawy
[Ballot comment]
Just a bunch of nits here:

Section 3:
Nits:
* "... a certain amount of delay.  Or that downstream ..." -- s/. O/, …
[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
2020-03-31
04 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2020-03-31
04 Pete Resnick Request for Last Call review by GENART Completed: Ready. Reviewer: Pete Resnick. Sent review to list.
2020-03-31
04 Amy Vezza Placed on agenda for telechat - 2020-04-09
2020-03-31
04 Warren Kumari
[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 …
[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.
---
2020-03-31
04 Warren Kumari Ballot comment text updated for Warren Kumari
2020-03-31
04 Warren Kumari IESG state changed to IESG Evaluation from Waiting for Writeup
2020-03-31
04 Warren Kumari Ballot has been issued
2020-03-31
04 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2020-03-31
04 Warren Kumari Created "Approve" ballot
2020-03-31
04 Warren Kumari Ballot writeup was changed
2020-03-31
04 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-03-27
04 Daniel Migault Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Daniel Migault. Sent review to list.
2020-03-23
04 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2020-03-23
04 Sabrina Tanamal
(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 …
(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
2020-03-13
04 Jean Mahoney Request for Last Call review by GENART is assigned to Pete Resnick
2020-03-13
04 Jean Mahoney Request for Last Call review by GENART is assigned to Pete Resnick
2020-03-12
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Daniel Migault
2020-03-12
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Daniel Migault
2020-03-11
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Zitao Wang
2020-03-11
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Zitao Wang
2020-03-10
04 Amy Vezza IANA Review state changed to IANA - Review Needed
2020-03-10
04 Amy Vezza
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 …
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.




2020-03-10
04 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2020-03-10
04 Amy Vezza Last call announcement was changed
2020-03-10
04 Warren Kumari Last call was requested
2020-03-10
04 Warren Kumari Last call announcement was generated
2020-03-10
04 Warren Kumari Ballot approval text was generated
2020-03-10
04 Warren Kumari Ballot writeup was generated
2020-03-10
04 Warren Kumari IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2020-03-08
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-03-08
04 Shumon Huque New version available: draft-ietf-dnsop-multi-provider-dnssec-04.txt
2020-03-08
04 (System) New version accepted (logged-in submitter: Shumon Huque)
2020-03-08
04 Shumon Huque Uploaded new revision
2020-01-18
03 Warren Kumari IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested
2020-01-18
03 Warren Kumari Changed consensus to Yes from Unknown
2019-12-24
03 Benno Overeinder
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 …
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.
2019-12-24
03 Benno Overeinder Responsible AD changed to Warren Kumari
2019-12-24
03 Benno Overeinder IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2019-12-24
03 Benno Overeinder IESG state changed to Publication Requested from I-D Exists
2019-12-24
03 Benno Overeinder IESG process started in state Publication Requested
2019-12-24
03 Benno Overeinder
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 …
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.
2019-11-24
03 Tim Wicinski IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2019-10-31
03 Tim Wicinski IETF WG state changed to In WG Last Call from WG Document
2019-09-02
03 Tim Wicinski Notification list changed to Benno Overeinder <benno@NLnetLabs.nl>
2019-09-02
03 Tim Wicinski Document shepherd changed to Benno Overeinder
2019-07-22
03 Shumon Huque New version available: draft-ietf-dnsop-multi-provider-dnssec-03.txt
2019-07-22
03 (System) New version approved
2019-07-22
03 (System) Request for posting confirmation emailed to previous authors: Jan Vcelak , John Dickinson , David Blacka , Shumon Huque , Pallavi Aras
2019-07-22
03 Shumon Huque Uploaded new revision
2019-07-08
02 Shumon Huque New version available: draft-ietf-dnsop-multi-provider-dnssec-02.txt
2019-07-08
02 (System) New version approved
2019-07-08
02 (System) Request for posting confirmation emailed to previous authors: Jan Vcelak , John Dickinson , David Blacka , Shumon Huque , Pallavi Aras
2019-07-08
02 Shumon Huque Uploaded new revision
2019-03-26
01 Tim Wicinski Added to session: IETF-104: dnsop  Tue-1350
2019-03-11
01 Shumon Huque New version available: draft-ietf-dnsop-multi-provider-dnssec-01.txt
2019-03-11
01 (System) New version approved
2019-03-11
01 (System) Request for posting confirmation emailed to previous authors: Jan Vcelak , John Dickinson , David Blacka , Shumon Huque , Pallavi Aras
2019-03-11
01 Shumon Huque Uploaded new revision
2019-01-07
00 Tim Wicinski Intended Status changed to Informational from None
2019-01-07
00 Tim Wicinski This document now replaces draft-huque-dnsop-multi-provider-dnssec instead of None
2019-01-07
00 Pallavi Aras New version available: draft-ietf-dnsop-multi-provider-dnssec-00.txt
2019-01-07
00 (System) WG -00 approved
2019-01-07
00 Pallavi Aras Set submitter to "Pallavi Aras ", replaces to draft-huque-dnsop-multi-provider-dnssec and sent approval email to group chairs: dnsop-chairs@ietf.org
2019-01-07
00 Pallavi Aras Uploaded new revision