draft-ietf-dnsext-trustupdate-timers-05.txt   draft-ietf-dnsext-trustupdate-timers-06.txt 
Network Working Group M. StJohns Network Working Group M. StJohns
Internet-Draft Nominum, Inc. Internet-Draft Independent
Intended status: Informational November 29, 2006 Expires: October 4, 2007 April 2, 2007
Expires: June 2, 2007
Automated Updates of DNSSEC Trust Anchors Automated Updates of DNSSEC Trust Anchors
draft-ietf-dnsext-trustupdate-timers-05 draft-ietf-dnsext-trustupdate-timers-06
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 34 skipping to change at page 1, line 33
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 June 2, 2007. This Internet-Draft will expire on October 4, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
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 N-1 key compromises of N keys in the trust point protection against N-1 key compromises of N keys 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(s). hierarchy, and, ultimately, supplant the existing anchor(s).
skipping to change at page 2, line 37 skipping to change at page 2, line 36
6.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10 6.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10
6.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 10 6.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 10
6.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10 6.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10
6.6. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 10 6.6. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 11 8.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 11
8.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 11 8.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 11
8.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11 8.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11
9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 13
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) [RFC4033] [RFC4034] [RFC4035], the community has Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has
come to the realization that there will not be one signed name space, come to the realization that there will not be one signed name space,
but rather islands of signed name space each originating from but rather islands of signed name space each originating from
specific points (i.e. 'trust points') in the DNS tree. Each of those specific points (i.e. 'trust points') in the DNS tree. Each of those
skipping to change at page 3, line 27 skipping to change at page 3, line 27
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 these 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 replacement/ in the resolvers, but should make trust point key 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].
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 zone operator adds a new SEP key (i.e. a the DNS hierarchy. When a zone operator adds a new SEP key (i.e. a
DNSKEY with the Secure Entry Point bit set) (see [RFC4034]section DNSKEY with the Secure Entry Point bit set) (see [RFC4034], section
2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is 2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is
validated by an existing trust anchor, then the resolver can add the validated by an existing trust anchor, then the resolver can add the
new key to its valid set of trust anchors for that trust point. new key to its set of valid trust anchors for that trust point.
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
attacker to add their own 'valid' data. This implies a need for a attacker to add their own 'valid' data. This implies a need for a
method to revoke an existing key regardless of whether or not that method to revoke an existing key regardless of whether or not that
key is compromised. As another example, assuming a single key key is compromised. As another example, assuming a single key
compromise, we need to prevent an attacker from adding a new key and compromise, we need to prevent an attacker from adding a new key and
revoking all the other old keys. revoking all the other old keys.
2.1. Revocation 2.1. Revocation
skipping to change at page 5, line 44 skipping to change at page 5, line 44
In the given example, the zone owner can recover from a compromise by In the given example, the zone owner can recover from a compromise by
revoking B and adding a new key D and signing the DNSKEY RRSet with revoking B and adding a new key D and signing the DNSKEY RRSet with
both A and B. both A and B.
The reason this does not completely solve the problem has to do with The reason this does not completely solve the problem has to do with
the distributed nature of DNS. The resolver only knows what it sees. the distributed nature of DNS. The resolver only knows what it sees.
A determined attacker who holds one compromised key could keep a A determined attacker who holds one compromised key could keep a
single resolver from realizing that key had been compromised by single resolver from realizing that key had been compromised by
intercepting 'real' data from the originating zone and substituting intercepting 'real' data from the originating zone and substituting
their own (e.g. using the example, signed only by B). This is no their own (e.g., using the example, signed only by B). This is no
worse than the current situation assuming a compromised key. worse than the current situation assuming a compromised key.
2.3. Active Refresh 2.3. Active Refresh
A resolver which has been configured for automatic update of keys A resolver which has been configured for automatic update of keys
from a particular trust point MUST query that trust point (e.g. do a from a particular trust point MUST query that trust point (e.g., do a
lookup for the DNSKEY RRSet and related RRSIG records) no less often lookup for the DNSKEY RRSet and related RRSIG records) no less often
than the lesser of 15 days or half the original TTL for the DNSKEY than the lesser of 15 days or half the original TTL for the DNSKEY
RRSet or half the RRSIG expiration interval and no more often than RRSet or half the RRSIG expiration interval and no more often than
once per hour. The expiration interval is the amount of time from once per hour. The expiration interval is the amount of time from
when the RRSIG was last retrieved until the expiration time in the when the RRSIG was last retrieved until the expiration time in the
RRSIG. RRSIG. I.e.: queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL,
1/2*RRSigExpirationInterval))
If the query fails, the resolver MUST repeat the query until If the query fails, the resolver MUST repeat the query until
satisfied no more often than once an hour and no less often than the satisfied no more often than once an hour and no less often than the
lesser of 1 day or 10% of the original TTL or 10% of the original lesser of 1 day or 10% of the original TTL or 10% of the original
expiration interval. I.e.: retryTime = MAX (1 hour, MIN (1 day, .1 * expiration interval. I.e.: retryTime = MAX (1 hour, MIN (1 day, .1 *
origTTL, .1 * expireInterval)). origTTL, .1 * expireInterval)).
2.4. Resolver Parameters 2.4. Resolver Parameters
2.4.1. Add Hold-Down Time 2.4.1. Add Hold-Down Time
skipping to change at page 6, line 40 skipping to change at page 6, line 41
not adversely impact the security of this protocol, but may end up not adversely impact the security of this protocol, but may end up
with a database cluttered with obsolete key information. with a database cluttered with obsolete key information.
2.4.3. Minimum Trust Anchors per Trust Point 2.4.3. Minimum Trust Anchors per Trust Point
A compliant resolver MUST be able to manage at least five SEP keys A compliant resolver MUST be able to manage at least five SEP keys
per trust point. per trust point.
3. Changes to DNSKEY RDATA Wire Format 3. Changes to DNSKEY RDATA Wire Format
Bit n [msj2]of the DNSKEY Flags field is designated as the 'REVOKE' Bit n of the DNSKEY Flags field is designated as the 'REVOKE' flag.
flag. If this bit is set to '1', AND the resolver sees an If this bit is set to '1', AND the resolver sees an RRSIG(DNSKEY)
RRSIG(DNSKEY) signed by the associated key, then the resolver MUST signed by the associated key, then the resolver MUST consider this
consider this key permanently invalid for all purposes except for key permanently invalid for all purposes except for validating the
validating the revocation. revocation.
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.
skipping to change at page 7, line 21 skipping to change at page 7, line 22
the top shows the next state. The intersection of the two shows the the top shows the next state. The intersection of the two shows the
event that will cause the state to transition from the current state event that will cause the state to transition from the 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 | | | | | | |
---------------------------------------------------------- ----------------------------------------------------------
skipping to change at page 7, line 45 skipping to change at page 8, line 4
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 it's been present in the RRSet for at least 'add time'. after it's 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 RevBit The key has appeared in the trust anchor DNSKEY RRSet with
its "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 either hasn't yet It may or may not exist at the zone server, but either hasn't yet
been seen at the resolver or was seen but was absent from the last been seen at the resolver or was seen but was absent from the last
DNSKEY RRSet (e.g. KeyRem event). DNSKEY RRSet (e.g., KeyRem event).
AddPend The key has been seen at the resolver, has its 'SEP' bit AddPend The key has been seen at the resolver, has its 'SEP' bit
set, and has been included in a validated DNSKEY RRSet. There is set, and has been included in a validated DNSKEY RRSet. There is
a 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
point key, but was not seen at the resolver in the last validated point key, but was not seen at the resolver in the last validated
DNSKEY RRSet. This is an abnormal state because the zone operator DNSKEY RRSet. This is an abnormal state because the zone operator
should be using the REVOKE bit prior to removal. should be using the REVOKE bit prior to removal.
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.
skipping to change at page 9, line 18 skipping to change at page 9, line 23
6. Scenarios - Informative 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.
6.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 (i.e. for various resolvers timers to go off and for 5. Wait a while (i.e. for various resolvers' timers to go off and
them to retrieve the new DNSKEY RRSet and signatures). for them to retrieve the new DNSKEY RRSet and signatures).
6. The new trust anchor will be populated at the resolvers on the 6. The new trust anchor will be populated at the resolvers on the
schedule described by the state table and update algorithm - see schedule described by the state table and update algorithm - see
Section 2 above Section 2 and 4 above.
6.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 revocation bit on key 'A'. 1. Set the revocation 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.
skipping to change at page 11, line 10 skipping to change at page 11, line 12
Revoking the old trust point keys at the same time as adding new keys 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 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 new keys as trust anchors. Adding DS records for the old keys avoids
a race condition where either the subordinate zone becomes unsecure a race condition where either the subordinate zone becomes unsecure
(because the trust point was deleted) or becomes bogus (because it (because the trust point was deleted) or becomes bogus (because it
didn't chain to the superior zone). didn't chain to the superior zone).
7. IANA Considerations 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 7 of [RFC4034]) for the REVOKE bit. There are no other IANA
IANA actions required. actions required.
8. Security Considerations 8. Security Considerations
In addition to the following sections, see also Theory of Operation In addition to the following sections, see also Theory of Operation
above and especially Section 2.2 for related discussions. above and especially Section 2.2 for related discussions.
8.1. Key Ownership vs Acceptance Policy 8.1. Key Ownership vs Acceptance Policy
The reader should note that, while the zone owner is responsible for The reader should note that, while the zone owner is responsible for
creating and distributing keys, it's wholly the decision of the creating and distributing keys, it's wholly the decision of the
skipping to change at page 11, line 36 skipping to change at page 11, line 38
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.
8.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.
8.3. Dynamic Updates 8.3. Dynamic Updates
Allowing a resolver to update its trust anchor set based on in-band Allowing a resolver to update its trust anchor set based on in-band
skipping to change at page 12, line 27 skipping to change at page 12, line 30
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.
Editorial Comments
[msj2] msj: To be assigned.
Author's Address Author's Address
Michael StJohns Michael StJohns
Nominum, Inc. Independent
2385 Bay Road
Redwood City, CA 94063
USA
Phone: +1-301-528-4729 Email: mstjohns@comcast.net
Email: Mike.StJohns@nominum.com
URI: www.nominum.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
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, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE 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.
Intellectual Property 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
 End of changes. 28 change blocks. 
46 lines changed or deleted 37 lines changed or added

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