mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-31 06:25:31 +00:00
Code Issues Releases Wiki Activity

new draft

Browse Source
This commit is contained in:
Mark Andrews
2006-11-30 23:36:51 +00:00
parent 08ee470dbc
commit 55108aa1a0
1 changed files with 283 additions and 284 deletions
Download Patch File Download Diff File Expand all files Collapse all files

567
doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt → doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt
View File

@@ -1,14 +1,14 @@
Network Working Group M. StJohns
Internet-Draft Nominum, Inc.
Expires: July 14, 2006 January 10, 2006
Intended status: Informational November 29, 2006
Expires: June 2, 2007
Automated Updates of DNSSEC Trust Anchors
draft-ietf-dnsext-trustupdate-timers-02
draft-ietf-dnsext-trustupdate-timers-05
Status of this Memo
@@ -33,7 +33,7 @@ Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 14, 2006.
This Internet-Draft will expire on June 2, 2007.
Copyright Notice
@@ -43,55 +43,54 @@ Abstract
This document describes a means for automated, authenticated and
authorized updating of DNSSEC "trust anchors". The method provides
protection against single key compromise of a key 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
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(s).
This mechanism, if adopted, will require changes to resolver
management behavior (but not resolver resolution behavior), and the
This mechanism will require changes to resolver management behavior
StJohns Expires July 14, 2006 [Page 1]
StJohns Expires June 2, 2007 [Page 1]
Internet-Draft trustanchor-update January 2006
Internet-Draft trustanchor-update November 2006
addition of a single flag bit to the DNSKEY record.
(but not resolver resolution behavior), and the addition of a single
flag bit to the DNSKEY record.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Compliance Nomenclature . . . . . . . . . . . . . . . . . 3
1.2. Changes since -00 . . . . . . . . . . . . . . . . . . . . 3
2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
2.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5
2.4. Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6
2.5. Resolver Parameters . . . . . . . . . . . . . . . . . . . 6
2.5.1. Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6
2.5.2. Remove Hold-Down Time . . . . . . . . . . . . . . . . 6
2.5.3. Minimum Trust Anchors per Trust Point . . . . . . . . 6
2.3. Active Refresh . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Resolver Parameters . . . . . . . . . . . . . . . . . . . 6
2.4.1. Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6
2.4.2. Remove Hold-Down Time . . . . . . . . . . . . . . . . 6
2.4.3. Minimum Trust Anchors per Trust Point . . . . . . . . 6
3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6
4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. States . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 8
5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 9
5.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9
5.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9
5.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 9
5.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10
7.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 10
7.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . . 11
5. Trust Point Deletion . . . . . . . . . . . . . . . . . . . . . 8
6. Scenarios - Informative . . . . . . . . . . . . . . . . . . . 9
6.1. Adding a Trust Anchor . . . . . . . . . . . . . . . . . . 9
6.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9
6.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10
6.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 10
6.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10
6.6. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 11
8.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 11
8.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11
9. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
@@ -109,23 +108,23 @@ Table of Contents
StJohns Expires July 14, 2006 [Page 2]
StJohns Expires June 2, 2007 [Page 2]
Internet-Draft trustanchor-update January 2006
Internet-Draft trustanchor-update November 2006
1. Introduction
As part of the reality of fielding DNSSEC (Domain Name System
Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the
community has come to the realization that there will not be one
signed name space, but rather islands of signed name space each
originating from specific points (i.e. 'trust points') in the DNS
tree. Each of those islands will be identified by the trust point
name, and validated by at least one associated public key. For the
purpose of this document we'll call the association of that name and
a particular key a 'trust anchor'. A particular trust point can have
more than one key designated as a trust anchor.
Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has
come to the realization that there will not be one signed name space,
but rather islands of signed name space each originating from
specific points (i.e. 'trust points') in the DNS tree. Each of those
islands will be identified by the trust point name, and validated by
at least one associated public key. For the purpose of this document
we'll call the association of that name and a particular key a 'trust
anchor'. A particular trust point can have more than one key
designated as a trust anchor.
For a DNSSEC-aware resolver to validate information in a DNSSEC
protected branch of the hierarchy, it must have knowledge of a trust
@@ -159,41 +158,34 @@ Internet-Draft trustanchor-update January 2006
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, [RFC2119].
1.2. Changes since -00
Added the concept of timer triggered resolver queries to refresh the
StJohns Expires July 14, 2006 [Page 3]
StJohns Expires June 2, 2007 [Page 3]
Internet-Draft trustanchor-update January 2006
resolvers view of the trust anchor key RRSet.
Re-submitted expired draft as -01. Updated DNSSEC RFC References.
Draft -02. Added the IANA Considerations section. Added text to
describe what happens if all trust anchors at a trust point are
deleted.
Internet-Draft trustanchor-update November 2006
2. Theory of Operation
The general concept of this mechanism is that existing trust anchors
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
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.
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
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
new key to its valid set of trust anchors for that trust point.
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
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
key is compromised. As another example assuming a single key
compromise, an attacker could add a new key and revoke all the other
old keys.
key is compromised. As another example, assuming a single key
compromise, we need to prevent an attacker from adding a new key and
revoking all the other old keys.
2.1. Revocation
@@ -204,49 +196,54 @@ Internet-Draft trustanchor-update January 2006
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-
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
key as a trust anchor or for any other purposes except validating the
RRSIG over the DNSKEY RRSet specifically for the purpose of
RRSIG it signed over the DNSKEY RRSet specifically for the purpose of
validating the revocation. Unlike the 'Add' operation below,
revocation is immediate and permanent upon receipt of a valid
revocation at the resolver.
A self-signed RRSet is a DNSKEY RRSet which contains the specific
DNSKEY and for which there is a corresponding validated RRSIG record.
It's not a special DNSKEY RRSet, just a way of describing the
validation requirements for that RRSet.
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
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.
In the given example, the attacker could revoke B because it has
StJohns Expires July 14, 2006 [Page 4]
Internet-Draft trustanchor-update January 2006
knowledge of B's private key, but could not revoke A.
StJohns Expires June 2, 2007 [Page 4]
Internet-Draft trustanchor-update November 2006
2.2. Add Hold-Down
Assume two trust point keys A and B. Assume that B has been
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
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
it accepted as valid by resolvers.
then invalidate the compromised key. This would result in both the
attacker and owner being able to sign data in the zone and have it
accepted as valid by resolvers.
To mitigate, but not completely solve, this problem, we add a hold-
down time to the addition of the trust anchor. When the resolver
sees a new SEP key in a validated trust point DNSKEY RRSet, the
resolver starts an acceptance timer, and remembers all the keys that
validated the RRSet. If the resolver ever sees the DNSKEY RRSet
without the new key but validly signed, it stops the acceptance
process and resets the acceptance timer. If all of the keys which
were originally used to validate this key are revoked prior to the
timer expiring, the resolver stops the acceptance process and resets
the timer.
To mitigate but not completely solve this problem, we add a hold-down
time to the addition of the trust anchor. When the resolver sees a
new SEP key in a validated trust point DNSKEY RRSet, the resolver
starts an acceptance timer, and remembers all the keys that validated
the RRSet. If the resolver ever sees the DNSKEY RRSet without the
new key but validly signed, it stops the acceptance process for that
key and resets the acceptance timer. If all of the keys which were
originally used to validate this key are revoked prior to the timer
expiring, the resolver stops the acceptance process and resets the
timer.
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
@@ -270,52 +267,50 @@ Internet-Draft trustanchor-update January 2006
their own (e.g. using the example, signed only by B). This is no
worse than the current situation assuming a compromised key.
2.3. Remove Hold-down
A new key which has been seen by the resolver, but hasn't reached
it's add hold-down time, MAY be removed from the DNSKEY RRSet by the
StJohns Expires July 14, 2006 [Page 5]
Internet-Draft trustanchor-update January 2006
zone owner. If the resolver sees a validated DNSKEY RRSet without
this key, it waits for the remove hold-down time and then, if the key
hasn't reappeared, SHOULD discard any information about the key.
2.4. Active Refresh
2.3. Active Refresh
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
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
RRSet or half the RRSIG expiration interval. The expiration interval
is the amount of time from when the RRSIG was last retrieved until
the expiration time in the RRSIG.
StJohns Expires June 2, 2007 [Page 5]
Internet-Draft trustanchor-update November 2006
RRSet or half the RRSIG expiration interval and no more often than
once per hour. The expiration interval is the amount of time from
when the RRSIG was last retrieved until the expiration time in the
RRSIG.
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
lesser of 1 day or 10% of the original TTL or 10% of the original
expiration interval.
expiration interval. I.e.: retryTime = MAX (1 hour, MIN (1 day, .1 *
origTTL, .1 * expireInterval)).
2.5. Resolver Parameters
2.4. Resolver Parameters
2.5.1. Add Hold-Down Time
2.4.1. Add Hold-Down Time
The add hold-down time is 30 days or the expiration time of the TTL
of the first trust point DNSKEY RRSet which contained the key,
whichever is greater. This ensures that at least two validated
DNSKEY RRSets which contain the new key MUST be seen by the resolver
prior to the key's acceptance.
The add hold-down time is 30 days or the expiration time of the
original TTL of the first trust point DNSKEY RRSet which contained
the new key, whichever is greater. This ensures that at least two
validated DNSKEY RRSets which contain the new key MUST be seen by the
resolver prior to the key's acceptance.
2.5.2. Remove Hold-Down Time
2.4.2. Remove Hold-Down Time
The remove hold-down time is 30 days.
The remove hold-down time is 30 days. This parameter is solely a key
management database bookeeping parameter. Failure to remove
information about the state of defunct keys from the database will
not adversely impact the security of this protocol, but may end up
with a database cluttered with obsolete key information.
2.5.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
per trust point.
@@ -323,35 +318,36 @@ Internet-Draft trustanchor-update January 2006
3. Changes to DNSKEY RDATA Wire Format
Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE'
Bit n [msj2]of the DNSKEY Flags field is designated as the 'REVOKE'
flag. If this bit is set to '1', AND the resolver sees an
RRSIG(DNSKEY) signed by the associated key, then the resolver MUST
consider this key permanently invalid for all purposes except for
validing the revocation.
StJohns Expires July 14, 2006 [Page 6]
Internet-Draft trustanchor-update January 2006
validating the revocation.
4. State Table
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
StJohns Expires June 2, 2007 [Page 6]
Internet-Draft trustanchor-update November 2006
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'.
The resolver's view of the state of the key changes as various events
occur.
[msj1] This is the state of a trust point key as seen from the
resolver. The column on the left indicates the current state. The
header at 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 to the next.
This is the state of a trust point key as seen from the resolver.
The column on the left indicates the current state. The header at
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
to the next.
NEXT STATE
--------------------------------------------------
@@ -370,39 +366,43 @@ Internet-Draft trustanchor-update January 2006
Removed | | | | | | |
----------------------------------------------------------
State Table
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
after its been present in the RRSet for at least 'add time'.
KeyPres The key has returned to the valid DNSKEY RRSet.
KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
after it's been present in the RRSet for at least 'add time'.
KeyPres The key has returned to the valid DNSKEY RRSet.
KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
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'.
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.
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
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
signed by this key.
StJohns Expires July 14, 2006 [Page 7]
StJohns Expires June 2, 2007 [Page 7]
Internet-Draft trustanchor-update January 2006
Internet-Draft trustanchor-update November 2006
4.2. States
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
seen at the resolver.
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 a
hold-down time for the key before it can be used as a trust
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
been seen at the resolver or was seen but was absent from the last
DNSKEY RRSet (e.g. KeyRem event).
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
a hold-down time for the key before it can be used as a trust
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
through the hold-down time. It is now valid for verifying RRSets
that arrive after the hold down time. Clarification: The DNSKEY
@@ -410,31 +410,51 @@ Internet-Draft trustanchor-update January 2006
(e.g. its TTL might expire). If the RRSet is seen, and is
validated (i.e. verifies against an existing trust anchor), this
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
DNSKEY RRSet. This is an abnormal state because the zone operator
should be using the REVOKE bit prior to removal. [Discussion
item: Should a missing key be considered revoked after some period
of time?]
Revoked This is the state a key moves to once the resolver sees an
should be using the REVOKE bit prior to removal.
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
this key with its REVOKE bit set to '1'. Once in this state, this
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
MUST NOT be considered a valid trust anchor.
MUST NOT be considered a valid trust anchor. (Note: this state is
more or less equivalent to the "Start" state, except that it's bad
practice to re-introduce previously used keys - think of this as
the holding state for all the old keys for which the resolver no
longer needs to track state.)
4.3. Trust Point Deletion
5. Trust Point Deletion
A trust point which has all of its trust anchors revoked is
considered deleted and is treated as if the trust point was never
configured. If there are no superior trust points, data at and below
the deleted trust point are considered insecure. If there there ARE
superior trust points, data at and below the deleted trust point are
evaluated with respect to the superior trust point.
configured. If there are no superior configured trust points, data
at and below the deleted trust point are considered insecure by the
resolver. If there ARE superior configured trust points, data at and
below the deleted trust point are evaluated with respect to the
superior trust point(s).
Alternately, a trust point which is subordinate to another configured
trust point MAY be deleted by a resolver after 180 days where such
subordinate trust point validly chains to a superior trust point.
The decision to delete the subordinate trust anchor is a local
5. Scenarios
StJohns Expires June 2, 2007 [Page 8]
Internet-Draft trustanchor-update November 2006
configuration decision. Once the subordinate trust point is deleted,
validation of the subordinate zone is dependent on validating the
chain of trust to the superior trust point.
6. Scenarios - Informative
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
@@ -442,23 +462,15 @@ Internet-Draft trustanchor-update January 2006
RRSet, but the resolver will accept it as a trust anchor if/when it
sees the signature on the trust point DNSKEY RRSet.
StJohns Expires July 14, 2006 [Page 8]
Internet-Draft trustanchor-update January 2006
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.
locked in a safe, split among many parties, etc. Notionally, the
stand-by key should be less subject to compromise than an active key,
but that will be dependent on operational concerns not addressed
here.
5.1. Adding A Trust Anchor
6.1. Adding a Trust Anchor
Assume an existing trust anchor key 'A'.
1. Generate a new key pair.
@@ -467,19 +479,33 @@ Internet-Draft trustanchor-update January 2006
3. Add the DNSKEY to the RRSet.
4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
'A'.
5. Wait a while.
5. Wait a while (i.e. for various resolvers timers to go off and for
them to retrieve the new DNSKEY RRSet and signatures).
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
and delete 'A'.
1. Set the revolcation bit on key 'A'.
1. Set the revocation bit on key 'A'.
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
it from the DNSKEY RRSet.
5.3. Key Roll-Over
StJohns Expires June 2, 2007 [Page 9]
Internet-Draft trustanchor-update November 2006
6.3. Key Roll-Over
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
@@ -490,50 +516,73 @@ Internet-Draft trustanchor-update January 2006
3. Set the revocation bit on key 'A'.
4. Sign the RRSet with 'A' and 'B'.
'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,
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.
StJohns Expires July 14, 2006 [Page 9]
Internet-Draft trustanchor-update January 2006
5.5. Stand-by Key Compromised
6.5. Stand-by Key Compromised
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'.
2. Add 'C' to the DNSKEY RRSet.
3. Set the revocation bit on key 'B'.
4. Sign the RRSet with 'A' and 'B'.
'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.
6.6. Trust Point Deletion
6. IANA Considerations
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
StJohns Expires June 2, 2007 [Page 10]
Internet-Draft trustanchor-update November 2006
(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
section 4.3 of [RFC3755]) for the REVOKE bit. There are no other
IANA actions required.
7. Security Considerations
8. Security Considerations
7.1. Key Ownership vs Acceptance Policy
In addition to the following sections, see also Theory of Operation
above and especially Section 2.2 for related discussions.
The reader should note that, while the zone owner is responsible
8.1. Key Ownership vs Acceptance Policy
The reader should note that, while the zone owner is responsible for
creating and distributing keys, it's wholly the decision of 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 to
update trust anchor keys based on trust for a current trust anchor
key is also the resolver owner's decision.
@@ -543,7 +592,7 @@ Internet-Draft trustanchor-update January 2006
will need to establish a mechanism for manual or other out-of-band
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
anchor key remains uncompromised. E.g. if there are three keys, you
@@ -554,31 +603,29 @@ Internet-Draft trustanchor-update January 2006
manual or other out-of-band update of all resolvers will be required
if all trust anchor keys at a trust point are compromised.
8.3. Dynamic Updates
StJohns Expires July 14, 2006 [Page 10]
Internet-Draft trustanchor-update January 2006
7.3. Dynamic Updates
Allowing a resolver to update its trust anchor set based in-band key
information is potentially less secure than a manual process.
Allowing a resolver to update its trust anchor set based on in-band
key information is potentially less secure than a manual process.
However, given the nature of the DNS, the number of resolvers that
would require update if a trust anchor key were compromised, and the
StJohns Expires June 2, 2007 [Page 11]
Internet-Draft trustanchor-update November 2006
lack of a standard management framework for DNS, this approach is no
worse than the existing situation.
8. Normative References
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer (DS)", RFC 3755, May 2004.
@@ -596,27 +643,8 @@ Internet-Draft trustanchor-update January 2006
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.
[msj3] msj: For discussion: What's the implementation guidance for
resolvers currently with respect to the non-assigned flag
bits? If they consider the flag bit when doing key matching
at the trust anchor, they won't be able to match.
StJohns Expires July 14, 2006 [Page 11]
Internet-Draft trustanchor-update January 2006
Author's Address
@@ -640,41 +668,29 @@ Author's Address
StJohns Expires July 14, 2006 [Page 12]
StJohns Expires June 2, 2007 [Page 12]
Internet-Draft trustanchor-update January 2006
Internet-Draft trustanchor-update November 2006
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
Intellectual Property Rights or other rights that might be claimed to
@@ -699,32 +715,15 @@ Intellectual Property Statement
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
Funding for the RFC Editor function is currently provided by the
Internet Society.
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
StJohns Expires July 14, 2006 [Page 13]
StJohns Expires June 2, 2007 [Page 13]