draft-ietf-dnsext-trustupdate-timers-02.txt   draft-ietf-dnsext-trustupdate-timers-03.txt 
Network Working Group M. StJohns Network Working Group M. StJohns
Internet-Draft Nominum, Inc. Internet-Draft Nominum, Inc.
Expires: July 14, 2006 January 10, 2006 Expires: January 17, 2007 July 16, 2006
Automated Updates of DNSSEC Trust Anchors Automated Updates of DNSSEC Trust Anchors
draft-ietf-dnsext-trustupdate-timers-02 draft-ietf-dnsext-trustupdate-timers-03
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 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 July 14, 2006. This Internet-Draft will expire on January 17, 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
key set. Based on the trust established by the presence of a current key set. Based on the trust established by the presence of a current
anchor, other anchors may be added at the same place in the anchor, other anchors may be added at the same place in the
hierarchy, and, ultimately, supplant the existing anchor. hierarchy, and, ultimately, supplant the existing anchor.
This mechanism, if adopted, will require changes to resolver This mechanism will require changes to resolver management behavior
management behavior (but not resolver resolution behavior), and the (but not resolver resolution behavior), and the addition of a single
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 . . . . . . . . . . . . . . . . . . . . 3
2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
2.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . 6
2.5.3. Minimum Trust Anchors per Trust Point . . . . . . . . 6 2.5.3. Minimum Trust Anchors per Trust Point . . . . . . . . 6
3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 7
4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. States . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. States . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 8 4.3. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 8
5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 9 5.1. Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 9
5.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9 5.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 10
5.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10
5.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 9 5.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 10
5.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10 5.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10 7.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 11
7.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 10 7.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 11
7.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11 7.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 13 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
originating from specific points (i.e. 'trust points') in the DNS originating from specific points (i.e. 'trust points') in the DNS
tree. Each of those islands will be identified by the trust point tree. Each of those islands will be identified by the trust point
name, and validated by at least one associated public key. For the name, and validated by at least one associated public key. For the
skipping to change at page 3, line 52 skipping to change at page 3, line 52
configuration of trust anchors for the resolver. configuration of trust anchors for the resolver.
1.1. Compliance Nomenclature 1.1. Compliance Nomenclature
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, [RFC2119]. document are to be interpreted as described in BCP 14, [RFC2119].
1.2. Changes since -00 1.2. Changes since -00
N.B. This section to be deleted prior to submission to RFC editor.
Added the concept of timer triggered resolver queries to refresh the Added the concept of timer triggered resolver queries to refresh the
resolvers view of the trust anchor key RRSet. resolvers view of the trust anchor key RRSet.
Re-submitted expired draft as -01. Updated DNSSEC RFC References. 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
limitations.
2. Theory of Operation 2. Theory of Operation
The general concept of this mechanism is that existing trust anchors The general concept of this mechanism is that existing trust anchors
can be used to authenticate new trust anchors at the same point in can be used to authenticate new trust anchors at the same point in
the DNS hierarchy. When a new SEP key is added to a trust point the DNS hierarchy. When a new SEP key (see [RFC4034] section 2.1.1)
DNSKEY RRSet, and when that RRSet is validated by an existing trust is added to a trust point DNSKEY RRSet, and when that RRSet is
anchor, then the new key can be added to the set of trust anchors. validated by an existing trust anchor, then the new key can be added
to the set of trust anchors.
There are some issues with this approach which need to be mitigated. There are some issues with this approach which need to be mitigated.
For example, a compromise of one of the existing keys could allow an For example, a compromise of one of the existing keys could allow an
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, an attacker could add a new key and revoke all the other compromise, an attacker could add a new key and revoke all the other
old keys. old keys.
2.1. Revocation 2.1. Revocation
skipping to change at page 4, line 45 skipping to change at page 4, line 51
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 6 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
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 N.B. A DNSKEY with the REVOKE bit set has a different fingerprint
than one without the bit set. This affects the matching of a DNSKEY than one without the bit set. This affects the matching of a DNSKEY
to DS records in the parent, or the fingerprint stored at a resolver to DS records in the parent, or the fingerprint stored at a resolver
used to configure a trust point. [msj3] used to configure a trust point.
In the given example, the attacker could revoke B because it has In the given example, the attacker could revoke B because it has
knowledge of B's private key, but could not revoke A. knowledge of B's private key, but could not revoke A.
2.2. Add Hold-Down 2.2. Add Hold-Down
Assume two trust point keys A and B. Assume that B has been Assume two trust point keys A and B. Assume that B has been
compromised. An attacker could generate and add a new trust anchor compromised. An attacker could generate and add a new trust anchor
key - C (by adding C to the DNSKEY RRSet and signing it with B), and key - C (by adding C to the DNSKEY RRSet and signing it with B), and
then invalidate the compromised key. This would result in the both then invalidate the compromised key. This would result in the both
skipping to change at page 8, line 40 skipping to change at page 8, line 51
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 4.3. 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 trust points, data at and below
the deleted trust point are considered insecure. If there there ARE the deleted trust point are considered insecure. If there ARE
superior trust points, data at and below the deleted trust point are superior trust points, data at and below the deleted trust point are
evaluated with respect to the superior trust point. 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
trust point MAY be deleted by a resolver after 180 days where such
trust point validly chains to a superior trust point. The decision
to delete the subordinate trust anchor is a local 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.
5. Scenarios 5. Scenarios
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
skipping to change at page 11, line 46 skipping to change at page 13, line 5
Editorial Comments Editorial Comments
[msj1] msj: N.B. This table is preliminary and will be revised to [msj1] msj: N.B. This table is preliminary and will be revised to
match implementation experience. For example, should there match implementation experience. For example, should there
be a state for "Add hold-down expired, but haven't seen the be a state for "Add hold-down expired, but haven't seen the
new RRSet"? new RRSet"?
[msj2] msj: To be assigned. [msj2] msj: To be assigned.
[msj3] msj: For discussion: What's the implementation guidance for
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.
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
 End of changes. 19 change blocks. 
29 lines changed or deleted 60 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/