From ef38731b6fc5e672744be5c5f1272f373fdbddf4 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 14 Jan 2002 22:47:36 +0000 Subject: [PATCH] new rev --- ...draft-ietf-dnsext-delegation-signer-04.txt | 674 ---------------- ...draft-ietf-dnsext-delegation-signer-05.txt | 730 ++++++++++++++++++ 2 files changed, 730 insertions(+), 674 deletions(-) delete mode 100644 doc/draft/draft-ietf-dnsext-delegation-signer-04.txt create mode 100644 doc/draft/draft-ietf-dnsext-delegation-signer-05.txt diff --git a/doc/draft/draft-ietf-dnsext-delegation-signer-04.txt b/doc/draft/draft-ietf-dnsext-delegation-signer-04.txt deleted file mode 100644 index 84f726284d..0000000000 --- a/doc/draft/draft-ietf-dnsext-delegation-signer-04.txt +++ /dev/null @@ -1,674 +0,0 @@ - - - - - - - DNSEXT Working Group Olafur Gudmundsson - INTERNET-DRAFT November 2001 - - - Updates: RFC 1035, RFC 2535, RFC 3008. - - - Delegation Signer record in parent. - - -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 May 20, 2002. - - Copyright Notice - - Copyright (C) The Internet Society (2001). All rights reserved. - - - -Abstract - - The Delegation Signer (DS) RR set is stored in a delegating (parent) - zone at each delegation point, and indicates the keys used in the - delegated (child) zone. The main design goal of the DS RR simplify the - operation of secure delegations by eliminating the need to store the - same RR in parent and child, as is done with the NS RR set and the KEY - - - -Gudmundsson Expires May 2002 [Page 1] - -INTERNET-DRAFT Delegation Signer Record November 2001 - - - set in RFC2535. - Secure resolvers need to take an additional step with DS to verify a - child's KEY RR set. Operationally this schema is much simpler as - operation of the two zones at delegation is now decoupled to great - extent. - This document updates RFC1035, RFC2535 and RFC3008. - - -1 - Introduction - - Familiarity with the DNS system [RFC1035], DNS security extensions - [RFC2535] and DNSSEC terminology [RFC3090] is important. - - 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 is some debate, where the signed KEY set should reside, - parent[Parent] or child[RFC2535]. If the KEY set resides at the child, - 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. If the KEY set - resides at the parent the communication is reduced as the child only - sends changed key sets to parent. - - DNSSEC[RFC2535] requires that the parent store NULL key set for - unsecure children, this 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 allows the elimination of - the NULL key set. - - Another complication of the DNSSEC KEY model is that KEY record is - used to store DNS zone keys and public keys for other protocols. - 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. - - - -Gudmundsson Expires May 2002 [Page 2] - -INTERNET-DRAFT Delegation Signer Record November 2001 - - - 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 proposes an alternative to the KEY record chain of - trust, that uses a special record that can only reside at the parent. - This record will identify the key(s) that child are allowed 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, and the child maintains full control over the - apex KEY set and its content. Child can maintain any 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 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. - - - - - -Gudmundsson Expires May 2002 [Page 3] - -INTERNET-DRAFT Delegation Signer Record November 2001 - - - 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. One further advantage - is the information stored in the parent is minimized, as only records - for secure delegations are needed. - - The main disadvantage of this approach that verifying delegations KEY - set requires twice as many signature verification operations. There - is no impact on the number of signatures verified for other RR sets. - -2.2 Protocol change - - Each secure delegation in a secure zone MUST contain a DS RR set. If - a DS RR set accompanies the NS RR set, the intent is to state 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. - - In a zone that uses DS, insecure delegations MUST have the NODS[TBD] - bit set in the NXT record. This is required to differenciate this - delegation from Secure RFC2535 delegation. - - Updates RFC2535 sections 2.3.4 and 3.4, as well as RFC3008 section - 2.7: - Delegating zones MUST NOT store KEY records for delegations. The only - records that can appear at delegation in parent are NS, SIG, NXT and - DS. - - Zone MUST self sign its apex KEY set, it SHOULD sign it with a key - that corresponds to a DS record in the parent. The KEY used to sign - the apex KEY RRset MAY sign other RRsets in the zone. - - If child apex KEY RRset is not signed with one of the keys specified - in the DS record the child is locally secure[RFC3090] and SHOULD only - be considered secure if the resolver has been configured to trust the - key used. - - Authorative server answering a query with the OK bit[OKbit] set, MUST - include the DS records and NXT record along with signatures in answers - for a delegation and space is available. DS and NXT records SHOULD - have lower priority than address records but higher priority than KEY. - Caching servers SHOULD return the DS and parent NXT record(s) in the - additional section under the same condition. - - - -Gudmundsson Expires May 2002 [Page 4] - -INTERNET-DRAFT Delegation Signer Record November 2001 - - -2.2.1 - Comments on protocol change - - 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 the first DNS record that can only appear on the upper - side of a delegation. NS records appear at both sides as do SIG and - NXT. All other records can only appear at the lower side. This will - cause some problems as servers authorative for parent, reject DS - record even if the server understands unknown types, or will not hand - them out unless explicitly asked. Similarly a nameserver acting as a - authorative for child and as a caching recursive server may never - return the DS record. - - A caching server that supports unkown types, does not care from which - side DS record comes from and thus does not have to be changed. - Different TTL values on the child's NS set and parents DS set can - cause the DS set to expire before the NS set. - - Secure resolvers need to know about the DS record and how to interpret - it. In the worst case, introducing the DS record, doubles the - signatures that need to be checked to validate a KEY set. - -2.3 Wire format of DS record - - The DS (type=TDB) record consists of algorithm, key tag and SHA-1 - digest of the public key KEY record allowed to sign the child's - delegation. - - 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 | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SHA-1 digest | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | (20 bytes) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - -Gudmundsson Expires May 2002 [Page 5] - -INTERNET-DRAFT Delegation Signer Record November 2001 - - - 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 SHA-1 digest is calculated over - the canonical name of the delegation followed by the RDATA of the KEY - record. - DS records MUST NOT point to a null KEY record, and the KEY records - pointed to by DS records MUST have protocol value 3 (DNSSEC). - DS records MUST NOT point to KEY records where flag field has folowing - bit settings, bit 0 (no authentication) is set, bit 6 MUST be set to 0 - and bit 7 MUST be set to 1 (zone key). Settings of other bits are not - important. - The size of the DS RDATA is 23 bytes, regardless of key size. - -2.3.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. - - 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. - - DS record is also well suited to lists trusted keys for islands of - security in configuration files. - -2.4 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 123456789abcdef67890 - - - - - - - - - - - - - - -Gudmundsson Expires May 2002 [Page 6] - -INTERNET-DRAFT Delegation Signer Record November 2001 - - -2.5 Transition issues for installed base - - RFC2535 compliant resolver will assume that all DS secured delegations - are locally secure. This is a bad thing, thus it might be necessary - for a transition period to support both DS and SIG@Child. The cost is - one or more signatures in the answer for KEY records and that early - adopters have to use cumbersome communications that DS solves. #.bp - -2.6 Backwards compatibilty with RFC2535 SIG@child 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 adds 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 NODS - - If the NODS bit is not used, a resover can not determine if this is a - DS delegation zone. Thus is not able to determine if this delegtion is - a secure RFC2535 or a insecure DS. - -2.6.1 NODS support in servers - - NODS is a virtual type, servers MUST refuse to store any record of - this type. No special processing is required on answers. - - - - - - - - - - - - -Gudmundsson Expires May 2002 [Page 7] - -INTERNET-DRAFT Delegation Signer Record November 2001 - - -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. In zone "example." - we have - example. KEY - secure.example. DS tag=10243 alg=3 - secure.example. NS ns1.secure.example. - NS ns2.secure.example. - 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 NS ns2.unsecure.example. - unsecure.example. NXT NS SIG NXT NODS .example. - unsecure.example. SIG(NXT) - - In zone "secure.example." we have - secure.example. SOA - secure.example. NS ns1.secure.example. - NS ns1.secure.example. - secure.example. KEY - KEY - 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 "secure.example". Here - "secure.example." has three different KEY records and the KEY - identified in the DS record signs the KEY set, thus the KEY set is - validated and trusted. Note that one of the other keys in the keyset - actually signs the zone data, and resolvers will trust the signatures - as the key appears in the KEY set. - - This example has only one DS record for the child but there no reason - to outlaw multiple DS records. More than one DS record is needed - during signing key rollover. It is strongly recommended that the DS - set be kept small. - - Resolver determines the security status of "unsecure.example." by - examining the parent size NXT for this name. - - - - - -Gudmundsson Expires May 2002 [Page 8] - -INTERNET-DRAFT Delegation Signer Record November 2001 - - -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 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, Jakob Schlyter, Scott Rosen, Edward - Lewis, Dan Massey, Lars-Johan Liman, Mark Kosters, Olaf Kolman, Miek - Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David Blacka, - Rob Austein, Derek Atkins, Roy Arends, and others have provided useful - comments. - -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 May 2002 [Page 9] - -INTERNET-DRAFT Delegation Signer Record November 2001 - - - 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 allocate RR type code for the virtual NODS record from - the standard RR type space. Note: SINK (40) was never implemented and - that type code can be reused for NODS. - -References: - -[RFC1035] P. Mockapetris, ``Domain Names - Implementation and - Specification'', STD 13, RFC 1035, November 1987. - -[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. - -[OKbit] D. Conrad, ``Indicating Resolver Support of DNSSEC'', work in - progress , April 2001. - -[Parent] R. Gieben, T. Lindgreen, ``Parent stores the child's zone - KEYs'', work in progress , May 2001. - -Author Address - - Olafur Gudmundsson - 3826 Legation Street, NW - Washington, DC, 20015 - USA - - - - - - - - - - - -Gudmundsson Expires May 2002 [Page 10] - -INTERNET-DRAFT Delegation Signer Record November 2001 - - -Appendix A: Changes from Prior versions - -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 distiguish insecure DS - delegation from secure SIG@child one. - Added the requirement that NXT be returned with referal 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. - - -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 (2001). 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 - - - -Gudmundsson Expires May 2002 [Page 11] - -INTERNET-DRAFT Delegation Signer Record November 2001 - - - 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 May 2002 [Page 12] diff --git a/doc/draft/draft-ietf-dnsext-delegation-signer-05.txt b/doc/draft/draft-ietf-dnsext-delegation-signer-05.txt new file mode 100644 index 0000000000..a52b05131d --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-delegation-signer-05.txt @@ -0,0 +1,730 @@ + + + + + + + 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]