< draft-ietf-dnsop-delegation-trust-maintainance-00.txt   draft-ietf-dnsop-delegation-trust-maintainance-01.txt >
dnsop W. Kumari dnsop W. Kumari
Internet-Draft Google Internet-Draft Google
Intended status: Informational O. Gudmundsson Intended status: Informational O. Gudmundsson
Expires: May 17, 2014 Shinkuro Inc. Expires: July 8, 2014 Shinkuro Inc.
G. Barwood G. Barwood
November 13, 2013 January 4, 2014
Automating DNSSEC delegation trust maintenance Automating DNSSEC delegation trust maintenance
draft-ietf-dnsop-delegation-trust-maintainance-00 draft-ietf-dnsop-delegation-trust-maintainance-01
Abstract Abstract
This document describes a method to allow DNS operators to more This document describes a method to allow DNS operators to more
easily update DNSSEC Key Signing Keys using DNS as communication easily update DNSSEC Key Signing Keys using DNS as communication
channel. This document does not address the initial configuration of channel. This document does not address the initial configuration of
trust anchors for a domain. The technique described is aimed at trust anchors for a domain. The technique described is aimed at
delegations in which it is currently hard to move information from delegations in which it is currently hard to move information from
the child to parent. the child to parent.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 May 17, 2014. This Internet-Draft will expire on July 8, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements notation . . . . . . . . . . . . . . . . . . 4 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. DNS delegations . . . . . . . . . . . . . . . . . . . . . 4 2.1. DNS delegations . . . . . . . . . . . . . . . . . . . . . 4
2.2. Relationship between Parent and Child DNS operator . . . 5 2.2. Relationship between Parent and Child DNS operator . . . 5
2.2.1. Solution Space . . . . . . . . . . . . . . . . . . . 6 2.2.1. Solution Space . . . . . . . . . . . . . . . . . . . 6
2.2.2. DNSSEC key change process . . . . . . . . . . . . . . 6 2.2.2. DNSSEC key change process . . . . . . . . . . . . . . 7
3. CDS / CDNSKEY (Child DS/ Child DNSKEY) record definitions . . 7 3. CDS / CDNSKEY (Child DS/ Child DNSKEY) record definitions . . 7
3.1. CDS Resource Record Format . . . . . . . . . . . . . . . 7 3.1. CDS Resource Record Format . . . . . . . . . . . . . . . 7
3.2. CDNSKEY Resource Record Format . . . . . . . . . . . . . 7 3.2. CDNSKEY Resource Record Format . . . . . . . . . . . . . 8
4. Automating DS maintainance with CDS/CDNSKEY records . . . . . 7 4. Automating DS maintainance with CDS/CDNSKEY records . . . . . 8
4.1. CDS / CDNSKEY processing rules . . . . . . . . . . . . . 8 4.1. CDS / CDNSKEY processing rules . . . . . . . . . . . . . 8
5. Child's CDS / CDNSKEY Publication . . . . . . . . . . . . . . 8 5. Child's CDS / CDNSKEY Publication . . . . . . . . . . . . . . 9
6. Parent side CDS / CDNSKEY Consumption . . . . . . . . . . . . 9 6. Parent side CDS / CDNSKEY Consumption . . . . . . . . . . . . 9
6.1. Detecting a changed CDS / CDNSKEY . . . . . . . . . . . . 9 6.1. Detecting a changed CDS / CDNSKEY . . . . . . . . . . . . 9
6.1.1. CDS / CDNSKEY Polling . . . . . . . . . . . . . . . . 9 6.1.1. CDS / CDNSKEY Polling . . . . . . . . . . . . . . . . 10
6.1.2. Other mechanisms . . . . . . . . . . . . . . . . . . 10 6.1.2. Other mechanisms . . . . . . . . . . . . . . . . . . 10
6.2. Using the new CDS / CDNSKEY records . . . . . . . . . . . 10 6.2. Using the new CDS / CDNSKEY records . . . . . . . . . . . 10
6.2.1. Parent calculates DS . . . . . . . . . . . . . . . . 11 6.2.1. Parent calculates DS . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
Appendix A. RRR background . . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. RRR background . . . . . . . . . . . . . . . . . . . 15
Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 15 Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
When a DNS operator first signs their zone, they need to communicate When a DNS operator first signs their zone, they need to communicate
their DS record(s) (or DNSKEY(s)) to their parent through some out- their DS record(s) (or DNSKEY(s)) to their parent through some out-
of-band method to complete the chain of trust. of-band method to complete the chain of trust.
Each time the child changes/rolls the key that is represented in the Each time the child changes/rolls the key that is represented in the
parent, the new and/or deleted key information has to be communicated parent, the new and/or deleted key information has to be communicated
to the parent and published there. How this information is sent to to the parent and published there. How this information is sent to
skipping to change at page 3, line 35 skipping to change at page 3, line 37
follows are as described in [RFC6781] section 4.1.2 follows are as described in [RFC6781] section 4.1.2
This technique is in some ways similar to RFC 5011 style rollovers, This technique is in some ways similar to RFC 5011 style rollovers,
but for sub-domains DS records, instead of trust anchors but for sub-domains DS records, instead of trust anchors
This technique is designed to be friendly both to fully automated This technique is designed to be friendly both to fully automated
tools and humans. Fully automated tools can perform all the actions tools and humans. Fully automated tools can perform all the actions
needed without human intervention, and thus can monitor when it is needed without human intervention, and thus can monitor when it is
safe to move to the next step. safe to move to the next step.
CDS is only appropriate for transferring information about DNSSEC CDS only allows transferring information about DNSSEC keys (DS and
keys (DS and DNSKEY) from the child to the parental agent. It lists DNSKEY) from the child to the parental agent. It lists exactly what
exactly what the parent should publish, and allows for publication of the parent should publish, and allows for publication of stand-by
stand-by keys. There is a complementary solution [I-D.csync] for keys. A different protocol, [I-D.csync], can be used to maintain
maintaining the other important delegation information, such as NS other important delegation information, such as NS and glue. These
and glue. two protocols have been kept as separate solutions because the
problems are fundamentally different, and a combined solution is
overly complex.
This document describes a method for automating maintanance of the
delegation trust information, and proposes a polled / periodic
trigger for simplicity. Some users may prefer a different trigger,
such as a button on a webpage, a REST interface, DNS NOTIFY, etc.
These alternate / additional triggers are not discussed in this
document.
1.1. Terminology 1.1. Terminology
There terminology we use is defined in this section There terminology we use is defined in this section
Highlighted roles Highlighted roles
o Child: "The entity on record that has the delegation of the domain o Child: "The entity on record that has the delegation of the domain
from the parent" from the parent"
skipping to change at page 12, line 5 skipping to change at page 12, line 13
CDNSKEY RRset. CDNSKEY RRset.
7. IANA Considerations 7. IANA Considerations
IANA has assigned RR Type code 59 for CDS. This was done for an IANA has assigned RR Type code 59 for CDS. This was done for an
earlier version of this document[I-D.ds-publish] This document is to earlier version of this document[I-D.ds-publish] This document is to
become the reference for CDS RRtype. become the reference for CDS RRtype.
IANA is requested to assign another RR Type for the CDNSKEY. IANA is requested to assign another RR Type for the CDNSKEY.
8. Security Considerations 8. Privacy Considerations
[ This needs more work, suggestions welcome.] All of the information handled / transmitted by this protocol is
public information published in the DNS.
9. Security Considerations
This work is for the normal case, when things go wrong there is only This work is for the normal case, when things go wrong there is only
so much that automation can fix. so much that automation can fix.
If child breaks DNSSEC validation by removing all the DNSKEYs that If child breaks DNSSEC validation by removing all the DNSKEYs that
are represented in the DS set its only repair actions are to contact are represented in the DS set its only repair actions are to contact
the parent or restore the DNSKEYs in the DS set. the parent or restore the DNSKEYs in the DS set.
In the event of a compromise of the server or system generating In the event of a compromise of the server or system generating
signatures for a zone, an attacker might be able to generate and signatures for a zone, an attacker might be able to generate and
skipping to change at page 13, line 11 skipping to change at page 13, line 19
fails. In the worst case Parental Agent performs an action reversing fails. In the worst case Parental Agent performs an action reversing
a prior action but after the child signing system decides to take the a prior action but after the child signing system decides to take the
next step in rollover, resulting in a broken delegation. next step in rollover, resulting in a broken delegation.
DNS is a loosely coherent distributed database with local caching; DNS is a loosely coherent distributed database with local caching;
therefore it is important to allow old information to expire from therefore it is important to allow old information to expire from
caches before deleting DS or DNSKEY records. Similarly, it is caches before deleting DS or DNSKEY records. Similarly, it is
important to allow new records to propagate through the DNS before important to allow new records to propagate through the DNS before
use, see [RFC6781] and [I-D.key-time] use, see [RFC6781] and [I-D.key-time]
9. Acknowledgements It is common practice for users to outsource their DNS hosting to a
3rd party DNS provider. In order for that provider to be able to
maintain the DNSSEC information some users give the provider their
registrar login credentials (which obviously has negative security
implications). Deploying the solution described in this document
allows the 3rd party DNS provider to maintain the DNSSEC information
without giving them the registrar credentials, thereby improving
security.
We would like to thank a large number of folk, including: Wes By automating the maintenance of the DNSSEC key information (and
Hardaker, Mark Andrews, Joe Abley, Jaap Akkerhuis, Roy Arends, Doug removing humans from the process) we expect to decrease the number of
Barton, Brian Dickinson, Paul Ebersman, Tony Finch, Patrik Faltsrom, DNSSEC related outages, which should increase DNSSEC deployment.
Jim Galvin, Olaf Kolkman, Cricket Liu, Stephan Lagerholm, Matt
10. Acknowledgements
We would like to thank a large number of folk, including: Mark
Andrews, Joe Abley, Jaap Akkerhuis, Roy Arends, Doug Barton, Brian
Dickinson, Paul Ebersman, Tony Finch, Patrik Faltsrom, Jim Galvin,
Paul Hoffman, Olaf Kolkman, Cricket Liu, Stephan Lagerholm, Matt
Larson, Marco Sanz, Antoin Verschuren, Suzanne Woolf, Paul Wouters, Larson, Marco Sanz, Antoin Verschuren, Suzanne Woolf, Paul Wouters,
Matthijs Meeking, John Dickinson, Timothe Litt and Edward Lewis. Matthijs Meeking, John Dickinson, Timothe Litt and Edward Lewis.
Special thanks to Wes Hardaker for contributing significant text and
creating the complementary (CSYNC) solution, and to Paul Hoffman for
some text.
There were a number of other folk with whom we discussed this, There were a number of other folk with whom we discussed this,
apologies for not remembering everyone. apologies for not remembering everyone.
10. References 11. References
11.1. Normative References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005. 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
skipping to change at page 13, line 49 skipping to change at page 14, line 28
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", STD 74, RFC 5011, September 2007. Trust Anchors", STD 74, RFC 5011, September 2007.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781, December Operational Practices, Version 2", RFC 6781, December
2012. 2012.
10.2. Informative References 11.2. Informative References
[I-D.auto-cpsync] [I-D.auto-cpsync]
Mekking, W., "Automated (DNSSEC) Child Parent Mekking, W., "Automated (DNSSEC) Child Parent
Synchronization using DNS UPDATE", draft-mekking-dnsop- Synchronization using DNS UPDATE", draft-mekking-dnsop-
auto-cpsync-01 (work in progress), December 2010. auto-cpsync-01 (work in progress), December 2010.
[I-D.csync] [I-D.csync]
Hardaker, W., "Child To Parent Synchronization in DNS", Hardaker, W., "Child To Parent Synchronization in DNS",
draft-hardaker-dnsop-csync-02 (work in progress), July draft-hardaker-dnsop-csync-02 (work in progress), July
2013. 2013.
skipping to change at page 15, line 12 skipping to change at page 15, line 40
In many RRR cases the Registrar and Registry communicate via In many RRR cases the Registrar and Registry communicate via
EPP[RFC5730] and use the EPP DNSSEC extension [RFC5910]. In a number EPP[RFC5730] and use the EPP DNSSEC extension [RFC5910]. In a number
of ccTLDs there are other mechanisms in use as well as EPP, but in of ccTLDs there are other mechanisms in use as well as EPP, but in
general there seems to be a movement towards EPP usage when DNSSEC is general there seems to be a movement towards EPP usage when DNSSEC is
enabled in the TLD. enabled in the TLD.
Appendix B. Changes / Author Notes. Appendix B. Changes / Author Notes.
[RFC Editor: Please remove this section before publication ] [RFC Editor: Please remove this section before publication ]
WG-00 to WG-01
o Addressed Vancouver: "Paul Hoffmann: NOT ready for WGLC. None of
the 2 documents explain why there is a split between the two
strategies." Thanks to Paul for providing text.
From -05 to WG-00: From -05 to WG-00:
o Nothing useful. o Nothing rchanged, resubmit under new name.
From 04 to 05 From 04 to 05
o Renamed the record back to CDS. o Renamed the record back to CDS.
o
From 03 to 04. From 03 to 04.
o Added text explaining that CDS and CSYNC complement each other, o Added text explaining that CDS and CSYNC complement each other,
not replace or compete. not replace or compete.
o Changed format of record to be <selector> <data> to allow the o Changed format of record to be <selector> <data> to allow the
publication of DS **or** DNSKEY. publication of DS **or** DNSKEY.
o Bunch of text changed to cover the above. o Bunch of text changed to cover the above.
 End of changes. 23 change blocks. 
37 lines changed or deleted 74 lines changed or added

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