draft-ietf-dnsext-trustupdate-timers-00.txt   draft-ietf-dnsext-trustupdate-timers-01.txt 
Network Working Group M. StJohns Network Working Group M. StJohns
Internet-Draft Nominum, Inc. Internet-Draft Nominum, Inc.
Expires: April 14, 2005 October 14, 2004 Expires: February 16, 2006 August 15, 2005
Automated Updates of DNSSEC Trust Anchors Automated Updates of DNSSEC Trust Anchors
draft-ietf-dnsext-trustupdate-timers-00 draft-ietf-dnsext-trustupdate-timers-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 14, 2005. This Internet-Draft will expire on February 16, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes a means for automated, authenticated and This document describes a means for automated, authenticated and
authorized updating of DNSSEC "trust anchors". The method provides authorized updating of DNSSEC "trust anchors". The method provides
protection against single key compromise of a key in the trust point protection against single key compromise of a key in the trust point
key set. Based on the trust established by the presence of a current key set. Based on the trust established by the presence of a current
anchor, other anchors may be added at the same place in the anchor, other anchors may be added at the same place in the
hierarchy, and, ultimately, supplant the existing anchor. hierarchy, and, ultimately, supplant the existing anchor.
skipping to change at page 2, line 14 skipping to change at page 2, line 13
management behavior (but not resolver resolution behavior), and the management behavior (but not resolver resolution behavior), and the
addition of a single flag bit to the DNSKEY record. addition of a single flag bit to the DNSKEY record.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Compliance Nomenclature . . . . . . . . . . . . . . . . . 3 1.1 Compliance Nomenclature . . . . . . . . . . . . . . . . . 3
1.2 Changes since -00 . . . . . . . . . . . . . . . . . . . . 3 1.2 Changes since -00 . . . . . . . . . . . . . . . . . . . . 3
2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
2.1 Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5 2.3 Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5
2.4 Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6 2.4 Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Resolver Parameters . . . . . . . . . . . . . . . . . . . 6 2.5 Resolver Parameters . . . . . . . . . . . . . . . . . . . 6
2.5.1 Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6 2.5.1 Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6
2.5.2 Remove Hold-Down Time . . . . . . . . . . . . . . . . 6 2.5.2 Remove Hold-Down Time . . . . . . . . . . . . . . . . 6
2.5.3 Minimum Trust Anchors per Trust Point . . . . . . . . 6 2.5.3 Minimum Trust Anchors per Trust Point . . . . . . . . 6
3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6
4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 States . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2 States . . . . . . . . . . . . . . . . . . . . . . . . . . 7
skipping to change at page 3, line 8 skipping to change at page 3, line 8
6.2 Multiple Key Compromise . . . . . . . . . . . . . . . . . 10 6.2 Multiple Key Compromise . . . . . . . . . . . . . . . . . 10
6.3 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 10 6.3 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 10
7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 12
1. Introduction 1. Introduction
As part of the reality of fielding DNSSEC (Domain Name System As part of the reality of fielding DNSSEC (Domain Name System
Security Extensions) [RFC2535][DSINTRO][DSPROT][DSREC], the community Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the
has come to the realization that there will not be one signed name community has come to the realization that there will not be one
space, but rather islands of signed name space each originating from signed name space, but rather islands of signed name space each
specific points (i.e. 'trust points') in the DNS tree. Each of originating from specific points (i.e. 'trust points') in the DNS
those islands will be identified by the trust point name, and tree. Each of those islands will be identified by the trust point
validated by at least one associated public key. For the purpose of name, and validated by at least one associated public key. For the
this document we'll call the association of that name and a purpose of this document we'll call the association of that name and
particular key a 'trust anchor'. A particular trust point can have a particular key a 'trust anchor'. A particular trust point can have
more than one key designated as a trust anchor. more than one key designated as a trust anchor.
For a DNSSEC-aware resolver to validate information in a DNSSEC For a DNSSEC-aware resolver to validate information in a DNSSEC
protected branch of the hierarchy, it must have knowledge of a trust protected branch of the hierarchy, it must have knowledge of a trust
anchor applicable to that branch. It may also have more than one anchor applicable to that branch. It may also have more than one
trust anchor for any given trust point. Under current rules, a chain trust anchor for any given trust point. Under current rules, a chain
of trust for DNSSEC-protected data that chains its way back to ANY of trust for DNSSEC-protected data that chains its way back to ANY
known trust anchor is considered 'secure'. known trust anchor is considered 'secure'.
Because of the probable balkanization of the DNSSEC tree due to Because of the probable balkanization of the DNSSEC tree due to
signing voids at key locations, a resolver may need to know literally signing voids at key locations, a resolver may need to know literally
thousands of trust anchors to perform its duties. (e.g. Consider an thousands of trust anchors to perform its duties. (e.g. Consider an
unsigned ".COM".) Requiring the owner of the resolver to manually unsigned ".COM".) Requiring the owner of the resolver to manually
manage this many relationships is problematic. It's even more manage this many relationships is problematic. It's even more
problematic when considering the eventual requirement for key problematic when considering the eventual requirement for key
replacement/update for a given trust anchor. The mechanism described replacement/update for a given trust anchor. The mechanism described
herein won't help with the initial configuration of the trust anchors herein won't help with the initial configuration of the trust anchors
in the resolvers, but should make trust point key in the resolvers, but should make trust point key replacement/
replacement/rollover more viable. rollover more viable.
As mentioned above, this document describes a mechanism whereby a As mentioned above, this document describes a mechanism whereby a
resolver can update the trust anchors for a given trust point, mainly resolver can update the trust anchors for a given trust point, mainly
without human intervention at the resolver. There are some corner without human intervention at the resolver. There are some corner
cases discussed (e.g. multiple key compromise) that may require cases discussed (e.g. multiple key compromise) that may require
manual intervention, but they should be few and far between. This manual intervention, but they should be few and far between. This
document DOES NOT discuss the general problem of the initial document DOES NOT discuss the general problem of the initial
configuration of trust anchors for the resolver. configuration of trust anchors for the resolver.
1.1 Compliance Nomenclature 1.1 Compliance Nomenclature
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, [RFC2119]. document are to be interpreted as described in BCP 14, [RFC2119].
1.2 Changes since -00 1.2 Changes since -00
Resubmitted draft-stjohns-dnssec-trustupdate as a working group
draft.
Added the concept of timer triggered resolver queries to refresh the Added the concept of timer triggered resolver queries to refresh the
resolvers view of the trust anchor key RRSet. resolvers view of the trust anchor key RRSet.
Re-submitted expired draft as -01. Updated DNSSEC RFC References.
2. Theory of Operation 2. Theory of Operation
The general concept of this mechanism is that existing trust anchors The general concept of this mechanism is that existing trust anchors
can be used to authenticate new trust anchors at the same point in can be used to authenticate new trust anchors at the same point in
the DNS hierarchy. When a new SEP key is added to a trust point the DNS hierarchy. When a new SEP key is added to a trust point
DNSKEY RRSet, and when that RRSet is validated by an existing trust DNSKEY RRSet, and when that RRSet is validated by an existing trust
anchor, then the new key can be added to the set of trust anchors. anchor, then the new key can be added to the set of trust anchors.
There are some issues with this approach which need to be mitigated. There are some issues with this approach which need to be mitigated.
For example, a compromise of one of the existing keys could allow an For example, a compromise of one of the existing keys could allow an
skipping to change at page 4, line 33 skipping to change at page 4, line 32
old keys. old keys.
2.1 Revocation 2.1 Revocation
Assume two trust anchor keys A and B. Assume that B has been Assume two trust anchor keys A and B. Assume that B has been
compromised. Without a specific revocation bit, B could invalidate A compromised. Without a specific revocation bit, B could invalidate A
simply by sending out a signed trust point key set which didn't simply by sending out a signed trust point key set which didn't
contain A. To fix this, we add a mechanism which requires knowledge contain A. To fix this, we add a mechanism which requires knowledge
of the private key of a DNSKEY to revoke that DNSKEY. of the private key of a DNSKEY to revoke that DNSKEY.
A key is considered revoked when the resolver sees the key in a A key is considered revoked when the resolver sees the key in a self-
self-signed RRSet and the key has the REVOKE bit set to '1'. Once signed RRSet and the key has the REVOKE bit set to '1'. Once the
the resolver sees the REVOKE bit, it MUST NOT use this key as a trust resolver sees the REVOKE bit, it MUST NOT use this key as a trust
anchor or for any other purposes except validating the RRSIG over the anchor or for any other purposes except validating the RRSIG over the
DNSKEY RRSet specifically for the purpose of validating the DNSKEY RRSet specifically for the purpose of validating the
revocation. Unlike the 'Add' operation below, revocation is revocation. Unlike the 'Add' operation below, revocation is
immediate and permanent upon receipt of a valid revocation at the immediate and permanent upon receipt of a valid revocation at the
resolver. resolver.
N.B. A DNSKEY with the REVOKE bit set has a different fingerprint N.B. A DNSKEY with the REVOKE bit set has a different fingerprint
than one without the bit set. This affects the matching of a DNSKEY than one without the bit set. This affects the matching of a DNSKEY
to DS records in the parent, or the fingerprint stored at a resolver to DS records in the parent, or the fingerprint stored at a resolver
used to configure a trust point. [msj3] used to configure a trust point. [msj3]
skipping to change at page 5, line 14 skipping to change at page 5, line 10
2.2 Add Hold-Down 2.2 Add Hold-Down
Assume two trust point keys A and B. Assume that B has been Assume two trust point keys A and B. Assume that B has been
compromised. An attacker could generate and add a new trust anchor compromised. An attacker could generate and add a new trust anchor
key - C (by adding C to the DNSKEY RRSet and signing it with B), and key - C (by adding C to the DNSKEY RRSet and signing it with B), and
then invalidate the compromised key. This would result in the both then invalidate the compromised key. This would result in the both
the attacker and owner being able to sign data in the zone and have the attacker and owner being able to sign data in the zone and have
it accepted as valid by resolvers. it accepted as valid by resolvers.
To mitigate, but not completely solve, this problem, we add a To mitigate, but not completely solve, this problem, we add a hold-
hold-down time to the addition of the trust anchor. When the down time to the addition of the trust anchor. When the resolver
resolver sees a new SEP key in a validated trust point DNSKEY RRSet, sees a new SEP key in a validated trust point DNSKEY RRSet, the
the resolver starts an acceptance timer, and remembers all the keys resolver starts an acceptance timer, and remembers all the keys that
that validated the RRSet. If the resolver ever sees the DNSKEY RRSet validated the RRSet. If the resolver ever sees the DNSKEY RRSet
without the new key but validly signed, it stops the acceptance without the new key but validly signed, it stops the acceptance
process and resets the acceptance timer. If all of the keys which process and resets the acceptance timer. If all of the keys which
were originally used to validate this key are revoked prior to the were originally used to validate this key are revoked prior to the
timer expiring, the resolver stops the acceptance process and resets timer expiring, the resolver stops the acceptance process and resets
the timer. the timer.
Once the timer expires, the new key will be added as a trust anchor Once the timer expires, the new key will be added as a trust anchor
the next time the validated RRSet with the new key is seen at the the next time the validated RRSet with the new key is seen at the
resolver. The resolver MUST NOT treat the new key as a trust anchor resolver. The resolver MUST NOT treat the new key as a trust anchor
until the hold down time expires AND it has retrieved and validated a until the hold down time expires AND it has retrieved and validated a
skipping to change at page 9, line 26 skipping to change at page 9, line 25
and delete 'A'. and delete 'A'.
1. Set the revolcation bit on key 'A'. 1. Set the revolcation bit on key 'A'.
2. Sign the DNSKEY RRSet with both 'A' and 'B'. 2. Sign the DNSKEY RRSet with both 'A' and 'B'.
'A' is now revoked. The operator SHOULD include the revoked 'A' in 'A' is now revoked. The operator SHOULD include the revoked 'A' in
the RRSet for at least the remove hold-down time, but then may remove the RRSet for at least the remove hold-down time, but then may remove
it from the DNSKEY RRSet. it from the DNSKEY RRSet.
5.3 Key Roll-Over 5.3 Key Roll-Over
Assume existing keys A and B. 'A' is actively in use (i.e. has been Assume existing keys A and B. 'A' is actively in use (i.e. has been
signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been
been in the DNSKEY RRSet and is a valid trust anchor, but wasn't in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
being used to sign the RRSet.) used to sign the RRSet.)
1. Generate a new key pair 'C'. 1. Generate a new key pair 'C'.
2. Add 'C' to the DNSKEY RRSet. 2. Add 'C' to the DNSKEY RRSet.
3. Set the revocation bit on key 'A'. 3. Set the revocation bit on key 'A'.
4. Sign the RRSet with 'A' and 'B'. 4. Sign the RRSet with 'A' and 'B'.
'A' is now revoked, 'B' is now the active key, and 'C' will be the 'A' is now revoked, 'B' is now the active key, and 'C' will be the
stand-by key once the hold-down expires. The operator SHOULD include stand-by key once the hold-down expires. The operator SHOULD include
the revoked 'A' in the RRSet for at least the remove hold-down time, the revoked 'A' in the RRSet for at least the remove hold-down time,
but may then remove it from the DNSKEY RRSet. but may then remove it from the DNSKEY RRSet.
5.4 Active Key Compromised 5.4 Active Key Compromised
skipping to change at page 10, line 43 skipping to change at page 10, line 42
6.3 Dynamic Updates 6.3 Dynamic Updates
Allowing a resolver to update its trust anchor set based in-band key Allowing a resolver to update its trust anchor set based in-band key
information is potentially less secure than a manual process. information is potentially less secure than a manual process.
However, given the nature of the DNS, the number of resolvers that However, given the nature of the DNS, the number of resolvers that
would require update if a trust anchor key were compromised, and the would require update if a trust anchor key were compromised, and the
lack of a standard management framework for DNS, this approach is no lack of a standard management framework for DNS, this approach is no
worse than the existing situation. worse than the existing situation.
7 Normative References 7. Normative References
[DSINTRO] Arends, R., "DNS Security Introduction and Requirements",
ID draft-ietf-dnsext-dnssec-intro-09.txt, October 2004,
<http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns
sec-intro-13.txt>.
[DSPROT] Arends, R., "Protocol Modifications for the DNS Security
Extensions", ID draft-ietf-dnsext-dnssec-protocol-05.txt,
October 2004,
<http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns
sec-protocol-09.txt>.
[DSREC] Arends, R., "Resource Records for the DNS Security
Extensions", ID draft-ietf-dnsext-dnssec-records-07.txt,
October 2004,
<http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns
sec-records-11.txt>.
[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.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
Editorial Comments Editorial Comments
[msj1] msj: N.B. This table is preliminary and will be revised to [msj1] msj: N.B. This table is preliminary and will be revised to
match implementation experience. For example, should there match implementation experience. For example, should there
be a state for "Add hold-down expired, but haven't seen the be a state for "Add hold-down expired, but haven't seen the
new RRSet"? new RRSet"?
[msj2] msj: To be assigned. [msj2] msj: To be assigned.
[msj3] msj: For discussion: What's the implementation guidance for [msj3] msj: For discussion: What's the implementation guidance for
skipping to change at page 11, line 43 skipping to change at page 11, line 36
Author's Address Author's Address
Michael StJohns Michael StJohns
Nominum, Inc. Nominum, Inc.
2385 Bay Road 2385 Bay Road
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
Phone: +1-301-528-4729 Phone: +1-301-528-4729
EMail: Mike.StJohns@nominum.com Email: Mike.StJohns@nominum.com
URI: www.nominum.com URI: www.nominum.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
skipping to change at page 12, line 46 skipping to change at page 12, line 46
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/