diff --git a/doc/draft/draft-ietf-dnsext-edns0dot5-00.txt b/doc/draft/draft-ietf-dnsext-edns0dot5-01.txt similarity index 66% rename from doc/draft/draft-ietf-dnsext-edns0dot5-00.txt rename to doc/draft/draft-ietf-dnsext-edns0dot5-01.txt index 4e5307a139..cd9e98a1ad 100644 --- a/doc/draft/draft-ietf-dnsext-edns0dot5-00.txt +++ b/doc/draft/draft-ietf-dnsext-edns0dot5-01.txt @@ -5,10 +5,10 @@ Network Working Group R. Austein -draft-ietf-dnsext-edns0dot5-00.txt InterNetShare.com, Inc. +draft-ietf-dnsext-edns0dot5-01.txt InterNetShare.com, Inc. H. Alvestrand EDB MaXware AS - February 2000 + July 2000 A Proposed Enhancement to the EDNS0 Version Mechanism @@ -55,9 +55,9 @@ Motivation and Scope -Austein & Alvestrand Expires 28 August 2000 [Page 1] +Austein & Alvestrand Expires 15 January 2001 [Page 1] -draft-ietf-dnsext-edns0dot5-00.txt February 2000 +draft-ietf-dnsext-edns0dot5-01.txt July 2000 This note proposes to replace the monolithic version numbering @@ -85,9 +85,10 @@ Model of the TTL field of the OPT RR, and a variable-length list of FEATURES, stored in the variable part of the OPT RR. - All FEATUREs are extensions of the DNS. We reserve FEATURE numbers 1 - to 100 for describing features of the original RFC 1034/1035 DNS - specification that we might eventually chose to deprecate. + All FEATUREs are extensions of the DNS. We reserve the range of + FEATURE numbers from 1 to 100 for describing features of the original + RFC 1034/1035 DNS specification that we might eventually choose to + deprecate. Any query/response pair can be described as using a set of DNS FEATUREs. Such features might for instance be: @@ -105,18 +106,18 @@ Model - SIG record parsing and checking; FEATURE numbers are handed out by IANA on a first-come-first-served - basis. Any revised specification of a format or function should have - its own FEATURE number; in the IETF process, any significantly - changed Internet-Draft should have a new FEATURE number assigned for + basis within their appropriate ranges. Any revised specification of + a format or function should have its own FEATURE number; in the IETF -Austein & Alvestrand Expires 28 August 2000 [Page 2] +Austein & Alvestrand Expires 15 January 2001 [Page 2] -draft-ietf-dnsext-edns0dot5-00.txt February 2000 +draft-ietf-dnsext-edns0dot5-01.txt July 2000 - experimentation. + process, any significantly changed Internet-Draft should have a new + FEATURE number assigned for experimentation. An assigned VERSION number names a set of FEATUREs. VERSION numbers are assigned by the IETF through a standards action. @@ -148,35 +149,46 @@ Mechanism Usage - When composing a query message, the client includes an OPT record - indicating the set of FEATUREs that: + In most respects, the FEATURE mechanism is used symmetrically by + clients and servers; exceptions to this rule are stated after the + general explanation. - - Allows the client to express this query; + When composing a DNS message, a client or server includes an OPT + record indicating a set of FEATUREs that: - - Allows the server to express all responses that the client is - prepared to accept for this query. + - MUST include all FEATUREs that the client or server believes are + relevant to this message; + + - MAY include all FEATURES that the client or server is prepared to + receive. This set is expressed as a VERSION and any additional FEATURES required. - The server will include an OPT pseudo-RR that indicates: - - - The highest VERSION numbers supported by the responder (for - information only -- the client takes no action based on this); - - -Austein & Alvestrand Expires 28 August 2000 [Page 3] +Austein & Alvestrand Expires 15 January 2001 [Page 3] -draft-ietf-dnsext-edns0dot5-00.txt February 2000 +draft-ietf-dnsext-edns0dot5-01.txt July 2000 - - The set of FEATUREs not encompassed by the VERSION that are - necessary to express the response. + In general, we expect that a client or server will include an OPT + pseudo-RR that indicates: - No FEATURE may be included or used that is not within the set of - FEATUREs that the query originator indicated. + - The highest VERSION number that the entity generating the message + supports; and + + - A small (possibly empty) set of additional FEATUREs not encompassed + by the VERSION that the entity deems necessary or desirable. + + The above symmetry notwithstanding, we impose one important + constraint on the server: while a server is allowed to indicate + whatever FEATUREs it believes are relevant or useful, a server MUST + NOT make use of any FEATURE in a response that is not within the set + of FEATUREs indicated by the client that generated the corresponding + request. That is, a response may say "I support FEATURE FOO" + regardless of what the client supports, but the rest of the response + must not use FEATURE FOO unless the client also supports it. As a special case, if a client explicitly queries for the OPT RR of the root zone, the server returns an OPT record including all @@ -190,8 +202,8 @@ Life Cycle - VERSION X is defined and deployed. - A new FEATURE is defined and experimentally implemented. All - clients and servers part of the experiment use FEATURE to indicate - support. + clients and servers taking part in the experiment use FEATURE to + indicate support. - Community consensus is reached that this FEATURE is genuinely useful. @@ -209,24 +221,29 @@ Risks all, since by any realistic estimate it takes years (decades?) to upgrade all the DNS implementations already in the field. + + +Austein & Alvestrand Expires 15 January 2001 [Page 4] + +draft-ietf-dnsext-edns0dot5-01.txt July 2000 + + A flexible extension mechanism of this type increases the risk that some implementors might chose to deploy features designed to hinder interoperability (so-called "labeled noninteroperability"). Security Considerations - We do not believe that this protocol enhancement adds any new + We do not believe that this protocol enhancement adds any major new security risks, but we do believe that it would be helpful in getting complicated DNS extensions such as [DNSSEC] deployed more quickly. - - - - -Austein & Alvestrand Expires 28 August 2000 [Page 4] - -draft-ietf-dnsext-edns0dot5-00.txt February 2000 - + As with any enhancement to or complication of the DNS protocol, this + enhancement offers attackers yet another way to increase the load on + a name server. Root, TLD and other "major" name servers should view + excessively complicated FEATURE sets with suspicion, and should not + allow themselves to be tricked into performing more work than is + really necessary. IANA Considerations @@ -234,6 +251,12 @@ IANA Considerations IANA will need to create a new registry of feature numbers. +Acknowledgments + + The authors would like to thank the following people for their help + in improving this document: Randy Bush, Patrik Faltstrom, Olafur + Gudmundsson, Bob Halley, and XXX. + References [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC @@ -251,6 +274,16 @@ References [BINARY-LABELS] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673 August 1999. + + + + + +Austein & Alvestrand Expires 15 January 2001 [Page 5] + +draft-ietf-dnsext-edns0dot5-01.txt July 2000 + + Author's addresses: Rob Austein @@ -279,4 +312,27 @@ Author's addresses: -Austein & Alvestrand Expires 28 August 2000 [Page 5] + + + + + + + + + + + + + + + + + + + + + + + +Austein & Alvestrand Expires 15 January 2001 [Page 6] diff --git a/doc/draft/draft-ietf-dnsext-zone-status-01.txt b/doc/draft/draft-ietf-dnsext-zone-status-01.txt deleted file mode 100644 index af7c85bbe3..0000000000 --- a/doc/draft/draft-ietf-dnsext-zone-status-01.txt +++ /dev/null @@ -1,640 +0,0 @@ -DNSEXT WG Edward Lewis -INTERNET DRAFT NAI Labs -Category:I-D April 13, 2000 - - DNS Security Extension Clarification on Zone Status - - -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 DNSIND WG mailing list -namedroppers@internic.net. - -This draft expires on October 13, 2000. - -Copyright Notice - -Copyright (C) The Internet Society (1999, 2000). All rights reserved. - -Abstract - -The definition of a secured zone is presented, updating RFC 2535. The -new definition has consequences that alter the interpretation of the -NXT record, obsolete NULL keys, and the designation of "experimentally -secure." - -1 Introduction - -Whether a DNS zone is "secured" or not is a question asked in at least -four contexts. A zone administrator asks the question when -configuring a zone to use DNSSEC. A dynamic update server asks the -question when an update request arrives, which may require DNSSEC -processing. A delegating zone asks the question of a child zone when -the parent enters data indicating the status the child. A resolver -asks the question upon receipt of data belonging to the zone. - -A zone administrator needs to be able to determine what steps are -needed to make the zone as secure as it can be. Realizing that due to -the distributed nature of DNS and its administration, any single zone - -Expires October 13, 2000 [Page 1] - DNS Security Extension Clarification on Zone Status April 13, 2000 - -is at the mercy of other zones when it comes to the appearance of -security. This document will define what makes a zone qualify as -secure (absent interaction with other zones). - -A name server performing dynamic updates needs to know whether a zone -being updated is to have signatures added to the updated data, NXT -records applied, and other required processing. In this case, it is -conceivable that the name server is configured with the knowledge, but -being able to determine the status of a zone by examining the data is -a desirable alternative to configuration parameters. - -A delegating zone is required to indicate whether a child zone is -secured. The reason for this requirement lies in the way in which a -resolver makes its own determination about a zone (next paragraph). To -shorten a long story, a parent needs to know whether a child should be -considered secured. This is a two part question, what does a parent -consider a secure child to be, and how does a parent know if the child -conforms? - -A resolver needs to know if a zone is secured when the resolver is -processing data from the zone. Ultimately, a resolver needs to know -whether or not to expect a usable signature covering the data. How -this determination is done is out of the scope of this document, -except that, in some cases, the resolver will need to contact the -parent of the zone to see if the parent states that the child is -secured. - -This document updates several sections of RFC 2535. The definition of -a secured zone is an update to section 3.4 of the RFC. The document -updates section 2.3.4, by specifying a replacement for the NULL zone -keys. Section 3.4 is updated to eliminate the definition of -experimental keys and illustrate a way to still achieve the -functionality they were designed to provide. Section 3.1.3 is updated -by the specifying the value of the protocol octet in a zone key. - -2 Status of a Zone - -In this section, rules governing a zone's DNSSEC status are presented. -There are three levels of security defined: full, private, and -unsecured. A zone is fully secure when it complies with the strictest -set of DNSSEC processing rules. A zone is privately secured when it -is configured in such a way that only resolvers that are appropriately -configured see the zone as secured. All other zones are unsecured. - -Note: there currently is no document completely defining DNSSEC -verification rules. For the purposes of this document, the strictest -rules are assumed to state that the verification chain of zone keys -parallels the delegation tree up to the root zone. This is not -intended to disallow alternate verification paths, just to establish a -baseline definition. - -To avoid repetition in the rules below, the following terms are -defined. - - -Expires October 13, 2000 [Page 2] - DNS Security Extension Clarification on Zone Status April 13, 2000 - -2.a. Zone signing KEY RR - A KEY RR whose flag field has the value 01 -for name type (indicating a zone key) and either value 00 or value 01 -for key type (indicating a key permitted to authenticate data). (See -RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value -of DNSSEC (3) or All (255). - -The definition updates RFC 2535's definition of a zone key. The -requirement that the protocol field be either DNSSEC or All is a new -requirement. - -2.b On-tree Validation - The authorization model in which only the -parent zone can is recognized to supply a DNSSEC-meaningful signature -that is used by a resolver to build a chain of trust from the child's -keys to a recognized root of security. The term "on-tree" refers to -following up the DNS domain hierarchy to reach a trusted key, -presumably the root key if no other key is available. The term -"validation" refers to the digital signature by the parent to prove -the integrity, authentication and authorization of the child' key to -sign the child's zone data. - -2.c Off-tree Validation - Any authorization model that permits domain -names other than the parent's to provide a signature over a child's -zone keys that will enable a resolver to trust the keys. - -2.1 Fully Secured - -A fully secured zone, in a nutshell, is a zone that uses only -mandatory to implement algorithms (RFC 2535, section 3.2) and relies -on a key certification chain that parallels the delegation tree -(on-tree validation). Fully secured zones are defined by the -following rules. - -2.1.a. The zone's apex MUST have a KEY RR set. There MUST be at least -one zone signing KEY RR (2.a) of a mandatory to implement algorithm in -the set. - -2.1.b. The zone's apex KEY RR set MUST be signed by a private key -belonging to the parent zone. 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. - -If a zone cannot get a conforming signature from the parent zone, the -child zone cannot be considered fully secured. The only exception to -this is the root zone, for which there is no parent zone. - -2.1.c. NXT records MUST be deployed throughout the zone. (Updates RFC -2535, section 2.3.2.) Note: there is some operational discomfort with -the current NXT record. This requirement is open to modification when -two things happen. First, an alternate mechanism to the NXT is -defined and second, a means by which a zone can indicate that it is -using an alternate method. - -2.1.d. Each RR set that qualifies for zone membership MUST be signed -by a key that is in the apex's KEY RR set and is a zone signing KEY RR - -Expires October 13, 2000 [Page 3] - DNS Security Extension Clarification on Zone Status April 13, 2000 - -(2.a) of a mandatory to implement algorithm. (Updates 2535, section -2.3.1.) - -Mentioned earlier, the root zone is a special case. Defining what -constitutes a secure root zone is difficult, as the discussion on -securing the root zone has not come to a consensus in an open forum. -However, the security of the root zone will be determined by the -preconfiguration of a trusted key in resolvers. Who generates and -distributes the trusted key is an open issue. - -2.2 Privately Secured - -Note that the term "privately" is open to debate... - -A privately secured zone is a zone that complies with rules like those -for a fully secured zone with the following exceptions. The signing -keys may be of an algorithm that is not mandatory to implement and/or -the verification of the zone keys in use may rely on a verification -chain that is not parallel to the delegation tree (off-tree -validation). - -2.2.a. The zone's apex MUST have a KEY RR set. There MUST be at least -one zone signing KEY RR (2.a) in the set. - -2.2.b. The zone's apex KEY RR set MUST be signed by a private key and -one of the following two subclauses MUST hold true. - -2.2.b.1 The private key's public companion MUST be preconfigured in -all the resolvers of interest. - -2.2.b.2 The private key's public component MUST be a zone signing KEY -RR (2.a) authorized to provide validation of the zone's apex KEY RR -set, as recognized by resolvers of interest. - -The previous sentence is trying to convey the notion of using a -trusted third party to provide validation of keys. If the domain name -owning the validating key is not the parent zone, the domain name must -represent someone the resolver trusts to provide validation. - -2.2.c. NXT records MUST be deployed throughout the zone. (Updates RFC -2535, section 2.3.2.) Note: see the discussion following 2.1.c. - -2.2.d. Each RR set that qualifies for zone membership MUST be signed -by a key that is in the apex's KEY RR set and is a zone signing KEY RR -(2.a).. (Updates 2535, section 2.3.1.) - -2.3 Unsecured - -All other zones qualify as unsecured. This includes zones that are -designed to be experimentally secure, as defined in a later section on -that topic. - - - - -Expires October 13, 2000 [Page 4] - DNS Security Extension Clarification on Zone Status April 13, 2000 - -2.4 Wrap up - -The designation of fully secured, privately secured, and unsecured are -merely labels to apply to zones, based on their contents. Resolvers, -when determining whether a signature is expected or not, will only see -a zone as secured or unsecured. - -Resolvers that follow the most restrictive DNSSEC verification rules -will only see fully secured zones as secured, and all others as -unsecured, including zones which are privately secured. Resolvers -that are not as restrictive, such as those that implement algorithms -in addition to the mandatory to implement algorithms, will see some -privately secured zones as secured. - -The intent of the labels "fully" and "privately" is to identify the -specific attributes of a zone. The words are chosen to assist in the -writing of a document recommending the actions a zone administrator -take in making use of the DNS security extensions. The words are -explicitly not intended to convey a state of compliance with DNS -security standards. - -3 Parental Notification - -For a resolver to come to a definitive answer concerning a zone's -security status there is a requirement that the parent of a zone -signify whether the child zone is signed or not. The justification of -this requirement requires a discussion of the resolver's activity, -which is described in RFC 2535. - -In RFC 2535, a parent is required to hold a NULL key for an unsigned -child (a bone of contention here is how this works in light of -multiple algorithms). The parent has the option to hold the keys of -the child if the child is signed. The parent may also hold nothing -cryptographic if the child is signed. This, of course, assumes the -parent is a signed zone. - -RFC 2535 does permit the following case, a child zone that uses DNSSEC -capable software yet chooses to remain unsecured could hold a signed -NULL key delivered from the parent. This is considered to be a rare -condition, a zone administrator that goes to the trouble to get the -keys from the parent and have it signed will likely just sign the -whole zone, or leave the NULL key to the parent. - -There is a strong case for discouraging a parent from holding keys of -a signed child, or an unsigned child for that matter. These include -concrete concerns about performance and more abstract concerns about -the liability of the parent. - -DNS [RFC 1034 and 1035] requires a parent to hold NS records for a -child zone, this signifies the delegation. RFC 2535 requires a -secured parent to also have signed NXT records for the child, and -possibly a signed KEY RR set (required for some NULL key situations). - -By redefining the security status of a zone to be per zone and not per - -Expires October 13, 2000 [Page 5] - DNS Security Extension Clarification on Zone Status April 13, 2000 - -algorithm, there is an opportunity to completely remove the need for a -KEY RR set in the parent. Because the question of whether the zone is -secure or not is a yes-or-no question, the notification needs just one -bit to be expressed. - -Keep in mind that the following sections speak to the contents of a -zone, not a name server. In the case of a name server speaking -authoritatively for both the parent and child, or if a server caches -the information for the other half of the delegation, then a server -will have more types of data at a delegation point than a parent is -supposed to hold. (E.g., if a parent zone's name server caches the -SOA for the child, the SOA is not in the parent zone, but is in the -server's cache.) - -3.1 Child Has Keys Bit - -This section is written assuming the current definition of NXT holds. -There is some controversy surrounding the NXT record, which may result -in a complete replacement of it for proof of non-existence. The -current NXT definition provides an extension bit in the types present -bit map, whose use is remains incompletely defined. The following -text largely ignores these uncertainties, and should be rewritten to -accommodate these uncertainties in revisions. - -In the parent's half of the delegation point, there will be an NXT -record, called an "upper" NXT. According to the rules for a -delegation point, only the NS, NXT, and SIG bits will be turned on in -the types present field, assuming we drop the KEY set altogether. - -The KEY bit in the parent's NXT types present bit map is hereby -redefined to have the following meaning. (Note that this applies to -just delegation points.) - -If the bit corresponding to the KEY RR set in an upper NXT is set, the -parent has generated and issued a currently valid SIG (KEY) RR -validating the child's apex KEY RR set. Note that this does not -require the child to include either a zone signing KEY RR (2.a) or a -NULL zone KEY RR. This does assume that only on-tree validation (2.b) -is in use. - -The temporal validity of the bit's setting may be enforced in the SIG -(NXT) RR validity period, timely editing of the master file, dynamic -updates, or whatever another mechanism. - -If a child submits a key set to the parent for validation that does -not include a zone signing KEY RR (2.a), then the child will remain -unsecured although the upper NXT KEY RR bit will be set to 1 by the -parent. A resolver seeing this will know to look for a child key set, -and see that there is no zone signing KEY RR (2.a) and know to treat -the child as unsecured. - -If a NULL zone KEY RR is seen, the resolver ignores it. If a NULL key -is the only zone key, then the resolver will deduce the child is -unsecured as in the previous paragraph. If there is both a NULL and - -Expires October 13, 2000 [Page 6] - DNS Security Extension Clarification on Zone Status April 13, 2000 - -one or more zone signing KEY RR (2.a), then the zone is considered -signed in the algorithm(s) identified in the signing capable key(s). - -If the bit is 0 then the child has not submitted a KEY RR set for -validation, hence is to be considered unsigned. - -Note that for a fully secured zone (section 2.1), the bit is on (1). -For all unsecured zones (section 2.3) the bit is either off (0) or on -(1) with a NULL KEY and no zone signing KEY RR at the apex. For -privately secured zones (section 2.2), the setting of the bit is -determined by whether the parent signs the child's keys or not. -Hence, for privately secured zones, the parent may have no -responsibility. A child wishing to have the parent set the bit must -contact the parent. - -3.2 Rules Governing the Bit - -In this section, the words of the previous are turned into definitive -MUST and SHOULDs. Note that this section does not refer to the bit in -the NXT. This is in anticipation of a change in the way NXT indicates -types present (e.g., if bit 0 of the field is defined) or a successor -to the NXT is defined. - -3.2.a. At a delegation point, a secured parent zone MUST have a -mechanism in place to indicate which RR sets are present. The -mechanism MUST indicate that the NS, SIG, and the type(s) -corresponding to the mechanism itself are present (of course, with -these types actually being present). With the exception of the KEY RR -type, all other types MUST be indicated as not present, and, in -accordance with delegation rules, actually be absent from the zone. -If, in the future, other data is permitted to be present at a -delegation point, this requirement MUST be amended. - -Assuming the NXT record, the above requirement reads as follows. At a -delegation point, a parent zone must have a secured NXT record. This -NXT record must indicate that the NS, SIG, and NXT types are present. -With the exception of KEY, all other types must be indicated as not -present. The lower casing of the word "must" is intentional, -conveying that this is an explanation of the rule above. - -3.2.b. The KEY set MUST be indicated as present during the time when -the parent has issued a signature for the child's KEY set. Conversely, -during periods of time in which the parent knows it has not generated -a signature for the KEY RR set, the KEY set MUST be indicated to be -absent. - -If the parent has issued signatures with discontinuous validity spans, -then the presence of the KEY set will flip from present to not present -and back as time progresses. - -3.2.c. When signing a child's KEY RR set, a parent SHOULD carefully -consider the algorithm of the key used to generate the signature. The -parent SHOULD make clear to child zones what steps are to be taken to - - -Expires October 13, 2000 [Page 7] - DNS Security Extension Clarification on Zone Status April 13, 2000 - -get the parent to indicate that the child is signed. This document -will go no further in specifying operational considerations. - -(Let's say the parent signs the child's key set with an algorithm the -child can't process. The child could elect not to advertise this -signature, as it cannot verify that the signature covers the real key -set. If this happens, is the parent justified in claiming that the -child is secured?) - -3.2.d. The parent MUST have the capability to allow the child, through -some trusted, probably non-DNS mechanism, to request that the -indication of the KEY set to be turned off. This allows a child to -revert to an unsigned state. - -3.2.e. The parent SHOULD NOT allow the child to request that the KEY -set be indicated as present in the absence of a key signing request. - -3.3 Operational Considerations - -Retrieving the NXT for a delegated name from the parent zone (the -upper NXT) is not a trivial operation. The complication arises due to -having an NXT in the delegatee (the lower NXT) that matches the owner -name of the upper NXT. (The case in which both the parent and child -zones are secured is the only case mentioned here. If both are not -secured, then there will be at most one NXT, which is easily -retrieved.) - -There are two complications to describe. One involves the multiple -NXT sets matching the same owner. The other is the pragmatic issue of -knowing where to get the answer. - -With multiple NXT sets at the same owner, caches may become a problem. -If a (for example) recursive server has cached the lower NXT, any -query for the upper NXT may be confused for a lower NXT query. This -is akin to the issue of the ANY query, where a server with some cached -data will answer with just that and not seek the rest of the data. - -Note that distinguishing between an upper and lower NXT is a trivial -operation, especially so if the SIG RR is available. - -A resolver may know the child's server's addresses and the parent zone -may not be sharing servers with the child. In this case the resolver -will need to be able to locate the parent zones (possibly having to go -to the root servers and descend) in order to obtain the upper NXT -record. - -A potential solution to this is to define an NXT meta-query that will -force a recursive server to find all available NXT RR sets for a given -name. Details of this have not been examined. - -3.4 Interaction with Dynamic Update - -Dynamic update [RFC 2136, draft-ietf-dnsext-simple-secure-update- -xy.txt] defines a means by which a zone can change without undergoing - -Expires October 13, 2000 [Page 8] - DNS Security Extension Clarification on Zone Status April 13, 2000 - -a full reload. This combination of dynamic update and the proposed -use of the NXT record to signify a child's status raises some -concerns. - -First a few elements need to be labeled. There is an off-line signer, -which is the process that signs zone data files away from the name -server. There is an on-line signer, part of a name server, that the -dynamic update mechanism uses to sign the updated data. Finally, -there is an on-line key validator, perhaps a misnomer, which accepts -requests for parent signatures over each child zone's keys. - -The proposal depicted in this draft relies upon the on-line key -validator informing the on-line and off-line signers of the status of -a child, recall that the status of a child has a temporal element. -E.g., a signature may be generated for just the month of July, so the -child is secured for the month of July, but not the month of August. - -The first issues pertain to the way in which an off-line signer comes -to encode a validation in an NXT record. There is a need for the -status information to flow from the on-line validator to the off-line -signer and then be used as input to the signing process. The way that -this information makes the transition is an issue. The second issue -is through what mechanism is this information ingested into the NXT -generating process. Recall that all other information can be derived -by the zone data, the status of the child isn't stored anywhere else -in the parent zone. - -The next issue is the means in which a validation action is reported -to the active zone. On the surface, dynamically updating the NXT -would seem to make sense, but updating the NXT in this manner can lead -to a race condition in the server, this is unstable. The issue here -is deriving a mechanism by which a name server knows to signify that -the child status has changed. Note that this applies to newly -validated keys as well as the granting of a child's request to cancel -a validation. - -The final issue is the operation of the off-line signer. When an NXT -is being regenerated, the old NXT is needed to see what the previous -setting of the child's status had been. The old NXT signature is also -needed to know that, had the child been known to be secured, for what -interval was is it thought to be secured so that the new NXT signature -is appropriately set. Of course, if the reason for updating the NXT -is a change as described in the previous paragraph, the old NXT is of -lesser value. - -The issue raised in the last paragraph leads to a questioning of the -sanity of using signature validity periods to signify the temporal -status of data in a server. What does a server return if the NXT -needed is not currently covered by a valid signature? - -4 NULL keys - -Through the use of the types present to indicate the existence of a -signature validating the KEY set of a child, the need for NULL keys - -Expires October 13, 2000 [Page 9] - DNS Security Extension Clarification on Zone Status April 13, 2000 - -effectively disappears. NULL keys are left as a defined entity, but -are rendered meaningless in DNSSEC. - -5 Experimental Status - -Without NULL keys, an experimentally secured zone cannot be defined as -it is in RFC 2535. The purpose of an experimentally secured zone was -to facilitate the migration from an unsecured zone to a secured zone. - -The objective of facilitating the migration can be achieved without a -special designation of an experimentally secure status. Experimentally -secured is a special case of privately secured. A zone administrator -can achieve this by publishing a zone with signatures and configuring -a set of test resolvers with the corresponding public keys. Even if -the public key is published in a KEY RR, as long as there is no parent -signature, the resolvers will need some preconfiguration to know to -process the signatures. This allows a zone to be secured with in the -sphere of the experiment, yet still be registered as unsecured in the -general Internet. - -6 IANA/ICANN Considerations - -This document does not request any action from an assigned number -authority nor recommends any actions. - -7 Security Considerations - -Without a means to enforce compliance with specified protocols or -recommended actions, declaring a DNS zone to be "completely" secured -is impossible. Even if, assuming an omnipotent view of DNS, one can -declare a zone to be properly configured for security, and all of the -zones up to the root too, a misbehaving resolver could be duped into -believing bad data. If a zone and resolver comply, a non-compliant or -subverted parent could interrupt operations. The best that can be -hoped for is that all parties are prepared to be judged secure and -that security incidents can be traced to the cause in short order. - -8 Acknowledgements - -The need to refine the definition of a secured zone has become -apparent through the efforts of the participants at two DNSSEC -workshops, sponsored by the NIC-SE (.se registrar) and CAIRN (a -DARPA-funded research network). Further discussions leading to the -document include Olafur Gudmundsson, Russ Mundy, Robert Watson, and -Brian Wellington. - -9 References - -[RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities," -RFC 1034, November 1987. - -[RFC1035] P. Mockapetris, "Domain Names - Implementation and -Specification," RFC 1034, November 1987. - - -Expires October 13, 2000 [Page 10] - DNS Security Extension Clarification on Zone Status April 13, 2000 - -[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate -Requirement Levels," RFC 2119, March 1997 - -[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound "Dynamic -Updates in the Domain Name System," RFC 2136, April 1997. - -[RFC2535] D. Eastlake, "Domain Name System Security Extensions," RFC -2535, March 1999. - -[draft-ietf-dnsext-simple-secure-update-xy.txt] B. Wellington, "Simple -Secure Domain Name System (DNS) Dynamic Update," version 00, February -2000. - -10 Author Information - -Edward Lewis NAI Labs 3060 Washington Road Glenwood, MD 21738 +1 443 -259 2352 - -11 Full Copyright Statement - -Copyright (C) The Internet Society (1999, 2000). 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." - - - - - - - - - - - -Expires October 13, 2000 [Page 11] - - diff --git a/doc/draft/draft-ietf-dnsext-zone-status-02.txt b/doc/draft/draft-ietf-dnsext-zone-status-02.txt new file mode 100644 index 0000000000..dc0836b113 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-zone-status-02.txt @@ -0,0 +1,464 @@ +DNSEXT WG Edward Lewis +INTERNET DRAFT NAI Labs +Category:I-D July 12, 2000 + + DNS Security Extension Clarification on Zone Status + + +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 DNSIND WG mailing list +namedroppers@internic.net. + +This draft expires on January 12, 2001. + +Copyright Notice + +Copyright (C) The Internet Society (1999, 2000). All rights reserved. + +Abstract + +The definition of a secured zone is presented, updating RFC 2535. +After discussion on the mailing list and other working group +consideration, removed from earlier editions of this draft are a new +interpretation of the NXT record and a proposal to obsolete NULL +keys. Deprecation of "experimentally secure" remains. + +1 Introduction + +Whether a DNS zone is "secured" or not is a question asked in at least +four contexts. A zone administrator asks the question when +configuring a zone to use DNSSEC. A dynamic update server asks the +question when an update request arrives, which may require DNSSEC +processing. A delegating zone asks the question of a child zone when +the parent enters data indicating the status the child. A resolver +asks the question upon receipt of data belonging to the zone. + + + + +Expires July 12, 2000 [Page 1] +^LDNS Security Extension Clarification on Zone Status January 12, 2001 + +1.1 When a Zone's Status is Important + +A zone administrator needs to be able to determine what steps are +needed to make the zone as secure as it can be. Realizing that due to +the distributed nature of DNS and its administration, any single zone +is at the mercy of other zones when it comes to the appearance of +security. This document will define what makes a zone qualify as +secure (absent interaction with other zones). + +A name server performing dynamic updates needs to know whether a zone +being updated is to have signatures added to the updated data, NXT +records applied, and other required processing. In this case, it is +conceivable that the name server is configured with the knowledge, but +being able to determine the status of a zone by examining the data is +a desirable alternative to configuration parameters. + +A delegating zone is required to indicate whether a child zone is +secured. The reason for this requirement lies in the way in which a +resolver makes its own determination about a zone (next paragraph). To +shorten a long story, a parent needs to know whether a child should be +considered secured. This is a two part question, what does a parent +consider a secure child to be, and how does a parent know if the child +conforms? + +A resolver needs to know if a zone is secured when the resolver is +processing data from the zone. Ultimately, a resolver needs to know +whether or not to expect a usable signature covering the data. How +this determination is done is out of the scope of this document, +except that, in some cases, the resolver will need to contact the +parent of the zone to see if the parent states that the child is +secured. + +1.2 Islands of Security + +The goal of DNSSEC is to have each zone secured, from the root zone +and the top-level domains down the hierarchy to the leaf zones. +Transitioning from an unsecured DNS, as we have now, to a fully +secured - or "as much as will be secured" - tree will take some time. +During this time, DNSSEC will be applied in various locations in the +tree, not necessarily "top down." + +For example, at a particular instant, the root zone and the "test." +TLD might be secured, but region1.test. might not be. (For reference, +let's assume that region2.test. is secured.) However, +subarea1.region1.test. may have gone through the process of becoming +secured, along with its delegations. The dilemma here is that +subarea1 cannot get its zone keys properly signed as its parent zone, +region1, is not secured. + +The popular term for the secured zones at or below subarea1 is an +"island of security." The only way in which a DNSSEC resolver will +come to trust any data from this island is if the resolver is +pre-configured with the zone key(s) for subarea1. All other resolvers +will not recognize this island as secured. + +Expires July 12, 2000 [Page 2] +^LDNS Security Extension Clarification on Zone Status January 12, 2001 + +Although both subarea1.region1.test. and region2.test. have both been +properly brought to a secure state by the administering staff, only +the latter of the two is actually fully secured - in the sense that +all DNSSEC resolvers can and will verify its data. The former, +subarea1, will be seen as secured by a subset of those resolvers, just +those appropriately configured. + +In RFC 2535, there is a provision for "certification authorities," +entities that will sign public keys for zones such as subarea1. There +is another draft (currently in last call) that restricts this +activity. Regardless of the other draft, resolvers would still need +proper configuration to be able to use the certification authority to +verify the data for the subarea1 island. + +1.3 Impact on RFC 2535 + +This document updates several sections of RFC 2535. The definition of +a secured zone is an update to section 3.4 of the RFC. Section 3.4 is +updated to eliminate the definition of experimental keys and +illustrate a way to still achieve the functionality they were designed +to provide. Section 3.1.3 is updated by the specifying the value of +the protocol octet in a zone key. + +2 Status of a Zone + +In this section, rules governing a zone's DNSSEC status are presented. +There are three levels of security defined: full, private, and +unsecured. A zone is fully secure when it complies with the strictest +set of DNSSEC processing rules. A zone is privately secured when it +is configured in such a way that only resolvers that are appropriately +configured see the zone as secured. All other zones are unsecured. + +Note: there currently is no document completely defining DNSSEC +verification rules. For the purposes of this document, the strictest +rules are assumed to state that the verification chain of zone keys +parallels the delegation tree up to the root zone. This is not +intended to disallow alternate verification paths, just to establish a +baseline definition. + +To avoid repetition in the rules below, the following terms are +defined. + +2.a. Zone signing KEY RR - A KEY RR whose flag field has the value 01 +for name type (indicating a zone key) and either value 00 or value 01 +for key type (indicating a key permitted to authenticate data). (See +RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value +of DNSSEC (3) or ALL (255). + +The definition updates RFC 2535's definition of a zone key. The +requirement that the protocol field be either DNSSEC or ALL is a new +requirement. + +2.b On-tree Validation - The authorization model in which only the +parent zone can is recognized to supply a DNSSEC-meaningful signature + +Expires July 12, 2000 [Page 3] +^LDNS Security Extension Clarification on Zone Status January 12, 2001 + +that is used by a resolver to build a chain of trust from the child's +keys to a recognized root of security. The term "on-tree" refers to +following up the DNS domain hierarchy to reach a trusted key, +presumably the root key if no other key is available. The term +"validation" refers to the digital signature by the parent to prove +the integrity, authentication and authorization of the child' key to +sign the child's zone data. + +2.c Off-tree Validation - Any authorization model that permits domain +names other than the parent's to provide a signature over a child's +zone keys that will enable a resolver to trust the keys. + +2.1 Fully Secured + +A fully secured zone, in a nutshell, is a zone that uses only +mandatory to implement algorithms (RFC 2535, section 3.2) and relies +on a key certification chain that parallels the delegation tree +(on-tree validation). Fully secured zones are defined by the +following rules. + +2.1.a. The zone's apex MUST have a KEY RR set. There MUST be at least +one zone signing KEY RR (2.a) of a mandatory to implement algorithm in +the set. + +2.1.b. The zone's apex KEY RR set MUST be signed by a private key +belonging to the parent zone. 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. + +If a zone cannot get a conforming signature from the parent zone, the +child zone cannot be considered fully secured. The only exception to +this is the root zone, for which there is no parent zone. + +2.1.c. NXT records MUST be deployed throughout the zone. (Updates RFC +2535, section 2.3.2.) Note: there is some operational discomfort with +the current NXT record. This requirement is open to modification when +two things happen. First, an alternate mechanism to the NXT is +defined and second, a means by which a zone can indicate that it is +using an alternate method. + +2.1.d. Each RR set that qualifies for zone membership MUST be signed +by a key that is in the apex's KEY RR set and is a zone signing KEY RR +(2.a) of a mandatory to implement algorithm. (Updates 2535, section +2.3.1.) + +Mentioned earlier, the root zone is a special case. Defining what +constitutes a secure root zone is difficult, as the discussion on +securing the root zone has not come to a consensus in an open forum. +However, the security of the root zone will be determined by the +pre-configuration of a trusted key in resolvers. Who generates and +distributes the trusted key is an open issue. + + + + +Expires July 12, 2000 [Page 4] +^LDNS Security Extension Clarification on Zone Status January 12, 2001 + +2.2 Privately Secured + +Note that the term "privately" is open to debate. The term stems from +the likely hood that the only resolvers to be configured for a +particular zone will be resolvers "private" to an organization. +Perhaps the more clumsy "colloquially secure" is more accurate. + +A privately secured zone is a zone that complies with rules like those +for a fully secured zone with the following exceptions. The signing +keys may be of an algorithm that is not mandatory to implement and/or +the verification of the zone keys in use may rely on a verification +chain that is not parallel to the delegation tree (off-tree +validation). + +2.2.a. The zone's apex MUST have a KEY RR set. There MUST be at least +one zone signing KEY RR (2.a) in the set. + +2.2.b. The zone's apex KEY RR set MUST be signed by a private key and +one of the following two subclauses MUST hold true. + +2.2.b.1 The private key's public companion MUST be pre-configured in +all the resolvers of interest. + +2.2.b.2 The private key's public component MUST be a zone signing KEY +RR (2.a) authorized to provide validation of the zone's apex KEY RR +set, as recognized by resolvers of interest. + +The previous sentence is trying to convey the notion of using a +trusted third party to provide validation of keys. If the domain name +owning the validating key is not the parent zone, the domain name must +represent someone the resolver trusts to provide validation. + +2.2.c. NXT records MUST be deployed throughout the zone. (Updates RFC +2535, section 2.3.2.) Note: see the discussion following 2.1.c. + +2.2.d. Each RR set that qualifies for zone membership MUST be signed +by a key that is in the apex's KEY RR set and is a zone signing KEY RR +(2.a). (Updates 2535, section 2.3.1.) + +2.3 Unsecured + +All other zones qualify as unsecured. This includes zones that are +designed to be experimentally secure, as defined in a later section on +that topic. + +2.4 Wrap up + +The designation of fully secured, privately secured, and unsecured are +merely labels to apply to zones, based on their contents. Resolvers, +when determining whether a signature is expected or not, will only see +a zone as secured or unsecured. + +Resolvers that follow the most restrictive DNSSEC verification rules +will only see fully secured zones as secured, and all others as + +Expires July 12, 2000 [Page 5] +^LDNS Security Extension Clarification on Zone Status January 12, 2001 + +unsecured, including zones which are privately secured. Resolvers +that are not as restrictive, such as those that implement algorithms +in addition to the mandatory to implement algorithms, will see some +privately secured zones as secured. + +The intent of the labels "fully" and "privately" is to identify the +specific attributes of a zone. The words are chosen to assist in the +writing of a document recommending the actions a zone administrator +take in making use of the DNS security extensions. The words are +explicitly not intended to convey a state of compliance with DNS +security standards. + +3 Deleted + +4 Deleted + +5 Experimental Status + +The purpose of an experimentally secured zone is to facilitate the +migration from an unsecured zone to a secured zone. This distinction +is dropped. + +The objective of facilitating the migration can be achieved without a +special designation of an experimentally secure status. +Experimentally secured is a special case of privately secured. A zone +administrator can achieve this by publishing a zone with signatures +and configuring a set of test resolvers with the corresponding public +keys. Even if the public key is published in a KEY RR, as long as +there is no parent signature, the resolvers will need some +pre-configuration to know to process the signatures. This allows a +zone to be secured with in the sphere of the experiment, yet still be +registered as unsecured in the general Internet. + +6 IANA/ICANN Considerations + +This document does not request any action from an assigned number +authority nor recommends any actions. + +7 Security Considerations + +Without a means to enforce compliance with specified protocols or +recommended actions, declaring a DNS zone to be "completely" secured +is impossible. Even if, assuming an omnipotent view of DNS, one can +declare a zone to be properly configured for security, and all of the +zones up to the root too, a misbehaving resolver could be duped into +believing bad data. If a zone and resolver comply, a non-compliant or +subverted parent could interrupt operations. The best that can be +hoped for is that all parties are prepared to be judged secure and +that security incidents can be traced to the cause in short order. + +8 Acknowledgements + +The need to refine the definition of a secured zone has become +apparent through the efforts of the participants at two DNSSEC + +Expires July 12, 2000 [Page 6] +^LDNS Security Extension Clarification on Zone Status January 12, 2001 + +workshops, sponsored by the NIC-SE (.se registrar), CAIRN (a +DARPA-funded research network), and other workshops. Further +discussions leading to the document include Olafur Gudmundsson, Russ +Mundy, Robert Watson, and Brian Wellington. Roy Arends, Ted Lindgreen +and others have contributed significant input via the namedroppers +mailing list. + +9 References + +[RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities," +RFC 1034, November 1987. + +[RFC1035] P. Mockapetris, "Domain Names - Implementation and +Specification," RFC 1034, November 1987. + +[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate +Requirement Levels," RFC 2119, March 1997 + +[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound "Dynamic +Updates in the Domain Name System," RFC 2136, April 1997. + +[RFC2535] D. Eastlake, "Domain Name System Security Extensions," RFC +2535, March 1999. + +[draft-ietf-dnsext-simple-secure-update-xy.txt] B. Wellington, "Simple +Secure Domain Name System (DNS) Dynamic Update," version 00, February +2000. + +10 Author Information + +Edward Lewis +NAI Labs +3060 Washington Road +Glenwood, MD 21738 ++1 443 259 2352 + + +11 Full Copyright Statement + +Copyright (C) The Internet Society (1999, 2000). 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. + + +Expires July 12, 2000 [Page 7] +^LDNS Security Extension Clarification on Zone Status January 12, 2001 + +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." + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Expires July 12, 2000 [Page 8]