From 82ce657001db1d2c41e984012848c5db58db0d11 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 19 Jun 2003 23:41:31 +0000 Subject: [PATCH] new draft --- ...draft-ietf-dnsext-delegation-signer-14.txt | 914 ---------------- ...draft-ietf-dnsext-delegation-signer-15.txt | 992 ++++++++++++++++++ 2 files changed, 992 insertions(+), 914 deletions(-) delete mode 100644 doc/draft/draft-ietf-dnsext-delegation-signer-14.txt create mode 100644 doc/draft/draft-ietf-dnsext-delegation-signer-15.txt diff --git a/doc/draft/draft-ietf-dnsext-delegation-signer-14.txt b/doc/draft/draft-ietf-dnsext-delegation-signer-14.txt deleted file mode 100644 index bddf377df5..0000000000 --- a/doc/draft/draft-ietf-dnsext-delegation-signer-14.txt +++ /dev/null @@ -1,914 +0,0 @@ - - - - - - - DNSEXT Working Group Olafur Gudmundsson - INTERNET-DRAFT May 2003 - - - 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 December 6, 2003. - - Copyright Notice - - Copyright (C) The Internet Society (2003). 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 December 2003 [Page 1] - -INTERNET-DRAFT Delegation Signer Record February 2003 - - - 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 - registry 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 was thought to simplify 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 December 2003 [Page 2] - -INTERNET-DRAFT Delegation Signer Record February 2003 - - - 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 reasons, SIG@parent isn't any better than SIG/KEY@Child. - - -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 Specification of the Delegation key Signer - - This section defines the Delegation Signer (DS) RR type (type code - TBD) and the changes to DNS to accommodate it. - -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 - 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 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 - - - -Gudmundsson Expires December 2003 [Page 3] - -INTERNET-DRAFT Delegation Signer Record February 2003 - - - a different key to sign the other RRsets in the zone. - - This model fits well with a slow roll out 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. - - Even though DS identifies two roles for KEY's, Key Signing Key (KSK) - and Zone Signing Key (ZSK), there is no requirement that zone use two - different keys for these roles. It is expected that many small zones - will only use one key, while larger organizations will be more likely - to use multiple keys. - -2.2 Protocol Change - - All DNS servers and resolvers that support DS MUST support the OK bit - [RFC3225] and a larger message size [RFC3226]. In order for a - delegation to be considered secure the delegation 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: - If DS RRset is present: - parents copy of childs NS RRset - DS and SIG(DS) - If no DS RRset is present: - parents copy of childs NS RRset - parents zone NXT and SIG(NXT) - - This increases the size of referral messages and possilbly causing - some or all glue to be omitted. If the DS or NXT RRsets with - signatures do not fit in the DNS message, the TC bit MUST be set. - Additional section processing is not changed. - - A DS RRset accompanying a NS RRset indicates that the child zone is - secure. If a NS RRset exists without a DS RRset, the child zone is - unsecure (from the parents point of view). DS RRsets MUST NOT appear - - - -Gudmundsson Expires December 2003 [Page 4] - -INTERNET-DRAFT Delegation Signer Record February 2003 - - - at non-delegation points or at a zone's apex. - - Section 2.2.1 defines special considerations related to authoritative - servers responding to DS queries and replaces RFC2535 sections 2.3.4 - and 3.4. Section 2.2.2 replaces RFC3008 section 2.7, and section - 2.2.3 updates RFC3090. - - -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]. - - Each DS RRset stored in the parent zone MUST be signed by at least - one of the parent zone's private key. The parent zone MUST NOT - contain a KEY RRset at any delegation point. 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 zone 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. - - -2.2.1.1 Special processing for DS queries - - When a server is authoritative for the parent zone at a delegation - point and receives a query for the DS record at that name, it will - return the DS from the parent zone. This is true whether or not it - is also authoritative for the child zone. - - - - - -Gudmundsson Expires December 2003 [Page 5] - -INTERNET-DRAFT Delegation Signer Record February 2003 - - - When the server is authoritative for the child zone at a delegation - point but not the parent zone, there is no natural response, since - the child zone is not authoritative for the DS record at the zone's - apex. As these queries are only expected to originate from recursive - servers which are not DS-aware, the authoritative server MUST answer - with: - RCODE: NOERROR - AA bit: set - Answer Section: Empty - Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)] - - That is, it answers as if it is authoritative and the DS record does - not exist. DS-aware recursive servers will query the parent zone at - delegation points, so will not be affected by this. - - A server authoritative for only the child zone at a delegation point - that is also a caching server MAY (if the RD bit is set in the query) - perform recursion to find the DS record at the delegation point, and - may return the DS record from its cache. In this case, the AA bit - MUST not be set in the response. - - -2.2.1.2 Special processing when child and an ancestor share server" - - Special rules are needed to permit DS RR aware servers to gracefully - interact with older caches which otherwise might falsely label a - server as lame because of the new placement of the DS RR set. - - Such a situation might arise when a server is authoritative for both - a zone and it's grandparent, but not the parent. This sounds like an - obscure example, but it is very real. The root zone is currently - served on 13 machines, and "root-servers.net." is served on 4 of the - same 13, but "net." is served elsewhere. - - When a server receives a query for (, DS, IN), the response - MUST be determined from reading these rules in order: - - - 1) If the server is authoritative for the zone that holds the DS RR - set (i.e., the zone that delegates away, aka the "parent" - zone), the response contains the DS RR set as an authoritative - answer. - - 2) If the server is offering recursive service and the RD bit is set - in the query, the server performs the query itself (according to the - rules for resolvers described below) and returns it's findings. - - 3) If the server is authoritative for the zone that holds the - 's SOA RR set, the response is an authoritative negative - - - -Gudmundsson Expires December 2003 [Page 6] - -INTERNET-DRAFT Delegation Signer Record February 2003 - - - answer as described in 2.2.1.1. - - 4) If the server is authoritative for a zone or zones above the - QNAME, a referral to the most enclosing zone's servers is made. - - 5) If the server is not authoritative for any part of the QNAME, a - response indicating a lame server for QNAME is given. - - Using these rules will require some special processing on the part of - a DS RR aware resolver. To illustrate this, an example is used. - - Assuming a server is authoritative for roots.example.net. and for the - root zone but not the intervening two zones (or the intervening two - label deep zone). Assume that QNAME=roots.example.net., QTYPE=DS, - and QCLASS=IN. - - The resolver will issue this request (assuming no cached data) - expecting a referral to a net. server. Instead, rule number 3 above - applies and a negative answer is returned by the server. The - reaction by the resolver is not to accept this answer as final as it - can determine from the SOA RR in the negative answer the context - within which the server has answered. - - A solution to this is to instruct the resolver to hunt for the - authoritative zone of the data in a brute force manner. - - This can be accomplished by taking the owner name of the returned SOA - RR and strip off enough left-hand labels until a successful NS - response is obtained. A successful response here means that the - answer has NS records in it. (Entertaining the possibility that a - cut point may be two labels down in a zone.) - - Returning to the example, the response will include a negative answer - with either the SOA RR for "roots.example.net." or "example.net." - depending on whether roots.example.net is a delegated domain. In - either case, removing the least significant label of the SOA owner - name will lead to the location of the desired data. - - -2.2.1.3 Modification on KEY RR in the construction of Responses - - This section updates RFC2535 section 3.5 by replacing it with the - following: - - An query for KEY RR MUST NOT trigger any additional section - processing. Security aware resolver will include corresponding SIG - records in the answer section. - - - - - -Gudmundsson Expires December 2003 [Page 7] - -INTERNET-DRAFT Delegation Signer Record February 2003 - - - KEY records SHOULD NOT be added to additional records section in - response to any query. - - RFC2535 included rules to in add KEY records to additional section - when SOA or NS records where included in an answer. The is was done - to reduce round trips (in the case of SOA) and to force out NULL - KEY's (in the NS case), as this document obsoletes NULL keys there is - no need for the second case, the first case causes redundant - transfers of KEY RRset as SOA is included in the authority section of - negative answers. - - RFC2535 section 3.5 also included rule for adding KEY RRset to query - for A and AAAA, as Restrict KEY[RFC3445] eliminated use of KEY RR by - all applications therfore the rule is not needed anymore. - - -2.2.2 Signer's Name (replaces RFC3008 section 2.7) - - The signer's name field of a SIG RR 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.3 Changes to RFC3090 - - A number of sections of RFC3090 need to be updated to reflect the DS - record. - - -2.2.3.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.3.2 RFC3090 section 2.1: Globally Secured - - Rule 2.1.b is replaced by the following rule: - - - - - -Gudmundsson Expires December 2003 [Page 8] - -INTERNET-DRAFT Delegation Signer Record February 2003 - - - 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.3.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.2.4 NULL KEY elimination - - RFC3445 section 3 elminates the top two bits in the flags field of - KEY RR. These two bits where used to indicate NULL KEY or NO KEY. - RFC3090 defines that zone that defines that zone is either secure or - not, eliminates the possible need to put NULL keys in the zone apex - to indicate that the zone is not secured for a algorithm. Along with - this document these other two elminate all uses for the NULL KEY, - Thus this document obsoletes NULL KEY. - -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 - 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 interoperabilty 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 or DS records to - the authority section. The same is true for caching servers; in - fact, some may even refuse to pass on the DS or NXT records. - - - - - - - -Gudmundsson Expires December 2003 [Page 9] - -INTERNET-DRAFT Delegation Signer Record February 2003 - - -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 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | digest (length depends on type) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | (SHA-1 digest is 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 (all four fields). - - digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata) - - KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key - - Digest type value 0 is reserved, value 1 is SHA-1, and reserving - other types requires IETF standards action. For interoperabilty - reasons, as few digest algorithms as possible should be reserved. The - only reason to reserve additional digest types is to increase - security. - - 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 bit 7 MUST be set to 1. The value of - other flag 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, new digest types probably will have larger digests. - - - - - -Gudmundsson Expires December 2003 [Page 10] - -INTERNET-DRAFT Delegation Signer Record February 2003 - - -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 rdata 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: - example. DS 12345 3 1 123456789abcdef67890123456789abcdef67890 - -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. - -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: - - - -Gudmundsson Expires December 2003 [Page 11] - -INTERNET-DRAFT Delegation Signer Record February 2003 - - - 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. - - DNSSEC with DS has the following two states: - - Secure DS: NS + DS + SIG(DS) - 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. - -2.7 KEY and corresponding DS record example - - This is an example of a KEY record and the corresponding DS record. - - dskey.example. KEY 256 3 1 ( - AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj - 4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt - ) ; key id = 28668 - DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE - - - - - - - - - - - - - - - - -Gudmundsson Expires December 2003 [Page 12] - -INTERNET-DRAFT Delegation Signer Record February 2003 - - -3 Resolver - -3.1 DS 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 secure.example. - example. SIG(SOA) - example. SIG(NS) - example. SIG(NXT) - example. SIG(KEY) - secure.example. NS ns1.secure.example. - secure.example. DS tag=12345 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. KEY - secure.example. NXT - secure.example. SIG(KEY) - secure.example. SIG(SOA) - secure.example. SIG(NS) - secure.example. SIG(NXT) - - 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 and multiple KEY - algorithms. - - - - - -Gudmundsson Expires December 2003 [Page 13] - -INTERNET-DRAFT Delegation Signer Record February 2003 - - - 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. Note the NXT record - SHOULD only be examined after verifying the corresponding signature. - -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, of a specific DS set, and thus - forge data from the child. This possibility is considered - impractical, as on average more than - 2 ^ (160 - ) - keys would have to be generated before a match would be found. - - An attacker that wants to match any DS record will have to generate - on average at least 2^80 keys. - - 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 - - - -Gudmundsson Expires December 2003 [Page 14] - -INTERNET-DRAFT Delegation Signer Record February 2003 - - - 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. - -5 IANA Considerations: - - IANA needs to allocate an RR type code for DS from the standard RR - type space (type 43 requested). - - IANA needs to open a new registry for the DS RR type for digest - algorithms. Defined types are: - 0 is Reserved, - 1 is SHA-1. - Adding new reservations requires IETF standards action. - -6 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, Sam Weiler, Paul Vixie, Jakob - Schlyter, Scott Rose, 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, Mark - Andrews, Harald Alvestrand, and others have provided useful comments. - -Normative 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. - -[RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC - 3225, December 2001. - -[RFC3445] D. Massey, S. Rose ``Limiting the scope of the KEY Resource - Record (RR)``, RFC 3445, December 2002. - - - - - -Gudmundsson Expires December 2003 [Page 15] - -INTERNET-DRAFT Delegation Signer Record February 2003 - - -Informational References - -[RFC2181] R. Elz, R. Bush, ``Clarifications to the DNS Specification'', - RFC 2181, July 1997. - -[RFC3226] O. Gudmundsson, ``DNSSEC and IPv6 A6 aware server/resolver - message size requirements'', RFC 3226, December 2001. - -Author Address - - Olafur Gudmundsson - 3821 Village Park Drive - Chevy Chase, MD, 20815 - USA - - -Full Copyright Statement - - Copyright (C) The Internet Society (2003). 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 December 2003 [Page 16] diff --git a/doc/draft/draft-ietf-dnsext-delegation-signer-15.txt b/doc/draft/draft-ietf-dnsext-delegation-signer-15.txt new file mode 100644 index 0000000000..2164a10a71 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-delegation-signer-15.txt @@ -0,0 +1,992 @@ + + + + + + + DNSEXT Working Group Olafur Gudmundsson + INTERNET-DRAFT June 2003 + + + 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 + + This draft expires on January 19, 2004. + + Copyright Notice + + Copyright (C) The Internet Society (2003). 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 + operational considerations. The intent is to use this resource record + as an explicit statement about the delegation, rather than relying on + inference. + + + + Gudmundsson Expires January 2004 [Page 1] + +INTERNET-DRAFT Delegation Signer Record June 2003 + + + This document defines the DS RR, gives examples of how it is used and + describes the implications on resolvers. This change is not backwards + compatible with RFC 2535. + This document updates RFC1035, RFC2535, RFC3008 and RFC3090. + + Table of contents + + Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . . 1 + Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 + Table of contents . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2 Reserved Words" . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2 Specification of the Delegation key Signer" . . . . . . . . . . . 4 + 2.1 Delegation Signer Record Model" . . . . . . . . . . . . . . . . 4 + 2.2 Protocol Change" . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.2.1 RFC2535 2.3.4 and 3.4: Special Considerations at + Delegation Points" . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.2.1.1 Special processing for DS queries" . . . . . . . . . . . . 6 + 2.2.1.2 Special processing when child and an ancestor share + server" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.2.1.3 Modification on use of KEY RR in the construction of + Responses" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 2.2.2 Signer's Name (replaces RFC3008 section 2.7)" . . . . . . . . 9 + 2.2.3 Changes to RFC3090" . . . . . . . . . . . . . . . . . . . . . 9 + 2.2.3.1 RFC3090: Updates to section 1: Introduction" . . . . . . . . 9 + 2.2.3.2 RFC3090 section 2.1: Globally Secured" . . . . . . . . . . . 9 + 2.2.3.3 RFC3090 section 3: Experimental Status." . . . . . . . . . 10 + 2.2.4 NULL KEY elimination" . . . . . . . . . . . . . . . . . . . . 10 + 2.3 Comments on Protocol Changes" . . . . . . . . . . . . . . . . . 10 + 2.4 Wire Format of the DS record" . . . . . . . . . . . . . . . . . 11 + 2.4.1 Justifications for Fields" . . . . . . . . . . . . . . . . . . 12 + 2.5 Presentation Format of the DS Record" . . . . . . . . . . . . . 12 + 2.6 Transition Issues for Installed Base" . . . . . . . . . . . . . 12 + 2.6.1 Backwards compatibility with RFC2535 and RFC1035" . . . . . . 12 + 2.7 KEY and corresponding DS record example" . . . . . . . . . . . . 13 + 3 Resolver" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.1 DS Example" . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.2 Resolver Cost Estimates for DS Records" . . . . . . . . . . . . 15 + 4 Security Considerations: " . . . . . . . . . . . . . . . . . . . . 15 + 5 IANA Considerations: " . . . . . . . . . . . . . . . . . . . . . . 16 + 6 Acknowledgments" . . . . . . . . . . . . . . . . . . . . . . . . . 16 + Normative References: " . . . . . . . . . . . . . . . . . . . . . . 16 + Informational References" " . . . . . . . . . . . . . . . . . . . . 17 + Author Address" . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + Full Copyright Statement" . . . . . . . . . . . . . . . . . . . . . 17 + + + + + + + + + + Gudmundsson Expires January 2004 [Page 2] + +INTERNET-DRAFT Delegation Signer Record June 2003 + + + 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 + registry 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 was thought to simplify 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. + + Prior to the restrictions imposed by RFC3445[RFC3445], another + implication of the DNSSEC key model is that the KEY record could 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. + + + + Gudmundsson Expires January 2004 [Page 3] + +INTERNET-DRAFT Delegation Signer Record June 2003 + + + 4. The parent may refuse to sign KEY RRsets with non-DNSSEC zone + keys. + 5. The parent may not meet the child's expectations of turnaround + time for resigning the KEY RRset. + + Given these reasons, SIG@parent isn't any better than SIG/KEY@Child. + + + 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 Specification of the Delegation key Signer + + This section defines the Delegation Signer (DS) RR type (type code + TBD) and the changes to DNS to accommodate it. + + 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. + + Even though DS identifies two roles for KEYs, Key Signing Key (KSK) + and Zone Signing Key (ZSK), there is no requirement that zone use two + different keys for these roles. It is expected that many small zones + will only use one key, while larger zones will be more likely to use + multiple keys. + + 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 + 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 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 + a different key to sign the other RRsets in the zone. + + This model fits well with a slow roll out of DNSSEC and the islands + of security model. In this model, someone who trusts "good.example." + + + + Gudmundsson Expires January 2004 [Page 4] + +INTERNET-DRAFT Delegation Signer Record June 2003 + + + 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 be used in configuration files 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 demanded 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 in RFC 2535 chain of trust. 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]. In order for a + delegation to be considered secure the delegation 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: + If DS RRset is present: + parent's copy of child's NS RRset + DS and SIG(DS) + If no DS RRset is present: + parent's copy of child's NS RRset + parent's zone NXT and SIG(NXT) + + This increases the size of referral messages, possibly causing some + or all glue to be omitted. If the DS or NXT RRsets with signatures do + not fit in the DNS message, the TC bit MUST be set. Additional + section processing is not changed. + + A DS RRset accompanying a NS RRset indicates that the child zone is + secure. If a NS RRset exists without a DS RRset, the child zone is + unsecure (from the parents point of view). DS RRsets MUST NOT appear + at non-delegation points or at a zone's apex. + + Section 2.2.1 defines special considerations related to authoritative + servers responding to DS queries and replaces RFC2535 sections 2.3.4 + and 3.4. Section 2.2.2 replaces RFC3008 section 2.7, and section + 2.2.3 updates RFC3090. + + + + + + + + Gudmundsson Expires January 2004 [Page 5] + +INTERNET-DRAFT Delegation Signer Record June 2003 + + + 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]. + + Each DS RRset stored in the parent zone MUST be signed by at least + one of the parent zone's private keys. The parent zone MUST NOT + contain a KEY RRset at any delegation point. 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 zone 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. + + + 2.2.1.1 Special processing for DS queries + + When a server is authoritative for the parent zone at a delegation + point and receives a query for the DS record at that name, it MUST + answer based on data in the parent zone, return DS or negative + answer. This is true whether or not it is also authoritative for the + child zone. + + When the server is authoritative for the child zone at a delegation + point but not the parent zone, there is no natural response, since + the child zone is not authoritative for the DS record at the zone's + apex. As these queries are only expected to originate from recursive + servers which are not DS-aware, the authoritative server MUST answer + with: + RCODE: NOERROR + AA bit: set + + + + Gudmundsson Expires January 2004 [Page 6] + +INTERNET-DRAFT Delegation Signer Record June 2003 + + + Answer Section: Empty + Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)] + + That is, it answers as if it is authoritative and the DS record does + not exist. DS-aware recursive servers will query the parent zone at + delegation points, so will not be affected by this. + + A server authoritative for only the child zone, that is also a + caching server MAY (if the RD bit is set in the query) perform + recursion to find the DS record at the delegation point, or MAY + return the DS record from its cache. In this case, the AA bit MUST + not be set in the response. + + + 2.2.1.2 Special processing when child and an ancestor share server + + Special rules are needed to permit DS RR aware servers to gracefully + interact with older caches which otherwise might falsely label a + server as lame because of the placement of the DS RR set. + + Such a situation might arise when a server is authoritative for both + a zone and it's grandparent, but not the parent. This sounds like an + obscure example, but it is very real. The root zone is currently + served on 13 machines, and "root-servers.net." is served on 4 of the + same 13, but "net." is served elsewhere. + + When a server receives a query for (, DS, ), the + response MUST be determined from reading these rules in order: + + + 1) If the server is authoritative for the zone that holds the DS RR + set (i.e., the zone that delegates , aka the "parent" zone), + the response contains the DS RR set as an authoritative answer. + + 2) If the server is offering recursive service and the RD bit is set + in the query, the server performs the query itself (according to the + rules for resolvers described below) and returns its findings. + + 3) If the server is authoritative for the zone that holds the + 's SOA RR set, the response is an authoritative negative + answer as described in 2.2.1.1. + + 4) If the server is authoritative for a zone or zones above the + QNAME, a referral to the most enclosing zone's servers is made. + + 5) If the server is not authoritative for any part of the QNAME, a + response indicating a lame server for QNAME is given. + + + + + + Gudmundsson Expires January 2004 [Page 7] + +INTERNET-DRAFT Delegation Signer Record June 2003 + + + Using these rules will require some special processing on the part of + a DS RR aware resolver. To illustrate this, an example is used. + + Assuming a server is authoritative for roots.example.net. and for the + root zone but not the intervening two zones (or the intervening two + label deep zone). Assume that QNAME=roots.example.net., QTYPE=DS, + and QCLASS=IN. + + The resolver will issue this request (assuming no cached data) + expecting a referral to a net. server. Instead, rule number 3 above + applies and a negative answer is returned by the server. The + reaction by the resolver is not to accept this answer as final as it + can determine from the SOA RR in the negative answer the context + within which the server has answered. + + A solution to this is to instruct the resolver to hunt for the + authoritative zone of the data in a brute force manner. + + This can be accomplished by taking the owner name of the returned SOA + RR and striping off enough left-hand labels until a successful NS + response is obtained. A successful response here means that the + answer has NS records in it. (Entertaining the possibility that a + cut point can be two labels down in a zone.) + + Returning to the example, the response will include a negative answer + with either the SOA RR for "roots.example.net." or "example.net." + depending on whether roots.example.net is a delegated domain. In + either case, removing the left most label of the SOA owner name will + lead to the location of the desired data. + + + 2.2.1.3 Modification on use of KEY RR in the construction of Responses + + This section updates RFC2535 section 3.5 by replacing it with the + following: + + A query for KEY RR MUST NOT trigger any additional section + processing. Security aware resolvers will include corresponding SIG + records in the answer section. + + KEY records SHOULD NOT be added to the additional records section in + response to any query. + + RFC2535 specified that KEY records be added to the additional section + when SOA or NS records where included in an answer. This was done to + reduce round trips (in the case of SOA) and to force out NULL KEYs + (in the NS case). As this document obsoletes NULL keys there is no + need for the inclusion of KEYs with NSs. Furthermore as SOAs are + included in the authority section of negative answers, including the + + + + Gudmundsson Expires January 2004 [Page 8] + +INTERNET-DRAFT Delegation Signer Record June 2003 + + + KEYs each time will cause redundant transfers of KEYs. + + RFC2535 section 3.5 also included rule for adding the KEY RRset to + the response for a query for A and AAAA types. As Restrict + KEY[RFC3445] eliminated use of KEY RR by all applications this rule + is no longer needed. + + + 2.2.2 Signer's Name (replaces RFC3008 section 2.7) + + The signer's name field of a SIG RR 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.3 Changes to RFC3090 + + A number of sections of RFC3090 need to be updated to reflect the DS + record. + + + 2.2.3.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.3.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. + + + + Gudmundsson Expires January 2004 [Page 9] + +INTERNET-DRAFT Delegation Signer Record June 2003 + + + 2.2.3.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.2.4 NULL KEY elimination + + RFC3445 section 3 eliminates the top two bits in the flags field of + KEY RR. These two bits were used to indicate NULL KEY or NO KEY. + RFC3090 defines that zone is either secure or not, these rules + eliminates the possible need to put NULL keys in the zone apex to + indicate that the zone is not secured for a algorithm. Along with + this document these other two eliminate all uses for the NULL KEY, + This document obsoletes NULL KEY. + + 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 + 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 interoperabilty 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 or DS records to + the authority section. The same is true for caching servers; in + fact, some might even refuse to pass on the DS or NXT records. + + + + + + + + + + + + + + + + + + + Gudmundsson Expires January 2004 [Page 10] + +INTERNET-DRAFT Delegation Signer Record June 2003 + + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | digest (length depends on type) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (SHA-1 digest is 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 (all four fields). + + digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata) + + KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key + + Digest type value 0 is reserved, value 1 is SHA-1, and reserving + other types requires IETF standards action. For interoperabilty + reasons, keeping number of digest algorithms low is strongly + RECOMMENDED. The only reason to reserve additional digest types is + to increase security. + + DS records MUST point to zone KEY records that are allowed to + authenticate DNS data. The indicated KEY records protocol field MUST + be set to 3; flag field bit 7 MUST be set to 1. The value of other + flag 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. New digest types probably will have larger digests. + + + + + + Gudmundsson Expires January 2004 [Page 11] + +INTERNET-DRAFT Delegation Signer Record June 2003 + + + 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 rdata 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. + + 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: + example. DS 12345 3 1 123456789abcdef67890123456789abcdef67890 + + 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. + + 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: + + + + + Gudmundsson Expires January 2004 [Page 12] + +INTERNET-DRAFT Delegation Signer Record June 2003 + + + 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. + + DNSSEC with DS has the following two states: + + Secure DS: NS + DS + SIG(DS) + 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 to cause a flag day. + + 2.7 KEY and corresponding DS record example + + This is an example of a KEY record and the corresponding DS record. + + dskey.example. KEY 256 3 1 ( + AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj + 4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt + ) ; key id = 28668 + DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE + + + + + + + + + + + + + + + + + Gudmundsson Expires January 2004 [Page 13] + +INTERNET-DRAFT Delegation Signer Record June 2003 + + + 3 Resolver + + 3.1 DS 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 secure.example. + example. SIG(SOA) + example. SIG(NS) + example. SIG(NXT) + example. SIG(KEY) + secure.example. NS ns1.secure.example. + secure.example. DS tag=12345 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. KEY + secure.example. NXT + secure.example. SIG(KEY) + secure.example. SIG(SOA) + secure.example. SIG(NS) + secure.example. SIG(NXT) + + 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 and multiple KEY + algorithms. + + + + + + Gudmundsson Expires January 2004 [Page 14] + +INTERNET-DRAFT Delegation Signer Record June 2003 + + + 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. Note the NXT record + SHOULD only be examined after verifying the corresponding signature. + + 3.2 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 have to do an extra query to get the DS record and this + increases the overall cost of resolving this question, 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, of a specific DS set, and thus + forge data from the child. This possibility is considered + impractical, as on average more than + 2 ^ (160 - ) + keys would have to be generated before a match would be found. + + An attacker that wants to match any DS record will have to generate + on average at least 2^80 keys. + + + + + + Gudmundsson Expires January 2004 [Page 15] + +INTERNET-DRAFT Delegation Signer Record June 2003 + + + 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. + + 5 IANA Considerations: + + IANA needs to allocate an RR type code for DS from the standard RR + type space (type 43 requested). + + IANA needs to open a new registry for the DS RR type for digest + algorithms. Defined types are: + 0 is Reserved, + 1 is SHA-1. + Adding new reservations requires IETF standards action. + + 6 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, Sam Weiler, Paul Vixie, Jakob + Schlyter, Scott Rose, 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, Mark + Andrews, Harald Alvestrand, and others have provided useful comments. + + Normative 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. + + [RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC + 3225, December 2001. + + [RFC3445] D. Massey, S. Rose ``Limiting the scope of the KEY Resource + Record (RR)``, RFC 3445, December 2002. + + + + Gudmundsson Expires January 2004 [Page 16] + +INTERNET-DRAFT Delegation Signer Record June 2003 + + + Informational References + + [RFC2181] R. Elz, R. Bush, ``Clarifications to the DNS Specification'', + RFC 2181, July 1997. + + [RFC3226] O. Gudmundsson, ``DNSSEC and IPv6 A6 aware server/resolver + message size requirements'', RFC 3226, December 2001. + + Author Address + + Olafur Gudmundsson + 3821 Village Park Drive + Chevy Chase, MD, 20815 + USA + + + Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 January 2004 [Page 17] + +INTERNET-DRAFT Delegation Signer Record June 2003 + + + + + + + + + + + + + + + + + Gudmundsson Expires January 2004 [Page 1]