draft-ietf-dnsop-dnssec-key-timing-00.txt   draft-ietf-dnsop-dnssec-key-timing-01.txt 
Internet Engineering Task Force S. Morris Internet Engineering Task Force S. Morris
Internet-Draft ISC Internet-Draft ISC
Intended status: Informational J. Ihren Intended status: Informational J. Ihren
Expires: January 2, 2011 Netnod Expires: April 28, 2011 Netnod
J. Dickinson J. Dickinson
Sinodun Sinodun
July 1, 2010 October 25, 2010
DNSSEC Key Timing Considerations DNSSEC Key Timing Considerations
draft-ietf-dnsop-dnssec-key-timing-00.txt draft-ietf-dnsop-dnssec-key-timing-01.txt
Abstract Abstract
This document describes the issues surrounding the timing of events This document describes the issues surrounding the timing of events
in the rolling of a key in a DNSSEC-secured zone. It presents in the rolling of a key in a DNSSEC-secured zone. It presents
timelines for the key rollover and explicitly identifies the timelines for the key rollover and explicitly identifies the
relationships between the various parameters affecting the process. relationships between the various parameters affecting the process.
Status of this Memo Status of this Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 January 2, 2011. This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 33 skipping to change at page 2, line 33
3.3. Key-Signing Key Rollover Timelines . . . . . . . . . . . . 17 3.3. Key-Signing Key Rollover Timelines . . . . . . . . . . . . 17
3.3.1. Double-Signature Method . . . . . . . . . . . . . . . 17 3.3.1. Double-Signature Method . . . . . . . . . . . . . . . 17
3.3.2. Double-DS Method . . . . . . . . . . . . . . . . . . . 20 3.3.2. Double-DS Method . . . . . . . . . . . . . . . . . . . 20
3.3.3. Double-RRset Method . . . . . . . . . . . . . . . . . 22 3.3.3. Double-RRset Method . . . . . . . . . . . . . . . . . 22
3.3.4. Interaction with Configured Trust Anchors . . . . . . 25 3.3.4. Interaction with Configured Trust Anchors . . . . . . 25
3.3.4.1. Addition of KSK . . . . . . . . . . . . . . . . . 25 3.3.4.1. Addition of KSK . . . . . . . . . . . . . . . . . 25
3.3.4.2. Removal of KSK . . . . . . . . . . . . . . . . . . 25 3.3.4.2. Removal of KSK . . . . . . . . . . . . . . . . . . 25
3.3.5. Introduction of First KSK . . . . . . . . . . . . . . 26 3.3.5. Introduction of First KSK . . . . . . . . . . . . . . 26
4. Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . . 27 4. Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . . 27
5. Algorithm Considerations . . . . . . . . . . . . . . . . . . . 28 5. Algorithm Considerations . . . . . . . . . . . . . . . . . . . 28
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6. Limitation of Scope . . . . . . . . . . . . . . . . . . . . . 28
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10. Change History . . . . . . . . . . . . . . . . . . . . . . . . 29 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.2. Informative References . . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . . . 30
Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 30 12.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
1.1. Key Rolling Considerations 1.1. Key Rolling Considerations
When a zone is secured with DNSSEC, the zone manager must be prepared When a zone is secured with DNSSEC, the zone manager must be prepared
to replace ("roll") the keys used in the signing process. The to replace ("roll") the keys used in the signing process. The
rolling of keys may be caused by compromise of one or more of the rolling of keys may be caused by compromise of one or more of the
existing keys, or it may be due to a management policy that demands existing keys, or it may be due to a management policy that demands
periodic key replacement for security or operational reasons. In periodic key replacement for security or operational reasons. In
skipping to change at page 28, line 21 skipping to change at page 28, line 21
RRset". RRset".
Except in the case of an algorithm rollover - where the algorithms Except in the case of an algorithm rollover - where the algorithms
used to create the signatures are being changed - there is no used to create the signatures are being changed - there is no
relationship between the keys of different algorithms. This means relationship between the keys of different algorithms. This means
that they can be rolled independently of one another. In other that they can be rolled independently of one another. In other
words, the key rollover logic described above should be run words, the key rollover logic described above should be run
separately for each algorithm; the union of the results is included separately for each algorithm; the union of the results is included
in the zone, which is signed using the active key for each algorithm. in the zone, which is signed using the active key for each algorithm.
6. Summary 6. Limitation of Scope
This document represents current thinking at the time of publication.
However, the subject matter is evolving and it is more than likely
that this document will need to be revised in the future.
Some of the techniques and ideas that DNSSEC operators are thinking
about differ from this those described in this document. Of note are
alternatives to the strict split into KSK and ZSK key roles and the
consequences for rollover logic from partial signing (i.e. when the
new key initially only signs a fraction of the zone while leaving
other signatures generated by the old key in place).
Furthermore, as noted in section 5, this document covers only rolling
keys of the same algorithm, it does not cover transition to/from/
addition/deletion of different algorithm. Algorithm rollovers will
require a separate document.
The reader is therefore reminded that DNSSEC is as of publication in
early stages of deployment, and best practices will likely change in
the near term.
7. Summary
For ZSKs, "Pre-Publication" is generally considered to be the For ZSKs, "Pre-Publication" is generally considered to be the
preferred way of rolling keys. As shown in this document, the time preferred way of rolling keys. As shown in this document, the time
taken to roll is wholly dependent on parameters under the control of taken to roll is wholly dependent on parameters under the control of
the zone manager. the zone manager.
In contrast, "Double-RRset" is the most efficient method for KSK In contrast, "Double-RRset" is the most efficient method for KSK
rollover due to the ability to have new DS records and DNSKEY RRsets rollover due to the ability to have new DS records and DNSKEY RRsets
propagate in parallel. The time taken to roll KSKs may depend on propagate in parallel. The time taken to roll KSKs may depend on
factors related to the parent zone if the parent is signed. For factors related to the parent zone if the parent is signed. For
skipping to change at page 28, line 43 skipping to change at page 29, line 18
virtually all cases the rollover time will be determined by the virtually all cases the rollover time will be determined by the
RFC5011 "add hold-down" and "remove hold-down" times. It should be RFC5011 "add hold-down" and "remove hold-down" times. It should be
emphasized that this delay is a policy choice and not a function of emphasized that this delay is a policy choice and not a function of
timing values and that it also requires changes to the rollover timing values and that it also requires changes to the rollover
process due to the need to manage revocation of trust anchors. process due to the need to manage revocation of trust anchors.
Finally, the treatment of emergency key rollover is significantly Finally, the treatment of emergency key rollover is significantly
simplified by the introduction of stand-by keys as standard practice simplified by the introduction of stand-by keys as standard practice
during all types of rollovers. during all types of rollovers.
7. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 9. Security Considerations
This document does not introduce any new security issues beyond those This document does not introduce any new security issues beyond those
already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5011]. already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5011].
9. Acknowledgements 10. Acknowledgements
The authors gratefully acknowledge help and contributions from Roy The authors gratefully acknowledge help and contributions from Roy
Arends and Wouter Wijngaards. Arends and Wouter Wijngaards.
10. Change History 11. Change History
o draft-ietf-dnsop-dnssec-key-timing-00
* Added section on limitation of scope.
o draft-morris-dnsop-dnssec-key-timing-02 o draft-morris-dnsop-dnssec-key-timing-02
* General restructuring. * General restructuring.
* Added descriptions of more rollovers (IETF-76 meeting). * Added descriptions of more rollovers (IETF-76 meeting).
* Improved description of key states and removed diagram. * Improved description of key states and removed diagram.
* Provided simpler description of standby keys. * Provided simpler description of standby keys.
* Added section concerning first key in a zone. * Added section concerning first key in a zone.
* Moved [RFC5011] to a separate section. * Moved [RFC5011] to a separate section.
* Various nits fixed (Alfred Hones, Jeremy Reed, Scott Rose, Sion * Various nits fixed (Alfred Hoenes, Jeremy Reed, Scott Rose, Sion
Lloyd, Tony FinchX). Lloyd, Tony Finch).
o draft-morris-dnsop-dnssec-key-timing-01 o draft-morris-dnsop-dnssec-key-timing-01
* Use latest boilerplate for IPR text. * Use latest boilerplate for IPR text.
* List different ways to roll a KSK (acknowledgements to Mark * List different ways to roll a KSK (acknowledgements to Mark
Andrews). Andrews).
* Restructure to concentrate on key timing, not management * Restructure to concentrate on key timing, not management
procedures. procedures.
* Change symbol notation (Diane Davidowicz and others). * Change symbol notation (Diane Davidowicz and others).
* Added key state transition diagram (Diane Davidowicz). * Added key state transition diagram (Diane Davidowicz).
* Corrected spelling, formatting, grammatical and style errors * Corrected spelling, formatting, grammatical and style errors
skipping to change at page 29, line 46 skipping to change at page 30, line 28
* Take account of the fact that signing a zone is not atomic * Take account of the fact that signing a zone is not atomic
(Chris Thompson). (Chris Thompson).
* Add section contrasting pre-publication rollover with double * Add section contrasting pre-publication rollover with double
signature rollover (Matthijs Mekking). signature rollover (Matthijs Mekking).
* Retained distinction between first and subsequent keys in * Retained distinction between first and subsequent keys in
definition of initial publication interval (Matthijs Mekking). definition of initial publication interval (Matthijs Mekking).
o draft-morris-dnsop-dnssec-key-timing-00 o draft-morris-dnsop-dnssec-key-timing-00
Initial draft. Initial draft.
11. References 12. References
11.1. Normative References
12.1. Normative References
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998. NCACHE)", RFC 2308, March 1998.
[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", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 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",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
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", RFC 5011, September 2007. Trust Anchors", RFC 5011, September 2007.
11.2. Informative References 12.2. Informative References
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
RFC 4641, September 2006. RFC 4641, September 2006.
Appendix A. List of Symbols Appendix A. List of Symbols
The document defines a number of symbols, all of which are listed The document defines a number of symbols, all of which are listed
here. All are of the form: here. All are of the form:
All symbols used in the text are of the form: All symbols used in the text are of the form:
 End of changes. 13 change blocks. 
24 lines changed or deleted 51 lines changed or added

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