< draft-ietf-dnsop-multi-provider-dnssec-01.txt   draft-ietf-dnsop-multi-provider-dnssec-02.txt >
Internet Engineering Task Force S. Huque Internet Engineering Task Force S. Huque
Internet-Draft P. Aras Internet-Draft P. Aras
Intended status: Informational Salesforce Intended status: Informational Salesforce
Expires: September 12, 2019 J. Dickinson Expires: January 9, 2020 J. Dickinson
Sinodun Sinodun
J. Vcelak J. Vcelak
NS1 NS1
D. Blacka D. Blacka
Verisign Verisign
March 11, 2019 July 8, 2019
Multi Provider DNSSEC models Multi Signer DNSSEC models
draft-ietf-dnsop-multi-provider-dnssec-01 draft-ietf-dnsop-multi-provider-dnssec-02
Abstract Abstract
Many enterprises today employ the service of multiple DNS providers Many enterprises today employ the service of multiple DNS providers
to distribute their authoritative DNS service. Deploying DNSSEC in to distribute their authoritative DNS service. Deploying DNSSEC in
such an environment may present some challenges depending on the such an environment may present some challenges depending on the
configuration and feature set in use. This document will present configuration and feature set in use. This document will present
several deployment models that may be suitable. several deployment models that may be suitable.
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2
2. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 3 2. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Multiple Signer models . . . . . . . . . . . . . . . . . 3 2.1. Multiple Signer models . . . . . . . . . . . . . . . . . 3
2.1.1. Model 1: Common KSK, Unique ZSK per provider . . . . 4 2.1.1. Model 1: Common KSK, Unique ZSK per provider . . . . 4
2.1.2. Model 2: Unique KSK and ZSK per provider . . . . . . 4 2.1.2. Model 2: Unique KSK and ZSK per provider . . . . . . 4
3. Validating Resolver Behavior . . . . . . . . . . . . . . . . 4 3. Validating Resolver Behavior . . . . . . . . . . . . . . . . 5
4. Signing Algorithm Considerations . . . . . . . . . . . . . . 6 4. Signing Algorithm Considerations . . . . . . . . . . . . . . 6
5. Authenticated Denial Considerations . . . . . . . . . . . . . 6 5. Authenticated Denial Considerations . . . . . . . . . . . . . 6
5.1. Single Method . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Single Method . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Mixing Methods . . . . . . . . . . . . . . . . . . . . . 7 5.2. Mixing Methods . . . . . . . . . . . . . . . . . . . . . 7
6. Key Rollover Considerations . . . . . . . . . . . . . . . . . 7 6. Key Rollover Considerations . . . . . . . . . . . . . . . . . 7
6.1. Model 1: Common KSK, Unique ZSK per provider . . . . . . 8 6.1. Model 1: Common KSK, Unique ZSK per provider . . . . . . 8
6.2. Model 2: Unique KSK and ZSK per provider . . . . . . . . 8 6.2. Model 2: Unique KSK and ZSK per provider . . . . . . . . 8
7. Inter Provider Handoff . . . . . . . . . . . . . . . . . . . 9 7. Use of CDS and CDNSKEY . . . . . . . . . . . . . . . . . . . 9
8. Key Management Mechanism Requirements . . . . . . . . . . . . 9 8. Key Management Mechanism Requirements . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. DNS Response Size Considerations . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 11 13.1. Normative References . . . . . . . . . . . . . . . . . . 11
13.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction and Motivation 1. Introduction and Motivation
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING:
The source for this draft is maintained in GitHub at: The source for this draft is maintained in GitHub at:
https://github.com/shuque/multi-provider-dnssec https://github.com/shuque/multi-provider-dnssec
Many enterprises today employ the service of multiple DNS providers Many enterprises today employ the service of multiple DNS providers
to distribute their authoritative DNS service. This allows the DNS to distribute their authoritative DNS service. This allows the DNS
skipping to change at page 9, line 22 skipping to change at page 9, line 25
has their own ZSK. The ZSK roll for provider A would start with has their own ZSK. The ZSK roll for provider A would start with
them generating new ZSK and including it in their DNSKEY RRset and them generating new ZSK and including it in their DNSKEY RRset and
re-signing the new DNSKEY RRset with their KSK. The new ZSK of re-signing the new DNSKEY RRset with their KSK. The new ZSK of
provider A would then be communicated to the Zone Owner, who will provider A would then be communicated to the Zone Owner, who will
initiate the process of importing this ZSK into the DNSKEY RRsets initiate the process of importing this ZSK into the DNSKEY RRsets
of the other providers, using their respective APIs. Once the of the other providers, using their respective APIs. Once the
necessary Pre-Publish key rollover time periods have elapsed, necessary Pre-Publish key rollover time periods have elapsed,
provider A and the Zone Owner can initiate the process of removing provider A and the Zone Owner can initiate the process of removing
the old ZSK from the DNSKEY RRset of all providers. the old ZSK from the DNSKEY RRset of all providers.
7. Inter Provider Handoff 7. Use of CDS and CDNSKEY
The primary use case for the models presented in this draft are for CDS and CDNSKEY records [RFC7344] [RFC8078] are used to facilitate
steady state operation of multiple concurrent signing providers. But automated updates of DNSSEC secure entry point keys between parent
they can also be leveraged in a fairly straightforward manner to and child zones. Multi-signer DNSSEC configurations can support this
perform non-disruptive transfer of a signed DNS domain from one too. In Model 1, CDS/CDNSKEY changes are centralized at the zone
provider to another. This involves initially bringing the new owner. However, the zone owner will still need to push down updated
provider into a multi-provider configuration, and then at a later signed CDNS/DNSKEY RRsets to the providers via the key management
time detaching the old provider. [TBD: flesh out this use case in mechanism. In Model 2, the key management mechanism needs to support
more detail.] cross importation of the CDS/CDNSKEY records, so that a common view
of the RRset can be constructed at each provider, and is visible to
the parent zone attempting to update the DS RRset.
8. Key Management Mechanism Requirements 8. Key Management Mechanism Requirements
Managed DNS providers often have their own proprietary zone Managed DNS providers often have their own proprietary zone
configuration and data management APIs, typically utilizing HTTPS/ configuration and data management APIs, typically utilizing HTTPS/
REST interfaces. So, rather than outlining a new API for key REST interfaces. So, rather than outlining a new API for key
management here, we describe the specific functions that the provider management here, we describe the specific functions that the provider
API needs to support in order to enable the multi-signer models. The API needs to support in order to enable the multi-signer models. The
Zone owner is expected to use these API functions to perform key Zone owner is expected to use these API functions to perform key
management tasks. Other mechanisms that can offer these functions, management tasks. Other mechanisms that can offer these functions,
if supported by the providers, include the DNS UPDATE protocol if supported by the providers, include the DNS UPDATE protocol
[RFC2136] and EPP [RFC5731]. [RFC2136] and EPP [RFC5731].
o The API must offer a way to query the current DNSKEY RRset of the o The API must offer a way to query the current DNSKEY RRset of the
provider provider
o For model 1, the API must offer a way to import a signed DNSKEY o For model 1, the API must offer a way to import a signed DNSKEY
RRset and replace the current one at the provider. RRset and replace the current one at the provider. Additionally,
if CDS/CDNSKEY is supported, the API must also offer a way to
import a signed CDS/CDNSKEY RRset.
o For model 2, the API must offer a way to import a DNSKEY record o For model 2, the API must offer a way to import a DNSKEY record
from an external provider into the current DNSKEY RRset from an external provider into the current DNSKEY RRset.
Additionally, if CDS/CDNSKEY is supported, the API must offer a
mechanism to import individual CDS/CDNSKEY records from an
external provider.
In model 2, once initially bootstrapped with each others zone signing In model 2, once initially bootstrapped with each others zone signing
keys via these API mechanisms, providers could, if desired, keys via these API mechanisms, providers could, if desired,
periodically query each others DNSKEY RRsets and automatically import periodically query each others DNSKEY RRsets and automatically import
or withdraw ZSKs in the keyset as key rollover events happen. or withdraw ZSKs in the keyset as key rollover events happen.
9. IANA Considerations 9. DNS Response Size Considerations
The Multi-Signer models described in this document result in larger
DNSKEY RRsets, so the DNSKEY response size will be larger. The
actual size depends on multiple factors: DNSKEY algorithm and keysize
choices, the number of providers, how many simultaneous key rollovers
are in progress etc. Newer elliptic curve algorithms produce keys
small enough that the responses will typically be far below the
common Internet path MTU, and thus operational issues related to IP
fragmentation or truncation and TCP fallback are unlikely to be
encountered.
10. IANA Considerations
This document includes no request to IANA. This document includes no request to IANA.
10. Security Considerations 11. Security Considerations
The Zone key import APIs required by these models need to be strongly The Zone key import APIs required by these models need to be strongly
authenticated to prevent tampering of key material by malicious third authenticated to prevent tampering of key material by malicious third
parties. Many providers today offer REST/HTTPS APIs that utilize a parties. Many providers today offer REST/HTTPS APIs that utilize a
number of authentication mechanisms (username/password, API keys number of authentication mechanisms (username/password, API keys
etc). If DNS protocol mechanisms like UPDATE are being used for key etc). If DNS protocol mechanisms like UPDATE are being used for key
insertion and deletion, they should similarly be strongly insertion and deletion, they should similarly be strongly
authenticated, e.g. by employing Transaction Signatures (TSIG) authenticated, e.g. by employing Transaction Signatures (TSIG)
[RFC2845]. [RFC2845].
11. Acknowledgments 12. Acknowledgments
The initial version of this document benefited from discussions with The initial version of this document benefited from discussions with
and review from Duane Wessels. Additional helpful comments were and review from Duane Wessels. Additional helpful comments were
provided by Steve Crocker, Ulrich Wisser, Tony Finch, and Olafur provided by Steve Crocker, Ulrich Wisser, Tony Finch, and Olafur
Gudmundsson. Gudmundsson.
12. References 13. References
12.1. Normative References 13.1. Normative References
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997, RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>. <https://www.rfc-editor.org/info/rfc2136>.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
<https://www.rfc-editor.org/info/rfc2845>. <https://www.rfc-editor.org/info/rfc2845>.
skipping to change at page 11, line 30 skipping to change at page 12, line 5
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Domain Name Mapping", STD 69, RFC 5731, Domain Name Mapping", STD 69, RFC 5731,
DOI 10.17487/RFC5731, August 2009, <https://www.rfc- DOI 10.17487/RFC5731, August 2009, <https://www.rfc-
editor.org/info/rfc5731>. editor.org/info/rfc5731>.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781, Operational Practices, Version 2", RFC 6781,
DOI 10.17487/RFC6781, December 2012, <https://www.rfc- DOI 10.17487/RFC6781, December 2012, <https://www.rfc-
editor.org/info/rfc6781>. editor.org/info/rfc6781>.
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344,
DOI 10.17487/RFC7344, September 2014, <https://www.rfc-
editor.org/info/rfc7344>.
[RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from
the Parent via CDS/CDNSKEY", RFC 8078,
DOI 10.17487/RFC8078, March 2017, <https://www.rfc-
editor.org/info/rfc8078>.
[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
July 2017, <https://www.rfc-editor.org/info/rfc8198>. July 2017, <https://www.rfc-editor.org/info/rfc8198>.
12.2. Informative References 13.2. Informative References
[BLACKLIES] [BLACKLIES]
Valsorda, F. and O. Gudmundsson, "Compact DNSSEC Denial of Valsorda, F. and O. Gudmundsson, "Compact DNSSEC Denial of
Existence or Black Lies", <https://tools.ietf.org/html/ Existence or Black Lies", <https://tools.ietf.org/html/
draft-valsorda-dnsop-black-lies>. draft-valsorda-dnsop-black-lies>.
[BR-ROLLOVER] [BR-ROLLOVER]
Neves, F., ".br DNSSEC Algorithm Rollover Update", Neves, F., ".br DNSSEC Algorithm Rollover Update",
in ICANN 62 DNSSEC Workshop, June 2018, in ICANN 62 DNSSEC Workshop, June 2018,
<https://static.ptbl.co/static/ <https://static.ptbl.co/static/
 End of changes. 18 change blocks. 
30 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/