draft-ietf-dnsop-delegation-trust-maintainance-10.txt   draft-ietf-dnsop-delegation-trust-maintainance-11.txt 
dnsop W. Kumari dnsop W. Kumari
Internet-Draft Google Internet-Draft Google
Intended status: Informational O. Gudmundsson Intended status: Informational O. Gudmundsson
Expires: October 18, 2014 Shinkuro Inc. Expires: October 18, 2014 Shinkuro Inc.
G. Barwood G. Barwood
April 16, 2014 April 16, 2014
Automating DNSSEC Delegation Trust Maintenance Automating DNSSEC Delegation Trust Maintenance
draft-ietf-dnsop-delegation-trust-maintainance-10 draft-ietf-dnsop-delegation-trust-maintainance-11
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 the DNS as communication easily update DNSSEC Key Signing Keys using the DNS as communication
channel. This document does not address the initial configuration of channel. The technique described is aimed at delegations in which it
trust anchors for a domain. The technique described is aimed at is currently hard to move information from the child to parent.
delegations in which it is currently hard to move information from
the child to parent.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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/.
skipping to change at page 2, line 29 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . 8 3.1. CDS Resource Record Format . . . . . . . . . . . . . . . 8
3.2. CDNSKEY Resource Record Format . . . . . . . . . . . . . 8 3.2. CDNSKEY Resource Record Format . . . . . . . . . . . . . 8
4. Automating DS Maintainance With CDS/CDNSKEY records . . . . . 8 4. Automating DS Maintainance With CDS/CDNSKEY records . . . . . 8
4.1. CDS / CDNSKEY Processing Rules . . . . . . . . . . . . . 8 4.1. CDS / CDNSKEY Processing Rules . . . . . . . . . . . . . 8
5. CDS / CDNSKEY Publication . . . . . . . . . . . . . . . . . . 9 5. 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 . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . 11
6.2.1. Parent Calculates DS . . . . . . . . . . . . . . . . 11 6.2.1. Parent Calculates DS . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. RRR background . . . . . . . . . . . . . . . . . . . 15 Appendix A. RRR background . . . . . . . . . . . . . . . . . . . 15
Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 16 Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 16
skipping to change at page 3, line 44 skipping to change at page 3, line 42
The solution described in this document only allows transferring The solution described in this document only allows transferring
information about DNSSEC keys (DS and DNSKEY) from the child to the information about DNSSEC keys (DS and DNSKEY) from the child to the
parental agent. It lists exactly what the parent should publish, and parental agent. It lists exactly what the parent should publish, and
allows for publication of stand-by keys. A different protocol, allows for publication of stand-by keys. A different protocol,
[I-D.csync], can be used to maintain other important delegation [I-D.csync], can be used to maintain other important delegation
information, such as NS and glue. These two protocols have been kept information, such as NS and glue. These two protocols have been kept
as separate solutions because the problems are fundamentally as separate solutions because the problems are fundamentally
different, and a combined solution is overly complex. different, and a combined solution is overly complex.
This document describes a method for automating maintanance of the This document describes a method for automating maintenance of the
delegation trust information, and proposes a polled / periodic delegation trust information, and proposes a polled / periodic
trigger for simplicity. Some users may prefer a different trigger, trigger for simplicity. Some users may prefer a different trigger,
for example a button on a webpage, a REST interface or a DNS NOTIFY. for example a button on a webpage, a REST interface or a DNS NOTIFY.
These alternate / additional triggers are not discussed in this These alternate / additional triggers are not discussed in this
document. document.
This proposal does not include all operations needed for the This proposal does not include all operations needed for the
maintenance of DNSSEC key material, specifically the initial maintenance of DNSSEC key material, specifically the initial
introduction or complete removal of all keys. Because of this, introduction or complete removal of all keys. Because of this,
alternate communications mechanisms must always exist, potentially alternate communications mechanisms must always exist, potentially
skipping to change at page 8, line 48 skipping to change at page 8, line 48
publish that record type (for example, some children wish the parent publish that record type (for example, some children wish the parent
to publish a DS, but they wish to keep the DNSKEY "hidden" until to publish a DS, but they wish to keep the DNSKEY "hidden" until
needed). If the child publishes both, the two RRsets MUST match in needed). If the child publishes both, the two RRsets MUST match in
content. content.
4.1. CDS / CDNSKEY Processing Rules 4.1. CDS / CDNSKEY Processing Rules
If there are no CDS / CDNSKEY RRset in the child, this signals that If there are no CDS / CDNSKEY RRset in the child, this signals that
no change should be made to the current DS set. This means that, no change should be made to the current DS set. This means that,
once the child and parent are in sync, the Child DNS Operator MAY once the child and parent are in sync, the Child DNS Operator MAY
remove all CDS and CDNSKEY resource records from the zone. remove all CDS and CDNSKEY resource records from the zone The Child
DNS Operator may choose to do this to decrease the size of the zone,
or to decrease the workload for the parent (if the parent receives no
CDS / CDNSKEY records it can go back to sleep. If it does receive a
CDS or CDNSKEY RRset it needs to check them against what is currently
published - see Section 5)
Following acceptance rules are placed on the CDS / CDNSKEY resource Following acceptance rules are placed on the CDS / CDNSKEY resource
records as follows: records as follows:
o Location: "the CDS / CDNSKEY resource records MUST be at the child o Location: "the CDS / CDNSKEY resource records MUST be at the child
zone apex". zone apex".
o Signer: "MUST be signed with a key that is represented in both the o Signer: "MUST be signed with a key that is represented in both the
current DNSKEY and DS RRset's" (unless the parent validates the current DNSKEY and DS RRset's" (unless the parent uses the CDS /
CDS / CDNSKEY though some other means (see Section 6.1 and the CDNSKEY RRset for initial enrollment, in that case the parent
Security Considerations.)) validates the CDS / CDNSKEY though some other means (see
Section 6.1 and the Security Considerations.))
o Continuity: "MUST NOT break the current delegation if applied to o Continuity: "MUST NOT break the current delegation if applied to
DS RRset" DS RRset"
If any these conditions fail the CDS / CDNSKEY resource record MUST If any these conditions fail the CDS / CDNSKEY resource record MUST
be ignored. be ignored.
5. CDS / CDNSKEY Publication 5. CDS / CDNSKEY Publication
Child DNS Operator publishes CDS and / or CDNSKEY resource records. Child DNS Operator publishes CDS and / or CDNSKEY resource records.
skipping to change at page 10, line 8 skipping to change at page 10, line 16
each of the children that has a DS record to see if there is a each of the children that has a DS record to see if there is a
CDS or CDNSKEY RRset. CDS or CDNSKEY RRset.
Pushing The delegation user interface has a button {Fetch DS} when Pushing The delegation user interface has a button {Fetch DS} when
pushed preforms the CDS / CDNSKEY processing. If the Parent pushed preforms the CDS / CDNSKEY processing. If the Parent
zone does not contain DS for this delegation then the "push" zone does not contain DS for this delegation then the "push"
SHOULD be ignored. If the Parental Agent displays the contents SHOULD be ignored. If the Parental Agent displays the contents
of the CDS / CDSNKEY to the user and gets confirmation that of the CDS / CDSNKEY to the user and gets confirmation that
this represents their key, the Parental Agent MAY use this for this represents their key, the Parental Agent MAY use this for
initial enrolment (when the Parent zone does not contain the DS initial enrolment (when the Parent zone does not contain the DS
for this delgation). for this delegation).
In either case the Parental Agent MAY apply additional rules that In either case the Parental Agent MAY apply additional rules that
defer the acceptance of a CDS / CDNSKEY change, these rules may defer the acceptance of a CDS / CDNSKEY change, these rules may
include a condition that the CDS / CDNSKEY remains in place and valid include a condition that the CDS / CDNSKEY remains in place and valid
for some time period before it is accepted. It may be appropriate in for some time period before it is accepted. It may be appropriate in
the "Pushing" case to assume that the Child is ready and thus accept the "Pushing" case to assume that the Child is ready and thus accept
changes without delay. changes without delay.
6.1.1. CDS / CDNSKEY Polling 6.1.1. CDS / CDNSKEY Polling
This is the only defined use of CDS / CDNSKEY resource records in This is the only defined use of CDS / CDNSKEY resource records in
this document. There are limits to the scaleability of polling this document. There are limits to the scaleability of polling
techniques, thus some other mechanism is likely to be specified later techniques, thus some other mechanism is likely to be specified later
that addresses CDS / CDNSKEY resource recod usage in the situation that addresses CDS / CDNSKEY resource record usage in the situation
where polling does not scale to. Having said that Polling will work where polling does not scale to. Having said that Polling will work
in many important cases such as enterprises, universities and smaller in many important cases such as enterprises, universities and smaller
TLDs. In many regulatory environments the registry is prohibited TLDs. In many regulatory environments the registry is prohibited
from talking to the registrant. In most of these cases the from talking to the registrant. In most of these cases the
registrant has a business relationship with the registrar, and so the registrant has a business relationship with the registrar, and so the
registrar can offer this as a service. registrar can offer this as a service.
If the CDS / CDNSKEY RRset does not exist, the Parental Agent MUST If the CDS / CDNSKEY RRset does not exist, the Parental Agent MUST
take no action. Specifically it MUST NOT delete or alter the take no action. Specifically it MUST NOT delete or alter the
existing DS RRset. existing DS RRset.
skipping to change at page 10, line 51 skipping to change at page 11, line 10
records or an unauthenticated POST could be made to a webserver (with records or an unauthenticated POST could be made to a webserver (with
rate-limiting).) rate-limiting).)
Other documents can specify the trigger conditions. Other documents can specify the trigger conditions.
6.2. Using the New CDS / CDNSKEY Records 6.2. Using the New CDS / CDNSKEY Records
Regardless of how the Parental Agent detected changes to a CDS / Regardless of how the Parental Agent detected changes to a CDS /
CDNSKEY RRset, the Parental Agent SHOULD use a DNSSEC validator to CDNSKEY RRset, the Parental Agent SHOULD use a DNSSEC validator to
obtain a validated CDS / CDNSKEY RRset from the Child zone. The only obtain a validated CDS / CDNSKEY RRset from the Child zone. The only
exception to this is if the parent perfoms some additional validation exception to this is if the parent performs some additional
on the data to confirm that it is the "correct" key. This behavior validation on the data to confirm that it is the "correct" key. This
is NOT RECOMMENDED. behavior is NOT RECOMMENDED.
The Parental Agent MUST ensure that previous versions of the CDS / The Parental Agent MUST ensure that previous versions of the CDS /
CDNSKEY RRset do not overwrite more recent versions. This MAY be CDNSKEY RRset do not overwrite more recent versions. This MAY be
accomplished by checking that the signature inception in the RRSIG accomplished by checking that the signature inception in the RRSIG
for CDS / CDNSKEY RRset is later and/or the serial number on the for CDS / CDNSKEY RRset is later and/or the serial number on the
child's SOA is greater. This may require the Parental Agent to child's SOA is greater. This may require the Parental Agent to
maintain some state information. maintain some state information.
The Parental Agent MAY take extra security measures. For example, to The Parental Agent MAY take extra security measures. For example, to
mitigate the possibility that a Child's key signing key has been mitigate the possibility that a Child's key signing key has been
skipping to change at page 12, line 12 skipping to change at page 12, line 14
not identical with the data in the CDS resource record made available not identical with the data in the CDS resource record made available
by the child. by the child.
7. IANA Considerations 7. IANA Considerations
IANA has assigned RR Type code 59 for the CDS resource record. This IANA has assigned RR Type code 59 for the CDS resource record. This
was done for an earlier version of this document[I-D.ds-publish] This was done for an earlier version of this document[I-D.ds-publish] This
document is to become the reference for CDS RRtype. document is to become the reference for CDS RRtype.
IANA is requested to assign another RR Type for the CDNSKEY, and to IANA is requested to assign another RR Type for the CDNSKEY, and to
replace TBA1 with this value (currntly 60 is still free, it would be replace TBA1 with this value (currently 60 is still free, it would be
nice if that were assigned...) nice if that were assigned...)
8. Privacy Considerations 8. Privacy Considerations
All of the information handled / transmitted by this protocol is All of the information handled / transmitted by this protocol is
public information published in the DNS. public information published in the DNS.
9. Security Considerations 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
skipping to change at page 14, line 9 skipping to change at page 14, line 9
security. security.
By automating the maintenance of the DNSSEC key information (and By automating the maintenance of the DNSSEC key information (and
removing humans from the process), we expect to decrease the number removing humans from the process), we expect to decrease the number
of DNSSEC related outages, which should increase DNSSEC deployment. of DNSSEC related outages, which should increase DNSSEC deployment.
10. Acknowledgements 10. Acknowledgements
We would like to thank a large number of folk, including: Mark We would like to thank a large number of folk, including: Mark
Andrews, Joe Abley, Jaap Akkerhuis, Roy Arends, Doug Barton, Brian Andrews, Joe Abley, Jaap Akkerhuis, Roy Arends, Doug Barton, Brian
Dickinson, Paul Ebersman, Tony Finch, Jim Galvin, Paul Hoffman, Samir Dickson, Paul Ebersman, Tony Finch, Jim Galvin, Paul Hoffman, Samir
Hussain, Tatuya Jinmei, Olaf Kolkman, Stephan Lagerholm, Cricket Liu, Hussain, Tatuya Jinmei, Olaf Kolkman, Stephan Lagerholm, Cricket Liu,
Stephan Lagerholm, Matt Larson, Marco Sanz, Antoin Verschuren, Matt Larson, Marco Sanz, Antoin Verschuren, Suzanne Woolf, Paul
Suzanne Woolf, Paul Wouters, John Dickinson, Timothe Litt and Edward Wouters, John Dickinson, Timothe Litt and Edward Lewis.
Lewis.
Special thanks to Wes Hardaker for contributing significant text and Special thanks to Wes Hardaker for contributing significant text and
creating the complementary (CSYNC) solution, and to Patrik Faltstrom, creating the complementary (CSYNC) solution, and to Patrik Faltstrom,
Paul Hoffman, Matthijs Mekking and Mukund Sivaraman for text and in- Paul Hoffman, Matthijs Mekking and Mukund Sivaraman for text and in-
depth review. depth review.
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.
11. References 11. References
skipping to change at page 15, line 45 skipping to change at page 15, line 45
Provisioning Protocol (EPP)", RFC 5910, May 2010. Provisioning Protocol (EPP)", RFC 5910, May 2010.
Appendix A. RRR background Appendix A. RRR background
In the RRR world, the different parties are frequently from different In the RRR world, the different parties are frequently from different
organizations. In the single enterprise world there are also organizations. In the single enterprise world there are also
organizational/geographical/cultural separations that affect how organizational/geographical/cultural separations that affect how
information flows from a Child to the parent. information flows from a Child to the parent.
Due to the complexity of the different roles and interconnections, Due to the complexity of the different roles and interconnections,
automation of delegation information has not yet occured. There have automation of delegation information Expolhas not yet occurred.
been proposals to automate this, in order to improve the reliability There have been proposals to automate this, in order to improve the
of the DNS. These proposals have not gained enough traction to reliability of the DNS. These proposals have not gained enough
become standards. traction to become standards.
For example in many of the TLD cases there is the RRR model For example in many of the TLD cases there is the RRR model
(Registry, Registrar and Registrant). The Registry operates DNS for (Registry, Registrar and Registrant). The Registry operates DNS for
the TLD, the Registrars accept registrations and place information the TLD, the Registrars accept registrations and place information
into the Registries database. The Registrant only communicates with into the Registries database. The Registrant only communicates with
the Registrar; frequently the Registry is not allowed to communicate the Registrar; frequently the Registry is not allowed to communicate
with the Registrant. In that case as far as the registrant is with the Registrant. In that case as far as the registrant is
concerned the Registrar == Parent. concerned the Registrar == Parent.
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-10 to WG-11
o More useful text from Matthijs.
o Explained why the child might want to remove the CDS / CDNSKEY
Records.
WG-09 to WG-10 WG-09 to WG-10
o Incorporated off list comments from Stephan Lagerholm. Largest o Incorporated off list comments from Stephan Lagerholm. Largest
change is fixing discrepancy between parent MAY perform OOB change is fixing discrepancy between parent MAY perform OOB
validation and the Signer rule in 4.1. Clarified by updating validation and the Signer rule in 4.1. Clarified by updating
signer rule to allow signer rule to allow
WG-08 to WG-09 WG-08 to WG-09
o New text from Paul Hoffman for the first paragraph of the intro. o New text from Paul Hoffman for the first paragraph of the intro.
 End of changes. 14 change blocks. 
25 lines changed or deleted 35 lines changed or added

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