Automated Updates of DNS Security (DNSSEC) Trust Anchors
RFC 5011

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 06

Network Working Group                                         M. StJohns
Request for Comments: 5011                                   Independent
Category: Standards Track                                 September 2007

        Automated Updates of DNS Security (DNSSEC) Trust Anchors

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document describes a means for automated, authenticated, and
   authorized updating of DNSSEC "trust anchors".  The method provides
   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(s).

   This mechanism will require changes to resolver management behavior
   (but not resolver resolution behavior), and the addition of a single
   flag bit to the DNSKEY record.

StJohns                     Standards Track                     [Page 1]
RFC 5011                  Trust Anchor Update             September 2007

Table of Contents

   1. Introduction ....................................................2
      1.1. Compliance Nomenclature ....................................3
   2. Theory of Operation .............................................3
      2.1. Revocation .................................................4
      2.2. Add Hold-Down ..............................................4
      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 .....................................................6
      4.1. Events .....................................................7
      4.2. States .....................................................7
   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 ...................................12
      8.3. Dynamic Updates ...........................................12
   9. Normative References ...........................................12
   10. Informative References ........................................12

1.  Introduction

   As part of the reality of fielding DNSSEC (Domain Name System
   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 spaces 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
   anchor applicable to that branch.  It may also have more than one

StJohns                     Standards Track                     [Page 2]
RFC 5011                  Trust Anchor Update             September 2007

   trust anchor for any given trust point.  Under current rules, a chain
   of trust for DNSSEC-protected data that chains its way back to ANY
   known trust anchor is considered 'secure'.

   Because of the probable balkanization of the DNSSEC tree due to
   signing voids at key locations, a resolver may need to know literally
   thousands of trust anchors to perform its duties (e.g., consider an