draft-ietf-dnsext-trustupdate-timers-03.txt   draft-ietf-dnsext-trustupdate-timers-04.txt 
Network Working Group M. StJohns Network Working Group M. StJohns
Internet-Draft Nominum, Inc. Internet-Draft Nominum, Inc.
Expires: January 17, 2007 July 16, 2006 Intended status: Informational August 14, 2006
Expires: February 15, 2007
Automated Updates of DNSSEC Trust Anchors Automated Updates of DNSSEC Trust Anchors
draft-ietf-dnsext-trustupdate-timers-03 draft-ietf-dnsext-trustupdate-timers-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 33 skipping to change at page 1, line 34
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 January 17, 2007. This Internet-Draft will expire on February 15, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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
skipping to change at page 2, line 10 skipping to change at page 2, line 11
hierarchy, and, ultimately, supplant the existing anchor. hierarchy, and, ultimately, supplant the existing anchor.
This mechanism will require changes to resolver management behavior This mechanism will require changes to resolver management behavior
(but not resolver resolution behavior), and the addition of a single (but not resolver resolution behavior), and the addition of a single
flag bit to the DNSKEY record. 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 . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 6 2.3. Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . 7
2.5.3. Minimum Trust Anchors per Trust Point . . . . . . . . 6 2.5.3. Minimum Trust Anchors per Trust Point . . . . . . . . 7
3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 7 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 7
4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. States . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. States . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 8 5. Trust Point Deletion . . . . . . . . . . . . . . . . . . . . . 9
5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Scenarios - Informative . . . . . . . . . . . . . . . . . . . 9
5.1. Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 9 6.1. Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 10
5.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 10 6.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 10
5.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10 6.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10
5.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 10 6.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 10
5.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10 6.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6.6. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 11 8.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 11
7.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11 8.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 12
8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 8.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 14
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] [RFC4033][RFC4034][RFC4035], the Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the
community has come to the realization that there will not be one community has come to the realization that there will not be one
signed name space, but rather islands of signed name space each signed name space, but rather islands of signed name space each
skipping to change at page 4, line 17 skipping to change at page 4, line 21
Re-submitted expired draft as -01. Updated DNSSEC RFC References. Re-submitted expired draft as -01. Updated DNSSEC RFC References.
Draft -02. Added the IANA Considerations section. Added text to Draft -02. Added the IANA Considerations section. Added text to
describe what happens if all trust anchors at a trust point are describe what happens if all trust anchors at a trust point are
deleted. deleted.
Draft -03. Revised the trust point deletion language to note Draft -03. Revised the trust point deletion language to note
limitations. limitations.
Draft -04. Restructured section 4.3 (Trust point deletion) and 5
(Scenarios). Section 4.3 is now section 5. Section 5 is now section
6 and "Informative"
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 (see [RFC4034] section 2.1.1) the DNS hierarchy. When a new SEP key (see [RFC4034] section 2.1.1)
is added to a trust point DNSKEY RRSet, and when that RRSet is is added to a trust point DNSKEY RRSet, and when that RRSet is
validated by an existing trust anchor, then the new key can be added validated by an existing trust anchor, then the new key can be added
to the set of trust anchors. 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.
skipping to change at page 4, line 43 skipping to change at page 4, line 51
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 self- A key is considered revoked when the resolver sees the key in a self-
signed RRSet and the key has the REVOKE bit (see Section 6 below) set signed RRSet and the key has the REVOKE bit (see Section 7 below) set
to '1'. Once the resolver sees the REVOKE bit, it MUST NOT use this to '1'. Once the resolver sees the REVOKE bit, it MUST NOT use this
key as a trust anchor or for any other purposes except validating the key as a trust anchor or for any other purposes except validating the
RRSIG over the DNSKEY RRSet specifically for the purpose of RRSIG over the DNSKEY RRSet specifically for the purpose of
validating the revocation. Unlike the 'Add' operation below, validating the revocation. Unlike the 'Add' operation below,
revocation is immediate and permanent upon receipt of a valid revocation is immediate and permanent upon receipt of a valid
revocation at the resolver. revocation at the resolver.
A self-signed RRSet is a DNSKEY RRSet which contains the specific A self-signed RRSet is a DNSKEY RRSet which contains the specific
DNSKey and for which there is a corresponding validated RRSIG record. DNSKey and for which there is a corresponding validated RRSIG record.
It's not a special DNSKEY RRSet, just a way of describing the It's not a special DNSKEY RRSet, just a way of describing the
skipping to change at page 7, line 22 skipping to change at page 7, line 31
4. State Table 4. State Table
The most important thing to understand is the resolver's view of any The most important thing to understand is the resolver's view of any
key at a trust point. The following state table describes that view key at a trust point. The following state table describes that view
at various points in the key's lifetime. The table is a normative at various points in the key's lifetime. The table is a normative
part of this specification. The initial state of the key is 'Start'. part of this specification. The initial state of the key is 'Start'.
The resolver's view of the state of the key changes as various events The resolver's view of the state of the key changes as various events
occur. occur.
[msj1] This is the state of a trust point key as seen from the This is the state of a trust point key as seen from the resolver.
resolver. The column on the left indicates the current state. The The column on the left indicates the current state. The header at
header at the top shows the next state. The intersection of the two the top shows the next state. The intersection of the two shows the
shows the event that will cause the state to transition from the event that will cause the state to transition from the current state
current state to the next. to the next.
NEXT STATE NEXT STATE
-------------------------------------------------- --------------------------------------------------
FROM |Start |AddPend |Valid |Missing|Revoked|Removed| FROM |Start |AddPend |Valid |Missing|Revoked|Removed|
---------------------------------------------------------- ----------------------------------------------------------
Start | |NewKey | | | | | Start | |NewKey | | | | |
---------------------------------------------------------- ----------------------------------------------------------
AddPend |KeyRem | |AddTime| | | AddPend |KeyRem | |AddTime| | |
---------------------------------------------------------- ----------------------------------------------------------
Valid | | | |KeyRem |Revbit | | Valid | | | |KeyRem |Revbit | |
---------------------------------------------------------- ----------------------------------------------------------
Missing | | |KeyPres| |Revbit | | Missing | | |KeyPres| |Revbit | |
---------------------------------------------------------- ----------------------------------------------------------
Revoked | | | | | |RemTime| Revoked | | | | | |RemTime|
---------------------------------------------------------- ----------------------------------------------------------
Removed | | | | | | | Removed | | | | | | |
---------------------------------------------------------- ----------------------------------------------------------
State Table
4.1. Events 4.1. Events
NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
That key will become a new trust anchor for the named trust point That key will become a new trust anchor for the named trust point
after its been present in the RRSet for at least 'add time'. after its been present in the RRSet for at least 'add time'.
KeyPres The key has returned to the valid DNSKEY RRSet. KeyPres The key has returned to the valid DNSKEY RRSet.
KeyRem The resolver sees a valid DNSKEY RRSet that does not contain KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
this key. this key.
AddTime The key has been in every valid DNSKEY RRSet seen for at AddTime The key has been in every valid DNSKEY RRSet seen for at
least the 'add time'. least the 'add time'.
RemTime A revoked key has been missing from the trust point DNSKEY RemTime A revoked key has been missing from the trust point DNSKEY
RRSet for sufficient time to be removed from the trust set. RRSet for sufficient time to be removed from the trust set.
RevBit The key has appeared in the trust anchor DNSKEY RRSet with its RevBit The key has appeared in the trust anchor DNSKEY RRSet with
"REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet its "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
signed by this key. signed by this key.
4.2. States 4.2. States
Start The key doesn't yet exist as a trust anchor at the resolver. Start The key doesn't yet exist as a trust anchor at the resolver.
It may or may not exist at the zone server, but hasn't yet been It may or may not exist at the zone server, but hasn't yet been
seen at the resolver. seen at the resolver.
AddPend The key has been seen at the resolver, has its 'SEP' bit set, AddPend The key has been seen at the resolver, has its 'SEP' bit
and has been included in a validated DNSKEY RRSet. There is a set, and has been included in a validated DNSKEY RRSet. There is
hold-down time for the key before it can be used as a trust a hold-down time for the key before it can be used as a trust
anchor. anchor.
Valid The key has been seen at the resolver and has been included in Valid The key has been seen at the resolver and has been included in
all validated DNSKEY RRSets from the time it was first seen up all validated DNSKEY RRSets from the time it was first seen up
through the hold-down time. It is now valid for verifying RRSets through the hold-down time. It is now valid for verifying RRSets
that arrive after the hold down time. Clarification: The DNSKEY that arrive after the hold down time. Clarification: The DNSKEY
RRSet does not need to be continuously present at the resolver RRSet does not need to be continuously present at the resolver
(e.g. its TTL might expire). If the RRSet is seen, and is (e.g. its TTL might expire). If the RRSet is seen, and is
validated (i.e. verifies against an existing trust anchor), this validated (i.e. verifies against an existing trust anchor), this
key MUST be in the RRSet otherwise a 'KeyRem' event is triggered. key MUST be in the RRSet otherwise a 'KeyRem' event is triggered.
Missing This is an abnormal state. The key remains as a valid trust Missing This is an abnormal state. The key remains as a valid trust
skipping to change at page 8, line 46 skipping to change at page 9, line 20
item: Should a missing key be considered revoked after some period item: Should a missing key be considered revoked after some period
of time?] of time?]
Revoked This is the state a key moves to once the resolver sees an Revoked This is the state a key moves to once the resolver sees an
RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
this key with its REVOKE bit set to '1'. Once in this state, this this key with its REVOKE bit set to '1'. Once in this state, this
key MUST permanently be considered invalid as a trust anchor. key MUST permanently be considered invalid as a trust anchor.
Removed After a fairly long hold-down time, information about this Removed After a fairly long hold-down time, information about this
key may be purged from the resolver. A key in the removed state key may be purged from the resolver. A key in the removed state
MUST NOT be considered a valid trust anchor. MUST NOT be considered a valid trust anchor.
4.3. Trust Point Deletion 5. Trust Point Deletion
A trust point which has all of its trust anchors revoked is A trust point which has all of its trust anchors revoked is
considered deleted and is treated as if the trust point was never considered deleted and is treated as if the trust point was never
configured. If there are no superior trust points, data at and below configured. If there are no superior configured trust points, data
the deleted trust point are considered insecure. If there ARE at and below the deleted trust point are considered insecure by the
superior trust points, data at and below the deleted trust point are resolver. If there ARE superior configured trust points, data at and
evaluated with respect to the superior trust point. below the deleted trust point are evaluated with respect to the
superior trust point.
To delete a trust point which is subordinate to another configured
trust point (e.g. example.com to .com) requires some juggling of the
data. The specific process is a) generate a new DNSKEY and DS record
and provide the DS record to the parent along with DS records for the
old keys; b) once the parent has published the DSs, add the new
DNSKEY to the RRSet and revoke ALL of the old keys at the same time
while signing the DNSKEY RRSet with all of the old and new keys; c)
after 30 days remove the old, revoked keys and any corresponding DS
records in the parent.
Revoking the old trust point keys at the same time as adding new keys
that chain to a superior trust prevents the resolver from adding the
new keys as trust anchors. Adding DS records for the old keys avoids
a race condition where either the subordinate zone becomes unsecure
(because the trust point was deleted) or becomes bogus (because it
didn't chain to the superior zone).
Alternately, a trust point which is subordinate to another configured Alternately, a trust point which is subordinate to another configured
trust point MAY be deleted by a resolver after 180 days where such trust point MAY be deleted by a resolver after 180 days where such
trust point validly chains to a superior trust point. The decision trust point validly chains to a superior trust point. The decision
to delete the subordinate trust anchor is a local configuration to delete the subordinate trust anchor is a local configuration
decision. Once the subordinate trust point is deleted, validation of decision. Once the subordinate trust point is deleted, validation of
the subordinate zone is dependent on validating the chain of trust to the subordinate zone is dependent on validating the chain of trust to
the superior trust point. the superior trust point.
5. Scenarios 6. Scenarios - Informative
The suggested model for operation is to have one active key and one The suggested model for operation is to have one active key and one
stand-by key at each trust point. The active key will be used to stand-by key at each trust point. The active key will be used to
sign the DNSKEY RRSet. The stand-by key will not normally sign this sign the DNSKEY RRSet. The stand-by key will not normally sign this
RRSet, but the resolver will accept it as a trust anchor if/when it RRSet, but the resolver will accept it as a trust anchor if/when it
sees the signature on the trust point DNSKEY RRSet. sees the signature on the trust point DNSKEY RRSet.
Since the stand-by key is not in active signing use, the associated Since the stand-by key is not in active signing use, the associated
private key may (and SHOULD) be provided with additional protections private key may (and should) be provided with additional protections
not normally available to a key that must be used frequently. E.g. not normally available to a key that must be used frequently. E.g.
locked in a safe, split among many parties, etc. Notionally, the locked in a safe, split among many parties, etc. Notionally, the
stand-by key should be less subject to compromise than an active key, stand-by key should be less subject to compromise than an active key,
but that will be dependent on operational concerns not addressed but that will be dependent on operational concerns not addressed
here. here.
5.1. Adding A Trust Anchor 6.1. Adding A Trust Anchor
Assume an existing trust anchor key 'A'. Assume an existing trust anchor key 'A'.
1. Generate a new key pair. 1. Generate a new key pair.
2. Create a DNSKEY record from the key pair and set the SEP and Zone 2. Create a DNSKEY record from the key pair and set the SEP and Zone
Key bits. Key bits.
3. Add the DNSKEY to the RRSet. 3. Add the DNSKEY to the RRSet.
4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
'A'. 'A'.
5. Wait a while. 5. Wait a while.
6. The new trust anchor will be populated at the resolvers on the
schedule described by the state table and update algorithm - see
Section 2 above
5.2. Deleting a Trust Anchor 6.2. Deleting a Trust Anchor
Assume existing trust anchors 'A' and 'B' and that you want to revoke Assume existing trust anchors 'A' and 'B' and that you want to revoke
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 6.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 been signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been
in the DNSKEY RRSet and is a valid trust anchor, but wasn't being in the DNSKEY RRSet and is a valid trust anchor, but wasn't 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 6.4. Active Key Compromised
This is the same as the mechanism for Key Roll-Over (Section 5.3) This is the same as the mechanism for Key Roll-Over (Section 6.3)
above assuming 'A' is the active key. above assuming 'A' is the active key.
5.5. Stand-by Key Compromised 6.5. Stand-by Key Compromised
Using the same assumptions and naming conventions as Key Roll-Over Using the same assumptions and naming conventions as Key Roll-Over
(Section 5.3) above: (Section 6.3) above:
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 'B'. 3. Set the revocation bit on key 'B'.
4. Sign the RRSet with 'A' and 'B'. 4. Sign the RRSet with 'A' and 'B'.
'B' is now revoked, 'A' remains the active key, and 'C' will be the 'B' is now revoked, 'A' remains the active key, and 'C' will be the
stand-by key once the hold-down expires. 'B' SHOULD continue to be stand-by key once the hold-down expires. 'B' SHOULD continue to be
included in the RRSet for the remove hold-down time. included in the RRSet for the remove hold-down time.
6. IANA Considerations 6.6. Trust Point Deletion
To delete a trust point which is subordinate to another configured
trust point (e.g. example.com to .com) requires some juggling of the
data. The specific process is:
1. Generate a new DNSKEY and DS record and provide the DS record to
the parent along with DS records for the old keys
2. Once the parent has published the DSs, add the new DNSKEY to the
RRSet and revoke ALL of the old keys at the same time while
signing the DNSKEY RRSet with all of the old and new keys.
3. After 30 days stop publishing the old, revoked keys and remove
any corresponding DS records in the parent.
Revoking the old trust point keys at the same time as adding new keys
that chain to a superior trust prevents the resolver from adding the
new keys as trust anchors. Adding DS records for the old keys avoids
a race condition where either the subordinate zone becomes unsecure
(because the trust point was deleted) or becomes bogus (because it
didn't chain to the superior zone).
7. IANA Considerations
The IANA will need to assign a bit in the DNSKEY flags field (see The IANA will need to assign a bit in the DNSKEY flags field (see
section 4.3 of [RFC3755]) for the REVOKE bit. There are no other section 4.3 of [RFC3755]) for the REVOKE bit. There are no other
IANA actions required. IANA actions required.
7. Security Considerations 8. Security Considerations
7.1. Key Ownership vs Acceptance Policy 8.1. Key Ownership vs Acceptance Policy
The reader should note that, while the zone owner is responsible The reader should note that, while the zone owner is responsible
creating and distributing keys, it's wholly the decision of the creating and distributing keys, it's wholly the decision of the
resolver owner as to whether to accept such keys for the resolver owner as to whether to accept such keys for the
authentication of the zone information. This implies the decision authentication of the zone information. This implies the decision
update trust anchor keys based on trust for a current trust anchor update trust anchor keys based on trust for a current trust anchor
key is also the resolver owner's decision. key is also the resolver owner's decision.
The resolver owner (and resolver implementers) MAY choose to permit The resolver owner (and resolver implementers) MAY choose to permit
or prevent key status updates based on this mechanism for specific or prevent key status updates based on this mechanism for specific
trust points. If they choose to prevent the automated updates, they trust points. If they choose to prevent the automated updates, they
will need to establish a mechanism for manual or other out-of-band will need to establish a mechanism for manual or other out-of-band
updates outside the scope of this document. updates outside the scope of this document.
7.2. Multiple Key Compromise 8.2. Multiple Key Compromise
This scheme permits recovery as long as at least one valid trust This scheme permits recovery as long as at least one valid trust
anchor key remains uncompromised. E.g. if there are three keys, you anchor key remains uncompromised. E.g. if there are three keys, you
can recover if two of them are compromised. The zone owner should can recover if two of them are compromised. The zone owner should
determine their own level of comfort with respect to the number of determine their own level of comfort with respect to the number of
active valid trust anchors in a zone and should be prepared to active valid trust anchors in a zone and should be prepared to
implement recovery procedures once they detect a compromise. A implement recovery procedures once they detect a compromise. A
manual or other out-of-band update of all resolvers will be required manual or other out-of-band update of all resolvers will be required
if all trust anchor keys at a trust point are compromised. if all trust anchor keys at a trust point are compromised.
7.3. Dynamic Updates 8.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.
8. Normative References 9. 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.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer (DS)", RFC 3755, May 2004. Signer (DS)", RFC 3755, May 2004.
skipping to change at page 12, line 30 skipping to change at page 13, line 11
[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.
Editorial Comments Editorial Comments
[msj1] msj: N.B. This table is preliminary and will be revised to
match implementation experience. For example, should there
be a state for "Add hold-down expired, but haven't seen the
new RRSet"?
[msj2] msj: To be assigned. [msj2] msj: To be assigned.
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 Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
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
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 14, line 29 skipping to change at page 14, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
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 provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 37 change blocks. 
92 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/