Automated Updates of DNS Security (DNSSEC) Trust Anchors
RFC 5011
Document | Type |
RFC - Internet Standard
(September 2007; No errata)
Also known as STD 74
|
|
---|---|---|---|
Author | Michael StJohns | ||
Last updated | 2018-12-20 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5011 (Internet Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Mark Townsley | ||
Send notices to | (None) |
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 anShow full document text