draft-ietf-dnsext-trustupdate-timers-01.txt revision 1d24d9f5c9239f60414d1eb78cde8755650b1bed
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceNetwork Working Group M. StJohns
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceInternet-Draft Nominum, Inc.
027e89d47af308db4b41761ca9f847c026b63ec8Andreas GustafssonExpires: February 16, 2006 August 15, 2005
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Automated Updates of DNSSEC Trust Anchors
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce draft-ietf-dnsext-trustupdate-timers-01
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceStatus of this Memo
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce By submitting this Internet-Draft, each author represents that any
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce applicable patent or other IPR claims of which he or she is aware
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce have been or will be disclosed, and any of which he or she becomes
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce aware will be disclosed, in accordance with Section 6 of BCP 79.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Internet-Drafts are working documents of the Internet Engineering
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Task Force (IETF), its areas, and its working groups. Note that
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce other groups may also distribute working documents as Internet-
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Internet-Drafts are draft documents valid for a maximum of six months
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce and may be updated, replaced, or obsoleted by other documents at any
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce time. It is inappropriate to use Internet-Drafts as reference
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce material or to cite them other than as "work in progress."
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce The list of current Internet-Drafts can be accessed at
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce The list of Internet-Draft Shadow Directories can be accessed at
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce This Internet-Draft will expire on February 16, 2006.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceCopyright Notice
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Copyright (C) The Internet Society (2005).
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce This document describes a means for automated, authenticated and
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce authorized updating of DNSSEC "trust anchors". The method provides
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce protection against single key compromise of a key in the trust point
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce key set. Based on the trust established by the presence of a current
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce anchor, other anchors may be added at the same place in the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce hierarchy, and, ultimately, supplant the existing anchor.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce This mechanism, if adopted, will require changes to resolver
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce management behavior (but not resolver resolution behavior), and the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceStJohns Expires February 16, 2006 [Page 1]
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceInternet-Draft trustanchor-update August 2005
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce addition of a single flag bit to the DNSKEY record.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceTable of Contents
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 1.1 Compliance Nomenclature . . . . . . . . . . . . . . . . . 3
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 1.2 Changes since -00 . . . . . . . . . . . . . . . . . . . . 3
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 2.1 Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 2.2 Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 4
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 2.3 Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 2.4 Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 2.5 Resolver Parameters . . . . . . . . . . . . . . . . . . . 6
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 2.5.1 Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 2.5.2 Remove Hold-Down Time . . . . . . . . . . . . . . . . 6
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 2.5.3 Minimum Trust Anchors per Trust Point . . . . . . . . 6
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 4.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 4.2 States . . . . . . . . . . . . . . . . . . . . . . . . . . 7
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 5.1 Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 8
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 5.2 Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 5.3 Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 5.4 Active Key Compromised . . . . . . . . . . . . . . . . . . 9
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 5.5 Stand-by Key Compromised . . . . . . . . . . . . . . . . . 9
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 6.1 Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 6.2 Multiple Key Compromise . . . . . . . . . . . . . . . . . 10
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 6.3 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 10
3d9b2687475344a87c377a5158c41b43a03fc443Andreas Gustafsson 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Intellectual Property and Copyright Statements . . . . . . . . 12
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceStJohns Expires February 16, 2006 [Page 2]
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceInternet-Draft trustanchor-update August 2005
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce1. Introduction
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce As part of the reality of fielding DNSSEC (Domain Name System
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce community has come to the realization that there will not be one
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce signed name space, but rather islands of signed name space each
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce originating from specific points (i.e. 'trust points') in the DNS
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce tree. Each of those islands will be identified by the trust point
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce name, and validated by at least one associated public key. For the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce purpose of this document we'll call the association of that name and
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce a particular key a 'trust anchor'. A particular trust point can have
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce more than one key designated as a trust anchor.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce For a DNSSEC-aware resolver to validate information in a DNSSEC
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce protected branch of the hierarchy, it must have knowledge of a trust
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce anchor applicable to that branch. It may also have more than one
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce trust anchor for any given trust point. Under current rules, a chain
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce of trust for DNSSEC-protected data that chains its way back to ANY
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce known trust anchor is considered 'secure'.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Because of the probable balkanization of the DNSSEC tree due to
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce signing voids at key locations, a resolver may need to know literally
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce thousands of trust anchors to perform its duties. (e.g. Consider an
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce unsigned ".COM".) Requiring the owner of the resolver to manually
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce manage this many relationships is problematic. It's even more
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce problematic when considering the eventual requirement for key
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce replacement/update for a given trust anchor. The mechanism described
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce herein won't help with the initial configuration of the trust anchors
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce in the resolvers, but should make trust point key replacement/
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce rollover more viable.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce As mentioned above, this document describes a mechanism whereby a
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce resolver can update the trust anchors for a given trust point, mainly
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce without human intervention at the resolver. There are some corner
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce cases discussed (e.g. multiple key compromise) that may require
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce manual intervention, but they should be few and far between. This
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce document DOES NOT discuss the general problem of the initial
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce configuration of trust anchors for the resolver.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce1.1 Compliance Nomenclature
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce document are to be interpreted as described in BCP 14, [RFC2119].
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce1.2 Changes since -00
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Added the concept of timer triggered resolver queries to refresh the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceStJohns Expires February 16, 2006 [Page 3]
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceInternet-Draft trustanchor-update August 2005
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce resolvers view of the trust anchor key RRSet.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Re-submitted expired draft as -01. Updated DNSSEC RFC References.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce2. Theory of Operation
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce The general concept of this mechanism is that existing trust anchors
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce can be used to authenticate new trust anchors at the same point in
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce the DNS hierarchy. When a new SEP key is added to a trust point
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce DNSKEY RRSet, and when that RRSet is validated by an existing trust
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce anchor, then the new key can be added to the set of trust anchors.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce There are some issues with this approach which need to be mitigated.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce For example, a compromise of one of the existing keys could allow an
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce attacker to add their own 'valid' data. This implies a need for a
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce method to revoke an existing key regardless of whether or not that
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce key is compromised. As another example assuming a single key
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce compromise, an attacker could add a new key and revoke all the other
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce2.1 Revocation
5f09ce124cad9712a9675f17f83ddc915e734909Andreas Gustafsson Assume two trust anchor keys A and B. Assume that B has been
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce compromised. Without a specific revocation bit, B could invalidate A
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce simply by sending out a signed trust point key set which didn't
5f09ce124cad9712a9675f17f83ddc915e734909Andreas Gustafsson contain A. To fix this, we add a mechanism which requires knowledge
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce of the private key of a DNSKEY to revoke that DNSKEY.
5f09ce124cad9712a9675f17f83ddc915e734909Andreas Gustafsson A key is considered revoked when the resolver sees the key in a self-
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce signed RRSet and the key has the REVOKE bit set to '1'. Once the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce resolver sees the REVOKE bit, it MUST NOT use this key as a trust
c71787bd6356c92e9c7d0a174cd63ab17fcf34c6Eric Luce anchor or for any other purposes except validating the RRSIG over the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce DNSKEY RRSet specifically for the purpose of validating the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce revocation. Unlike the 'Add' operation below, revocation is
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce immediate and permanent upon receipt of a valid revocation at the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce N.B. A DNSKEY with the REVOKE bit set has a different fingerprint
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce than one without the bit set. This affects the matching of a DNSKEY
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce to DS records in the parent, or the fingerprint stored at a resolver
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce used to configure a trust point. [msj3]
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce In the given example, the attacker could revoke B because it has
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce knowledge of B's private key, but could not revoke A.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce2.2 Add Hold-Down
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Assume two trust point keys A and B. Assume that B has been
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceStJohns Expires February 16, 2006 [Page 4]
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceInternet-Draft trustanchor-update August 2005
b9c96971964d87c2705c8dc29300ff8103479ee6Andreas Gustafsson compromised. An attacker could generate and add a new trust anchor
b9c96971964d87c2705c8dc29300ff8103479ee6Andreas Gustafsson key - C (by adding C to the DNSKEY RRSet and signing it with B), and
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce then invalidate the compromised key. This would result in the both
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce the attacker and owner being able to sign data in the zone and have
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce it accepted as valid by resolvers.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce To mitigate, but not completely solve, this problem, we add a hold-
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce down time to the addition of the trust anchor. When the resolver
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce sees a new SEP key in a validated trust point DNSKEY RRSet, the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce resolver starts an acceptance timer, and remembers all the keys that
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce validated the RRSet. If the resolver ever sees the DNSKEY RRSet
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce without the new key but validly signed, it stops the acceptance
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce process and resets the acceptance timer. If all of the keys which
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce were originally used to validate this key are revoked prior to the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce timer expiring, the resolver stops the acceptance process and resets
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Once the timer expires, the new key will be added as a trust anchor
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce the next time the validated RRSet with the new key is seen at the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce resolver. The resolver MUST NOT treat the new key as a trust anchor
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce until the hold down time expires AND it has retrieved and validated a
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce DNSKEY RRSet after the hold down time which contains the new key.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce N.B.: Once the resolver has accepted a key as a trust anchor, the key
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce MUST be considered a valid trust anchor by that resolver until
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce explictly revoked as described above.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce In the given example, the zone owner can recover from a compromise by
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce revoking B and adding a new key D and signing the DNSKEY RRSet with
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce both A and B.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce The reason this does not completely solve the problem has to do with
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce the distributed nature of DNS. The resolver only knows what it sees.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce A determined attacker who holds one compromised key could keep a
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce single resolver from realizing that key had been compromised by
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce intercepting 'real' data from the originating zone and substituting
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce their own (e.g. using the example, signed only by B). This is no
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce worse than the current situation assuming a compromised key.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce2.3 Remove Hold-down
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce A new key which has been seen by the resolver, but hasn't reached
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce it's add hold-down time, MAY be removed from the DNSKEY RRSet by the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce zone owner. If the resolver sees a validated DNSKEY RRSet without
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce this key, it waits for the remove hold-down time and then, if the key
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce hasn't reappeared, SHOULD discard any information about the key.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceStJohns Expires February 16, 2006 [Page 5]
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceInternet-Draft trustanchor-update August 2005
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce2.4 Active Refresh
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce A resolver which has been configured for automatic update of keys
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce from a particular trust point MUST query that trust point (e.g. do a
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce lookup for the DNSKEY RRSet and related RRSIG records) no less often
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce than the lesser of 15 days or half the original TTL for the DNSKEY
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce RRSet or half the RRSIG expiration interval. The expiration interval
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce is the amount of time from when the RRSIG was last retrieved until
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce the expiration time in the RRSIG.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce If the query fails, the resolver MUST repeat the query until
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce satisfied no more often than once an hour and no less often than the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce lesser of 1 day or 10% of the original TTL or 10% of the original
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce expiration interval.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce2.5 Resolver Parameters
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce2.5.1 Add Hold-Down Time
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce The add hold-down time is 30 days or the expiration time of the TTL
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce of the first trust point DNSKEY RRSet which contained the key,
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce whichever is greater. This ensures that at least two validated
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce DNSKEY RRSets which contain the new key MUST be seen by the resolver
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce prior to the key's acceptance.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce2.5.2 Remove Hold-Down Time
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce The remove hold-down time is 30 days.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce2.5.3 Minimum Trust Anchors per Trust Point
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce A compliant resolver MUST be able to manage at least five SEP keys
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce per trust point.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce3. Changes to DNSKEY RDATA Wire Format
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE'
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce flag. If this bit is set to '1', AND the resolver sees an
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce RRSIG(DNSKEY) signed by the associated key, then the resolver MUST
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce consider this key permanently invalid for all purposes except for
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce validing the revocation.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce The most important thing to understand is the resolver's view of any
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce key at a trust point. The following state table describes that view
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce at various points in the key's lifetime. The table is a normative
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce part of this specification. The initial state of the key is 'Start'.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceStJohns Expires February 16, 2006 [Page 6]
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceInternet-Draft trustanchor-update August 2005
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce The resolver's view of the state of the key changes as various events
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce [msj1] This is the state of a trust point key as seen from the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce resolver. The column on the left indicates the current state. The
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce header at the top shows the next state. The intersection of the two
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce shows the event that will cause the state to transition from the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce current state to the next.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce --------------------------------------------------
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce FROM |Start |AddPend |Valid |Missing|Revoked|Removed|
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce ----------------------------------------------------------
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Start | |NewKey | | | | |
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce ----------------------------------------------------------
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce AddPend |KeyRem | |AddTime| | |
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce ----------------------------------------------------------
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Valid | | | |KeyRem |Revbit | |
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce ----------------------------------------------------------
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Missing | | |KeyPres| |Revbit | |
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce ----------------------------------------------------------
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Revoked | | | | | |RemTime|
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce ----------------------------------------------------------
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Removed | | | | | | |
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce ----------------------------------------------------------
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce That key will become a new trust anchor for the named trust point
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce after its been present in the RRSet for at least 'add time'.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce KeyPres The key has returned to the valid DNSKEY RRSet.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce AddTime The key has been in every valid DNSKEY RRSet seen for at
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce least the 'add time'.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce RemTime A revoked key has been missing from the trust point DNSKEY
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce RRSet for sufficient time to be removed from the trust set.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce RevBit The key has appeared in the trust anchor DNSKEY RRSet with its
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce signed by this key.
ab19d688255b3a333a41b4ebe6f4213538e89c2aEric Luce Start The key doesn't yet exist as a trust anchor at the resolver.
ab19d688255b3a333a41b4ebe6f4213538e89c2aEric Luce It may or may not exist at the zone server, but hasn't yet been
ab19d688255b3a333a41b4ebe6f4213538e89c2aEric Luce seen at the resolver.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceStJohns Expires February 16, 2006 [Page 7]
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceInternet-Draft trustanchor-update August 2005
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce AddPend The key has been seen at the resolver, has its 'SEP' bit set,
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce and has been included in a validated DNSKEY RRSet. There is a
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce hold-down time for the key before it can be used as a trust
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Valid The key has been seen at the resolver and has been included in
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce all validated DNSKEY RRSets from the time it was first seen up
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce through the hold-down time. It is now valid for verifying RRSets
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce that arrive after the hold down time. Clarification: The DNSKEY
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce RRSet does not need to be continuously present at the resolver
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce (e.g. its TTL might expire). If the RRSet is seen, and is
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce validated (i.e. verifies against an existing trust anchor), this
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce key MUST be in the RRSet otherwise a 'KeyRem' event is triggered.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Missing This is an abnormal state. The key remains as a valid trust
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce point key, but was not seen at the resolver in the last validated
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce DNSKEY RRSet. This is an abnormal state because the zone operator
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce should be using the REVOKE bit prior to removal. [Discussion
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce item: Should a missing key be considered revoked after some
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce period of time?]
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Revoked This is the state a key moves to once the resolver sees an
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce this key with its REVOKE bit set to '1'. Once in this state, this
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce key MUST permanently be considered invalid as a trust anchor.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Removed After a fairly long hold-down time, information about this
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce key may be purged from the resolver. A key in the removed state
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce MUST NOT be considered a valid trust anchor.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce The suggested model for operation is to have one active key and one
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce stand-by key at each trust point. The active key will be used to
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce sign the DNSKEY RRSet. The stand-by key will not normally sign this
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce RRSet, but the resolver will accept it as a trust anchor if/when it
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce sees the signature on the trust point DNSKEY RRSet.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Since the stand-by key is not in active signing use, the associated
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce private key may (and SHOULD) be provided with additional protections
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce not normally available to a key that must be used frequently. E.g.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce locked in a safe, split among many parties, etc. Notionally, the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce stand-by key should be less subject to compromise than an active key,
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce but that will be dependent on operational concerns not addressed
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce5.1 Adding A Trust Anchor
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Assume an existing trust anchor key 'A'.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 1. Generate a new key pair.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceStJohns Expires February 16, 2006 [Page 8]
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceInternet-Draft trustanchor-update August 2005
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 2. Create a DNSKEY record from the key pair and set the SEP and Zone
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 3. Add the DNSKEY to the RRSet.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 5. Wait a while.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce5.2 Deleting a Trust Anchor
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Assume existing trust anchors 'A' and 'B' and that you want to revoke
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce and delete 'A'.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 1. Set the revolcation bit on key 'A'.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 2. Sign the DNSKEY RRSet with both 'A' and 'B'.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 'A' is now revoked. The operator SHOULD include the revoked 'A' in
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce the RRSet for at least the remove hold-down time, but then may remove
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce it from the DNSKEY RRSet.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce5.3 Key Roll-Over
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Assume existing keys A and B. 'A' is actively in use (i.e. has been
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce used to sign the RRSet.)
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 1. Generate a new key pair 'C'.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 2. Add 'C' to the DNSKEY RRSet.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 3. Set the revocation bit on key 'A'.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 4. Sign the RRSet with 'A' and 'B'.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 'A' is now revoked, 'B' is now the active key, and 'C' will be the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce stand-by key once the hold-down expires. The operator SHOULD include
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce the revoked 'A' in the RRSet for at least the remove hold-down time,
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce but may then remove it from the DNSKEY RRSet.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce5.4 Active Key Compromised
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce This is the same as the mechanism for Key Roll-Over (Section 5.3)
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce above assuming 'A' is the active key.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce5.5 Stand-by Key Compromised
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Using the same assumptions and naming conventions as Key Roll-Over
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce (Section 5.3) above:
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 1. Generate a new key pair 'C'.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 2. Add 'C' to the DNSKEY RRSet.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 3. Set the revocation bit on key 'B'.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 4. Sign the RRSet with 'A' and 'B'.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 'B' is now revoked, 'A' remains the active key, and 'C' will be the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce stand-by key once the hold-down expires. 'B' SHOULD continue to be
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce included in the RRSet for the remove hold-down time.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceStJohns Expires February 16, 2006 [Page 9]
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceInternet-Draft trustanchor-update August 2005
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce6. Security Considerations
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce6.1 Key Ownership vs Acceptance Policy
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce The reader should note that, while the zone owner is responsible
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce creating and distributing keys, it's wholly the decision of the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce resolver owner as to whether to accept such keys for the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce authentication of the zone information. This implies the decision
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce update trust anchor keys based on trust for a current trust anchor
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce key is also the resolver owner's decision.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce The resolver owner (and resolver implementers) MAY choose to permit
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce or prevent key status updates based on this mechanism for specific
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce trust points. If they choose to prevent the automated updates, they
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce will need to establish a mechanism for manual or other out-of-band
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce updates outside the scope of this document.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce6.2 Multiple Key Compromise
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce This scheme permits recovery as long as at least one valid trust
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce anchor key remains uncompromised. E.g. if there are three keys, you
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce can recover if two of them are compromised. The zone owner should
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce determine their own level of comfort with respect to the number of
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce active valid trust anchors in a zone and should be prepared to
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce implement recovery procedures once they detect a compromise. A
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce manual or other out-of-band update of all resolvers will be required
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce if all trust anchor keys at a trust point are compromised.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce6.3 Dynamic Updates
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Allowing a resolver to update its trust anchor set based in-band key
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce information is potentially less secure than a manual process.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce However, given the nature of the DNS, the number of resolvers that
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce would require update if a trust anchor key were compromised, and the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce lack of a standard management framework for DNS, this approach is no
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce worse than the existing situation.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce7. Normative References
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Requirement Levels", BCP 14, RFC 2119, March 1997.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce RFC 2535, March 1999.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Rose, "DNS Security Introduction and Requirements",
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce RFC 4033, March 2005.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceStJohns Expires February 16, 2006 [Page 10]
5f09ce124cad9712a9675f17f83ddc915e734909Andreas GustafssonInternet-Draft trustanchor-update August 2005
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Rose, "Resource Records for the DNS Security Extensions",
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce RFC 4034, March 2005.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Rose, "Protocol Modifications for the DNS Security
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Extensions", RFC 4035, March 2005.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceEditorial Comments
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce [msj1] msj: N.B. This table is preliminary and will be revised to
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce match implementation experience. For example, should there
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce be a state for "Add hold-down expired, but haven't seen the
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce [msj2] msj: To be assigned.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce [msj3] msj: For discussion: What's the implementation guidance for
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce resolvers currently with respect to the non-assigned flag
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce bits? If they consider the flag bit when doing key matching
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce at the trust anchor, they won't be able to match.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceAuthor's Address
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Michael StJohns
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Nominum, Inc.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce 2385 Bay Road
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Redwood City, CA 94063
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Phone: +1-301-528-4729
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Email: Mike.StJohns@nominum.com
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceStJohns Expires February 16, 2006 [Page 11]
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceInternet-Draft trustanchor-update August 2005
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceIntellectual Property Statement
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce The IETF takes no position regarding the validity or scope of any
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Intellectual Property Rights or other rights that might be claimed to
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce pertain to the implementation or use of the technology described in
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce this document or the extent to which any license under such rights
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce might or might not be available; nor does it represent that it has
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce made any independent effort to identify any such rights. Information
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce on the procedures with respect to rights in RFC documents can be
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce found in BCP 78 and BCP 79.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce Copies of IPR disclosures made to the IETF Secretariat and any
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce assurances of licenses to be made available, or the result of an
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce attempt made to obtain a general license or permission for the use of
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce such proprietary rights by implementers or users of this
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce specification can be obtained from the IETF on-line IPR repository at
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce The IETF invites any interested party to bring to its attention any
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce copyrights, patents or patent applications, or other proprietary
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce rights that may cover technology that may be required to implement
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce this standard. Please address the information to the IETF at
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce ietf-ipr@ietf.org.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce The IETF has been notified of intellectual property rights claimed in
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce regard to some or all of the specification contained in this
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric Luce document. For more information consult the online list of claimed
5f09ce124cad9712a9675f17f83ddc915e734909Andreas GustafssonDisclaimer of Validity
5f09ce124cad9712a9675f17f83ddc915e734909Andreas Gustafsson This document and the information contained herein are provided on an
5f09ce124cad9712a9675f17f83ddc915e734909Andreas Gustafsson "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
5f09ce124cad9712a9675f17f83ddc915e734909Andreas Gustafsson OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
5f09ce124cad9712a9675f17f83ddc915e734909Andreas Gustafsson ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
5f09ce124cad9712a9675f17f83ddc915e734909Andreas Gustafsson INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
5f09ce124cad9712a9675f17f83ddc915e734909Andreas Gustafsson INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
5f09ce124cad9712a9675f17f83ddc915e734909Andreas Gustafsson WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
5f09ce124cad9712a9675f17f83ddc915e734909Andreas GustafssonCopyright Statement
5f09ce124cad9712a9675f17f83ddc915e734909Andreas Gustafsson Copyright (C) The Internet Society (2005). This document is subject
5f09ce124cad9712a9675f17f83ddc915e734909Andreas Gustafsson to the rights, licenses and restrictions contained in BCP 78, and
5f09ce124cad9712a9675f17f83ddc915e734909Andreas Gustafsson except as set forth therein, the authors retain all their rights.
5f09ce124cad9712a9675f17f83ddc915e734909Andreas GustafssonStJohns Expires February 16, 2006 [Page 12]
5f09ce124cad9712a9675f17f83ddc915e734909Andreas GustafssonInternet-Draft trustanchor-update August 2005
5f09ce124cad9712a9675f17f83ddc915e734909Andreas Gustafsson Funding for the RFC Editor function is currently provided by the
5f09ce124cad9712a9675f17f83ddc915e734909Andreas Gustafsson Internet Society.
f293a69bcd1c1dd7bdac8f4102fc2398b9e475c8Eric LuceStJohns Expires February 16, 2006 [Page 13]