From 99157ebe3aecdcb94ac392e29dae496571f1a489 Mon Sep 17 00:00:00 2001 From: Brian Wellington Date: Tue, 5 Mar 2002 23:55:25 +0000 Subject: [PATCH] update DS draft. --- ...draft-ietf-dnsext-delegation-signer-05.txt | 730 ---------------- ...draft-ietf-dnsext-delegation-signer-06.txt | 800 ++++++++++++++++++ 2 files changed, 800 insertions(+), 730 deletions(-) delete mode 100644 doc/draft/draft-ietf-dnsext-delegation-signer-05.txt create mode 100644 doc/draft/draft-ietf-dnsext-delegation-signer-06.txt diff --git a/doc/draft/draft-ietf-dnsext-delegation-signer-05.txt b/doc/draft/draft-ietf-dnsext-delegation-signer-05.txt deleted file mode 100644 index a52b05131d..0000000000 --- a/doc/draft/draft-ietf-dnsext-delegation-signer-05.txt +++ /dev/null @@ -1,730 +0,0 @@ - - - - - - - DNSEXT Working Group Olafur Gudmundsson - INTERNET-DRAFT January 2002 - - - Updates: RFC 1035, RFC 2535, RFC 3008, RFC 3090. - - - Delegation Signer Resource Record - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - Comments should be sent to the authors or the DNSEXT WG mailing list - namedroppers@ops.ietf.org - - This draft expires on July 5, 2002. - - Copyright Notice - - Copyright (C) The Internet Society (2002). All rights reserved. - - - -Abstract - - The Delegation Signer Resource Record is inserted at a zone cut point - to indicate tha the delegated zone is digitally signed and that the - delegation zone recognizes the indicated key as a valid zone key for - the delegated zone. The DS RR is an modification to the DNS Security - - - -Gudmundsson Expires July 2002 [Page 1] - -INTERNET-DRAFT Delegation Signer Record January 2002 - - - Extensions definition, motivated by operational considerations. The - intent is to use the resource record as an explicit statement about - the delegation, rather than relying on inference. - - This document defines the DS RR, gives examples of how it is used and - the implications of this record on resolvers. This change is not - backwards compatible with RFC 2535. - This document updates RFC1035, RFC2535, RFC3008 and RFC3090. - - -1 - Introduction - - Familiarity with the DNS system [RFC1035], DNS security extensions - [RFC2535] and DNSSEC terminology [RFC3090] is important. - - Experience shows that when the same data can reside in two - administratively different DNS zones, the data frequently gets out of - sync. NS record in a zone indicates that this name is a delegation - and the NS record lists the authorative servers for the real zone. - Based on actual measurements 10-30% of all delegations in the - Internet have differing NS sets at parent and child. There are number - of reasons for this, including lack of communication between parent - and child and bogus name-servers being listed to meet registrar - requirements. - - DNSSEC [RFC2535,RFC3008,RFC3090] specifies that child must have its - KEY set signed by the parent to create a verifiable chain of KEYs. - There has been some debate on where the signed KEY set should reside, - at the child[RFC2535] or at the parent. If the KEY set resides at the - child, maintaining the signed KEY set in the child, requires frequent - two way communication is needed between the two parties. First the - child needs to transmit the key set to parent and then the parent - sends the signed set or signatures to child. Storing the KEY at the - parent simplifies the communication. - - DNSSEC[RFC2535] requires that the parent store NULL key set for - unsecure children, this is intended to be a signal that the child is - unsecure. NULL Key RRset is a waste as a whole signed RRset is used - to effectively communicate one bit of information, child is unsecure. - Chasing down NULL key records complicates resolution process in many - cases as servers for both parent and child need to be queried for KEY - set if the child server does not return a KEY set. Storing the KEY - record only in the parent zone simplifies this and would allow the - elimination of the NULL key set. For large delegation zones the cost - of NULL keys is significant barrier to deployment. - - Another complication of the DNSSEC KEY model is that KEY record is - used to store DNS zone keys and public keys for other protocols. - - - -Gudmundsson Expires July 2002 [Page 2] - -INTERNET-DRAFT Delegation Signer Record January 2002 - - - There are number of potential problems with this including: - 1. KEY set can become quite large if many applications/protocols - store their keys at the zone apex. Possible protocols are IPSEC, - HTTP, SMTP, SSH and others that use public key cryptography. - 2. Key set may require frequent updates. - 3. Probability of compromised/lost keys increases and triggers - emergency key rollover procedures. - 4. Parent may refuse sign key sets with NON DNS zone keys. - 5. Parent may not meet the child's expectations in turnaround time - in resigning the key set. - - Given these and other reasons there is good reason to explore - alternatives to using only KEY records to create chain of trust. - - Some of these problems can be reduced or eliminated by operational - rules or protocol changes. To reduce the number of keys at apex, a - rule to require applications to store their KEY records at the SRV - name for that application is one possibility. Another is to restrict - KEY record to DNS keys only and create a new type for all non DNS - keys. Third possible solution is to ban the storage of non DNS - related keys at zone apex. There are other possible solutions but - they are outside the scope of this document. - - -1.2 - Reserved words - - The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", - "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be - interpreted as described in RFC2119. - -2 - DS (Delegation KEY Signer) - -2.1 - Delegation Signer Record model - - This document presents replacement of the DNSSEC KEY record chain of - trust[RFC2535], that uses a new RR that only reside at the parent. - This record will identify the key(s) that child uses to self sign its - own KEY set. - - The chain of trust is now established by verifying the parent KEY - set, the DS set from the parent and the KEY set at the child. This is - cryptographically equivalent to just using KEY records. - - Communication between the parent and child is greatly reduced, since - the child only needs to notify parent about changes in keys that sign - its apex KEY RRset. Parent is ignorant of all other keys in the - child's apex KEY RRset, furthermore the child maintains full control - over the apex KEY set and its content. Child can maintain any - - - -Gudmundsson Expires July 2002 [Page 3] - -INTERNET-DRAFT Delegation Signer Record January 2002 - - - policies over its DNS and other KEY usage with minimal impact on - parent. Thus if child wants to have frequent key rollover for its DNS - zone keys parent does not need to be aware of it as the child can use - one key to only sign its apex KEY set and other keys to sign the - other record sets in the zone. - - This model fits well with slow roll out of DNSSEC and islands of - security model. In the islands of security model someone that trusts - "good.example." can preconfigure a key from "good.example." as a - trusted keys and from then on trusts any data that is signed by that - key or has a chain of trust to that key. If "example." starts - advertising DS records, "good.example." does not have to change - operations, by suspending self-signing. DS records can also be used - to identify trusted keys instead of KEY records. Another significant - advantage is the information stored in the large delegation zones - reduced, as only signed keying records for secure delegations are - needed, unlike the NULL KEY record at every unsecure delegation. - - The main disadvantage of this approach that verifying delegations KEY - set requires two signature verification operations instead of one in - RFC 2535. There is no impact on the number of signatures verified - for other RR sets. - -2.2 Protocol change - - All DNS servers and resolvers that support DS MUST support OK bit - [RFC3225] and support larger message size[RFC3226]. Each secure - delegation in a secure zone MUST contain a DS RR set. If a query - contains the OK bit, server returning a referral for the delegation - MUST include the following RR sets in the authority section in this - order: - parent NS - DS and SIG(DS) (if present) - parent NXT and SIG(NXT/parent) - This increases the size of referral messages and may cause some or - all glue to be omitted. If DS or NXT RR or their signatures do not - fit inside the DNS message the TC bit must be set. Additional - section processing is not changed. - - If a DS RR set accompanies the NS RR set, this states that the child - zone is secured. If an NS RR set exists without a DS RR set the - intent is to state that the child zone is unsecure. DS sets MUST NOT - appear at non delegations or at zone APEX. - - Following section 2.2.1 replaces RFC2535 sections 2.3.4 and 3.4, - section 2.2.2 replaces RFC3008 section 2.7, RFC3090 updates are in - section 2.2.3. - - - - -Gudmundsson Expires July 2002 [Page 4] - -INTERNET-DRAFT Delegation Signer Record January 2002 - - -2.2.1 RFC2535 2.3.4 and 3.4: Special considerations at delegation points - - DNS security would like to view each zone as a unit of data - completely under the control of the zone owner with each entry - (RRset) signed by a special private key held by the zone manager. - But the DNS protocol views the leaf nodes in a zone, which are also - the apex nodes of a subzone (i.e., delegation points), as "really" - belonging to the subzone. These nodes occur in two master files and - might have RRs signed by both the upper and lower zone's keys. A - retrieval could get a mixture of these RRs and SIGs, especially since - one server could be serving both the zone above and below a - delegation point[RFC 2181]. - - For every secure delegation there MUST be a DS record stored in - parent zone signed by parent zone key. Parent zone MUST NOT contain - KEY record at delegation points. Delegations in parent MAY only - contain following RR types NS, DS, NXT and SIG. NS RR set MUST NOT be - signed. The NXT RR type is the exceptional case that will always - appear differently and authoritatively in both the super-zone and - subzone, if both are secure. - - All secure zones MUST contain a self signed KEY RR set at apex. Upon - verifying the DS set from the parent, the resolver MAY trust any KEY - identified in the DS set as a valid signer of the childs apex KEY - set. Resolvers configured to trust one of the KEY's signing the KEY - set MAY now treat any data signed by the zone keys in the KEY set as - secure. In all other cases resolvers MUST consider the zone - insecure. DS RR MUST NOT appear at zone APEX. - - -2.2.2 Signers name (replaces RFC3008 section 2.7) - - The signer's name field of a data SIG MUST contain the name of the - zone to which the data and signature belong. The combination of - signer's name, key tag, and algorithm MUST identify a zone key if the - SIG is to be considered material. This document defines a standard - policy for DNSSEC validation; local policy may override the standard - policy. - - There are no restrictions on the signer field of a SIG(0) record. - The combination of signer's name, key tag, and algorithm MUST - identify a key if this SIG(0) is to be processed. - - -2.2.4 changes to RFC3090 - - Number of sections of RFC3090 need to be updated to reflect the DS - record. - - - -Gudmundsson Expires July 2002 [Page 5] - -INTERNET-DRAFT Delegation Signer Record January 2002 - - -2.2.4.1 RFC3090: Updates to section 1: Introduction - - Most of the text is still relevant but the words ``NULL key'' are to - be replaced with ``missing DS set''. In section 1.3 the last three - paragraphs discuss the confusion in sections of RFC 2535, that are - replaced in section 2.2.1 above, thus these paragraphs are now - obsolete. - - -2.2.4.2 RFC3090 section 2.1: Globally Secured - - Rule 2.1.b is replaced by following rule: - - 2.1.b. The zone's apex KEY RR set MUST be self signed by a private - key in the KEY RR set. The private key's public companion MUST be a - zone signing KEY RR (2.a) of a mandatory to implement algorithm and - owned by the parent's apex. This KEY must be identified by a signed - DS RR in the parent zone. - - If a zone cannot get a parent to advertise a DS record for it, child - zone cannot be considered globally secured. The only exception to - this is the root zone, for which there is no parent zone - - -2.2.4.3 RFC3090 section 3: Experimental Status. - - The only difference between Experimental status and globally secured - is the missing DS in the parent. All Locally Secured zones are - Experimental. - -2.3 - Comments on protocol changes - - Over the years there has been various discussions on that the - delegation model in DNS is broken as there is no real good way to - assert if delegation exists. In RFC2535 version of DNSSEC the - authentication of a delegation is the NS bit in the NXT bitmap at the - delegation point. Something more explicit is needed and the DS record - addresses this for secure delegations. - - DS record is a major change to DNS as it is the first DNS record that - can only appear on the upper side of a delegation. Adding it will - cause interoperabilty problems and a flag day for DNSSEC. Many old - servers and resolvers MUST be upgraded to take advantage of DS. Some - old servers will be able to be authorative for zones with DS records - but will not add the NXT and DS records to authority section. Same - goes for caching servers, some may even refuse to pass on the DS and - NXT records. - - - - -Gudmundsson Expires July 2002 [Page 6] - -INTERNET-DRAFT Delegation Signer Record January 2002 - - -2.4 Wire format of DS record - - The DS (type=TDB) record consists of algorithm, key tag and SHA-1 - digest of a public key KEY record that is allowed/used to sign the - child's delegation. Other keys MAY sign the child's apex KEY set. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | key tag | algorithm | Digest type | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SHA-1 digest | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | (20 bytes) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - The key tag is calculated as specified in RFC2535, Algorithm MUST be - an algorithm number assigned in the range 1..251 and the algorithm - MUST be allowed to sign DNS data. The digest type is an identifier - for the digest algorithm used. The digest is calculated over the - canonical name of the delegation followed by the whole RDATA of the - KEY record. - - Digest type value 0 is reserved, value 1 is SHA-1, reserving other - types requires IETF standards action. For interoperabilty reasons as - few digest type algorithms should be reserved, the only reason to - reserve another digest type is to increase security. - DS records MUST point to zone KEY records that are allowed to - authenticate DNS data. Protocol MUST be set to 3. Flag field bits 0 - and 6 MUST be set to 0, bit 7 MUST be set to 1. Value of other bits - is not important. - The size of the DS RDATA for type 1(SHA-1) is 24 bytes, regardless of - key size. - -2.4.1 Justifications for fields - - The algorithm and key tag fields are here to allow resolvers to - quickly identify the candidate KEY records to examine. The key tag - adds some greater assurance than SHA-1 digest on its own. SHA-1 is a - strong cryptographic checksum, it is real hard for attacker to - generate a KEY record that has the same SHA-1 digest. Combining the - name of the key and the key data as input to the digest provides - stronger assurance of the binding. - - - -Gudmundsson Expires July 2002 [Page 7] - -INTERNET-DRAFT Delegation Signer Record January 2002 - - - This format allows concise representation of the keys that child will - use, thus keeping down the size of the answer for the delegation, - reducing the probability of packet overflow. The SHA-1 hash is strong - enough to uniquely identify the key. This is similar to the PGP - footprint. The digest type field is there for possible future - expansion. - - DS record is well suited to lists trusted keys for islands of - security in configuration files. - -2.5 Presentation format of DS record - - The presentation format of DS record consists of 2 numbers followed - by digest presented in hex. - foo.example DS 12345 3 1 123456789abcdef67890 - -2.6 Transition issues for installed base - - RFC2535 compliant resolver will assume that all DS secured - delegations are locally secure. This is a bad thing, but the DNSEXT - working group has determined that rather than having to have to deal - with both RFC2535 secured zone and DS secured zone, a rapid adaption - of DS is preferable. Thus the only option for early adopters is to - upgrade to DS as soon as possible. - -2.6.1 Backwards compatibility with RFC2535 and RFC1035 - - This section documents how a resolver determines the type of - delegation. - RFC1035 delegation has: - - RFC1035 NS - - RFC2535 adds the following two cases: - - Secure RFC2535: NS + NXT + SIG(NXT) - NXT bit map contains: NS SIG NXT - Insecure RFC2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT) - NXT bit map contains: NS SIG KEY NXT - KEY must be null-key. - - DS has the following two states: - - Secure DS: NS + DS + SIG(DS) + NXT + SIG(NXT) - NXT bit map contains: NS SIG NXT DS - Insecure DS: NS + NXT + SIG(NXT) - NXT bit map contains: NS SIG KEY NXT - - - - -Gudmundsson Expires July 2002 [Page 8] - -INTERNET-DRAFT Delegation Signer Record January 2002 - - - It is hard for a resolver to determine if a delegation is Secure 2535 - or Insecure DS. This can be overcome by adding a flag to the NXT bit - map but only upgraded resolvers will understand this flag. Having - both parent and child signatures on the keyset may allow old - resolvers to accept zone as secure, but the cost of doing this for a - long time is much higher than just outlaw Sig@Child and force rapid - deployment of DS enabled servers and resolvers. - - RFC 2535 and DS can in theory be deployed in parallel, but this will - require resolvers to deal with RFC 2535 configurations forever. This - document obsoletes NULL KEY in parent zones, that is difficult enough - change that flag day is required. - -3 Resolver Example - - To create a chain of trust resolver goes from trusted KEY to DS to - KEY. - - Assume the key for domain "example." is trusted. Zone "example." - contains at least the following records: - example. SOA - example. NS ns.example. - example. KEY - example. NXT NS SOA KEY SIG NXT - example. SIG(SOA) - example. SIG(NS) - example. SIG(NXT) - example. SIG(KEY) - secure.example. NS ns1.secure.example. - secure.example. DS tag=10243 alg=3 - secure.example. NXT NS SIG NXT DS unsecure.example. - secure.example. SIG(NXT) - secure.example. SIG(DS) - unsecure.example NS ns1.unsecure.example. - unsecure.example. NXT NS SIG NXT .example. - unsecure.example. SIG(NXT) - - In zone "secure.example." following records exist: - secure.example. SOA - secure.example. NS ns1.secure.example. - secure.example. KEY - secure.example. SIG(KEY) - secure.example. SIG(SOA) - secure.example. SIG(NS) - - In this example the trusted key for "example." signs the DS record - for "secure.example.", making that a trusted record. The DS record - states what key is expected to sign the KEY RRset at - - - -Gudmundsson Expires July 2002 [Page 9] - -INTERNET-DRAFT Delegation Signer Record January 2002 - - - "secure.example". Here "secure.example." signs its KEY set with the - KEY identified in the DS set, thus the KEY set is validated and - trusted. - - This example has only one DS record for the child, parents MUST allow - multiple DS records to facilitate key rollover. It is strongly - recommended that the DS set be kept small, 2 or 3 records SHOULD be - sufficient in all cases. - - Resolver determines the security status of "unsecure.example." by - examining the parent NXT for this name. - -3.1 Resolver cost estimates for DS records - - From a RFC2535 resolver point of view for each delegation followed to - chase down an answer one KEY record has to be verified and possibly - some other records based on policy, for example the contents of the - NS set. Once the resolver gets to the appropriate delegation - validating the answer may require verifying one or more signatures. - A simple A record lookup requires at least N delegations to be - verified and 1 RRset. For a DS enabled resolver the cost is 2N+1. - For MX record the cost where the target of the MX record is in the - same zone as the MX record the costs are N+2 and 2N+2. In the case of - negative answer the same ratios hold true. - - Resolver may require an extra query to get the DS record and this may - add to the overall cost of the query, but this is never worse than - chasing down NULL KEY records from the parent in RFC2535 DNSSEC. - - DS adds processing overhead on resolvers, increases the size of - delegation answers but much less than SIG@Parent. - -4 - Security Considerations: - - This document proposes a change to the validation chain of KEY - records in DNS. The change in is not believed to reduce security in - the overall system, in RFC2535 DNSSEC child must communicate keys to - parent and prudent parents will require some authentication on that - handshake. The modified protocol will require same authentication but - allows the child to exert more local control over its own KEY set. - - There is a possibility that an attacker can generate an valid KEY - that matches all the DS fields thus starting to forge data from the - child. This is considered impractical as on average more than 2^80 - keys must be generated before one is found that will match. - - DS record is a change to DNSSEC protocol and there is some installed - base of implementations, as well as text books on how to set up - - - -Gudmundsson Expires July 2002 [Page 10] - -INTERNET-DRAFT Delegation Signer Record January 2002 - - - secured delegations. Implementations that do not understand DS record - will not be able to follow the KEY to DS to KEY chain and consider - all zone secured that way insecure. - -5 - IANA Considerations: - - IANA needs to allocate RR type code for DS from the standard RR type - space. - - IANA needs to open a new registry for the DS type for Digest - algorithms, Defined types are, 0 is Reserved, 1 is SHA-1. Adding new - reservations requires IETF standards action. - -4 Acknowledgments - - Number of people have over the last few years contributed number of - ideas that are captured in this document. The core idea of using one - key to only sign key set, comes from discussions with Bill Manning - and Perry Metzger on how to put in a single root key in all - resolvers. - Alexis Yushin, Brian Wellington, Paul Vixie, Jakob Schlyter, Scott - Rosen, Edward Lewis, Dan Massey, Lars-Johan Liman, Mark Kosters, Olaf - Kolman, Phillip Hallam-Baker, Miek Gieben, Havard Eidnes, Donald - Eastlake 3rd., Randy Bush, David Blacka, Steve Bellovin, Rob Austein, - Derek Atkins, Roy Arends, Harald Alvestrand, and others have provided - useful comments. - -References: - -[RFC1035] P. Mockapetris, ``Domain Names - Implementation and - Specification'', STD 13, RFC 1035, November 1987. - -[RFC2181] R. Elz, R. Bush, ``Clarifications to the DNS Specification'', - RFC 2181, July 1997. - -[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC - 2535, March 1999. - -[RFC3008] B. Wellington, ``Domain Name System Security (DNSSEC) Signing - Authority'', RFC 3008, November 2000. - -[RFC3090] E. Lewis `` DNS Security Extension Clarification on Zone - Status'', RFC 3090, March 2001. - -[RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC - 3225, December 2001. - - - - - -Gudmundsson Expires July 2002 [Page 11] - -INTERNET-DRAFT Delegation Signer Record January 2002 - - -[RFC3226] O. Gudmundsson, ``DNSSEC and IPv6 A6 aware server/resolver - message size requirements'', RFC 3226, December 2001. - - -Author Address - - Olafur Gudmundsson - 3826 Legation Street, NW - Washington, DC, 20015 - USA - - -Appendix A: Changes from Prior versions - -Changes from version 04 - Reworded document to obsolete RFC2535 chain of trust, no backwards - compatibility. Require DS and NXT records in referrals in authority - section. Removed the NODS bit. - Added the requirement for OK bit and Message size. - Rewrote Abstract to better express what is in the document. - Removed size field from examples and simplified them. - -Changes from version 03 - Added strict rules on what KEY records can be pointed to by DS. - -Changes from version 02 - Added text outlawing DS at non delegations. - Added table showing the contents of DS, SIG@child, and RFC1034 - delegations. - Added the NODS type/bit definition to distinguish insecure DS - delegation from secure SIG@child one. - Added the requirement that NXT be returned with referral answers. - Minor text edits. - -Changes from version 01 - Deleted KEY size field as it did not contribute anything but - complexity. - Number of wordsmith changes to make document more readable. - The word CAN was used when SHOULD was intended. - Deleted section 2.4 "Justifications for compact format" moved - relevant text to section 2.2. - Reverse alphabetized the acknowledgments section. - Reorganized sections 1 and 2 for readability. - - - - - - - - -Gudmundsson Expires July 2002 [Page 12] - -INTERNET-DRAFT Delegation Signer Record January 2002 - - -Changes from version 00 - Changed name from DK to DS based on working group comments. - Dropped verbose format based on WG comments. - Added text about TTL issue/problem in caching servers. - Added text about islands of security and clarified the cost impact. - Major editing of arguments and some reordering of text for clarity. - Added section on transition issues. - -Full Copyright Statement - - Copyright (C) The Internet Society (2002). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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." - - - - - - - - - - - - - - - - -Gudmundsson Expires July 2002 [Page 13] diff --git a/doc/draft/draft-ietf-dnsext-delegation-signer-06.txt b/doc/draft/draft-ietf-dnsext-delegation-signer-06.txt new file mode 100644 index 0000000000..431c99d872 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-delegation-signer-06.txt @@ -0,0 +1,800 @@ + + + + + + + DNSEXT Working Group Olafur Gudmundsson + INTERNET-DRAFT March 2002 + + + Updates: RFC 1035, RFC 2535, RFC 3008, RFC 3090. + + + Delegation Signer Resource Record + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as ``work in progress.'' + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + Comments should be sent to the authors or the DNSEXT WG mailing list + namedroppers@ops.ietf.org + + This draft expires on September 1, 2002. + + Copyright Notice + + Copyright (C) The Internet Society (2002). All rights reserved. + + + +Abstract + + The delegation signer (DS) resource record is inserted at a zone cut + (i.e., a delegation point) to indicate that the delegated zone is + digitally signed and that the delegated zone recognizes the indicated + key as a valid zone key for the delegated zone. The DS RR is a + modification to the DNS Security Extensions definition, motivated by + + + +Gudmundsson Expires August 2002 [Page 1] + +INTERNET-DRAFT Delegation Signer Record March 2002 + + + operational considerations. The intent is to use this resource record + as an explicit statement about the delegation, rather than relying on + inference. + + This document defines the DS RR, gives examples of how it is used and + the implications of this record on resolvers. This change is not + backwards compatible with RFC 2535. + This document updates RFC1035, RFC2535, RFC3008 and RFC3090. + + +1 Introduction + + Familiarity with the DNS system [RFC1035], DNS security extensions + [RFC2535] and DNSSEC terminology [RFC3090] is important. + + Experience shows that when the same data can reside in two + administratively different DNS zones, the data frequently gets out of + sync. The presence of an NS RRset in a zone anywhere other than at + the apex indicates a zone cut or delegation. The RDATA of the NS + RRset specifies the authoritative servers for the delegated or + "child" zone. Based on actual measurements, 10-30% of all delegations + on the Internet have differing NS RRsets at parent and child. There + are a number of reasons for this, including a lack of communication + between parent and child and bogus name servers being listed to meet + registrar requirements. + + DNSSEC [RFC2535,RFC3008,RFC3090] specifies that a child zone needs to + have its KEY RRset signed by its parent to create a verifiable chain + of KEYs. There has been some debate on where the signed KEY RRset + should reside, whether at the child [RFC2535] or at the parent. If + the KEY RRset resides at the child, maintaining the signed KEY RRset + in the child requires frequent two-way communication between the two + parties. First the child transmits the KEY RRset to the parent and + then the parent sends the signature(s) to the child. Storing the KEY + RRset at the parent simplifies the communication. + + DNSSEC [RFC2535] requires that the parent store a NULL KEY record for + an unsecure child zone to indicate that the child is unsecure. A NULL + KEY record is a waste: an entire signed RRset is used to communicate + effectively one bit of information--that the child is unsecure. + Chasing down NULL KEY RRsets complicates the resolution process in + many cases, because servers for both parent and child need to be + queried for the KEY RRset if the child server does not return it. + Storing the KEY RRset only in the parent zone simplifies this and + would allow the elimination of the NULL KEY RRsets entirely. For + large delegation zones the cost of NULL keys is a significant barrier + to deployment. + + + + + +Gudmundsson Expires August 2002 [Page 2] + +INTERNET-DRAFT Delegation Signer Record March 2002 + + + Another complication of the DNSSEC key model is that the KEY record + can be used to store public keys for other protocols in addition to + DNSSEC keys. There are number of potential problems with this, + including: + 1. The KEY RRset can become quite large if many applications and + protocols store their keys at the zone apex. Possible protocols are + IPSEC, HTTP, SMTP, SSH and others that use public key cryptography. + 2. The KEY RRset may require frequent updates. + 3. The probability of compromised or lost keys, which trigger + emergency key rollover procedures, increases. + 4. The parent may refuse sign KEY RRsets with non-DNSSEC zone keys. + 5. The parent may not meet the child's expectations in turnaround + time for resigning the KEY RRset. + + Given these and other reasons, there is good reason to explore + alternatives to using only KEY records to create a chain of trust. + + Some of these problems can be reduced or eliminated by operational + rules or protocol changes. To reduce the number of keys at the zone + apex, a rule to require applications to store their KEY records at + the SRV name for that application is one possibility. Another is to + restrict the KEY record to only DNSSEC keys and create a new record + type for all non-DNSSEC keys. A third possible solution is to + prohibit the storage of non-DNSSEC keys at the zone apex. There are + other possible solutions, but they are outside the scope of this + document. + + +1.2 Reserved Words + + The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", + "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be + interpreted as described in RFC2119. + +2 DS (Delegation KEY Signer) + +2.1 Delegation Signer Record Model + + This document presents a replacement for the DNSSEC KEY record chain + of trust [RFC2535] that uses a new RR that resides only at the + parent. This record identifies the key(s) that the child uses to + self-sign its own KEY RRset. + + The chain of trust is now established by verifying the parent KEY + RRset, the DS RRset from the parent and the KEY RRset at the child. + This is cryptographically equivalent to using just KEY records. + + Communication between the parent and child is greatly reduced, since + the child only needs to notify the parent about changes in keys that + + + +Gudmundsson Expires August 2002 [Page 3] + +INTERNET-DRAFT Delegation Signer Record March 2002 + + + sign its apex KEY RRset. The parent is ignorant of all other keys in + the child's apex KEY RRset. Furthermore, the child maintains full + control over the apex KEY RRset and its content. The child can + maintain any policies regarding its KEY usage for DNSSEC and other + applications and protocols with minimal impact on the parent. Thus if + the child wants to have frequent key rollover for its DNS zone keys, + the parent does not need to be aware of it: the child can use one key + to sign only its apex KEY RRset and other keys to sign the other + RRsets in the zone. + + This model fits well with a slow rollout of DNSSEC and the islands of + security model. In this model, someone who trusts "good.example." can + preconfigure a key from "good.example." as a trusted key, and from + then on trusts any data signed by that key or that has a chain of + trust to that key. If "example." starts advertising DS records, + "good.example." does not have to change operations by suspending + self-signing. DS records can also be used to identify trusted keys + instead of KEY records. Another significant advantage is that the + amount of information stored in large delegation zones is reduced: + rather than the NULL KEY record at every unsecure delegation required + by RFC 2535, only secure delegations require additional information + in the form of a signed DS RRset. + + The main disadvantage of this approach is that verifying a zone's KEY + RRset requires two signature verification operations instead of the + one required by RFC 2535. There is no impact on the number of + signatures verified for other types of RRsets. + +2.2 Protocol Change + + All DNS servers and resolvers that support DS MUST support the OK bit + [RFC3225] and a larger message size [RFC3226]. Each secure + delegation in a secure zone MUST contain a DS RRset. If a query + contains the OK bit, a server returning a referral for the delegation + MUST include the following RRsets in the authority section in this + order: + parent NS + DS and SIG(DS) (if present) + parent NXT and SIG(parent NXT) + This increases the size of referral messages and may cause some or + all glue to be omitted. If the DS or NXT RRsets or their signatures + do not fit in the DNS message, the TC bit MUST be set. Additional + section processing is not changed. + + A DS RRset accompanying an NS RRset indicates that the child zone is + secure. If an NS RRset exists without a DS RRset, the child zone is + unsecure. DS RRsets MUST NOT appear at non-delegation points or at a + zone's apex. + + + + +Gudmundsson Expires August 2002 [Page 4] + +INTERNET-DRAFT Delegation Signer Record March 2002 + + + The following section 2.2.1 replaces RFC2535 sections 2.3.4 and 3.4, + section 2.2.2 replaces RFC3008 section 2.7, and RFC3090 updates are + in section 2.2.3. + + +2.2.1 RFC2535 2.3.4 and 3.4: Special Considerations at Delegation Points + + DNS security views each zone as a unit of data completely under the + control of the zone owner with each entry (RRset) signed by a special + private key held by the zone manager. But the DNS protocol views the + leaf nodes in a zone that are also the apex nodes of a child zone + (i.e., delegation points) as "really" belonging to the child zone. + The corresponding domain names appear in two master files and might + have RRsets signed by both the parent and child zones' keys. A + retrieval could get a mixture of these RRsets and SIGs, especially + since one server could be serving both the zone above and below a + delegation point [RFC 2181]. + + For every secure delegation there MUST be a DS RRset stored in the + parent zone signed by the parent zone's private key. The parent zone + MUST NOT contain a KEY RRset at any delegation points. Delegations in + the parent MAY contain only the following RR types: NS, DS, NXT and + SIG. The NS RRset MUST NOT be signed. The NXT RRset is the + exceptional case: it will always appear differently and + authoritatively in both the parent and child zones if both are + secure. + + A secure zones MUST contain a self-signed KEY RRset at its apex. + Upon verifying the DS RRset from the parent, a resolver MAY trust any + KEY identified in the DS RRset as a valid signer of the child's apex + KEY RRset. Resolvers configured to trust one of the keys signing the + KEY RRset MAY now treat any data signed by the zone keys in the KEY + RRset as secure. In all other cases resolvers MUST consider the zone + unsecure. A DS RRset MUST NOT appear at a zone's apex. + + An authoritative server queried for type DS MUST return the DS RRset + in the answer section along with the corresponding NXT RRset in the + authority section. If the server is authoritative for both parent + and child zones, the answer MUST be from the parent. A caching + server MUST behave the same way, returning the DS RRset and the + parent's NXT RRset, if records are available. + + +2.2.2 Signer's Name (replaces RFC3008 section 2.7) + + The signer's name field of a data SIG MUST contain the name of the + zone to which the data and signature belong. The combination of + signer's name, key tag, and algorithm MUST identify a zone key if the + SIG is to be considered material. This document defines a standard + + + +Gudmundsson Expires August 2002 [Page 5] + +INTERNET-DRAFT Delegation Signer Record March 2002 + + + policy for DNSSEC validation; local policy may override the standard + policy. + + There are no restrictions on the signer field of a SIG(0) record. + The combination of signer's name, key tag, and algorithm MUST + identify a key if this SIG(0) is to be processed. + + +2.2.4 Changes to RFC3090 + + A number of sections of RFC3090 need to be updated to reflect the DS + record. + + +2.2.4.1 RFC3090: Updates to section 1: Introduction + + Most of the text is still relevant but the words ``NULL key'' are to + be replaced with ``missing DS RRset''. In section 1.3 the last three + paragraphs discuss the confusion in sections of RFC 2535 that are + replaced in section 2.2.1 above. Therefore, these paragraphs are now + obsolete. + + +2.2.4.2 RFC3090 section 2.1: Globally Secured + + Rule 2.1.b is replaced by the following rule: + + 2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a + private key whose public counterpart MUST appear in a zone signing + KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to- + implement algorithm. This KEY RR MUST be identified by a DS RR in a + signed DS RRset in the parent zone. + + If a zone cannot get its parent to advertise a DS record for it, the + child zone cannot be considered globally secured. The only exception + to this is the root zone, for which there is no parent zone. + + +2.2.4.3 RFC3090 section 3: Experimental Status. + + The only difference between experimental status and globally secured + is the missing DS RRset in the parent zone. All locally secured zones + are experimental. + +2.3 Comments on Protocol Changes + + Over the years there have been various discussions surrounding the + DNS delegation model, declaring it to be broken because there is no + good way to assert if a delegation exists. In the RFC2535 version of + + + +Gudmundsson Expires August 2002 [Page 6] + +INTERNET-DRAFT Delegation Signer Record March 2002 + + + DNSSEC, the presence of the NS bit in the NXT bit map proves there is + a delegation at this name. Something more explicit is needed and the + DS record addresses this need for secure delegations. + + The DS record is a major change to DNS: it is the first resource + record that can appear only on the upper side of a delegation. Adding + it will cause interoperability problems and requires a flag day for + DNSSEC. Many old servers and resolvers MUST be upgraded to take + advantage of DS. Some old servers will be able to be authoritative + for zones with DS records but will not add the NXT and DS records to + the authority section. The same is true for caching servers; in + fact, some may even refuse to pass on the DS and NXT records. + +2.4 Wire Format of the DS record + + The DS (type=TDB) record contains these fields: key tag, algorithm, + digest type, and the digest of a public key KEY record that is + allowed and/or used to sign the child's apex KEY RRset. Other keys + MAY sign the child's apex KEY RRset. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | key tag | algorithm | Digest type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SHA-1 digest | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (20 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The key tag is calculated as specified in RFC2535. Algorithm MUST be + an algorithm number assigned in the range 1..251 and the algorithm + MUST be allowed to sign DNS data. The digest type is an identifier + for the digest algorithm used. The digest is calculated over the + canonical name of the delegated domain name followed by the whole + RDATA of the KEY record. + + Digest type value 0 is reserved, value 1 is SHA-1, and reserving + other types requires IETF standards action. For interoperability + reasons, as few digest algorithms as possible should be reserved. The + only reason to reserve additional digest types is to increase + security. + + + + +Gudmundsson Expires August 2002 [Page 7] + +INTERNET-DRAFT Delegation Signer Record March 2002 + + + DS records MUST point to zone KEY records that are allowed to + authenticate DNS data. The indicated KEY record's protocol field + MUST be set to 3; flag field bits 0 and 6 MUST be set to 0; bit 7 + MUST be set to 1. The value of other bits is not significant for the + purposes of this document. + + The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless + of key size. + +2.4.1 Justifications for Fields + + The algorithm and key tag fields are present to allow resolvers to + quickly identify the candidate KEY records to examine. SHA-1 is a + strong cryptographic checksum: it is computationally infeasible for + an attacker to generate a KEY record that has the same SHA-1 digest. + Combining the name of the key and the key data as input to the digest + provides stronger assurance of the binding. Having the key tag in + the DS record adds greater assurance than the SHA-1 digest alone, as + there are now two different mapping functions that a KEY RR must + match. + + This format allows concise representation of the keys that the child + will use, thus keeping down the size of the answer for the + delegation, reducing the probability of DNS message overflow. The + SHA-1 hash is strong enough to uniquely identify the key and is + similar to the PGP key footprint. The digest type field is present + for possible future expansion. + + The DS record is well suited to listing trusted keys for islands of + security in configuration files. + +2.5 Presentation Format of the DS Record + + The presentation format of the DS record consists of three numbers + (key tag, algorithm and digest type) followed by the digest itself + presented in hex: + foo.example. DS 12345 3 1 123456789abcdef67890 + +2.6 Transition Issues for Installed Base + + No backwards compatibility with RFC2535 is provided. + + RFC2535-compliant resolvers will assume that all DS-secured + delegations are locally secure. This is bad, but the DNSEXT Working + Group has determined that rather than dealing with both + RFC2535-secured zones and DS-secured zones, a rapid adoption of DS is + preferable. Thus the only option for early adopters is to upgrade to + DS as soon as possible. + + + + +Gudmundsson Expires August 2002 [Page 8] + +INTERNET-DRAFT Delegation Signer Record March 2002 + + +2.6.1 Backwards compatibility with RFC2535 and RFC1035 + + This section documents how a resolver determines the type of + delegation. + RFC1035 delegation (in parent) has: + + RFC1035 NS + + RFC2535 adds the following two cases: + + Secure RFC2535: NS + NXT + SIG(NXT) + NXT bit map contains: NS SIG NXT + Unsecure RFC2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT) + NXT bit map contains: NS SIG KEY NXT + KEY must be a NULL key. + + DS has the following two states: + + Secure DS: NS + DS + SIG(DS) + NXT + SIG(NXT) + NXT bit map contains: NS SIG NXT DS + Unsecure DS: NS + NXT + SIG(NXT) + NXT bit map contains: NS SIG NXT + + It is difficult for a resolver to determine if a delegation is secure + RFC 2535 or unsecure DS. This could be overcome by adding a flag to + the NXT bit map, but only upgraded resolvers would understand this + flag, anyway. Having both parent and child signatures for a KEY RRset + might allow old resolvers to accept a zone as secure, but the cost of + doing this for a long time is much higher than just prohibiting RFC + 2535-style signatures at child zone apexes and forcing rapid + deployment of DS-enabled servers and resolvers. + + RFC 2535 and DS can in theory be deployed in parallel, but this would + require resolvers to deal with RFC 2535 configurations forever. This + document obsoletes the NULL KEY in parent zones, which is a difficult + enough change that a flag day is required. + + + + + + + + + + + + + + + + +Gudmundsson Expires August 2002 [Page 9] + +INTERNET-DRAFT Delegation Signer Record March 2002 + + +3 Resolver Example + + To create a chain of trust, a resolver goes from trusted KEY to DS to + KEY. + + Assume the key for domain "example." is trusted. Zone "example." + contains at least the following records: + example. SOA + example. NS ns.example. + example. KEY + example. NXT NS SOA KEY SIG NXT + example. SIG(SOA) + example. SIG(NS) + example. SIG(NXT) + example. SIG(KEY) + secure.example. NS ns1.secure.example. + secure.example. DS tag=10243 alg=3 digest_type=1 + secure.example. NXT NS SIG NXT DS unsecure.example. + secure.example. SIG(NXT) + secure.example. SIG(DS) + unsecure.example NS ns1.unsecure.example. + unsecure.example. NXT NS SIG NXT .example. + unsecure.example. SIG(NXT) + + In zone "secure.example." following records exist: + secure.example. SOA + secure.example. NS ns1.secure.example. + secure.example. KEY + secure.example. SIG(KEY) + secure.example. SIG(SOA) + secure.example. SIG(NS) + + In this example the private key for "example." signs the DS record + for "secure.example.", making that a secure delegation. The DS record + states which key is expected to sign the KEY RRset at + "secure.example.". Here "secure.example." signs its KEY RRset with + the KEY identified in the DS RRset, thus the KEY RRset is validated + and trusted. + + This example has only one DS record for the child, but parents MUST + allow multiple DS records to facilitate key rollover. It is strongly + recommended that the DS RRset be kept small: two or three DS records + SHOULD be sufficient in all cases. + + The resolver determines the security status of "unsecure.example." by + examining the parent zone's NXT record for this name. The absence of + the DS bit indicates an unsecure delegation. + + + + + +Gudmundsson Expires August 2002 [Page 10] + +INTERNET-DRAFT Delegation Signer Record March 2002 + + +3.1 Resolver Cost Estimates for DS Records + + From a RFC2535 resolver point of view, for each delegation followed + to chase down an answer, one KEY RRset has to be verified. + Additional RRsets might also need to be verified based on local + policy (e.g., the contents of the NS RRset). Once the resolver gets + to the appropriate delegation, validating the answer might require + verifying one or more signatures. A simple A record lookup requires + at least N delegations to be verified and one RRset. For a DS-enabled + resolver, the cost is 2N+1. For an MX record, where the target of + the MX record is in the same zone as the MX record, the costs are N+2 + and 2N+2, for RFC 2535 and DS, respectively. In the case of negatives + answer the same ratios hold true. + + The resolver may require an extra query to get the DS record and this + may add to the overall cost of the query, but this is never worse + than chasing down NULL KEY records from the parent in RFC2535 DNSSEC. + + DS adds processing overhead on resolvers and increases the size of + delegation answers, but much less than storing signatures in the + parent zone. + +4 Security Considerations: + + This document proposes a change to the validation chain of KEY + records in DNSSEC. The change is not believed to reduce security in + the overall system. In RFC2535 DNSSEC, the child zone has to + communicate keys to its parent and prudent parents will require some + authentication with that transaction. The modified protocol will + require the same authentication, but allows the child to exert more + local control over its own KEY RRset. + + There is a remote possibility that an attacker could generate a valid + KEY that matches all the DS fields and thus forge data from the + child. This possibility is considered impractical, as on average more + than 2^80 keys would have to be generated before a match would be + found. + + The DS record represents a change to the DNSSEC protocol and there is + an installed base of implementations, as well as textbooks on how to + set up secure delegations. Implementations that do not understand the + DS record will not be able to follow the KEY to DS to KEY chain and + will consider all zones secured that way as unsecure. + + + + + + + + + +Gudmundsson Expires August 2002 [Page 11] + +INTERNET-DRAFT Delegation Signer Record March 2002 + + +5 IANA Considerations: + + IANA needs to allocate an RR type code for DS from the standard RR + type space. + + IANA needs to open a new registry for the DS type for digest + algorithms. Defined types are: 0 is Reserved, 1 is SHA-1. Adding new + reservations requires IETF standards action. + +4 Acknowledgments + + Over the last few years a number of people have contributed ideas + that are captured in this document. The core idea of using one key to + sign only the KEY RRset comes from discussions with Bill Manning and + Perry Metzger on how to put in a single root key in all resolvers. + Alexis Yushin, Brian Wellington, Paul Vixie, Jakob Schlyter, Scott + Rosen, Edward Lewis, Lars-Johan Liman, Matt Larson, Mark Kosters, Dan + Massey, Olaf Kolman, Phillip Hallam-Baker, Miek Gieben, Havard + Eidnes, Donald Eastlake 3rd., Randy Bush, David Blacka, Steve + Bellovin, Rob Austein, Derek Atkins, Roy Arends, Harald Alvestrand, + and others have provided useful comments. + +References: + +[RFC1035] P. Mockapetris, ``Domain Names - Implementation and + Specification'', STD 13, RFC 1035, November 1987. + +[RFC2181] R. Elz, R. Bush, ``Clarifications to the DNS Specification'', + RFC 2181, July 1997. + +[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC + 2535, March 1999. + +[RFC3008] B. Wellington, ``Domain Name System Security (DNSSEC) Signing + Authority'', RFC 3008, November 2000. + +[RFC3090] E. Lewis `` DNS Security Extension Clarification on Zone + Status'', RFC 3090, March 2001. + +[RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC + 3225, December 2001. + +[RFC3226] O. Gudmundsson, ``DNSSEC and IPv6 A6 aware server/resolver + message size requirements'', RFC 3226, December 2001. + + + + + + + + +Gudmundsson Expires August 2002 [Page 12] + +INTERNET-DRAFT Delegation Signer Record March 2002 + + +Author Address + + Olafur Gudmundsson + 3826 Legation Street, NW + Washington, DC, 20015 + USA + + +Appendix A: Changes from Prior versions + +Changes from version 05 + Major wording changes for clarity contributed by Matt Larson. + Added explicit rule that query for type DS MUST be answered from the + upper side of delegation. + +Changes from version 04 + Reworded document to obsolete RFC2535 chain of trust, no backwards + compatibility. Require DS and NXT records in referrals in authority + section. Removed the NODS bit. + Added the requirement for OK bit and Message size. + Rewrote Abstract to better express what is in the document. + Removed size field from examples and simplified them. + +Changes from version 03 + Added strict rules on what KEY records can be pointed to by DS. + +Changes from version 02 + Added text outlawing DS at non delegations. + Added table showing the contents of DS, SIG@child, and RFC1034 + delegations. + Added the NODS type/bit definition to distinguish insecure DS + delegation from secure SIG@child one. + Added the requirement that NXT be returned with referral answers. + Minor text edits. + +Changes from version 01 + Deleted KEY size field as it did not contribute anything but + complexity. + Number of wordsmith changes to make document more readable. + The word CAN was used when SHOULD was intended. + Deleted section 2.4 "Justifications for compact format" moved + relevant text to section 2.2. + Reverse alphabetized the acknowledgments section. + Reorganized sections 1 and 2 for readability. + + + + + + + + +Gudmundsson Expires August 2002 [Page 13] + +INTERNET-DRAFT Delegation Signer Record March 2002 + + +Changes from version 00 + Changed name from DK to DS based on working group comments. + Dropped verbose format based on WG comments. + Added text about TTL issue/problem in caching servers. + Added text about islands of security and clarified the cost impact. + Major editing of arguments and some reordering of text for clarity. + Added section on transition issues. + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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." + + + + + + + + + + + + + + + + + +Gudmundsson Expires August 2002 [Page 14]