From 18657d332ba7c729ba3a0f1bac15780bf38a88f4 Mon Sep 17 00:00:00 2001 From: Andreas Gustafsson Date: Wed, 26 Apr 2000 05:25:14 +0000 Subject: [PATCH] updated internet drafts --- doc/draft/draft-duerst-dns-i18n-02.txt | 905 ------------------ doc/draft/draft-duerst-dns-i18n-03.txt | 5 + ....txt => draft-ietf-dnsext-sig-zero-01.txt} | 204 ++-- ...y-01.txt => draft-ietf-dnsext-tkey-02.txt} | 277 +++--- .../draft-ietf-dnsext-zone-status-00.txt | 580 ----------- doc/draft/draft-ietf-dnsind-dddd-01.txt | 334 ------- doc/draft/draft-ietf-dnsind-dddd-02.txt | 5 + doc/draft/draft-ietf-dnsind-edns1-03.txt | 249 ----- doc/draft/draft-ietf-dnsind-edns1-04.txt | 5 + .../draft-ietf-dnsind-keyreferral-00.txt | 440 --------- .../draft-ietf-dnsind-keyreferral-01.txt | 5 + ...draft-ietf-dnsind-local-compression-05.txt | 420 -------- ...draft-ietf-dnsind-local-compression-06.txt | 5 + doc/draft/draft-ietf-dnsind-rollover-00.txt | 648 ------------- doc/draft/draft-ietf-dnsind-rollover-01.txt | 5 + doc/draft/draft-ietf-dnsind-sec-rr-00.txt | 663 ------------- doc/draft/draft-ietf-dnsind-sec-rr-01.txt | 5 + 17 files changed, 275 insertions(+), 4480 deletions(-) delete mode 100644 doc/draft/draft-duerst-dns-i18n-02.txt create mode 100644 doc/draft/draft-duerst-dns-i18n-03.txt rename doc/draft/{draft-ietf-dnsext-sig-zero-00.txt => draft-ietf-dnsext-sig-zero-01.txt} (67%) rename doc/draft/{draft-ietf-dnsext-tkey-01.txt => draft-ietf-dnsext-tkey-02.txt} (80%) delete mode 100644 doc/draft/draft-ietf-dnsext-zone-status-00.txt delete mode 100644 doc/draft/draft-ietf-dnsind-dddd-01.txt create mode 100644 doc/draft/draft-ietf-dnsind-dddd-02.txt delete mode 100644 doc/draft/draft-ietf-dnsind-edns1-03.txt create mode 100644 doc/draft/draft-ietf-dnsind-edns1-04.txt delete mode 100644 doc/draft/draft-ietf-dnsind-keyreferral-00.txt create mode 100644 doc/draft/draft-ietf-dnsind-keyreferral-01.txt delete mode 100644 doc/draft/draft-ietf-dnsind-local-compression-05.txt create mode 100644 doc/draft/draft-ietf-dnsind-local-compression-06.txt delete mode 100644 doc/draft/draft-ietf-dnsind-rollover-00.txt create mode 100644 doc/draft/draft-ietf-dnsind-rollover-01.txt delete mode 100644 doc/draft/draft-ietf-dnsind-sec-rr-00.txt create mode 100644 doc/draft/draft-ietf-dnsind-sec-rr-01.txt diff --git a/doc/draft/draft-duerst-dns-i18n-02.txt b/doc/draft/draft-duerst-dns-i18n-02.txt deleted file mode 100644 index a42981634b..0000000000 --- a/doc/draft/draft-duerst-dns-i18n-02.txt +++ /dev/null @@ -1,905 +0,0 @@ - - - - - - -Internet Draft M. Duerst - Keio University -Expires in six months July 1998 - - - Internationalization of Domain Names - - -Status of this Memo - - This document is an Internet-Draft. Internet-Drafts are working doc- - uments of the Internet Engineering Task Force (IETF), its areas, and - its working groups. Note that other groups may also distribute work- - ing documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months. Internet-Drafts may be updated, replaced, or obsoleted by - other documents at any time. It is not appropriate to use Internet- - Drafts as reference material or to cite them other than as a "working - draft" or "work in progress". - - To learn the current status of any Internet-Draft, please check the - 1id-abstracts.txt listing contained in the Internet-Drafts Shadow - Directories on ftp.ietf.org (US East Coast), nic.nordu.net - (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific - Rim). - - Distribution of this document is unlimited. Please send comments to - the author at . - - -Abstract - - Internet domain names are currently limited to a very restricted - character set. This document proposes the introduction of a new - "zero-level" domain (ZLD) to allow the use of arbitrary characters - from the Universal Character Set (ISO 10646/Unicode) in domain names. - The proposal is fully backwards compatible and does not need any - changes to DNS. Version 02 is reissued without changes just to - keep this draft available. - -Table of contents - - 0. Change History ................................................. 2 - 0.8 Changes Made from Version 01 to Version 02 .................. 2 - 0.9 Changes Made from Version 00 to Version 01 .................. 2 - 1. Introduction ................................................... 3 - 1.1 Motivation .................................................. 3 - - - - Expires End of January 1998 [Page 1] - -Internet Draft Internationalization of Domain Names July 1997 - - - 1.2 Notational Conventions ...................................... 4 - 2. The Hidden Zero Level Domain ................................... 4 - 3. Encoding International Characters .............................. 5 - 3.1 Encoding Requirements ....................................... 5 - 3.2 Encoding Definition ......................................... 5 - 3.3 Encoding Example ............................................ 7 - 3.4 Length Considerations ....................................... 8 - 4. Usage Considerations ........................................... 8 - 4.1 General Usage ............................................... 8 - 4.2 Usage Restrictions .......................................... 9 - 4.3 Domain Name Creation ....................................... 10 - 4.4 Usage in URLs .............................................. 12 - 5. Alternate Proposals ........................................... 13 - 5.1 The Dillon Proposal ........................................ 13 - 5.2 Using a Separate Lookup Service ............................ 13 - 6. Generic Considerations ........................................ 14 - 5.1 Security Considerations .................................... 14 - 5.2 Internationalization Considerations ........................ 14 - Acknowledgements ................................................. 14 - Bibliography ..................................................... 15 - Author's Address .................................................= - 16 - - - - -0. Change History - - - -0.8 Changes Made from Version 01 to Version 02 - - No significant changes; reissued to make it available officially. - Changed author's address. - - Changes deferred to future versions (if ever): - - Decide on ZLD name (.i or .i18n.int or something else) - - Decide on casing solution - - Decide on exact syntax - - Proposals for experimental setup - - - - -0.9 Changes Made from Version 00 to Version 01 - - - - - - - - Expires End of January 1998 [Page 2] - -Internet Draft Internationalization of Domain Names July 1997 - - - - Minor rewrites and clarifications - - - Added the following references: [RFC1730], [Kle96], [ISO3166], - [iNORM] - - - Slightly expanded discussion about casing - - - Added some variant proposals for syntax - - - Added some explanations about different kinds of name parallelism - - - Added some explanation about independent addition of internation- - alized names in subdomains without bothering higher-level domains - - - Added some explanations about tools needed for support, and the - MX/CNAME problem - - - Change to RFC1123 (numbers allowed at beginning of labels) - - - - -1. Introduction - - -1.1 Motivation - - - The lower layers of the Internet do not discriminate any language or - script. On the application level, however, the historical dominance - of the US and the ASCII character set [ASCII] as a lowest common - denominator have led to limitations. The process of removing these - limitations is called internationalization (abbreviated i18n). One - example of the abovementioned limitations are domain names [RFC1034, - RFC1035], where only the letters of the basic Latin alphabet (case- - insensitive), the decimal digits, and the hyphen are allowed. - - While such restrictions are convenient if a domain name is intended - to be used by arbitrary people around the globe, there may be very - good reasons for using aliases that are more easy to remember or type - in a local context. This is similar to traditional mail addresses, - where both local scripts and conventions and the Latin script can be - used. - - There are many good reasons for domain name i18n, and some arguments - that are brought forward against such an extension. This document, - however, does not discuss the pros and cons of domain name i18n. It - proposes and discusses a solution and therefore eliminates one of the - - - - Expires End of January 1998 [Page 3] - -Internet Draft Internationalization of Domain Names July 1997 - - - most often heard arguments agains, namely "it cannot be done". - - The solution proposed in this document consists of the introduction - of a new "zero-level" domain building the root of a new domain - branch, and an encoding of the Universal Character Set (UCS) - [ISO10646] into the limited character set of domain names. - - - -1.2 Notational Conventions - - In the domain name examples in this document, characters of the basic - Latin alphabet (expressible in ASCII) are denoted with lower case - letters. Upper case letters are used to represent characters outside - ASCII, such as accented characters of the Latin alphabet, characters - of other alphabets and syllabaries, ideographic characters, and vari- - ous signs. - - -2. The Hidden Zero Level Domain - - The domain name system uses the domain "in-addr.arpa" to convert - internet addresses back to domain names. One way to view this is to - say that in-addr.arpa forms the root of a separate hierarchy. This - hierarchy has been made part of the main domain name hierarchy just - for implementation convenience. While syntactically, in-addr.arpa is - a second level domain (SLD), functionally it is a zero level domain - (ZLD) in the same way as "." is a ZLD. A similar example of a ZLD is - the domain tpc.int, which provides a hierarchy of the global phone - numbering system [RFC1530] for services such as paging and printing - to fax machines. - - For domain name i18n to work inside the tight restrictions of domain - name syntax, one has to define an encoding that maps strings of UCS - characters to strings of characters allowable in domain names, and a - means to distinguish domain names that are the result of such an - encoding from ordinary domain names. - - This document proposes to create a new ZLD to distinguish encoded - i18n domain names from traditional domain names. This domain would - be hidden from the user in the same way as a user does not see in- - addr.arpa. This domain could be called "i18n.arpa" (although the use - of arpa in this context is definitely not appropriate), simply - "i18n", or even just "i". Below, we are using "i" for shortness, - while we leave the decision on the actual name to further= - discussion. - - - - - - - Expires End of January 1998 [Page 4] - -Internet Draft Internationalization of Domain Names July= - 1997 - - -3. Encoding International Characters - - - - -3.1 Encoding Requirements - - - Until quite recently, the thought of going beyond ASCII for something - such as domain names failed because of the lack of a single encom- - passing character set for the scripts and languages of the world. - Tagging techniques such as those used in MIME headers [RFC1522] would - be much too clumsy for domain names. - - The definition of ISO 10646 [ISO10646], codepoint by codepoint iden- - tical with Unicode [Unicode], provides a single Universal Character - Set (UCS). A recent report [RFCIAB] clearly recommends to base the - i18n of the Internet on these standards. - - An encoding for i18n domain names therefore has to take the charac- - ters of ISO 10646/Unicode as a starting point. The full four-byte - (31 bit) form of UCS, called UCS4, should be used. A limitation to - the two-byte form (UCS2), which allows only for the encoding of the - Base Multilingual Plane, is too restricting. - - For the mapping between UCS4 and the strongly limited character set - of domain names, the following constraints have to be considered: - - - The structure of domain names, and therefore the "dot", have to be - conserved. Encoding is done for individual labels. - - - Individual labels in domain names allow the basic Latin alphabet - (monocase, 26 letters), decimal digits, and the "-" inside the - label. The capacity per octet is therefore limited to somewhat - above 5 bits. - - - There is no need nor possibility to preserve any characters. - - - Frequent characters (i.e. ASCII, alphabetic, UCS2, in that order) - should be encoded relatively compactly. A variable-length encoding - (similar to UTF-8) seems desirable. - - - -3.2 Encoding Definition - - - Several encodings for UCS, so called UCS Transform Formats, exist - - - - Expires End of January 1998 [Page 5] - -Internet Draft Internationalization of Domain Names July 1997 - - - already, namely UTF-8 [RFC2044], UTF-7 [RFC1642], and UTF-16 [Uni- - code]. Unfortunately, none of them is suitable for our purposes. We - therefore use the following encoding: - - - To accommodate the slanted probability distribution of characters - in UCS4, a variable-length encoding is used. - - - Each target letter encodes 5 bits of information. Four bits of - information encode character data, the fifth bit is used to indi- - cate continuation of the variable-length encoding. - - - Continuation is indicated by distinguishing the initial letter - from the subsequent letter. - - - Leading four-bit groups of binary value 0000 of UCS4 characters - are discarded, except for the last TWO groups (i.e. the last - octet). This means that ASCII and Latin-1 characters need two - target letters, the main alphabets up to and including Tibetan - need three target letters, the rest of the characters in the BMP - need four target letters, all except the last (private) plane in - the UTF-16/Surrogates area [Unicode] need five target letters, and - so on. - - - The letters representing the various bit groups in the various - positions are chosen according to the following table: - - - Nibble Value Initial Subsequent - Hex Binary - 0 0000 G 0 - 1 0001 H 1 - 2 0010 I 2 - 3 0011 J 3 - 4 0100 K 4 - 5 0101 L 5 - 6 0110 M 6 - 7 0111 N 7 - 8 1000 O 8 - 9 1001 P 9 - A 1010 Q A - B 1011 R B - C 1100 S C - D 1101 T D - E 1110 U E - F 1111 V F - - - [Should we try to eliminate "I" and "O" from initial? "I" might be - - - - Expires End of January 1998 [Page 6] - -Internet Draft Internationalization of Domain Names July 1997 - - - eliminated because then an algorithm can more easily detect ".i". "O" - could lead to some confusion with "0". What other protocols are - there that might be able to use a similar solution, but that might - have other restrictions for the initial letters? Proposal to run ini- - tial range from H to X. Extracting the initial bits then becomes ^ - 'H'. Proposal to have a special convention for all-ASCII labels - (start label with one of the letters not used above).] - - Please note that this solution has the following interesting proper- - ties: - - - For subsequent positions, there is an equivalence between the hex- - adecimal value of the character code and the target letter used. - This assures easy conversion and checking. - - - The absence of digits from the "initial" column, and the fact that - the hyphen is not used, assures that the resulting string conforms - to domain name syntax. - - - Raw sorting of encoded and unencoded domain names is equivalent. - - - The boundaries of characters can always be detected easily. - (While this is important for representations that are used inter- - nally for text editing, it is actually not very important here, - because tools for editing can be assumed to use a more straight- - forward representation internally.) - - - Unless control characters are allowed, the target string will - never actually contain a G. - - - -3.3 Encoding Example - - - As an example, the current domain - - is.s.u-tokyo.ac.jp - - with the components standing for information science, science, the - University of Tokyo, academic, and Japan, might in future be repre- - sented by - - JOUHOU.RI.TOUDAI.GAKU.NIHON - - (a transliteration of the kanji that might probably be chosen to rep- - resent the same domain). Writing each character in U+HHHH notation as - in [Unicode], this results in the following (given for reference - - - - Expires End of January 1998 [Page 7] - -Internet Draft Internationalization of Domain Names July 1997 - - - only, not the actual encoding or something being typed in by the - user): - - U+60c5U+5831.U+7406.U+6771U+5927.U+5b66.U+65e5U+672c - - The software handling internationalized domain names will translate - this, according to the above specifications, before submitting it to - the DNS resolver, to: - - M0C5L831.N406.M771L927.LB66.M5E5M72C.i - - - -3.4 Length Considerations - - - DNS allows for a maximum of 63 positions in each part, and for 255 - positions for the overall domain name including dots. This allows up - to 15 ideographs, or up to 21 letters e.g. from the Hebrew or Arabic - alphabet, in a label. While this does not allow for the same margin - as in the case of ASCII domain names, it should still be quite suffi- - cient. [Problems could only surface for languages that use very long - words or terms and don't know any kind of abbreviations or similar - shortening devices. Do these exist? Islandic expert asserted - Islandic is not a problem.] DNS contains a compression scheme that - avoids sending the same trailing portion of a domain name twice in - the same transmission. Long domain names are therefore not that much - of a concern. - - -4. Usage Considerations - - - -4.1 General Usage - - - To implement this proposal, neither DNS servers nor resolvers need - changes. These programs will only deal with the encoded form of the - domain name with the .i suffix. Software that wants to offer an - internationalized user interface (for example a web browser) is - responsible for the necessary conversions. It will analyze the domain - name, call the resolver directly if the domain name conforms to the - domain name syntax restrictions, and otherwise encode the name - according to the specifications of Section 3.2 and append the .i suf- - fix before calling the resolver. New implementations of resolvers - will of course offer a companion function to gethostbyname accepting - a ISO10646/Unicode string as input. - - - - Expires End of January 1998 [Page 8] - -Internet Draft Internationalization of Domain Names July 1997 - - - For domain name administrators, them main tool that will be needed is - a program to compile files configuring zones from an UTF-8 notation - (or any other suitable encoding) to the encoding described in Section - 3.3. Utility tools will include a corresponding decompiler, checkers - for various kinds of internationalization-related errors, and tools - for managing syntactic parallelism (see Section 4.3). - - -4.2 Usage Restrictions - - - While this proposal in theory allows to have control characters such - as BEL or NUL or symbols such as arrows and smilies in domain names, - such characters should clearly be excluded from domain names. Whether - this has to be explicitly specified or whether the difficulty to type - these characters on any keyboard of the world will limit their use - has to be discussed. One approach is to start with a very restricted - subset and gradually relax it; the other is to allow almost anything - and to rely on common sense. Anyway, such specifications should go - into a separate document to allow easy updates. - - A related point is the question of equivalence. For historical rea- - sons, ISO 10646/Unicode contain considerable number of compatibility - characters and allow more than one representation for characters with - diacritics. To guarantee smooth interoperability in these and related - cases, additional restrictions or the definition of some form of nor- - malization seem necessary. However, this is a general problem - affecting all areas where ISO 10646/Unicode is used in identifiers, - and should therefore be addressed in a generic way. See [iNORM] for - an initial proposal. - - Equally related is the problem of case equivalence. Users can very - well distinguish between upper case and lower case. Also, casing in - an i18n context is not as straightforward as for ASCII, so that case - equivalence is best avoided. Problems therefore result not from the - fact that case is distinguished for i18n domain names, but from the - fact that existing domain names do not distinguish case. Where it is - impossible to distinguish between next.com and NeXT.com, the same two - subdomains would easily be distinguishable if subordinate to a i18n - domain. There are several possible solutions. One is to try to grad- - ually migrate from a case-insensitive solution to a case-sensitive - solution even for ASCII. Another is to allow case-sensitivity only - beyond ASCII. Another is to restrict anything beyond ASCII to lower- - case only (lowercase distinguishes better than uppercase, and is also - generally used for ASCII domain names). - - A problem that also has to be discussed and solved is bidirectional- - ity. Arabic and Hebrew characters are written right-to-left, and the - - - - Expires End of January 1998 [Page 9] - -Internet Draft Internationalization of Domain Names July 1997 - - - mixture with other characters results in a divergence between logical - and graphical sequence. See [HTML-I18N] for more explanations. The - proposal of [Yer96] for dealing with bidirectionality in URLs could - probably be applied to domain names. Anyway, there should be a gen- - eral solution for identifiers, not a DNS-specific solution. - - -4.3 Domain Name Creation - - - The ".i" ZLD should be created as such to allow the internationaliza- - tion of domain names. Rules for creating subdomains inside ".i" - should follow the established rules for the creation of functionally - equivalent domains in the existing domain hierarchy, and should - evolve in parallel. - - For the actual domain hierarchy, the amount of parallelism between - the current ASCII-oriented hierarchy and some internationalized hier- - archy depends on various factors. In some cases, two fully parallel - hierarchies may emerge. In other cases, if more than one script or - language is used locally, more than two parallel hierarchies may - emerge. Some nodes, e.g. in intranets, may only appear in an i18n - hierarchy, whereas others may only appear in the current hierarchy. - In some cases, the pecularities of scripts, languages, cultures, and - the local marketplace may lead to completely different hierarchies. - - Also, one has to be aware that there may be several kinds of paral- - lelisms. The first one is called syntactic parallelism. If there is - a domain XXXX.yy.zz and a domain vvvv.yy.zz, then the domain yy.zz - will have to exist both in the traditional DNS hierarchy as well as - within the hierarchy starting at the .i ZLD, with appropriate encod- - ing. - - The second type of parallelism is called transcription parallelism. - It results by transcribing or transliterating relations between ASCII - domain names and domain names in other scripts. - - The third type of parallelism is called semantic parallelism. It - results from translating elements of a domain name from one language - to another, possibly also changing the script or set of used charac- - ters. - - On the host level, parallelism means that there are two names for the - same host. Conventions should exist to decide whether the parallel - names should have separate IP addresses or not (A record or CNAME - record). With separate IP addresses, address to name lookup is easy, - otherwise it needs special precautions to be able to find all names - corresponding to a given host address. Another detail entering this - - - - Expires End of January 1998 [Page 10] - -Internet Draft Internationalization of Domain Names July 1997 - - - consideration is that MX records only work for hostnames/domains, - not for CNAME aliases. This at least has the consequence that alias - resolution for internationalized mail addresses has to occur before - MX record lookup. - - When discussing and applying the rules for creating domain names, - some peculiarities of i18n domain names should be carefully consid- - ered: - - - Depending on the script, reasonable lengths for domain name parts - may differ greatly. For ideographic scripts, a part may often be - only a one-letter code. Established rules for lengths may need - adaptation. For example, a rule for country TLDs could read: one - ideographic character or two other characters. - - - If the number of generic TLDs (.com, .edu, .org, .net) is kept - low, then it may be feasible to restrict i18n TLDs to country - TLDs. - - - There are no ISO 3166 [ISO3166] two-letter codes in scripts other - than Latin. I18n domain names for countries will have to be - designed from scratch. - - - The names of some countries or regions may pose greater political - problems when expressed in the native script than when expressed - in 2-letter ISO 3166 codes. - - - I18n country domain names should in principle only be created in - those scripts that are used locally. There is probably little use - in creating an Arabic domain name for China, for example. - - - In those cases where domain names are open to a wide range of - applicants, a special procedure for accepting applications should - be used so that a reasonable-quality fit between ASCII domain - names and i18n domain names results where desired. This would - probably be done by establishing a period of about a month for - applications inside a i18n domain newly created as a parallel for - an existing domain, and resolving the detected conflicts. For - syntactically parallel domain names, the owners should always be - the same. Administration may be split in some cases to account for - the necessary linguistic knowledge. For domain names with tran- - scription parallelism and semantic parallelism, the question of - owner identity should depend on the real-life situation (trade- - marks,...). - - - It will be desirable to have internationalized subdomains in non- - internationalized TLDs. As an example, many companies in France - may want to register an accented version of their company name, - - - - Expires End of January 1998 [Page 11] - -Internet Draft Internationalization of Domain Names July 1997 - - - while remaining under the .fr TLD. For this, .fr would have to be - reregistered as .M6N2.i. Accented and other internationalized sub- - domains would go below .M6N2.i, whereas unaccented ones would go - below .fr in its plain form. - - - To generalize the above case, one may need to create a requirement - that any domain name registry would have to register and manage - syntactically parallel domain names below the .i ZLD upon request - to allow registration of i18n domain names in arbitrary subdo- - mains. An alternative to this is to organize domain name search - so that e.g. in a search for XXXXXX.fr, if M6N2.i is not found in - .i, the name server for .fr is queried for XXXXXX.M6N2.i (with - XXXXXX appropriately encoded). This convention would allow lower- - level domains to introduce internationalized subdomains without - depending on higher-level domains. - - - -4.4 Usage in URLs - - According to current definitions, URLs encode sequences of octets - into a sequence of characters from a character set that is almost as - limited as the character set of domain names [RFC1738]. This is - clearly not satisfying for i18n. - - Internationalizing URLs, i.e. assigning character semantics to the - encoded octets, can either be done separately for each part and/or - scheme, or in an uniform way. Doing it separately has the serious - disadvantage that software providing user interfaces for URLs in gen- - eral would have to know about all the different i18n solutions of the - different parts and schemes. Many of these solutions may not even be - known yet. - - It is therefore definitely more advantageous to decide on a single - and consistent solution for URL internationalization. The most valu- - able candidate [Yer96], for many reasons, is UTF-8 [RFC2044], an - ASCII-compatible encoding of UCS4. - - Therefore, an URL containing the domain name of the example of Sec- - tion 3.3 should not be written as: - - ftp://M0C5L831.N406.M771L927.LB66.M5E5M72C.i - - (although this will also work) but rather - - ftp://%e6%83%85%e5%a0%b1.%e7%90%86.%e6%9d%b1%e5%a4%a7. - %e5%ad%a6.%e6%97%a5%e6%9c%ac - - - - - Expires End of January 1998 [Page 12] - -Internet Draft Internationalization of Domain Names July 1997 - - - In this canonical form, the trailing .i is absent, and the octets can - be reconstructed from the %HH-encoding and interpreted as UTF-8 by - generic URL software. The software part dealing with domain names - will carry out the conversion to the .i form. - - -5. Alternate Proposals - - - -5.1 The Dillon Proposal - - The proposal of Michael Dillon [Dillon96] is also based on encoding - Unicode into the limited character set of domain names. Distinction - is done for each part, using the hyphen in initial position. Because - this does not fully conform to the syntax of existing domain names, - it is questionable whether it is backwards-compatible. On the other - hand, this has the advantage that local i18n domain names can be - installed easily without cooperation by the manager of the superdo- - main. - - A variable-length scheme with base 36 is used that can encode up to - 1610 characters, absolutely insufficient for Chinese or Japanese. - Characters assumed not to be used in i18n domain names are excluded, - i.e. only one case is allowed for basic Latin characters. This means - that large tables have to be worked out carefully to convert between - ISO 10646/Unicode and the actual number that is encoded with base= - 36. - - -5.2 Using a Separate Lookup Service - - Instead of using a special encoding and burdening DNS with i18n, one - could build and use a separate lookup service for i18n domain names. - Instead of converting to UCS4 and encoding according to Section 3.2, - and then calling the DNS resolver, a program would contact this new - service when seeing a domain name with characters outside the allowed - range. - - Such solutions have various problems. There are many directory ser- - vices and proposals for how to use them in a way similar to DNS. For - an overview and a specific proposal, see [Kle96]. However, while - there are many proposals, a real service containing the necessary - data and providing the wide installed base and distributed updating - is in DNS does not exist. - - Most directory service proposals also do not offer uniqueness. - Defining unique names again for a separate service will duplicate - much of the work done for DNS. If uniqueness is not guaranteed, the - - - - Expires End of January 1998 [Page 13] - -Internet Draft Internationalization of Domain Names July 1997 - - - user is bundened with additional selection steps. - - Using a separate lookup service for the internationalization of - domain names also results in more complex implementations than the - proposal made in this draft. Contrary to what some people might - expect, the use of a separate lookup service also does not solve a - capacity problem with DNS, because there is no such problem, nor will - one be created with the introduction of i18n domain names. - - -6. Generic Considerations - - - -6.1 Security Considerations - - This proposal is believed not to raise any other security considera- - tions than the current use of the domain name system. - - -6.2 Internationalization Considerations - - This proposal addresses internationalization as such. The main addi- - tional consideration with respect to internationalization may be the - indication of language. However, for concise identifiers such as - domain names, language tagging would be too much of a burden and - would create complex dependencies with semantics. - - - NOTE -- This section is introduced based on a recommenda- - tion in [RFCIAB]. A similar section addressing internation- - alization should be included in all application level - internet drafts and RFCs. - - - - - -Acknowledgements - - I am grateful in particular to the following persons for their advice - or criticism: Bert Bos, Lori Brownell, Michael Dillon, Donald E. - Eastlake 3rd, David Goldsmith, Larry Masinter, Ryan Moats, Keith - Moore, Thorvardur Kari Olafson, Erik van der Poel, Jurgen Schwertl, - Paul A. Vixie, Francois Yergeau, and others. - - - - - - - Expires End of January 1998 [Page 14] - -Internet Draft Internationalization of Domain Names July= - 1997 - - -Bibliography - - [ASCII] Coded Character Set -- 7-Bit American Standard Code - for Information Interchange, ANSI X3.4-1986. - - [Dillon96] M. Dillon, "Multilingual Domain Names", Memra Software - Inc., November 1996 (circulated Dec. 6, 1996 on iahc- - discuss@iahc.org). - - [HTML-I18N] F. Yergeau, G. Nicol, G. Adams, and M. Duerst, "Inter- - nationalization of the Hypertext Markup Language", - Work in progress (draft-ietf-html-i18n-05.txt), August - 1996. - - [iNORM] M. Duerst, "Normalization of Internationalized Identi- - fiers", draft-duerst-i18n-norm-00.txt, July 1997. - - [ISO3166] ISO 3166, "Code for the representation of names of - countries", ISO 3166:1993. - - [ISO10646] ISO/IEC 10646-1:1993. International standard -- Infor- - mation technology -- Universal multiple-octet coded - character Set (UCS) -- Part 1: Architecture and basic - multilingual plane. - - [Kle96] J. Klensin and T. Wolf, Jr., "Domain Names and Company - Name Retrieval", Work in progress (draft-klensin-tld- - whois-01.txt), November 1996. - - [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facili- - ties", ISI, Nov. 1987. - - [RFC1035] P. Mockapetris, "Domain Names - Implementation and - Specification", ISI, Nov. 1987. - - [RFC1522] K. Moore, "MIME (Multipurpose Internet Mail Exten- - sions) Part Two: Message Header Extensions for Non- - ASCII Text", University of Tennessee, September 1993. - - [RFC1642] D. Goldsmith, M. Davis, "UTF-7: A Mail-safe Transfor- - mation Format of Unicode", Taligent Inc., July 1994. - - [RFC1730] C. Malamud and M. Rose, "Principles of Operation for - the TPC.INT Subdomain: General Principles and Policy", - Internet Multicasting Service, October 1993. - - [RFC1738] T. Berners-Lee, L. Masinter, and M. McCahill, - "Uniform Resource Locators (URL)", CERN, Dec. 1994. - - - - Expires End of January 1998 [Page 15] - -Internet Draft Internationalization of Domain Names July 1997 - - - [RFC2044] F. Yergeau, "UTF-8, A Transformation Format of Unicode - and ISO 10646", Alis Technologies, October 1996. - - [RFCIAB] C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R. - Atkinson, M. Crispin, P. Svanberg, "Report from the - IAB Character Set Workshop", October 1996 (currently - available as draft-weider-iab-char-wrkshop-00.txt). - - [Unicode] The Unicode Consortium, "The Unicode Standard, Version - 2.0", Addison-Wesley, Reading, MA, 1996. - - [Yer96] F. Yergeau, "Internationalization of URLs", Alis Tech- - nologies, - = - . - - - -Author's Address - - Martin J. Duerst - World Wide Web Consortium - Keio Research Institute at SFC - Keio University - 5322 Endo - Fujisawa - 252-8520 Japan - - Tel: +81 466 49 11 70 - E-mail: mduerst@w3.org - - - NOTE -- Please write the author's name with u-Umlaut wherever - possible, e.g. in HTML as Dürst. - - - - - - - - - - - - - - - - - - - Expires End of January 1998 [Page 16] - diff --git a/doc/draft/draft-duerst-dns-i18n-03.txt b/doc/draft/draft-duerst-dns-i18n-03.txt new file mode 100644 index 0000000000..d09a2ded5b --- /dev/null +++ b/doc/draft/draft-duerst-dns-i18n-03.txt @@ -0,0 +1,5 @@ +This Internet-Draft has expired and is no longer available. + +Unrevised documents placed in the Internet-Drafts directories have a +maximum life of six months. After that time, they must be updated, or +they will be deleted. This document was deleted on March 20, 2000. diff --git a/doc/draft/draft-ietf-dnsext-sig-zero-00.txt b/doc/draft/draft-ietf-dnsext-sig-zero-01.txt similarity index 67% rename from doc/draft/draft-ietf-dnsext-sig-zero-00.txt rename to doc/draft/draft-ietf-dnsext-sig-zero-01.txt index 8052d1f7d2..971b13d33b 100644 --- a/doc/draft/draft-ietf-dnsext-sig-zero-00.txt +++ b/doc/draft/draft-ietf-dnsext-sig-zero-01.txt @@ -1,24 +1,23 @@ + INTERNET-DRAFT Donald E. Eastlake 3rd UPDATES RFC 2535 Motorola -Expires: September 2000 March 2000 +Expires: October 2000 April 2000 DNS Request and Transaction Signatures ( SIG(0)s ) --- ------- --- ----------- ---------- - ------- - - draft-ietf-dnsext-sig-zero-00.txt + Status of This Document - This draft, file name draft-ietf-dnsext-sig-zero-00.txt, is intended - to become a Proposed Standard RFC updating Proposed Standard [RFC - 2535]. Distribution of this document is unlimited. Comments should - be sent to the DNS Working Group mailing list - or to the author. [This is the successor - to draft-ietf-dnsind-sig-zero-01.txt.] + This draft is intended to become a Proposed Standard RFC updating + Proposed Standard [RFC 2535]. Distribution of this document is + unlimited. Comments should be sent to the DNS Working Group mailing + list or to the author. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working @@ -26,10 +25,11 @@ Status of This Document 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." + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + Drafts as reference material or to cite them other than as a + ``working draft'' or ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt @@ -57,7 +57,7 @@ Abstract D. Eastlake 3rd [Page 1] -INTERNET-DRAFT DNS SIG(0) March 2000 +INTERNET-DRAFT DNS SIG(0) April 2000 Acknowledgments @@ -67,6 +67,7 @@ Acknowledgments acknowledged: Olafur Gudmundsson + Ed Lewis Brian Wellington @@ -111,11 +112,10 @@ Table of Contents - D. Eastlake 3rd [Page 2] -INTERNET-DRAFT DNS SIG(0) March 2000 +INTERNET-DRAFT DNS SIG(0) April 2000 1. Introduction @@ -127,8 +127,8 @@ INTERNET-DRAFT DNS SIG(0) March 2000 transactions / responses. Such a resource record, because it has a type covered field of zero, is frequently called a SIG(0). The changes are based on implementation and attempted implementation - experience with TSIG [draft-ietf-{dnsind|dnsext}-tsig-*.txt] and the - [RFC 2535] specification for SIG(0). + experience with TSIG [draft-ietf-dnsext-tsig-*.txt] and the [RFC + 2535] specification for SIG(0). Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2 and 4.3. No changes are made herein related to the KEY or NXT RRs or @@ -143,17 +143,14 @@ INTERNET-DRAFT DNS SIG(0) March 2000 2. SIG(0) Design Rationale - The authenticated data origin and data existence denial services of - secure DNS protect only regular data resource records (RRs) or - authenticatably deny their nonexistence. These services provide no - protection for glue records, DNS requests, no protection for message - headers on requests or responses, and no protection of the overall - integrity of a response. - - If header bits are falsely set or the like by a bad server, there is - little that can be done. However, it is possible to add transaction - and query authentication to be sure that queries and responses and - not tampered with in transit. + SIG(0) provides protection for DNS transactions and requests that is + not provided by the regular SIG, KEY, and NXT RRs specified in [RFC + 2535]. The authenticated data origin services of secure DNS either + provide protected data resource records (RRs) or authenticatably deny + their nonexistence. These services provide no protection for glue + records, DNS requests, no protection for message headers on requests + or responses, and no protection of the overall integrity of a + response. @@ -161,19 +158,22 @@ INTERNET-DRAFT DNS SIG(0) March 2000 Transaction authentication means that a requester can be sure it is at least getting the messages from the server it queried and that the - response is from the request it sent (i.e., that these messages have - not been diddled in transit). This is accomplished by optionally - adding either a TSIG RR [draft-ietf-{dnsind|dnsext}-tsig-*.txt] or, - as described herein, a SIG(0) resource record at the end of the - response which digitally signs the concatenation of the server's - response and the corresponding resolver query. + received messages are in response to me query it sent. This is + accomplished by optionally adding either a TSIG RR [draft-ietf- + dnsext-tsig-*.txt] or, as described herein, a SIG(0) resource record + at the end of the response which digitally signs the concatenation of + the server's response and the corresponding resolver query. + + + + D. Eastlake 3rd [Page 3] -INTERNET-DRAFT DNS SIG(0) March 2000 +INTERNET-DRAFT DNS SIG(0) April 2000 2.2 Request Authentication @@ -214,43 +214,41 @@ INTERNET-DRAFT DNS SIG(0) March 2000 Because TSIG involves secret keys installed at both the requester and server the presence of such a key implies that the other party - understands TSIG and likely has the same key installed. Furthermore, - TSIG uses keyed hash authentication codes which are relatively - inexpensive to compute. Thus it is common to authenticate requests - with TSIG and responses are authenticated with TSIG if the + understands TSIG and very likely has the same key installed. + Furthermore, TSIG uses keyed hash authentication codes which are + relatively inexpensive to compute. Thus it is common to authenticate + requests with TSIG and responses are authenticated with TSIG if the corresponding request is authenticated. SIG(0) on the other hand, uses public key authentication, where the - public keys are stored in DNS as KEY RRs. Thus, existence of such a - KEY RR does not necessarily imply implementation of SIG(0). In - addition, SIG(0) involves relatively expensive public key - cryptographic operations that should be minimized and the - verification of a SIG(0) involves obtaining and verifying the + public keys are stored in DNS as KEY RRs and a private key is stored + at the signer. Existence of such a KEY RR does not necessarily imply + implementation of SIG(0). In addition, SIG(0) involves relatively + expensive public key cryptographic operations that should be + minimized and the verification of a SIG(0) involves obtaining and D. Eastlake 3rd [Page 4] -INTERNET-DRAFT DNS SIG(0) March 2000 +INTERNET-DRAFT DNS SIG(0) April 2000 - corresponding KEY which can be an expensive and lengthy operation. - Indeed, a policy of using SIG(0) on all requests and verifying it - before responding would, for some configurations, lead to a deadly - embrace with the attempt to obtain and verify the KEY needed to - authenticate the request SIG(0) resulting in additional requests - accompanied by a SIG(0) leading to further requests accompanied by a - SIG(0), etc. Furthermore, omitting SIG(0)s when not required on - requests halves the number of public key operations required by the - transaction. + verifying the corresponding KEY which can be an expensive and lengthy + operation. Indeed, a policy of using SIG(0) on all requests and + verifying it before responding would, for some configurations, lead + to a deadly embrace with the attempt to obtain and verify the KEY + needed to authenticate the request SIG(0) resulting in additional + requests accompanied by a SIG(0) leading to further requests + accompanied by a SIG(0), etc. Furthermore, omitting SIG(0)s when not + required on requests halves the number of public key operations + required by the transaction. For these reasons, SIG(0)s SHOULD only be used on requests when necessary to authenticate that the requester has some required privilege or identity. SIG(0)s on replies are defined in such a way as to not require a SIG(0) on the corresponding request and still - provide transaction protection. Some responses, such as those - involving TKEY [draft-ietf-dnsext-tkey-*.txt], MUST be authenticated - with TSIG or SIG(0). For other replies, whether they are + provide transaction protection. For other replies, whether they are authenticated by the server or required to be authenticated by the requester SHOULD be a local configuration option. @@ -265,14 +263,15 @@ INTERNET-DRAFT DNS SIG(0) March 2000 2535] and this document concerning SIG(0) RRs should be resolved in favor of this document. - For all transaction SIG(0)s, the signer field MUST be the name of the - originating server host and there MUST be a KEY RR at that name with - the public key corresponding to the private key used to calculate the - signature. (The inverse IP address mapping name for an IP address of - the server MAY be used if the relevant KEY is stored there.) + For all transaction SIG(0)s, the signer field MUST be a name of the + originating host and there MUST be a KEY RR at that name with the + public key corresponding to the private key used to calculate the + signature. (The host domain name used may be the inverse IP address + mapping name for an IP address of the host if the relevant KEY is + stored there.) For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are - meaningless. The TTL fields SHOULD be zero and the CLASS filed + meaningless. The TTL fields SHOULD be zero and the CLASS field SHOULD be ANY. To conserve space, the owner name SHOULD be root (a single zero octet). When SIG(0) authentication on a response is desired, that SIG RR must be considered the highest priority of any @@ -286,32 +285,29 @@ INTERNET-DRAFT DNS SIG(0) March 2000 + D. Eastlake 3rd [Page 5] -INTERNET-DRAFT DNS SIG(0) March 2000 +INTERNET-DRAFT DNS SIG(0) April 2000 3.1 Calculating Request and Transaction SIGs - A DNS request may be optionally signed by including one or more - SIG(0)s at the end of the query additional information section. Such - SIGs are identified by having a "type covered" field of zero. They - sign the preceding DNS request message including DNS header but not - including the UDP/IP header or any request SIG(0)s at the end and - before the request RR counts have been adjusted for the inclusions of - any request SIG(0)s. + A DNS request may be optionally signed by including one SIG(0)s at + the end of the query additional information section. Such a SIG is + identified by having a "type covered" field of zero. It signs the + preceding DNS request message including DNS header but not including + the UDP/IP header and before the request RR counts have been adjusted + for the inclusions of the request SIG(0). - Note: requests and response can either have a single TSIG or one or - more SIG(0)s but not both a TSIG and a SIG(0). + It is calculated by using a "data" (see [RFC 2535], Section 4.1.8) of + (1) the SIG's RDATA section omitting the signature subfield itself, + (2) the entire DNS query messages, including DNS header, but not the + UDP/IP header and before the reply RR counts have been adjusted for + the inclusion of the SIG(0). That is - They are calculated by using a "data" (see [RFC 2535], Section 4.1.8) - of (1) the SIG's RDATA section omitting the signature subfield - itself, (2) the entire DNS query messages, including DNS header, but - not the UDP/IP header or any SIG(0) and before the reply RR counts - have been adjusted for the inclusion of any SIG(0). That is - - data = RDATA | request - SIG(0)s + data = RDATA | request - SIG(0) where "|" is concatenation and RDATA is the RDATA of the SIG(0) being calculated less the signature itself. @@ -320,14 +316,14 @@ INTERNET-DRAFT DNS SIG(0) March 2000 that produced it. Such transaction signatures are calculated by using a "data" of (1) the SIG's RDATA section omitting the signature itself, (2) the entire DNS query message that produced this response, - including the query's DNS header and any SIG(0)s but not its UDP/IP - header, and (3) the entire DNS response message, including DNS header - but not the UDP/IP header or any SIG(0) and before the response RR - counts have been adjusted for the inclusion of any SIG(0). + including the query's DNS header but not its UDP/IP header, and (3) + the entire DNS response message, including DNS header but not the + UDP/IP header and before the response RR counts have been adjusted + for the inclusion of the SIG(0). That is - data = RDATA | full query | response - SIG(0)s + data = RDATA | full query | response - SIG(0) where "|" is concatenation and RDATA is the RDATA of the SIG(0) being calculated less the signature itself. @@ -342,24 +338,28 @@ INTERNET-DRAFT DNS SIG(0) March 2000 packet is calculated with "data" as above and for each subsequent packet, it is calculated as follows: + data = RDATA | DNS payload - SIG(0) | previous packet + + where "|" is concatenations, RDATA is as above, and previous packet + is the previous DNS payload including DNS header and the SIG(0) but D. Eastlake 3rd [Page 6] -INTERNET-DRAFT DNS SIG(0) March 2000 +INTERNET-DRAFT DNS SIG(0) April 2000 - data = RDATA | DNS payload - SIG(0)s | previous packet - - where "|" is concatenations, RDATA is as above, and previous packet - is the previous DNS payload including DNS header and any SIG(0)s but not the TCP/IP header. Support of SIG(0) for TCP is OPTIONAL. As an alternative, TSIG may be used after, if necessary, setting up a key with TKEY [draft-ietf-dnsext-tkey-*.txt]. Except where needed to authenticate an update, TKEY, or similar - privileged request, servers are not required to check request SIGs. + privileged request, servers are not required to check a request + SIG(0). + + Note: requests and response can either have a single TSIG or one + SIG(0) but not both a TSIG and a SIG(0). @@ -373,7 +373,7 @@ INTERNET-DRAFT DNS SIG(0) March 2000 mode in use. For all other responses, it MAY be checked and the message rejected if the checks fail. - If a response SIG(0) checks succeed, such a transaction + If a responses SIG(0) check succeed, such a transaction authentication SIG does NOT directly authenticate the validity any data-RRs in the message. However, it authenticates that they were sent by the queried server and have not been diddled. (Only a proper @@ -405,7 +405,7 @@ INTERNET-DRAFT DNS SIG(0) March 2000 D. Eastlake 3rd [Page 7] -INTERNET-DRAFT DNS SIG(0) March 2000 +INTERNET-DRAFT DNS SIG(0) April 2000 The inclusion of the SIG(0) inception and expiration time under the @@ -415,7 +415,8 @@ INTERNET-DRAFT DNS SIG(0) March 2000 5. IANA Considerations - No new fields are created or field values assigned by the document. + No new parameters are created or parameter values assigned by the + document. @@ -433,13 +434,12 @@ References [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", March 1999. - [draft-ietf-{dnsind|dnsext}-tsig-*.txt] - P. Vixie, O. Gudmundsson, - D. Eastlake, B. Wellington, "Secret Key Transaction Signatures for - DNS (TSIG)". + [draft-ietf-dnsext-tsig-*.txt] - P. Vixie, O. Gudmundsson, D. + Eastlake, B. Wellington, "Secret Key Transaction Signatures for DNS + (TSIG)". [draft-ietf-dnsext-tkey-*.txt] - D. Eastlake, "Secret Key - Establishment for DNS (RR)" - + Establishment for DNS (RR)". @@ -463,7 +463,7 @@ References D. Eastlake 3rd [Page 8] -INTERNET-DRAFT DNS SIG(0) March 2000 +INTERNET-DRAFT DNS SIG(0) April 2000 Author's Address @@ -483,9 +483,9 @@ Author's Address Expiration and File Name - This draft expires September 2000. + This draft expires October 2000. - Its file name is draft-ietf-dnsext-sig-zero-00.txt. + Its file name is draft-ietf-dnsext-sig-zero-01.txt. diff --git a/doc/draft/draft-ietf-dnsext-tkey-01.txt b/doc/draft/draft-ietf-dnsext-tkey-02.txt similarity index 80% rename from doc/draft/draft-ietf-dnsext-tkey-01.txt rename to doc/draft/draft-ietf-dnsext-tkey-02.txt index 6f9b3cc235..5cee98b527 100644 --- a/doc/draft/draft-ietf-dnsext-tkey-01.txt +++ b/doc/draft/draft-ietf-dnsext-tkey-02.txt @@ -1,24 +1,22 @@ DNSEXT Working Group Donald E. Eastlake, 3rd INTERNET-DRAFT Motorola -Expires: September 2000 March 2000 +Expires: October 2000 April 2000 Secret Key Establishment for DNS (TKEY RR) ------ --- ------------- --- --- ----- --- - draft-ietf-dnsext-tkey-01.txt - - Donald E. Eastlake 3rd + Status of This Document - This draft, file name draft-ietf-dnsext-tkey-01.txt, is intended to - be become a Proposed Standard RFC. Distribution of this document is - unlimited. Comments should be sent to the DNS working group mailing - list or to the author. + This draft is intended to be become a Proposed Standard RFC. + Distribution of this document is unlimited. Comments should be sent + to the DNS working group mailing list or + to the author. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working @@ -26,10 +24,11 @@ Status of This Document 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." + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + Drafts as reference material or to cite them other than as a + ``working draft'' or ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt @@ -55,21 +54,21 @@ Status of This Document -Donald E. Eastlake 3rd [Page 1] +Donald Eastlake 3rd [Page 1] -INTERNET-DRAFT The DNS TKEY RR March 2000 +INTERNET-DRAFT The DNS TKEY RR April 2000 Abstract - [draft-ietf-{dnsind|dnsext}-tsig-*.txt] provides a means of - authenticating Domain Name System (DNS) queries and responses using - shared secret keys via the TSIG resource record (RR). However, it - provides no mechanism for setting up such keys other than manual - exchange. This document describes a TKEY RR that can be used in a - number of different modes to establish shared secret keys between a - DNS resolver and server. + [draft-ietf-dnsext-tsig-*.txt] provides a means of authenticating + Domain Name System (DNS) queries and responses using shared secret + keys via the TSIG resource record (RR). However, it provides no + mechanism for setting up such keys other than manual exchange. This + document describes a TKEY RR that can be used in a number of + different modes to establish shared secret keys between a DNS + resolver and server. @@ -113,10 +112,10 @@ Acknowledgments -Donald E. Eastlake 3rd [Page 2] +Donald Eastlake 3rd [Page 2] -INTERNET-DRAFT The DNS TKEY RR March 2000 +INTERNET-DRAFT The DNS TKEY RR April 2000 Table of Contents @@ -148,7 +147,6 @@ Table of Contents 4.5 Query for Resolver Assigned Keying....................12 5. Spontaneous Server Inclusion...........................13 5.1 Spontaneous Server Key Deletion.......................13 - 5.2 Spontaneous GSS-API Exchange..........................14 6. Methods of Encryption..................................14 7. IANA Considerations....................................14 8. Security Considerations................................15 @@ -171,10 +169,11 @@ Table of Contents -Donald E. Eastlake 3rd [Page 3] + +Donald Eastlake 3rd [Page 3] -INTERNET-DRAFT The DNS TKEY RR March 2000 +INTERNET-DRAFT The DNS TKEY RR April 2000 1. Introduction @@ -186,12 +185,12 @@ INTERNET-DRAFT The DNS TKEY RR March 2000 security and dynamic update [RFC 2535, RFC 2136]. Familiarity with these RFCs is assumed. - [draft-ietf-{dnsind|dnsext}-tsig-*.txt] provides a means of - efficiently authenticating DNS messages using shared secret keys via - the TSIG resource record (RR) but provides no mechanism for setting - up such keys other than manual exchange. This document specifies a - TKEY RR that can be used in a number of different modes to establish - and delete such shared secret keys between a DNS resolver and server. + [draft-ietf-dnsext-tsig-*.txt] provides a means of efficiently + authenticating DNS messages using shared secret keys via the TSIG + resource record (RR) but provides no mechanism for setting up such + keys other than manual exchange. This document specifies a TKEY RR + that can be used in a number of different modes to establish and + delete such shared secret keys between a DNS resolver and server. Note that TKEY established keying material and TSIGs that use it are associated with DNS servers or resolvers. They are not associated @@ -229,13 +228,13 @@ INTERNET-DRAFT The DNS TKEY RR March 2000 Section 5 discusses spontaneous inclusion of TKEY RRs in responses by -Donald E. Eastlake 3rd [Page 4] +Donald Eastlake 3rd [Page 4] -INTERNET-DRAFT The DNS TKEY RR March 2000 +INTERNET-DRAFT The DNS TKEY RR April 2000 - servers. + servers which is currently used only for key deletion. Section 6 describes encryption methods for transmitting secret key information. In this document these are used only for the server @@ -287,10 +286,10 @@ INTERNET-DRAFT The DNS TKEY RR March 2000 For a TKEY with a non-root name appearing in a query, the TKEY RR -Donald E. Eastlake 3rd [Page 5] +Donald Eastlake 3rd [Page 5] -INTERNET-DRAFT The DNS TKEY RR March 2000 +INTERNET-DRAFT The DNS TKEY RR April 2000 name SHOULD be a domain locally unique at the resolver, less than 128 @@ -305,30 +304,30 @@ INTERNET-DRAFT The DNS TKEY RR March 2000 its owner name, then the server SHOULD create a globally unique domain name, to be the key name, by suffixing a pseudo-random [RFC 1750] label with a domain name of the server. For example - 89n3mDgX072pp.server.example.com. If generation of a new + 89n3mDgX072pp.server1.example.com. If generation of a new pseudo-random name in each case is an excessive computation load or entropy drain, a serial number prefix can be added to a fixed pseudo-random name generated an DNS server start time, such as - 1001.89n3mDgX072pp.server.example.com. + 1001.89n3mDgX072pp.server1.example.com. If the key is generated as the result of a query with a non-root name, say 789.resolver.example.net, then use the concatenation of that with a name of the server. For example - 789.resolver.example.net.server.example.com. + 789.resolver.example.net.server1.example.com. 2.2 The TTL Field - The TTL field is meaningless. It SHOULD always be zero to be sure - that older DNS implementations do not cache TKEY RRs. + The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to + be sure that older DNS implementations do not cache TKEY RRs. 2.3 The Algorithm Field The algorithm name is in the form of a domain name with the same - meaning as in [draft-ietf-{dnsind|dnsext}-tsig-*.txt]. The algorithm + meaning as in [draft-ietf-dnsext-tsig-*.txt]. The algorithm determines how the secret keying material agreed to using the TKEY RR is actually used to derive the algorithm specific key. @@ -345,10 +344,10 @@ INTERNET-DRAFT The DNS TKEY RR March 2000 material provided. -Donald E. Eastlake 3rd [Page 6] +Donald Eastlake 3rd [Page 6] -INTERNET-DRAFT The DNS TKEY RR March 2000 +INTERNET-DRAFT The DNS TKEY RR April 2000 To avoid different interpretations of the inception and expiration @@ -403,10 +402,10 @@ INTERNET-DRAFT The DNS TKEY RR March 2000 possible if a TKEY is spontaneously included in a response the TKEY -Donald E. Eastlake 3rd [Page 7] +Donald Eastlake 3rd [Page 7] -INTERNET-DRAFT The DNS TKEY RR March 2000 +INTERNET-DRAFT The DNS TKEY RR April 2000 RR and DNS header error field could have unrelated non-zero error @@ -418,7 +417,7 @@ INTERNET-DRAFT The DNS TKEY RR March 2000 The key data size field is an unsigned 16 bit integer in network order which specifies the size of the key exchange data field in - octets. The meaning of the key data depends on the mode. + octets. The meaning of this data depends on the mode. @@ -461,10 +460,10 @@ INTERNET-DRAFT The DNS TKEY RR March 2000 -Donald E. Eastlake 3rd [Page 8] +Donald Eastlake 3rd [Page 8] -INTERNET-DRAFT The DNS TKEY RR March 2000 +INTERNET-DRAFT The DNS TKEY RR April 2000 TKEY queries MUST be authenticated for all modes except GSS-API and, @@ -478,6 +477,9 @@ INTERNET-DRAFT The DNS TKEY RR March 2000 a public (SIG(0)) key signature. It MUST NOT use any key that the query is itself providing. + In the absence of required TKEY authentication, a NOTAUTH error MUST + be returned. + To avoid replay attacks, it is necessary that a TKEY response or query not be valid if replayed on the order of 2**32 second (about 136 years), or a multiple thereof, later. To accomplish this, the @@ -514,17 +516,17 @@ INTERNET-DRAFT The DNS TKEY RR March 2000 the additional information section specifying the Diffie-Hellman mode and accompanied by a KEY RR also in the additional information section specifying a resolver Diffie-Hellman key. The TKEY RR + + +Donald Eastlake 3rd [Page 9] + + +INTERNET-DRAFT The DNS TKEY RR April 2000 + + algorithm field is set to the authentication algorithm the resolver plans to use. The "key data" provided in the TKEY is used as a random [RFC 1750] nonce to avoid always deriving the same keying material - - -Donald E. Eastlake 3rd [Page 9] - - -INTERNET-DRAFT The DNS TKEY RR March 2000 - - for the same pair of DH KEYs. The server response contains a TKEY in its answer section with the @@ -572,17 +574,17 @@ INTERNET-DRAFT The DNS TKEY RR March 2000 toss keys, although it may have to go through another key exchange if it later needs one. Similarly, the server can discard keys although that will result in an error on receiving a query with a TSIG using + + +Donald Eastlake 3rd [Page 10] + + +INTERNET-DRAFT The DNS TKEY RR April 2000 + + the discarded key. To avoid attempted reliance in requests on keys no longer in effect, - - -Donald E. Eastlake 3rd [Page 10] - - -INTERNET-DRAFT The DNS TKEY RR March 2000 - - servers MUST implement key deletion whereby the server "discards" a key on receipt from a resolver of an authenticated delete request for a TKEY RR with the key's name. If the server has no record of a key @@ -605,8 +607,7 @@ INTERNET-DRAFT The DNS TKEY RR March 2000 should be seen for the full description. Basically the resolver and server can exchange queries and responses for type TKEY with a TKEY RR specifying the GSS-API mode in the additional information section - and a GSS-API token in the key data portion of the TKEY RR. See also - section 5.2. + and a GSS-API token in the key data portion of the TKEY RR. Any issues of possible encryption of parts the GSS-API token data being transmitted are handled by the GSS-API level. In addition, the @@ -631,23 +632,23 @@ INTERNET-DRAFT The DNS TKEY RR March 2000 algorithm the resolver plans to use. It is RECOMMENDED that any "key data" provided in the query TKEY RR by the resolver be strongly mixed by the server with server generated randomness [RFC 1750] to derive - the keying material to be used. The KEY RR that appears in the query - need not be accompanied by a SIG(KEY) RR. If the query is -Donald E. Eastlake 3rd [Page 11] +Donald Eastlake 3rd [Page 11] -INTERNET-DRAFT The DNS TKEY RR March 2000 +INTERNET-DRAFT The DNS TKEY RR April 2000 - authenticated by the resolver with a TSIG RR [draft-ietf- - {dnsind|dnsext}-tsig-*.txt] or SIG(0) RR and that authentication is - verified, then any SIG(KEY) provided in the query SHOULD be ignored. - The KEY RR in such a query SHOULD have a name that corresponds to the - resolver but it is only essential that it be a public key for which - the resolver has the corresponding private key so it can decrypt the - response data. + the keying material to be used. The KEY RR that appears in the query + need not be accompanied by a SIG(KEY) RR. If the query is + authenticated by the resolver with a TSIG RR [draft-ietf-dnsext- + tsig-*.txt] or SIG(0) RR and that authentication is verified, then + any SIG(KEY) provided in the query SHOULD be ignored. The KEY RR in + such a query SHOULD have a name that corresponds to the resolver but + it is only essential that it be a public key for which the resolver + has the corresponding private key so it can decrypt the response + data. The server response contains a TKEY RR in its answer section with the server assigned mode and echoes the KEY RR provided in the query in @@ -689,19 +690,19 @@ INTERNET-DRAFT The DNS TKEY RR March 2000 section. The name of the key and the keying data are completely controlled by the sending resolver so a globally unique key name SHOULD be used. The KEY RR used MUST be one for which the server has - the corresponding private key, or it will not be able to decrypt the - keying material and will return a FORMERR, and no untrusted party -Donald E. Eastlake 3rd [Page 12] +Donald Eastlake 3rd [Page 12] -INTERNET-DRAFT The DNS TKEY RR March 2000 +INTERNET-DRAFT The DNS TKEY RR April 2000 - (preferably no other party than the server) has the private key, or - the untrusted private key holder can capture the messages to the - server, learn the shared secret, and spoof valid TSIGs. + the corresponding private key, or it will not be able to decrypt the + keying material and will return a FORMERR, and for which no untrusted + party (preferably no other party than the server) has the private + key, or the untrusted private key holder can capture the messages to + the server, learn the shared secret, and spoof valid TSIGs. The query TKEY RR inception and expiry give the time period the querier intends to consider the keying material valid. The server @@ -720,16 +721,17 @@ INTERNET-DRAFT The DNS TKEY RR March 2000 A DNS server may include a TKEY RR spontaneously as additional information in responses. This SHOULD only be done if the server knows the querier understands TKEY and has this option implemented. - This technique can be used for GSS-API exchange, and to delete a key. - A disadvantage of this technique is that there is no way for the - server to get any error or success indication back and, in the case - of UDP, no way to even know if the DNS response reached the resolver. + This technique can be used to delete a key and may be specified for + modes defined in the future. A disadvantage of this technique is + that there is no way for the server to get any error or success + indication back and, in the case of UDP, no way to even know if the + DNS response reached the resolver. 5.1 Spontaneous Server Key Deletion - A server can optionally tell a client that it has deleted a symmetric + A server can optionally tell a client that it has deleted a secret key by spontaneously including a TKEY RR in the additional information section of a response with the key's name and specifying the key deletion mode. Such a response SHOULD be authenticated. If @@ -748,28 +750,10 @@ INTERNET-DRAFT The DNS TKEY RR March 2000 - - - -Donald E. Eastlake 3rd [Page 13] +Donald Eastlake 3rd [Page 13] -INTERNET-DRAFT The DNS TKEY RR March 2000 - - -5.2 Spontaneous GSS-API Exchange - - A server can spontaneously include in the additional information - section of a response, a GSS-API mode TKEY RR. The information in - the key data section of such a TKEY is a GSS-API token which SHOULD - be fed by the resolver to its local GSS-API implementation. If such - a response is authenticated, the authentication MAY be verify before - processing the data. To the extent that GSS-API provides its own - security, such a response need not be authenticated. To the extent - that GSS-API handles duplicated messages, such a spontaneous TKEY - could be sent repeatedly, until, for example, a response via a GSS- - API mode TKEY query is received. See also section 4.3. - +INTERNET-DRAFT The DNS TKEY RR April 2000 6. Methods of Encryption @@ -788,16 +772,17 @@ INTERNET-DRAFT The DNS TKEY RR March 2000 symmetric algorithms. If the KEY RR specifies the RSA algorithm, then the keying material - is encrypted as per the description of RSA encryption in PKCS#1 [RFC - 2437]. (Note, the secret keying material being sent is directly RSA - encrypted in PKCS#1 format, It is not "enveloped" under some other - symmetric algorithm.) In the unlikely event that the keying material - will not fit within one RSA modulus of the chosen public key, - additional RSA encryption blocks are included. The length of each - block is clear from the public RSA key specified and the PKCS#1 - padding makes it clear what part of the encrypted data is actually - keying material and what part is formatting or the required at least - eight bytes of random [RFC 1750] padding. + is encrypted as per the description of RSAES-PKCS1-v1_5 encryption in + PKCS#1 [RFC 2437]. (Note, the secret keying material being sent is + directly RSA encrypted in PKCS#1 format. It is not "enveloped" under + some other symmetric algorithm.) In the unlikely event that the + keying material will not fit within one RSA modulus of the chosen + public key, additional RSA encryption blocks are included. The + length of each block is clear from the public RSA key specified and + the RSAES-PKCS1-v1_5 padding makes it clear what part of the + encrypted data is actually keying material and what part is + formatting or the required at least eight bytes of random [RFC 1750] + padding. @@ -807,14 +792,6 @@ INTERNET-DRAFT The DNS TKEY RR March 2000 Mode field values 0x0000 through 0x00FF, and 0XFF00 through 0XFFFF can only be assigned by an IETF standards action. Special - - -Donald E. Eastlake 3rd [Page 14] - - -INTERNET-DRAFT The DNS TKEY RR March 2000 - - consideration should be given before the allocation of meaning for Mode field values 0x0000 and 0xFFFF. @@ -829,6 +806,14 @@ INTERNET-DRAFT The DNS TKEY RR March 2000 Standard should not be changed later just because that standard's status is changed to Proposed. + + +Donald Eastlake 3rd [Page 14] + + +INTERNET-DRAFT The DNS TKEY RR April 2000 + + The following assignments are documented herein: RR Type 249 for TKEY. @@ -844,7 +829,7 @@ INTERNET-DRAFT The DNS TKEY RR March 2000 The entirety of this specification is concerned with the secure establishment of a shared secret between DNS clients and servers in - support of TSIG. + support of TSIG [draft-ietf-dnsext-tsig-*.txt]. Protection against denial of service via the use of TKEY is not provided. @@ -867,10 +852,24 @@ INTERNET-DRAFT The DNS TKEY RR March 2000 -Donald E. Eastlake 3rd [Page 15] + + + + + + + + + + + + + + +Donald Eastlake 3rd [Page 15] -INTERNET-DRAFT The DNS TKEY RR March 2000 +INTERNET-DRAFT The DNS TKEY RR April 2000 References @@ -917,7 +916,7 @@ References RFC 2539 - D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", March 1999. - draft-ietf-{dnsind|dnsext}-tsig-*.txt - P. Vixie, O. Gudmundsson, D. + draft-ietf-dnsext-tsig-*.txt - P. Vixie, O. Gudmundsson, D. Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)". @@ -925,10 +924,10 @@ References -Donald E. Eastlake 3rd [Page 16] +Donald Eastlake 3rd [Page 16] -INTERNET-DRAFT The DNS TKEY RR March 2000 +INTERNET-DRAFT The DNS TKEY RR April 2000 Author's Address @@ -940,16 +939,16 @@ Author's Address Telephone: +1 914-276-2668 (h) +1 508-261-5434 (w) - FAX: +1 914-276-2947 (h) + FAX: +1 508-261-4447 (w) email: Donald.Eastlake@motorola.com Expiration and File Name - This draft expires August 2000. + This draft expires October 2000. - Its file name is draft-ietf-dnsext-tkey-01.txt. + Its file name is draft-ietf-dnsext-tkey-02.txt. @@ -983,5 +982,5 @@ Expiration and File Name -Donald E. Eastlake 3rd [Page 17] +Donald Eastlake 3rd [Page 17] diff --git a/doc/draft/draft-ietf-dnsext-zone-status-00.txt b/doc/draft/draft-ietf-dnsext-zone-status-00.txt deleted file mode 100644 index e6b788b503..0000000000 --- a/doc/draft/draft-ietf-dnsext-zone-status-00.txt +++ /dev/null @@ -1,580 +0,0 @@ -DNSEXT WG Edward Lewis -INTERNET DRAFT NAI Labs -Category:I-D Feburary 1, 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 August 1, 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 which 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 - -Expires August 1, 2000 [Page 1] - DNS Security Extension Clarification on Zone Status February 1, 2000 - -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. - -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. The document also updates section 3.4 to eliminate the -definition of experimental keys and illustrate a way to still achieve -the functionality they were designed to provide. - -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 other document completely defining DNSSEC -processing 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 term is defined. - -2.a. Zone signing KEY RR - A KEY RR whose flag field has the value 01 - -Expires August 1, 2000 [Page 2] - DNS Security Extension Clarification on Zone Status February 1, 2000 - -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). - -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. 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. - -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.) - -2.2 Privately Secured - -A privately secured zone is a zone that complies with rules like those -for fully secured, 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. - -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 sentences MUST hold true. The private key's -public companion MUST be preconfigured in all the resolvers of -interest. 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. - - -Expires August 1, 2000 [Page 3] - DNS Security Extension Clarification on Zone Status February 1, 2000 - -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 -unsecured, including zones which are privately secured. Resolvers -which 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. - - -Expires August 1, 2000 [Page 4] - DNS Security Extension Clarification on Zone Status February 1, 2000 - -There is a strong case for discouraging a parent from holding keys of -a signed child. 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 NULL key situations). - -By redefining the security status of a zone to be per zone and not per -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 Is Secured 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. 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. - -If the bit corresponding to the KEY RR set in a parent NXT is set, the -parent has signed a KEY RR set for the child that includes a zone -signing KEY RR (2.a). Furthermore, the validity period on the SIG -(KEY) RR covers the current time and the public component of the key -used to generate the SIG (KEY) RR is validly available from the -parent. - -E.g., Assume the zone "test." signs a key for "zone1.test.," with the -signature valid from May 1st to June 1st and a public key from "test." -available from April 1st until July 1st. The NXT record for -"zone1.test." will have the KEY RR bit set from May 1st to June 1st. - - -Expires August 1, 2000 [Page 5] - DNS Security Extension Clarification on Zone Status February 1, 2000 - -This constraint may be enforced in the SIG (NXT) RR validity period, -timely editing of the master file, or whatever other mechanism "test." -chooses to implement. - -Conversely, if the bit is 0, then the child is not secured. 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 off (0). 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 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. - -If the parent is aware that the child's keys are becoming valid or -will be becoming invalid at a certain point in time, it is recommended -that this be reflected in the NXT's signature validity period. - -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 August 1, 2000 [Page 6] - DNS Security Extension Clarification on Zone Status February 1, 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 allow the child, through some trusted, probably -non-DNS mechanism, to request that the indication of the KEY set in -the NXT 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 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. - -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 which 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 -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. - -Expires August 1, 2000 [Page 7] - DNS Security Extension Clarification on Zone Status February 1, 2000 - -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 August. - -The first issues pertain to the way in which a validation is encoded -in an NXT record by the off-line signer. 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 -effectively disappears. NULL keys are left as a defined entity, but -are rendered meaningless in DNSSEC. - - - -Expires August 1, 2000 [Page 8] - DNS Security Extension Clarification on Zone Status February 1, 2000 - -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. - -[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate -Requirement Levels," RFC 2119, March 1997 - - -Expires August 1, 2000 [Page 9] - DNS Security Extension Clarification on Zone Status February 1, 2000 - -[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 August 1, 2000 [Page 10] diff --git a/doc/draft/draft-ietf-dnsind-dddd-01.txt b/doc/draft/draft-ietf-dnsind-dddd-01.txt deleted file mode 100644 index 0d3b429c54..0000000000 --- a/doc/draft/draft-ietf-dnsind-dddd-01.txt +++ /dev/null @@ -1,334 +0,0 @@ - -DNSIND Working Group Brian Wellington (TISLabs) -INTERNET-DRAFT Olafur Gudmundsson (TISLabs) - April 1999 - - - -Updates: RFC 2136 - - - - Deferred Dynamic Domain Name System (DNS) Delete Operations - - -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 - - -Abstract - - This document proposes a mechanism for notifying a dynamic DNS server - that a delete operation should be performed at a certain point in the - future. This works within the framework of the current DNS dynamic - update protocol, and provides needed functionality for clients with - leased dynamic addresses. - - - - - - - - - -Expires October 1999 [Page 1] - -INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 - - -1 - Introduction - -Dynamic update operations for the Domain Name System [RFC1034, RFC1035] -are defined in [RFC2136], but there is no automated method of specifying -that records should have a fixed lifetime, or lease. - -1.1 - Overview of DNS Dynamic Update - -DNS dynamic update defines a new DNS opcode and a new interpretation of -the DNS message if that opcode is used. An update can specify -insertions or deletions of data, along with prerequisites necessary for -the updates to occur. All tests and changes for a DNS update request -are restricted to a single zone, and are performed at the primary server -for the zone. The primary server for a dynamic zone must increment the -zone SOA serial number when an update occurs or before the next -retrieval of the SOA. - -1.2 - Overview of DHCP leases - -DHCP [RFC2131] provides a means for a host to obtain a network address -from a DHCP server. The server may ``lease'' this address to the host, -meaning that it is valid only for the period of time specified in the -lease. The host may may extend its lease with subsequent requests, or -may issue a message to release the address back to the server when it is -no longer needed. - -2 - Background - -When a host receives dynamic addresses with associated dynamic DNS -records, the records can be updated by either the host or the DHCP -server. In many cases, update by the server is recommended, since the -server maintains lease information for each address. In some cases, -though, the server cannot update some or all of the DNS records. This -happens when the DNS and DHCP server are under different administration, -for example. - -A host can easily update its own DNS records when receiving information -from the DHCP server. It can also delete its records when shutting -down. If the host unexpectedly goes down, though, it cannot delete the -records. When the DHCP lease on the address expires and is not renewed, -the DHCP server may reassign the address. The DNS records now point to -an assigned address, but not the correct address. Until the host -updates its records again, DNS will contain bad information. - -Since the DHCP and DNS servers are often not co-located with the -clients, the possibility of a host unexpectedly going down and not -communicating with the servers is non-trivial. - - - - -Expires October 1999 [Page 2] - -INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 - - -If the host could set a lease on the DNS records similar to that on its -address, the DNS records would lose validity at the same time as the -address. This would prevent bad information from remaining in DNS. DNS -has no such provision for leases, though, since this would require -storing a lease time along with each record (or each record in a dynamic -zone). - -An alternative method is suggested. A ``delete'' update is sent along -with the ``add'' update, but the delete is marked in such a way that it -will not be exectuted immediately. Instead, it will be stored for the -specified amount of time before being applied. If the host wishes to -extend or shorten the lifetime of the DNS record(s), it can replace the -``deferred delete'' record, which will reset the lease time of the -record(s). The ``deferred delete'' record would, of course, also be -removed if a normal delete update was received. - -3 - Protocol changes - -When doing a delete update operation as defined in [RFC2136] (deleting -an RR, an RRset, or all RRset from a name), the TTL field MUST be -specified as 0. An [RFC2136] compliant server will silently ignore (*) -an update record with a non-zero TTL. This document overloads the TTL -field. If TTL is non-zero, the value represents the number of seconds -(a 32 bit unsigned integer) before which the delete will be applied to -the zone. Thus, the delete operation will be deferred for that number -of seconds, where the number of seconds indicates the lease time. A 32 -bit integer provides for a lease time of over 136 years, which should be -long enough for most uses. - -3.1 - Storage and execution - -Deferred delete records are stored, persistently, by the name server. -The name server SHOULD attempt to evaluate the deletes in a timely -manner. If multiple deferred deletes are sent in the same DNS message -with the same TTL value, they MUST be processed atomically if processed -as planned (that is, none of the deferred deletes are updated or -cancelled). - -3.2 - Processing of deferred deletes - -When a deferred delete is received, the server must check to see if it -matches an existing deferred delete records, where matching indicates -the same name, type, class, and rdata. If a match is found, the new -deferred delete MUST replace the old one. If the deferred delete does -not refer to any record in the server, it should fail as a normal delete -would. - - - - - -Expires October 1999 [Page 3] - -INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 - - -3.3 - Processing of normal deletes - -When a normal delete is received and accepted, the server SHOULD purge -any matching deferred delete records. - -3.4 - Processing of cancellations - -The value 0xFFFFFFFF (the largest unsigned 32 bit integer) in the TTL -field has a special meaning. If a delete containing this lease time is -received, the server will unconditionally remove any matching deferred -deletes. If no deferred delete matches, this request will be silently -ignored. - -3.5 - Processing of adds - -When data is added through a dynamic update which matches a deferred -delete, there is no additional processing done. - -4 - TTL handling - -Any record that may be deleted SHOULD have a short TTL compared to its -lease time, to prevent deleted data from being cached past its -expiration. - -When the time until an RR is deleted becomes low enough, the server MAY -modify the TTL of the RRset. Whenever the TTL is automatically reduced -by this process, the zone will be considered ``changed'' for the purpose -of automatic SOA SERIAL increment (as in [RFC2136]) and real time zone -slave notification [RFC1996]. As these operations can potentially be -expensive (more so if DNSSEC [RFC2535] signatures must be regenerated), -the specific limits and effects are left to the implementation. - -If the TTL is modified by the server, it is not reset if the lease is -renewed. Therefore, the original RR SHOULD be sent with the lease -renewal if the client expects that the server has modified the TTL. - - - - - - - - - - - - - - - - -Expires October 1999 [Page 4] - -INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 - - -5 - Usage - -Normally, a deferred delete update will initially be sent along with an -add, although this is not required. Further updates to the deferred -delete may be sent independently, although the add should be sent again. -If the deferred delete is associated with a leased address, the lease -time of the update SHOULD be approximately equal to the lease time of -the address. - -6 - Protocol robustness - -This protocol has no inherent protection against replayed messages, -which can either originate from an attack or faulty hardware. To -prevent this problem, prerequisites should be used in the update -message, such as a test for the existence of a TXT record describing the -lease, which would be added along with the other records (see [RFC2136], -section 5). - -7 - Security considerations - -This addition to the dynamic DNS protocol does not affect the security -of the protocol. If security is desired, TSIG [TSIG] and/or DNSSEC -[RFC2535] authentication should be used, as specified in [simple-update] -or [RFC2137, update2]. The authors strongly recommend using security -along with this protocol. - -If a DNSSEC signed-zone is modified with deferred deletes, the server -must resign any affected records when the delete is executed. No -special processing is required when the delete is received. - -8 - IANA Considerations - -None. - -9 - References - -[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' - RFC 1034, ISI, November 1987. - -[RFC1035] P. Mockapetris, ``Domain Names - Implementation and - Specification,'' RFC 1035, ISI, November 1987. - -[RFC1996] P. Vixie ``A Mechanism for Prompt Notification of Zone - Changes (DNS NOTIFY),'' RFC 1996, ISC, August 1996. - -[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic - Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore - & Cisco & DEC, April 1997. - - - -Expires October 1999 [Page 5] - -INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 - - -[RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC - 2137, CyberCash, April 1997. - -[RFC2535] D. Eastlake ``Domain Name System Security Extensions,'' RFC - 2535, IBM, March 1999. - -[TSIG] P. Vixie (ed), O. Gudmundsson, D. Eastlake, B. Wellington - ``Secret Key Transaction Signatures for DNS (TSIG),'' draft- - ietf-dnsind-tsig-08.txt, ISC & TISLabs & IBM & TISLabs, - February 1999. - -[simple-update] - B. Wellington ``Simple Secure Domain Name System (DNS) - Dynamic Update,'' draft-ietf-dnssec-simple-update-00.txt, - TISLabs, November 1998. - -[update2] D. Eastlake ``Secure Domain Name System (DNS) Dynamic - Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite - Systems Company, August 1998. - -8 - Author's Address - - - Brian Wellington Olafur Gudmundsson - TISLabs at Network Associates TISLabs at Network Associates - 3060 Washington Road, Route 97 3060 Washington Road, Route 97 - Glenwood, MD 21738 Glenwood, MD 21738 - +1 443 259 2369 +1 443 259 2389 - - - - - - - - - - - - - - - - - - - - - - - -Expires October 1999 [Page 6] - diff --git a/doc/draft/draft-ietf-dnsind-dddd-02.txt b/doc/draft/draft-ietf-dnsind-dddd-02.txt new file mode 100644 index 0000000000..d09a2ded5b --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-dddd-02.txt @@ -0,0 +1,5 @@ +This Internet-Draft has expired and is no longer available. + +Unrevised documents placed in the Internet-Drafts directories have a +maximum life of six months. After that time, they must be updated, or +they will be deleted. This document was deleted on March 20, 2000. diff --git a/doc/draft/draft-ietf-dnsind-edns1-03.txt b/doc/draft/draft-ietf-dnsind-edns1-03.txt deleted file mode 100644 index b300eed20c..0000000000 --- a/doc/draft/draft-ietf-dnsind-edns1-03.txt +++ /dev/null @@ -1,249 +0,0 @@ - DNSIND Working Group Paul Vixie - INTERNET-DRAFT ISC - June, 1999 - - Extensions to DNS (EDNS1) - - 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. - - Abstract - - This document specifies a number of extensions within the Extended - DNS framework defined by [EDNS0], including several new extended - label types and the ability to ask multiple questions in a single - request. - - 1 - Rationale and Scope - - 1.1. EDNS (see [EDNS0]) specifies an extension mechanism to DNS (see - [RFC1035]) which provides for larger message sizes, additional label - types, and new message flags. - - 1.2. This document makes use of the EDNS extension mechanisms to add - several new extended label types and message options, and the ability to - ask multiple questions in a single request. - - Expires December 1999 [Page 1] - - INTERNET-DRAFT EDNS1 June 1999 - - 2 - Affected Protocol Elements - - 2.1. Compression pointers are 14 bits in size and are relative to the - start of the DNS Message, which can be 64KB in length. 14 bits restrict - pointers to the first 16KB of the message, which makes labels introduced - in the last 48KB of the message unreachable by compression pointers. A - longer pointer format is needed. - - 2.2. DNS Messages are limited to 65535 octets in size when sent over - TCP. This acts as an effective maximum on RRset size, since multiple - TCP messages are only possible in the case of zone transfers. Some - mechanism must be created to allow normal DNS responses (other than zone - transfers) to span multiple DNS Messages when TCP is used. - - 2.3. Multiple queries in a question section have not been supported in - DNS due the applicability of some DNS Message Header flags (such as AA) - and of the RCODE field only to a single QNAME, QTYPE, and QCLASS. - Multiple questions per request are desirable, and some way of asking - them must be made available. - - 3 - Extended Label Types - - 3.1. In [EDNS0], the ``0 1'' label type was specified to denote an - extended label type, whose value is encoded in the lower six bits of the - first octet of a label, and an extended label type of ``1 1 1 1 1 1'' - was further reserved for use in future multibyte extended label types. - - 3.2. The ``0 0 0 0 0 0'' extended label type will indicate an extended - compression pointer, such that the following two octets comprise a - 16-bit compression pointer in network byte order. Like the normal - compression pointer, this pointer is relative to the start of the DNS - Message. - - 3.3. The ``0 0 0 0 0 1'' extended label type will indicate a counted bit - string label as described in [CRAW98]. - - 3.4. The ``0 0 0 0 1 0'' extended label type will indicate a ``long - local compression pointer'' as described in [KOCH98]. - - Expires December 1999 [Page 2] - - INTERNET-DRAFT EDNS1 June 1999 - - 4 - OPT pseudo-RR Flags and Options 4.1. The extended RCODE and flags - are structured as follows: - - +0 (MSB) +1 (LSB) - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 0: | EXTENDED-RCODE | VERSION | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 2: |MD |FM |RRD|LM | Z | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. (As - defined by [EDNS0].) - - VERSION Indicates the implementation level of whoever sets it. - Full conformance with the draft standard version of this - specification is version ``1.'' Note that both - requestors and responders should set this to the highest - level they implement, that responders should send back - RCODE=BADVERS and that requestors should be prepared to - probe using lower version numbers if they receive an - RCODE=BADVERS. - - MD ``More data'' flag. Valid only in TCP streams where - message ordering and reliability are guaranteed. This - flag indicates that the current message is not the - complete request or response, and should be aggregated - with the following message(s) before being considered - complete. Such messages are called ``segmented.'' It - is an error for the RCODE (including the EXTENDED- - RCODE), AA flag, or DNS Message ID to differ among - segments of a segmented message. It is an error for TC - to be set on any message of a segmented message. Any - given RR must fit completely within a message, and all - messages will both begin and end on RR boundaries. Each - section in a multipart message must appear in normal - message order, and each section must be complete before - later sections are added. All segments of a message - must be transmitted contiguously, without interleaving - of other messages. - - FM ``First match'' flag. Notable only when multiple - questions are present. If set in a request, questions - will be processed in wire order and the first question - whose answer would have NOERROR AND ANCOUNT>0 is treated - - Expires December 1999 [Page 3] - - INTERNET-DRAFT EDNS1 June 1999 - - as if it were the only question in the query message. - Otherwise, questions can be processed in any order and - all possible answer records will be included in the - response. Response FM should be ignored by requestors. - - RRD ``Recursion really desired'' flag. Notable only when a - request is processed by an intermediate name server - (``forwarder'') who is not authoritative for the zone - containing QNAME, and where QTYPE=ANY or QDCOUNT>1. If - set in a request, the intermediate name server can only - answer using unexpired cached answers (either positive - or negative) which were atomically acquired using (a) - the same QTYPE or set of QTYPEs present in the current - question and whose TTLs were each minimized to the - smallest among them when first cached, and (b) the same - FM and LM settings present in the current question. - - LM ``Longest match'' flag. If this flag is present in a - query message, then for any question whose QNAME is not - fully matched by zone or cache data, the longest - trailing label-bounded suffix of the QNAME for which - zone or cache data is present will be eligible for use - as an answer. Note that an intervening wildcard name - shall supercede this behaviour and the rules described - in [RFC1034 4.3.2, 4.3.3] shall apply, except that the - owner name of the answer will be the wildcard name - rather than the QNAME. Any of: QTYPE=ANY, or - QCLASS=ANY, or QCOUNT>1, shall be considered an error if - the LM flag is set. - - If LM is set in a request, then LM has meaning in the - response as follows: If the content of the response - would have been different without the LM flag being set - on the request, then the response LM will be set; If the - content of the response was not determined or affected - by the request LM, then the response LM will be cleared. - If the request LM was not set, then the response LM is - not meaningful and should be set to zero by responders - and ignored by requestors. - - Z Set to zero by senders and ignored by receivers, unless - modified in a subsequent specification. - - Expires December 1999 [Page 4] - - INTERNET-DRAFT EDNS1 June 1999 - - 5 - Multiple Questions for QUERY - - 5.1. If QDCOUNT>1, multiple questions are present. All questions must - be for the same QNAME and QCLASS; only the QTYPE is allowed to vary. It - is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY. - - 5.2. RCODE and AA apply to all RRs in the answer section having the - QNAME that is shared by all questions in the question section. AA - applies to all matching answers, and will not be set unless the exact - original request was processed by an authoritative server and the - response forwarded in its entirety. - - 5.3. If a multiple question request is processed by an intermediate - server and the authority server does not support multiple questions, the - intermediate server must generate an answer iteratively by making - multiple requests of the authority server. In this case, AA must never - be set in the final answer due to lack of atomicity of the contributing - authoritative responses. - - 5.4. If iteratively processing a multiple question request using an - authority server which can only process single question requests, if any - contributing request generates a SERVFAIL response, then the final - response's RCODE should be SERVFAIL. - - 6 - Acknowledgements - - Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, - Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Michael Patton, - and Michael Graff were each instrumental in creating this specification. - - 7 - References - - [RFC1035] P. Mockapetris, ``Domain Names - Implementation and - Specification,'' RFC 1035, USC/Information Sciences - Institute, November 1987. - - [EDNS0] P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' Draft - draft-ietf-dnsind-edns0-XX, IETF DNSIND, September 1998 - - [CRAW98] M. Crawford, ``Binary Labels in the Domain Name System,'' - Draft draft-ietf-dnsind-binary-labels-XX, IETF DNSIND, March - 1998. - - [KOCH98] P. Koch, ``A New Scheme for the Compression of Domain - Names,'' Draft draft-ietf-dnsind-local-compression-XX.txt. - - Expires December 1999 [Page 5] - - INTERNET-DRAFT EDNS1 June 1999 - - IETF DNSIND, March 1998. - - 8 - Author's Address - - Paul Vixie - Internet Software Consortium - 950 Charter Street - Redwood City, CA 94063 - +1 650 779 7001 - - - Expires December 1999 [Page 6] diff --git a/doc/draft/draft-ietf-dnsind-edns1-04.txt b/doc/draft/draft-ietf-dnsind-edns1-04.txt new file mode 100644 index 0000000000..d09a2ded5b --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-edns1-04.txt @@ -0,0 +1,5 @@ +This Internet-Draft has expired and is no longer available. + +Unrevised documents placed in the Internet-Drafts directories have a +maximum life of six months. After that time, they must be updated, or +they will be deleted. This document was deleted on March 20, 2000. diff --git a/doc/draft/draft-ietf-dnsind-keyreferral-00.txt b/doc/draft/draft-ietf-dnsind-keyreferral-00.txt deleted file mode 100644 index 7670b4c66e..0000000000 --- a/doc/draft/draft-ietf-dnsind-keyreferral-00.txt +++ /dev/null @@ -1,440 +0,0 @@ - -DNSIND WG Edward Lewis -INTERNET DRAFT TIS Labs -May Update: RFC 2535 Jerry Scharf -Catagory: I-D ISC - April 1, 1999 - - The Zone Key Referral - - -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 - . - - This draft expires on October 1, 1999 - -Copyright Notice - - Copyright (C) The Internet Society (1999). All rights - reserved. - -Notes on this document - -This section will only appear in the -00.txt edition of this draft. - -This document originated in the DNSSEC working group in June 1998. The -discussion of the issues in this draft were tabled until the publication -of the then current DNSSEC drafts as RFCs. - -The first version of this document lists a third author, John Gilmore. -He is listed as an author because he was one of the initiators of what is -proposed. In this and following versions he is only listed in the -Acknowledgements (as opposed to being an author) as he has not been -involved in the writing/editing of the draft. This has been done to -avoid assigning his name to a document he may not have a chance to read, -this is not intended as a slight on his efforts. - -When commenting on this draft, please be aware that some terms used here -are up for negotiation before progressing - such as "thief" and "road -block" appearing later in the draft. Comments which are left justified -were added during the re-issuing of the draft, they add context that -may have been lost over time. - - Abstract - - A new type of key is defined to address the problems of - performance in large delegeted zones and issues of liability of - registrars with regards to the storing of public keys belonging - to zone cuts. This new key type also brings DNSSEC more in line - with the DNS treatment of zone cuts and speeds recovery in - handling privatekey exposure. - - The new type of key is a referral record that is stored, signed, - at the parent zone's place for the delegation point. A resolver - receiving this record is being informed that there are genuine - public keys at the child's authoritative name servers. The - parent no longer needs to store the child's public keys locally. - -1 Introduction - - There are a number of different reasons for the proposal of this - new key type. Reasons include: - o the performance impact that RFC 2535 has on name servers - o the problem of updating a widely delegated parent zone on demand - o statements in RFC 2181 on authoritative data at delegations - o perceived liability of the operator of a name server or registry - - To address these issues, which are expanded upon below, a new - key type is proposed - a "zone key referral" - to join the user - key, host key, and zone key types defined in RFC 2535. - -1.1 Performance Issues - - A sample zone will be used to illustrate the problem. The - example will part from reality mostly in the length of zone - names, which changes the size of the owner and resource record - data fields. - - # $ORIGIN test. - # @ IN SOA - # IN SIG SOA - # IN KEY <1024 bit zone key> - # IN SIG KEY - # IN SIG KEY - # IN NS ns.test. - # IN SIG NS - # IN NXT my-org.test. NS SOA SIG KEY NXT - # IN SIG NXT - # - # my-org IN KEY <1024 bit zone key> - # IN KEY <1024 bit zone key> - # IN SIG KEY - # IN NS ns1.my-org.test. - # IN NS ns2.my-org.test. - # IN NXT them.test. NS SIG KEY NXT - # IN SIG NXT - # - # them IN KEY 0xC100 3 1 - # IN SIG KEY - # IN NS ns1.them.test. - # IN NS ns2.them.test. - # IN NXT test. NS SIG KEY NXT - # IN SIG NXT - - In this zone file fragment, "my-org" is a delegation point of - interest with two registered public keys. Presumably, one key - is for signatures generated currently and the other is for still - living and valid but older signatures. "them" is another - delegation point, with a NULL key. This signifies that this zone - is unsecured. - - To analyze the performance impact of the storing of keys, the - number of bytes used to represent the RRs in the procotol format - is used. The actual number of bytes stored will likely be - higher, accounting for data structure overhead and alignment. - The actual number of bytes transferred will be lower due to DNS - name compression. - - The number of bytes for my-org's two 1024-bit keys, two NS - records, NXT and the associated signatures is 526. The bytes - needed for them (with the NULL key) is 346. Currently, there - are close to 2 million entries in com., so if we take my-org as - a typical domain, over 1GB on memory will be needed for com. - - The zone keys used in the example are set to 1024 bits. This - number may range from as low as 512 bits upwards to over 3000 - bits. To scale the above numbers to a different key size, - multiply the difference in key sizes by 4 for my-org and by 2 - for them, and adjust the numbers accordingly. - - The increased size of the data held for the zone cuts will have - two impacts at the transport and below layers. Bandwidth beyond - that currently needed will be used to carry the KEY records. - The inclusion of all of the child's keys will also push DNS over - the UDP size limit and start using TCP - which could cause - critical problems for current heavily used name servers, like - the roots. - - Another impact, not illustrated by the example, is the frequency - of updates. If each time a public key for my-org is added or - deleted, the SOA serial number will have to increase, and the - SOA signed again. If an average zone changes its keys(s) once - per month, there will be on average 45 updates per minute in a - zone of 2 million delegations. - -(The multiple algorithms issue is an extension of multiple keys. The -example should be updated to show at least a DSS key as well as an RSA -key.) - -1.2 Security Incident Recovery (w/ respect to keys only) - - Once a zone administrator is alerted that any key's private - counterpart has been discovered (exposed), the first action to - be taken is to stop advertising the public key in DNS. This - doesn't end the availability of the key - it will be residing in - caches - but is the closest action resembling revokation - available in DNS. - - Stopping the advertisement in the zone's name servers is as - quick as altering the master file and restarting the name - server. Having to do this in two places will will only delay - the time until the recovery is complete. - - For example, a registrar of a top level domain has decided to - update its zone only on Mondays and Fridays due to the size of - the zone. A customer/delegatee is the victim of a break in, in - which one of the items taken is the file of private keys used to - sign DNS data. If this occurs on a Tuesday, the thief has until - Friday to use the keys before they disappear from the DNS, even - if the child stops publishing them immediately. - - If the public key set is in the parent zone, and the parent zone - is not able to make the change quickly, the public key cannot be - revoked quickly. If the parent only refers to there being a key - at the child zone, then the child has the agility to change the - keys - even issue a NULL key, which will force all signatures in - the zone to become suspect. - -1.3 DNS Clarifications - - RFC 2181, section 6, clarifies the status of data appearing at a - zone cut. Data at a zone cut is served authoritatively from the - servers listed in the NS set present at the zone cut. The data - is not (necessarily) served authoritatively from the parent. - (The exception is in servers handling both the parent and child - zone.) - - Section 6 also mentions that there are two exceptions created by - DNSSEC, the NXT single record set and the KEY set. This - proposal addresses the exception relating to the KEY set, - limiting its severity (but falling short of removing it - altogether). By limiting the exception, we will be simplifying - DNS. - -1.4 Liability - - Liability is a legal concept, so it is not wise to attempt an - engineering solution to it. However, the perceived liability - incurred in using DNSSEC by registrars may prevent the adoption - of DNSSEC. Hence DNSSEC should be engineered in such a away to - address the concern. - - One source of liability is the notion that by advertising a - public key for a child zone, a parent zone is providing a - service of security. With that comes responsibility. By having - the parent merely indicate that a child has a key (or has no - key), the parent is providing less in the way of security. If - the parent is wrong, the potential loss is less. Instead of - falsely authenticated data, configuration errors will be - apparent to the resolving client. - -2 The Proposal - - The proposal is to introduce a new key type which indicates - whether the delegated zone is running secured or not. Running - secured is either a zone signed with at least one key, an - experimental zone, or a zone with only NULL keys published. - - The Zone Referral Key will resemble the NULL key in syntax. - There will be a flags field, an algorithm field, and a protocol - field, but no public key material. The Referral Key is signed - by the parent zone, as was the public key set in RFC 2065. - There is only one Referral Key RR present. - - The Referral Key flags field will have the following values: - Field Bit(s) Value Meaning - - A/C 0- 1 0b01 indicates a key will be found - 0b11 indicates a key will not be found - 0b?0 error (referral cannot encrypt) - XT 2 0 no extended flags are needed - Z 4- 5 0 must be zero for all keys - NAMTYP 6- 7 0b11 this is a referral to a zone key - Z 8-11 0 must be zero for all keys - SIG 12-15 0 must be zero for a referral key - - The legal values of the flags field are (in summary): - - Hex Value Indicates - 0x4300 The delegation has a key record set - 0xC300 The delegation has no key record - - Other values are not valid for Referral Keys (but may be valid - for other keys). - - The Protocol field must be set to 3, the DNSSEC protocol value. - - The Algorithm field must be 0. - -The algorithm is not important at this point. So long as the searcher -knows to expect a key set at the delegated zone's apex, a secure chain -is possible. One the key set is retrieved and verified, then the -algorithms used in the delegated zone are known. (The issue is that a -zone may be signed in algorithm 1 and not 3, 3 and not 1, both, etc., -and a secure resolver must know this in order to set signature arrival -expectations. - -2.1 Example - - The Referral key for my-org.test. and them.test. would appear as - the following in the zone master file: - - my-org.test. IN KEY 0x4300 3 0 - them.test. IN KEY 0xC300 3 0 - - In the example introduced earlier, the master file would change - to the following. - - # $ORIGIN test. - # @ IN SOA - # IN SIG SOA - # IN KEY <1024 bit zone key> - # IN SIG KEY - # IN SIG KEY - # IN NS ns.test. - # IN SIG NS - # IN NXT my-org.test. NS SOA SIG KEY NXT - # IN SIG NXT - # - # my-org IN KEY 0x4300 3 0 - # IN SIG KEY - # IN NS ns1.my-org.test. - # IN NS ns2.my-org.test. - # IN NXT them.test. NS SIG KEY NXT - # IN SIG NXT - # - # them IN KEY 0xC300 3 1 - # IN SIG KEY - # IN NS ns1.them.test. - # IN NS ns2.them.test. - # IN NXT test. NS SIG KEY NXT - # IN SIG NXT - -3 Analysis - - By removing the public keys from the parent's master file, the - parent is no longer a road block during an emergency removal of - keys. A parent zone is unchanged as a zone changes from NULL - keys to experimental keys to fully signed. The parent is also - not providing a security service, other than to authentically - claim the existence of a KEY record set - akin to the "hints" of - the name servers. - - The change also improves the prospect for performance. The need - for multiple KEY RR's, each one on the order of 100 bytes, is - removed and replaced by a single KEY RR of the order of 25 - bytes. Saving bytes reduces the need to use TCP to avoid - truncated responses. Also, the need for updating the zone drops - - no longer will there be updates for each key change. - - As far as the statements by RFC 2181 conerning authority levels, - the Referral Key is not authortative and would be superseeded by - a verified set of the real zone keys. The only caveat is that - once the verified set of keys expire (assuming the parent has to - learn the keys from another server), the Referal Key must - reappear. This is an example of what has been labelled "mount- - like semantics." - - [No reference for mount-like semantics has yet been found.] - - The last point is important. This requires the "mount-like - semantics" that have been discussed for the BIND name servers. - Once hints are overridden by learned, authorititative and - verified data, the hints are not discarded. Hints in this state - are stored and become visible when the learned data expires. - -4 IANA Considerations - - Other than using a new value in the flags field of the KEY RR, - no new number assignments are needed. The flags field is not - under the control of IANA as of yet. There are no requirements - placed on IANA by this draft. - -5 Security Considerations - - There has been some debate about whether the Referral key should - be treated as a hint - just like the NS records. If so, then - there is no need to sign the Referral Key, and an unsigned - (hence non-authenticated) security record is of little value. - So, is the Referral Key even needed? - - Authentication in DNSSEC is done from the data "back" towards a - trusted point - e.g., "up" to the root. Since the - authentication is done by going repeatedly from child to parent, - why bother having the parent indicate the status of the child? - - The answer is in the scenario in which a resolver somewhere has - obtained data which fails the verification process. Perhaps the - signature is wrong, a key in the chain of trust is unavailable, - the set should have had a signature, but none is found (or vice - versa), or the trail of signed-by names is not acceptable. In - this case, the resolver needs to find the authoritative zone, - its status and its name server set. - - If a zone is being attacked by a masquerader, and parents do not - make any statements about the security of child zones, then an - easy and successfull attack may occur. An attacker only needs - to supply either fake name server records or glue records to - redirect queries. - - While this attack will not be stopped as far as denial of - service, the masquerader can be stopped from being accepted as - an authoritative source if the parent of the zone claims the - child is secure and signs the public keys of the true child and - not the masquerader. - - The masquerader cannot successfully claim that the zone is - unsigned, because it must have a zone key signed by the parent. - NULL or not, the key would not be trusted by the resolver, - assuming the parent has not also been duped. The resolver, - sensing this, should report an error or security incident, and - not accept data. - -6 Acknowledgements - - John Gilmore originally raised the issues that have led to this - document. - -7 Author's addresses - -Edward Lewis Jerry Scharf - -3060 Washinton Rd (Rte 97) -Glenwood, MD 21738 -+1(443)259-2352 - -8 References - -RFC 2181 "Clarifications to the DNS Specification", Elz and Bush -RFC 2535 "Domain Name System Security Extensions", Eastlake - -9 Full Copyright Statement - - Copyright (C) The Internet Society (1999). 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 implmentation 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." - -This draft expires on October 1, 1999 diff --git a/doc/draft/draft-ietf-dnsind-keyreferral-01.txt b/doc/draft/draft-ietf-dnsind-keyreferral-01.txt new file mode 100644 index 0000000000..d09a2ded5b --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-keyreferral-01.txt @@ -0,0 +1,5 @@ +This Internet-Draft has expired and is no longer available. + +Unrevised documents placed in the Internet-Drafts directories have a +maximum life of six months. After that time, they must be updated, or +they will be deleted. This document was deleted on March 20, 2000. diff --git a/doc/draft/draft-ietf-dnsind-local-compression-05.txt b/doc/draft/draft-ietf-dnsind-local-compression-05.txt deleted file mode 100644 index ec27e3ac77..0000000000 --- a/doc/draft/draft-ietf-dnsind-local-compression-05.txt +++ /dev/null @@ -1,420 +0,0 @@ -INTERNET-DRAFT Peter Koch -Expires: December 1999 Universitaet Bielefeld -Updates: 1035, 1183, 2163, 2168, 2535 June 1999 - - A New Scheme for the Compression of Domain Names - draft-ietf-dnsind-local-compression-05.txt - -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 author or the DNSIND WG mailing list - . - -Abstract - - The compression of domain names in DNS messages was introduced in - [RFC1035]. Although some remarks were made about applicability to - future defined resource record types, no method has been deployed yet - to support interoperable DNS compression for RR types specified since - then. - - This document summarizes current problems and proposes a new - compression scheme to be applied to future RR types which supports - interoperability. Also, suggestions are made how to deal with RR - types defined so far. - -1. Conventions used in this document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - -Koch Expires December 1999 [Page 1] - -INTERNET-DRAFT DNS Compression June 1999 - - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - Domain names herein are for explanatory purposes only and should not - be expected to lead to useful information in real life [RFC2606]. - -2. Background - - Domain name compression was introduced in [RFC1035], section 4.1.4, - as an optional protocol feature and later mandated by [RFC1123], - section 6.1.2.4. The intent was to reduce the message length, - especially that of UDP datagrams, by avoiding repetition of domain - names or even parts thereof. - - A domain name is internally represented by the concatenation of label - strings, where the first octet denotes the string length, not - including itself. The null string, consisting of a single octet of - zeroes, is the representation of the root domain name and also - terminates every domain name. - - As labels may be at most 63 characters long, the two most significant - bits in the length octet will always be zero. Compression works by - overloading the length octet with a second meaning. If the two MSB - have the value '1', the remainder of the length octet and the next - octet form a compression pointer, which denotes the position of the - next label of the current domain name in the message: - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | 1 1| OFFSET | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - It is important that these pointers always point backwards. - - Compression may occur in several places. First, the owner name of an - RR may be compressed. The compression target may be another owner - name or a domain name in the RDATA section of a previous RR. Second, - any domain name within the RDATA section may be compressed and the - target may be part of the same RR, being the owner name or another - domain name in the RDATA section, or it may live in a previous RR, - either as its owner or as a domain name in its RDATA section. In - fact, due to the chaining feature, combinations of the above may - occur. - -3. Problems - - While implementations shall use and must understand compressed domain - names in the RDATA section of "well known" RR types (those initially - defined in [RFC1035]), there is no interoperable way of applying - -Koch Expires December 1999 [Page 2] - -INTERNET-DRAFT DNS Compression June 1999 - - compression to the RDATA section of newer RRs: - - Quote from [RFC1123], section 6.1.3.5: - Compression relies on knowledge of the format of data inside a - particular RR. Hence compression must only be used for the - contents of well-known, class-independent RRs, and must never be - used for class-specific RRs or RR types that are not well-known. - The owner name of an RR is always eligible for compression. - - DNS records in messages may travel through caching resolvers not - aware of the particular RR's type and format. These caches cannot - rearrange compression pointers in the RDATA section simply because - they do not recognize them. Handing out these RRs in a different - context later will lead to confusion if the target resolver tries to - uncompress the domain names using wrong information. This is not - restricted to intermediate caching but affects any modification to - the order of RRs in the DNS message. - -4. Local Compression - - We often observe a certain locality in the domain names used as owner - and occuring in the RDATA section, e.g. in MX or NS RRs but also in - newer RR types [RFC1183]: - - host.foo.bar.example RP adm.foo.bar.example adm.persons.bar.example - - So, to still profit from compression without putting interoperability - at risk, a new scheme is defined which limits the effect of - compression to a single RR. - - In contrast to the usual method of using offsets relative to the - start of a DNS packet we start counting at the RR owner or calculate - pointers relative to the start of the RDATA to avoid context - sensitivity. We use an additional compression indicator for a two - octet local pointer: - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | 1 0| OFFSET | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - The "10" bits will indicate the use of local compression and - distinguish it from conventional compression, plain labels and EDNS - label codes [EDNS0]. Two types of pointers need to be specified: - those pointing into the owner name and those pointing into RDATA. - - A) Pointers into the owner name are interpreted as the ordinal label - number (starting at 0 for the topmost label, the TLD). This way we - avoid the need for extra decompression of the owner name during - -Koch Expires December 1999 [Page 3] - -INTERNET-DRAFT DNS Compression June 1999 - - message composition or decomposition. - - The highest possible value of a compression pointer pointing into - the owner name is 254. The value 255 is reserved for future use. - - B) Pointers into the RDATA section start at the fixed value 256 for - the first octet and have a maximum value of 16383 limiting - possible targets to the first 16128 octets. The actual offset - relative to the start of RDATA is determined by subtracting 256 - from the value of the pointer. - - Local pointers MUST point to a previous occurence of the same name in - the same RR. Even domain names in another RR of the same type cannot - serve as compression targets since the order of RRs in an RRSet is - not necessarily stable. The length of the compressed name(s) MUST be - used in the length calculation for the RDLENGTH field. - -Example - - Consider a DNS message containing two resource records, one CNAME RR - and one XMPL RR, undefined and meaningless so far, with an RDATA - section consisting of two domain names: - - ab.foo.example IN CNAME bar.example - bar.example IN XMPL a.foo.example foo.example - - In a message this appears as follows (randomly starting at octet 12): - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 12 | 2 | a | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 14 | b | 3 | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 16 | f | o | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 18 | o | 7 | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 20 | e | x | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 22 | a | m | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 24 | p | l | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 26 | e | 0 | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - 10 octets skipped (TYPE, CLASS, TTL, RDLENGTH) - -Koch Expires December 1999 [Page 4] - -INTERNET-DRAFT DNS Compression June 1999 - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 38 | 3 | b | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 40 | a | r | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 42 | 1 1| 19 | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - The XMPL RR with local compression applied: - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 44 | 1 1 | 38 | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - 10 octets skipped (TYPE, CLASS, TTL, RDLENGTH) - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 56 | 1 | a | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 58 | 3 | f | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 60 | o | o | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 62 | 1 0| 0 | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 64 | 1 0| 258 | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - The first local pointer at position 62 points to the topmost label - "example" of the XMPL RR's owner. - - The second local pointer at position 64 represents the "foo.example" - and points backwards into the RDATA section, third octet, at absolute - position 58. Note that with conventional compression this example - message would have occupied less space. - -5. Interaction with DNSSEC - - The security extensions to DNS [RFC2535] mandate that domain names in - RDATA be signed only in expanded, lower case format. For RR types - using local compression the specification is changed as follows: - - Resource Records subject to local compression MUST be stored, - signed, transmitted and verified in locally compressed form. Name - expansion or canonicalization MUST NOT be performed on the RDATA - section for signing or verification. - - This way RR type transparency can be achieved, since domain names in - -Koch Expires December 1999 [Page 5] - -INTERNET-DRAFT DNS Compression June 1999 - - the RDATA section are treated as arbitrary data and can be cached and - verified by resolvers not aware of the particular RR type. Old RR - types subject to conventional or no compression are not affected by - this change. - - Wildcard owners may serve as compression targets only in their fixed - part. Even if a particular query asks for a domain name which could - be used to compress the RDATA part more efficiently, this MUST NOT be - done. Otherwise signatures would be invalidated. - - Currently slave servers store zones in text format and re-encode the - data into wire format, e.g. after a restart. This encoding must be - unique to ensure signature validity. To achieve this, local - compression MUST be applied optimally, i.e. every domain name must be - compressed as far as possible and each local compression pointer must - point to the earliest available target (including the owner). - -6. Interaction with Binary Labels - - When constructing local compression pointers into the owner name, - every one-bit label is counted as a label. This way the compression - and decompression is independent of the actual bit-string - representation. - - For local compression pointers into the RDATA section, only bit- - string labels may serve as targets, not single one-bit labels. Bit- - string labels may be adjusted to increase compression efficiency - [BINLABELS, section 3.1] - - The internal representation of a domain name has a maximum length of - 255 [RFC 1035]. Any label consists of at least two octets, leading - to at most 127 labels per domain name plus the terminating zero - octet, which does not qualify as a compression target. With the - introduction of binary labels a domain name can consist of up to 1904 - labels (all one-bit labels). This document restricts the possible - compression targets in an owner name to the topmost 255 labels. This - limit was chosen to be consistent with [RFC2535], section 4.1.3. - -7. Old RR types and deployment - - Although differences in RDATA sections by class have not yet been - reported and the concept of classes did not really spread, we are - just considering the IN class here. - - The following RR types with domain names in the RDATA section have - been defined since [RFC1035] (Standards Track, Experimental and - Informational RFCs, ignoring withdrawn types): RP [RFC1183], AFSDB - [RFC1183], RT [RFC1183], SIG [RFC2535], PX [RFC2163], NXT [RFC2535], - -Koch Expires December 1999 [Page 6] - -INTERNET-DRAFT DNS Compression June 1999 - - SRV [RFC2052], NAPTR [RFC2168], KX [RFC2230]. Some specifications do - not mention DNS compression at all, others explicitly suggest it and - only in part identify interoperability issues. Only the KX and SRV - RR types are safe as their specifications prohibit compression. - - The specification of RP, AFSDB, RT, PX, and NAPTR is hereby changed - in that domain names in the RDATA section MUST NOT be compressed and - MUST NOT be compression targets. - - Local compression MUST NOT be used for owner names and it MUST NOT be - applied to domain names in RDATA sections of any RR type defined so - far. - - The specification of future RR types should explicitly select the use - of local compression or forbid RDATA domain name compression at all. - -8. Security Considerations - - The usual caveats for using unauthenticated DNS apply. This scheme is - believed not to introduce any new security problems. However, - implementors should be aware of problems caused by blindly following - compression pointers of any kind. [RFC1035] and this document limit - compression targets to previous occurences and this MUST be followed - in constructing and decoding messages. Otherwise applications might - be vulnerable to denial of service attacks launched by sending DNS - messages with infinite compression pointer loops. In addition, - pointers should be verified to really point to the start of a label - (for conventional and local RDATA pointers) and not beyond the end of - the domain name (for local owner name pointers). - - The maximum length of 255 applies to domain names in uncompressed - wire format, so care must be taken during decompression not to exceed - this limit to avoid buffer overruns. - -9. Acknowledgements - - The author would like to thank Andreas Gustafsson, Paul Vixie, Bob - Halley, Mark Andrews and Thomas Narten for their review and - constructive comments. - -10. References - - [RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities", - RFC 1034, STD 13, November 1987 - -Koch Expires December 1999 [Page 7] - -INTERNET-DRAFT DNS Compression June 1999 - - [RFC1035] Mockapetris,P., "Domain Names - Implementation and - Specification", RFC 1035, STD 13, November 1987 - - [RFC1123] Braden,R., "Requirements for Internet Hosts -- Application - and Support", RFC 1123, STD 3, October 1989 - - [RFC1183] Everhart,C., Mamakos,L., Ullmann,R., Mockapetris,P., "New - DNS RR Definitions", RFC 1183, October 1990 - - [RFC2052] Gulbrandsen,A., Vixie,P. "A DNS RR for specifying the - location of services (DNS SRV)", RFC 2052, October 1996 - - [RFC2119] Bradner,S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, BCP 14, March 1997 - - [RFC2163] Allocchio,C., "Using the Internet DNS to Distribute MIXER - Conformant Global Address Mapping (MCGAM)", RFC 2163, - January 1998 - - [RFC2168] Daniel,R., Mealling,M., "Resolution of Uniform Resource - Identifiers using the Domain Name System", RFC 2168, June - 1997 - - [RFC2230] Atkinson,R., "Key Exchange Delegation Record for the DNS", - RFC 2230, November 1997 - - [RFC2535] Eastlake,D., "Domain Name System Security Extensions", RFC - 2535, March 1999 - - [RFC2606] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names", - RFC 2606, BCP 32, June 1999 - - [EDNS0] Vixie,P., "Extension mechanisms for DNS (EDNS0)", draft- - ietf-dnsind-edns0-XX.txt, work in progress - - [BINLABELS] Crawford,M., "Binary Labels in the Domain Name System", - draft-ietf-dnsind-binary-labels-XX.txt, work in progress - -11. Author's Address - - Peter Koch - Universitaet Bielefeld - Technische Fakultaet - Postfach 10 01 31 - D-33501 Bielefeld - Germany - -Koch Expires December 1999 [Page 8] - -INTERNET-DRAFT DNS Compression June 1999 - - +49 521 106 2902 - - -Koch Expires December 1999 [Page 9] diff --git a/doc/draft/draft-ietf-dnsind-local-compression-06.txt b/doc/draft/draft-ietf-dnsind-local-compression-06.txt new file mode 100644 index 0000000000..d09a2ded5b --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-local-compression-06.txt @@ -0,0 +1,5 @@ +This Internet-Draft has expired and is no longer available. + +Unrevised documents placed in the Internet-Drafts directories have a +maximum life of six months. After that time, they must be updated, or +they will be deleted. This document was deleted on March 20, 2000. diff --git a/doc/draft/draft-ietf-dnsind-rollover-00.txt b/doc/draft/draft-ietf-dnsind-rollover-00.txt deleted file mode 100644 index 8d8cef1cfc..0000000000 --- a/doc/draft/draft-ietf-dnsind-rollover-00.txt +++ /dev/null @@ -1,648 +0,0 @@ -INTERNET-DRAFT DNSIND Key Rollover -UPDATES RFC 1996 April 1999 - Expires October 1999 -draft-ietf-dnsind-rollover-00.txt - - - - Domain Name System (DNS) Security Key Rollover - ------ ---- ------ ----- -------- --- -------- - - Donald E. Eastlake 3rd, Mark Andrews - - - -Status of This Document - - This draft, file name draft-ietf-dnsind-rollover-00.txt, is intended - to be become a Proposed Standard RFC. Distribution of this document - is unlimited. Comments should be sent to the DNS working group - mailing list or to the authors. - - 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. Internet-Drafts may be updated, replaced, or obsoleted by - other documents at any time. It is not appropriate to use Internet- - Drafts as reference material or to cite them other than as a - ``working draft'' or ``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. - - - -Abstract - - Deployment of Domain Name System (DNS) security with good cryptologic - practice will involve large volumes of key rollover traffic. A - standard format and protocol for such messages will be necessary for - this to be practical and is specified herein. - - [Note: this draft has been moved to dnsind from dnssec as part of the - ongoing combination of these working groups. It would have been - draft-ietf-dnssec-rollover-01.txt otherwise.] - - - - -D. Eastlake 3rd, M. Andrews [Page 1] - - - -INTERNET-DRAFT April 1999 DNSSEC Key Rollover - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - - Table of Contents..........................................2 - - 1. Introduction............................................3 - 2. Key Rollover Scenario...................................3 - 3. Rollover Operation......................................5 - 3.1 Rollover to Parent.....................................5 - 3.2 Rollover to Children...................................6 - 4. Secure Zone Cuts and Joinders...........................7 - 5. Security Considerations.................................8 - 6. IANA Considerations.....................................9 - - References................................................10 - Authors Address...........................................10 - Expiration and File Name..................................11 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd, M. Andrews [Page 2] - - - -INTERNET-DRAFT April 1999 DNSSEC Key Rollover - - -1. Introduction - - The Domain Name System (DNS) [RFC 1034, 1035] is the global - hierarchical replicated distributed database system for Internet - addressing, mail proxy, and other information. The DNS has been - extended to include digital signatures and cryptographic keys as - described in [RFC 2535]. - - The principle security service provided for DNS data is data origin - authentication. The owner of each zone signs the data in that zone - with a private key known only to the zone owner. Anyone that knows - the corresponding public key can then authenticate that zone data is - from the zone owner. To avoid having to preconfigure resolvers with - all zone's public keys, keys are stored in the DNS with each zone's - key signed by its parent (if the parent is secure). - - To obtain high levels of security, keys must be periodically changed, - or "rolled over". The longer a private key is used, the more likely - it is to be compromised due to cryptanalysis, accident, or treachery - [RFC 2541]. - - In a widely deployed DNS security system, the volume of update - traffic will be large. Just consider the .com zone. If only 10% of - its children are secure and change their keys only once a year, you - are talking about hundreds of thousands of new child public keys that - must be securely sent to the .com manager to sign and return with - their new parent signature. And when .com rolls over its private - key, it will needs to send hundred of thousands of new signatures on - the existing child public keys to the child zones. - - It will be impractical to handle such update volumes manually on a - case by case basis. The bulk of such key rollover updates must be - automated. - - The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" - in this document are to be interpreted as described in [RFC 2119]. - - - -2. Key Rollover Scenario - - Although DNSSEC provides for the storage of other keys in the DNS for - other purposes, DNSSEC zone keys are included solely for the purpose - of being retrieved to authenticate DNSSEC signatures. Thus, when a - zone key is being rolled over, the old public key should be left in - the zone, along with the addition of the new public key, for as long - as it will reasonably be needed to authenticate old signatures that - have been cached or are held by applications. Similarly, old parent - SIGs should be retained for a short time after a parent KEY(s) roll - over and new parent SIGs have been installed. - - -D. Eastlake 3rd, M. Andrews [Page 3] - - - -INTERNET-DRAFT April 1999 DNSSEC Key Rollover - - - If DNSSEC were universally deployed and all DNS server's clocks were - synchronized and zone transfers were instantaneous etc., it might be - possible to avoid ever having duplicate old/new KEY/SIG RRsets due to - simultaneous expiration of SIGs everywhere in the DNS. But these - assumptions do not hold. Security aware DNS servers decrease the TTL - of secure RRs served as the expiration of their authenticating SIG(s) - approaches but some dithered fudge must generally be left due to - clock skew, RR retention by applications, and the like. Retaining - old KEYs for a while after rolling over to new KEYs will be necessary - in practical cases. - - Assume a middle zone with a secure parent and a secure child wishes - to role over its KEY RRset. This RRset would probably be one KEY RR - per crypto algorithm used to secure the zone, but for this scenario, - we will simply assume it is one KEY RR. The old KEY RR and two SIG - RRs will exist at the apex of the middle zone. (These RRs may also - exist at the leaf node for this zone in its parent if the parent - chooses to store them there.) The contents of the middle zone and the - zone KEY RRs of its secure child will have SIGs under the old key. - - The middle zone owner needs to communicate with its parent to obtain - a new parental signature covering both the old and new KEY RRs and - covering just the new KEY RR. The signature on both is needed so the - old KEY can be retain for the period it might be needed to - authenticate old SIGs. The middle zone would probably want to obtain - these in advance so that it can install them at the right time along - with its new SIG RRs covering the content of its zone. Finally, it - needs to give new SIG RRs to its child that cover its KEY RRs so it - must signal its children to ask for such SIG RRs. - - BEFORE ROLLOVER SHORTLY AFTER AFTER ROLLOVER - - p.x KEY P1 p.x KEY P1 p.x KEY P1 - p.x SIG(KEY) P1 p.x SIG(KEY) P1 p.x SIG(KEY) P1 - p.x SIG(KEY) GP p.x SIG(KEY) GP p.x SIG(KEY) GP - - m.p.x KEY M1 m.p.x KEY M2 m.p.x KEY M2 - m.p.x SIG(KEY) P1 m.p.x KEY M1 m.p.x SIG(KEY) P1 - m.p.x SIG(KEY) M1 m.p.x SIG(KEY) P1 m.p.x SIG(KEY) M2 - m.p.x SIG(KEY) M2 - - c.m.p.x KEY C1 c.m.p.x KEY C1 c.m.p.x KEY C1 - c.m.p.x SIG(KEY) M1 c.m.p.x SIG(KEY) M2 c.m.p.x SIG(KEY) M2 - c.m.p.x SIG(KEY) C1 c.m.p.x SIG(KEY) M1 c.m.p.x SIG(KEY) C1 - c.m.p.x SIG(KEY) C1 - - p = parent, m = middle, c = child, GP = grandparent key - P* = parent key, M* = middle zone key, C* = child key - - - - -D. Eastlake 3rd, M. Andrews [Page 4] - - - -INTERNET-DRAFT April 1999 DNSSEC Key Rollover - - -3. Rollover Operation - - Rollover operations use a DNS request syntactically identical to the - UPDATE request [RFC 2136] (except that the operation code is ROLLOVER - which is equal to (TBD)) and use a new form of NOTIFY [RFC 1996]. - Considerations for such requests to the parent and children of a zone - are givens below. - - All rollover operations involve significant amounts of cryptographic - calculations. Appropriate rate limiting SHOULD be applied to avoid - denial of service attacks. - - [This draft does not consider cross-certification key rollover.] - - - -3.1 Rollover to Parent - - A zone rolling over its KEY RRset sends an upward ROLLOVER request to - its parent. Actually, it will normally do two upward ROLLOVERs, one - for a combined KEY RRset of its old and new KEYs and one for just its - new KEY RRset, as discussed above. - - The server selection algorithm in [RFC 2136] section 4 should be - used. A child needs to be configured with or determine the name of - its parent but SHOULD NOT remember the location of its parent other - than via normal DNS caching of address RRs so that rollover will - continue to work if its parent servers are moved. - - The ROLLOVER request Zone should be specified as the parent zone. - The request Update section has the new KEY RRset on which the parent - signature is requested along with the requesting zone's SIG(s) under - its old KEY(s) as RRs to be "added" to the parent zone. The - inception and expiration times in this child SIG or SIGs are the - requested inception and expiration times for the new parent SIG(s). - The "prerequisites" section has the old child KEY RRset with the - parent SIG (see next paragraph). - - An upward ROLLOVER request MUST be signed and if not signed a BADAUTH - response generated. The signature MUST be under the previous zone - KEY, so the parent can validate it, or under a valid TSIG key - [draft-ietf-dnsind-tsig-*.txt] arranged with the parent. Including - the "prerequisite" section as specified above enables a parent that - keeps no record of its children's KEYs to still authenticate a - child's ROLLOVER request based on the old child KEY because the - parent is presented with its own SIG on the old KEY. - - If the ROLLOVER command is erroneous or violates parental policy, an - Error response is returned. If a parent retains copies of its - children's KEYs, it may use that knowledge to validate ROLLOVER - - -D. Eastlake 3rd, M. Andrews [Page 5] - - - -INTERNET-DRAFT April 1999 DNSSEC Key Rollover - - - request SIGs and ignore the "prerequisites" section. - - If the ROLLOVER command is OK and the parent can sign online, its - response MAY include the new parent SIG(s) in the response Update - section. This response MUST be sent to the originator of the - request. - - If the parent can not sign online, it should return a response with - an empty Update section and queue the SIG(s) calculation request. - This response MUST be sent to the originator of the request. - - ROLLOVER response messages MUST always include the actual parent's - SOA signed with a key the child should recognize in the Additional - Information section (see section 4 below). - - Regardless of whether the server has sent the new signatures above, - it MUST, once it has calculated the new SIG(s), send a ROLLOVER to - the child zone using the DNS port (53) and the server selection - algorithm defined in RFC 2136, Section 4. This ROLLOVER reqeust - contains the KEY RRset that triggered it and the new SIG(s). There - are several reasons for sending the ROLLOVER response regardless of - whether the new SIG RR(s) were sent in the original response. One is - to provide an indication to the operators of the zone in the event - someone is trying to hijack the zone. Another is that this maximizes - the probability of the response getting through. - - Although the parent zone need not hold or serve the child's key, if - it does the ROLLOVER command REQUEST SHOULD NOT automatically update - the parent zone. A later UPDATE command can be used to actually put - the new KEY into the parent zone if desired and supported by parent - policy. - - This document does not cover the question of parental policy on key - rollovers. Parents may have restrictions on how far into the future - they will sign KEY RRsets, what algorithms or key lengths they will - support, might require payment for the service, etc. The signing of - a future KEY by a parent is, to some extent, a granting of future - authoritative existence to the controller of the child private key - even if the child zone ownership should change. The only effective - way of invalidating such future signed child public keys would be for - the parent to roll over its key(s), which might be an expensive - operation. - - - -3.2 Rollover to Children - - When a secure zone is going to rollover its key(s), it needs to re- - sign the zone keys of any secure children under its new key(s). The - parent simply notifIES the child via a rollover NOTIFY [RFC 1996] - - -D. Eastlake 3rd, M. Andrews [Page 6] - - - -INTERNET-DRAFT April 1999 DNSSEC Key Rollover - - - that the parent KEY(s) have changed. The child then proceeds to do - an upward ROLLOVER request, as described in 3.1 above to obtain the - new parental SIG(s). - - A rollover NOTIFY is a NOTIFY request [RFC 1996] that has a QTYPE of - SIG and the owner name of the child zone. The answer section has the - current parent SOA signed by a key the child will know (see section - 4). - - A rollover NOTIFY MUST be signed and if not signed a BADAUTH response - generated. The signature MUST be under the previous parental zone - KEY, so the child can validate it, or under a valid TSIG key [draft- - ietf-dnsind-tsig-*.txt] negotiated between parent and child. - - The rollover NOTIFY can be sent to any of the nameservers for the - child using the nameserver selection algorithm defined in RFC 2136, - Section 4. Nameservers for the child zone receiving a rollover - NOTIFY query will forward the rollover NOTIFY in the same manner as - an UPDATE is forwarded. - - Unless the master server is configured to initiate an automatic - ROLLOVER it MUST seek to inform its operators that a rollover NOTIFY - request has been received. This could be done by a number of methods - including generating a log message, generating an email request to - the child zone's SOA RNAME or any other method defined in the - server's configuration for the zone. The default SHOULD be to send - mail to the zone's SOA RNAME. As with all rollover operations, care - should be taken to rate limit these messages so prevent them being - used to facilitate a denial of service attack. - - Once the message has been sent (or suppressed if so configured) to - the child zone's administrator the master server for the child zone - is free to respond to the rollover NOTIFY request. - - - -4. Secure Zone Cuts and Joinders - - There are two other events that have some similarity to key rollover. - - The first is when a secure zone the is more than one level deep has a - zone cut introduced inside it. For example, assume zone example.com - has a.b.c.example.com, d.b.c.example.com and e.example.com in it. A - zone cut could be introduced such that b.c.example.com became a - separate child zone of example.com. A real world exampe would be a - company that structures its DNS as host.branch.company.example. It - might start out will all of these names in one zone but later decide - to delegate all or some of the branches to branch zone file - maintainers. - - - -D. Eastlake 3rd, M. Andrews [Page 7] - - - -INTERNET-DRAFT April 1999 DNSSEC Key Rollover - - - The second is when a secure zone absorbs a child zone eliminating a - zone cut. This is simply the inverse of the previous paragraph. - - From the point of view of the parent zone above the splitting zone or - above the upper of the two combining zones, there is no change. - - When a zone is split by introducing a cut, the newly created child - must be properly configured. - - However, from the point of view of a child of the splitting zone - which becomes a grandchild or a grandchild that becomes a child due - to joinder, there is a change in parent name. Therefore, in general, - there is a change in parent KEY(s). Unless the entity that handles - rollovers for the zone whose parent name has changed is appropriately - updated, future automated rollover will fail because it will be sent - to the old parent. - - For this reason and so that other consistency checks can be made, the - parent SOA and SIG(SOA) are always included in the Answer section of - rollover NOTIFY requests and in ROLLOVER responsess. For automated - rollover to the new cut or joined state to work, these SOAs must be - signed with old KEY(s) of the former parent so the signatures can be - validated by the zone whose parent name is changing. In the case of - a joinder, if the private key of the pinched out middle zone is not - available, then manual update of the former grandchild, now child, - will be necessary. In the case of introducing a cut, operational - coordination with the former parent, now grandparent, signing the - initial updates to the former child, now grandchild, will be needed - to automate the reconfiguration of the zones. - - - -5. Security Considerations - - The security of ROLLOVER or UPDATE requests is essential, otherwise - false children could steal parental authorization or a false parent - could cause a child to install an invalid signature on its zone key, - etc. - - A ROLLOVER request can be authenticated by request SIG(s)under the - old zone KEY(s) of the requestor [RFC 2535]. The response SHOULD - have transaction SIG(s) under the old zone KEY(s) of the responder. - (This public key security could be used to rollover a zone to the - unsecured state but at that point it would generally not be possible - to roll back without manual intervention.) - - Alternatively, if there is a prior arrangement between a child and a - parent, ROLLOVER requests and responses can be secured and - authenticated using TSIG [draft-ietf-dnsind-tsig-*.txt]. (TSIG - security could be used to rollover a zone to unsecured and to - - -D. Eastlake 3rd, M. Andrews [Page 8] - - - -INTERNET-DRAFT April 1999 DNSSEC Key Rollover - - - rollover an unsecured zone to the secured state.) - - A server that implements online signing SHOULD have the ability to - black list a zone and force manual processing or demand that a - particular signature be used to generate the ROLLOVER request. This - it to allow ROLLOVER to be used even after a private key has been - compromised. - - - -6. IANA Considerations - - The DNS operation code (TBD) is assigned to ROLLOVER. There are no - other IANA considerations in this document. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd, M. Andrews [Page 9] - - - -INTERNET-DRAFT April 1999 DNSSEC Key Rollover - - -References - - [RFC 1034] - "Domain names - concepts and facilities", P. - Mockapetris, 11/01/1987. - - [RFC 1035] - "Domain names - implementation and specification", P. - Mockapetris, 11/01/1987. - - [RFC 1996] - "A Mechanism for Prompt Notification of Zone Changes - (DNS NOTIFY)", P. Vixie, August 1996. - - [RFC 2119] - "Key words for use in RFCs to Indicate Requirement - Levels", S. Bradner. March 1997. - - [RFC 2136] - "Dynamic Updates in the Domain Name System (DNS - UPDATE)", P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April - 1997. - - [draft-ietf-dnsind-tsig-*.txt] - - [RFC 2535] - "Domain Name System Security Extensions", D. Eastlake. - March 1999. - - [RFC 2541] - "DNS Security Operational Considerations", D. Eastlake. - March 1999. - - - -Authors Address - - Donald E. Eastlake 3rd - IBM - 65 Sindegan Hill Road, RR #1 - Carmel, NY 10512 - - Telephone: +1 914-276-2668 (h) - +1 914-784-7913 (w) - FAX: +1 914-784-3833 (w) - EMail: dee3@us.ibm.com - - - Mark Andrews - Internet Software Consortium - 1 Seymour Street - Dundas Valley, NSW 2117 - AUSTRALIA - - Telephone: +61-2-9871-4742 - Email: marka@isc.org - - - -D. Eastlake 3rd, M. Andrews [Page 10] - - - -INTERNET-DRAFT April 1999 DNSSEC Key Rollover - - -Expiration and File Name - - This draft expires in October 1999. - - Its file name is draft-ietf-dnsind-rollover-00.txt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd, M. Andrews [Page 11] - - diff --git a/doc/draft/draft-ietf-dnsind-rollover-01.txt b/doc/draft/draft-ietf-dnsind-rollover-01.txt new file mode 100644 index 0000000000..d09a2ded5b --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-rollover-01.txt @@ -0,0 +1,5 @@ +This Internet-Draft has expired and is no longer available. + +Unrevised documents placed in the Internet-Drafts directories have a +maximum life of six months. After that time, they must be updated, or +they will be deleted. This document was deleted on March 20, 2000. diff --git a/doc/draft/draft-ietf-dnsind-sec-rr-00.txt b/doc/draft/draft-ietf-dnsind-sec-rr-00.txt deleted file mode 100644 index 81ab5155ad..0000000000 --- a/doc/draft/draft-ietf-dnsind-sec-rr-00.txt +++ /dev/null @@ -1,663 +0,0 @@ -DNSIND WG Edward Lewis -INTERNET DRAFT NAI Labs -Category: I-D Jerry Scharf - ISC - Olafur Gudmundsson - NAI Labs - June 25, 1999 - The SEC 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 DNSIND WG mailing list -namedroppers@internic.net. - -This draft expires on December 25, 1999. - -Copyright Notice - -Copyright (C) The Internet Society (1999). All rights reserved. - -Abstract - -A new DNS reseource record, the SECurity RR, is defined to address -concerns about the parent zone's holding of the child zone's KEY RR -set. These concerns are addressed in a manner that retains the -information needed by a secure resolver when asking a parent zone -about the child zone. This proposal updates RFC 2535 and RFC 2181. - -1. Introduction - -DNS security extensions require a signed zone to hold KEY RR sets for -each of its delegations. This requirement has four negative -implications for the top level domains, which, for the most part, -consist of delegation points. (These issues also impact other -delegating zones, these problems are not unique to the TLDs.) -Addressing these concerns by removing the requirement for the KEY RR -in the parent has an adverse effect on secure resolution of DNS - -Expires December 25, 1999 [Page 1] -Internet Draft June 25, 1999 - -signatures. A new DNS reseource record, the SECurity RR, is defined -to address these concerns. - -The Zone Key Referral, described in another draft by the same authors, -is one proposed response to the concerns about parent's holding child -keys. However, that proposal has two drawbacks. One, it results in -two KEY RR sets at a delegation, one in the parent and one in the -child, which differ. It also does not address the expression of -security parameters, such as whether or not the child zone uses the -NXT record (which is currently mandatory). - -This document will begin by repeating the arguments against the -holding of keys at the parent as presented in the Zone Key Referral. -The document will then present the need for information about the -child to be held in parent. Following this, the SEC RR will be -defined, its master file representation discussed, and implications on -name servers. - -(Editorial note. Sections 1.1 through 1.5 are copied nearly verbatim -from the Zone Key Referral so that retirement of that draft will not -cause a problem.) - -1.1 Reasons for removing the KEY data from the parent - -There are a number of different reasons for the removal of the KEY RR -from the parent. Reasons include: - - o the performance impact that holding keys has on name servers - o the problem of updating a widely delegated parent zone on demand - o statements in RFC 2181 on authoritative data at delegations - o perceived liability of the operator of a name server or registry - -1.2 Performance Issues - -A sample zone will be used to illustrate the problem. The example -will part from reality mostly in the length of zone names, which -changes the size of the owner and resource record data fields. - -Expires December 25, 1999 [Page 2] -Internet Draft June 25, 1999 - - # $ORIGIN test. - # @ IN SOA - # IN SIG SOA - # IN KEY <1024 bit zone key> - # IN SIG KEY - # IN SIG KEY - # IN NS ns.test. - # IN SIG NS - # IN NXT my-org.test. NS SOA SIG KEY NXT - # IN SIG NXT - # - # my-org IN KEY <1024 bit zone key> - # IN KEY <1024 bit zone key> - # IN SIG KEY - # IN NS ns1.my-org.test. - # IN NS ns2.my-org.test. - # IN NXT that-org.test. NS SIG KEY NXT - # IN SIG NXT - # - # that-org IN KEY 0xC100 3 255 - # IN SIG KEY - # IN NS ns1.that-org.test. - # IN NS ns2.that-org.test. - # IN NXT test. NS SIG KEY NXT - # IN SIG NXT - -In this zone file, "my-org" is a delegation point of interest with two -registered public keys. Presumably, one key is for signatures -generated currently and the other is for still living and valid but -older signatures. "that-org" is another delegation point, with a NULL -key. This signifies that this zone is unsecured. - -To analyze the performance impact of the storing of keys, the number -of bytes used to represent the RRs in the procotol format is used. -The actual number of bytes stored will likely be higher, accounting -for data structure overhead and alignment. The actual number of bytes -transferred will be lower due to DNS name compression. - -The number of bytes for my-org's two 1024-bit keys, two NS records, -NXT and the associated signatures is 526. (1024 bit RSA/MD5 keys were -used for the calculation.) The bytes needed for that-org (with the -NULL key) is 346. Currently, there are close to 2 million entries in -com., so if we take my-org as a typical domain, over 1GB on memory -will be needed for com. The zone keys used in the example are set to -1024 bits. This number may range from as low as 512 bits upwards to -over 3000 bits. - -The increased size of the data held for the zone cuts will have two -impacts at the transport and below layers. Bandwidth beyond that -currently needed will be used to carry the KEY records. The inclusion -of all of the child's keys will also push DNS over the UDP size limit -and start using TCP - which could cause critical problems for current - -Expires December 25, 1999 [Page 3] -Internet Draft June 25, 1999 - -heavily used name servers, like the root and TLD name servers. EDNS0 -[RFC-to-be] addresses expansion of UDP message size, which alleviates -this problem. - -Another impact, not illustrated by the example, is the frequency of -updates. If each time a public key for my-org is added or deleted, -the SOA serial number will have to increase, and the SOA signed again. -If an average zone changes the contents of its key RR set once per -month, there will be on average 45 updates per minute in a zone of 2 -million delegations. (This estimate does not address the fact that -signatures also expire, requiring a new signing of the zone -periodically.) - -1.3 Security Incident Recovery (w/ respect to keys only) - -Once a zone administrator is alerted that any key's private -counterpart has been discovered (exposed), the first action to be -taken is to stop advertising the public key in DNS. This doesn't end -the availability of the key - it will be residing in caches and given -in answers from those caches - but is the closest action resembling -revokation available in DNS. - -Stopping the advertisement in the zone's name servers is as quick as -altering the master file and restarting the name server. Having to do -this in two places will will only delay the time until the recovery is -complete. - -For example, a registrar of a top level domain has decided to update -its zone only on Mondays and Fridays due to the size of the zone. A -customer/delegatee is the victim of a break in, in which one of the -items taken is the file of private keys used to sign DNS data. If this -occurs on a Tuesday, the thief has until Friday to use the keys before -they disappear from the DNS, even if the child stops publishing them -immediately. - -If the public key set is in the parent zone, and the parent zone is -not able to make the change quickly, the public key cannot be revoked -quickly. If the parent only refers to there being a key at the child -zone, then the child has the agility to change the keys - even issue a -NULL key, which will force all signatures in the zone to become -suspect. - -1.4 DNS Clarifications - -RFC 2181, section 6, clarifies the status of data appearing at a zone -cut. Data at a zone cut is served authoritatively from the servers -listed in the NS set present at the zone cut. The data is not -(necessarily) served authoritatively from the parent. (The exception -is in servers handling both the parent and child zone.) - -Section 6 also mentions that there are two exceptions created by -DNSSEC, the NXT single record set and the KEY set. This proposal -addresses the exception relating to the KEY set, by removing the set - -Expires December 25, 1999 [Page 4] -Internet Draft June 25, 1999 - -from the parent. The SEC RR is introduced and belongs in the parent -zone, there is no counterpart in the child (at the apex). - -1.5 Liability - -Liability is a legal concept, so it is not wise to attempt an -engineering solution to it. However, the perceived liability incurred -in using DNSSEC by registrars may prevent the adoption of DNSSEC. -Hence DNSSEC should be engineered in such a way to address the -concern. - -One source of liability is the notion that by advertising a public key -for a child zone, a parent zone is providing a service of security. -With that comes responsibility. By having the parent merely indicate -that a child has a key (or has no key), the parent is providing less -in the way of security. If the parent is wrong, the potential loss is -less. Instead of falsely authenticated data, configuration errors -will be apparent to the resolving client. - -Whether or not the KEY RR remains advertised in the parent zone or the -SEC RR is in place, the parent zone administrators still have to -adhere to proper key handling practices, which are being documented in -DNSOP draft. In particular, the parent has to be sure that the keys -it is signing for a child have been submitted by the true -administrator of the the child zone, and not submitted by an imposter. - -1.6 The needs of the resolver - -Now that the reasons for removing the child's keys from the parent -zone have been presented, reasons why something must take their place -are presented. A "secure" resolver is a DNS resolver that receives an -answer and, if a signature arrives, verifies the signature. Most -often, this operation will happen in resolvers that are part of name -servers, as opposed to general purpose hosts. - -The first step in authenticating a DNS response is to see if the data -is accompanied by a signature. There are five possible outcomes. -Three results are not desirable, a signature may arrive but shouldn't, -no signature arrives but should, or a signature arrives but uses the -wrong cryptographic algorthm Two outcomes can be considered -successful, a signature arriving with the correct algorithm or no -signature arrives and shouldn't. (There is one other case - a -signature generated with an inappropriate key - which is a matter -beyond the scope of this draft.) - -Since the resolver can not instantly know whether a signature is -expected, the resolver must start a discovery process. This process -can be done by the resolver querying zones between the root and the -desired domain for information about the next successive zones. -(Optimizing this search is not presented here.) For this search to be -successful, the parent must hold something that indicates the status -of the child's security, so the resolver may search with certainty. -While refraining from using the word "policy" to describe the data, -the phrase "security parameters" is used. - -Expires December 25, 1999 [Page 5] -Internet Draft June 25, 1999 - -The security parameters of a zone are not entirely defined yet, and -will remain open until a critical mass of operations experience is -gained. Initially, the following information is known to be needed. - -The set of algorithms in use by the zone. -KEY RRs and SIG RRs have protocol fields indicating how the key is -made. For now, two are in distribution, a value of 1 for RSA/MD5 and -3 for DSA. Unfortunately, the value are numeric in 8 bits, so a -bitmap representation cannot be used. - -The mechanism for negative answers. -Currently, the NXT is mandatory, liked by some administrators and -disliked by other administrators. NXTs cannot be made optional, doing -so makes them obsolete. (An attacker can make the responses look like -a zone doesn't use NXTs, even if the zone does.) If the choice of NXT -or no NXT can be securely indicated, then this is solved. There have -been discussions on alternatives to the NXT record. By allowing a -zone to indicate the style of negative answer in use, alternatives can -be installed in experimental zones. - -Signature policy. -This is an untested issue. Expressing a policy, such as whether -multiple algorithms are used, whether verification of one signature -needed or all signatures, etc., has not been fully studied. - -2. The SEC RR - -The SEC RR is a record that describes the DNS security parameters of -the owner. The owner MUST also have an NS RR set, i.e., the owner -MUST be a cut point. A signed zone MUST have a SEC RR set for each -delegation point. - - 0 1 2 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Negative Answer Bitmap | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | | - ~ Security Parameters ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - The RDATA of the SEC RR - -The SEC RR RDATA contains two data fields. One is a 16-bit field -acting as a bitmap to indicate the means used to signify a negative -answer. The other field is an unbounded field of option-value pairs -indicating other salient settings for the zone. The latter field is -not padded to any particular byte boundary. - -The SEC RR is answered authoritatively from the parent zone, and is -signed by the parent. A properly configured delegation point in the -parent would have just an SEC RR, records used for negative answering, -and a glue NS set. The corresponding point in the child (the zone's -apex) would have the SOA, KEY set, NS records, negative answer - -Expires December 25, 1999 [Page 6] -Internet Draft June 25, 1999 - -records, and other desired and legal RR sets. SIG RR's appear in both -the parent and child side of the delegation. - -There is no other special processing of the SEC RR set. It is used in -a reply as an answer when it is the subject of a direct query (QTYPE -IS SEC) or when a QTYPE=ANY reaches the delegating zone. If a name -server is authoritative for both the parent and child, the SEC is -included in the ANY reply for the delegation point. - -(Editorial note: this region is in particular need of careful review.) - -The SEC RR for a name SHOULD be supplied optionally in the additional -data section if the CD bit is not set whenever a zone's NS or KEY set -is requested. If a request for a KEY set is sent to a parent-only -server and the server is not recursive, the server should add the SEC -record to the additional section of the referral message. - -If a name server authoritative for a child zone is asked for its SEC -RR and the server has never learned the SEC RR (whether through -caching the record or by also loading the parent zone), the server MAY -answer with a negative answer. The resolver seeking a SEC RR SHOULD -know to ask for this from a parent-serving name server. - -2.1 Negative Answer Bitmap - -The Negative Answer Bitmap indicates the mechanism for use in denying -the existance of data. The bitmap is 16 bits, the most significant -bit called 0, least significant is 15. - - Bit 0 = The parent doesn't know what the child uses (1=Yes) - Bit 1 = The child signs its negative answers (1=Yes) - Bit 2 = The child follows traditional DNS rules (1=yes) - Bit 3 = The child uses the NXT record (1=yes) - Bit 14 = The child uses a locally defined mechanism (1=yes) - Bit 15 = The length of the bit field has been extended (1=yes) - -Bits 4 through 14 are currently unassigned, and are under the purview -of IANA. Bit 15 MUST BE zero. (This specification must be -superceeded to define an extension mechanism.) - -A zone may use multiple mechanisms to indicate a negative answer. A -zone SHOULD expect that a resolver finding any one of the mechanisms -used in a reply indicates a negative answer, i.e. the mechanisms are -OR'd together. - -The only illegal values for this bit field are: - Bit 0 = 1 and any other bit turned on - Bit 0 = 0, Bit 1 = 1, and no other bit turned on - Bit 15 = 1 - -2.1.1 Bit 0 (Better titles will be attached later) - -The situation in which this bit is on should not arise, but it is -defined to be safe. The philosophy behind this is that security - -Expires December 25, 1999 [Page 7] -Internet Draft June 25, 1999 - -parameters should always be made explicit, including when a sitation -is unclear. - -2.1.2 Bit 1 - -This bit indicates that the child attachs SIG records to the resource -records used in the negative answer. For example, this may indicate -that the reslover should expect to see a SIG (NXT) when an NXT is -returned. - -2.1.3 Bit 2 - -The child will answer with an SOA or any of the other means used in -the past to indicate a negative answer. (I think a reference to the -negative answer/cache document should go here.) - -2.1.4. Bit 3 - -The child uses the NXT as defined in RFC 2535. This document declares -that the use of the NXT is optional, a deviation from RFC 2535. - -2.1.5 Bit 14 - -The child is using a mechanism that is not globally defined. A zone -should be in such a state for only experimental reasons and realize -that in this state, the negative answers it gives may not be useful to -the general population of resolvers. - -2.1.6 Bit 15 - -As of this specification, this bit must be 0 (zero). - -2.1.7 Unallocated bits - -The remainder of the bits must also be zero. A procedure will be -defined for allocating them. - -2.2 Security Parameters - -The Security parameters is a sequence of options and values. An -option is a numeric indicatior of the parameter. The value is usually -either a yes or no, or a enumerated value. In rare instances, an -option may require variable length data, in this case a triplet of -option-length-value is used. The presence of the length field is -indicated by the most significant bit in the option field being 1. -Due to the nature of the SEC RR, the length field is not commonly -used. - -The option field is 8 bits. The most significant bit of the options -field is turned on if there is a length field. The value field is -also 8 bits. If the option-length-value is needed, the length is 8 -bits and contains the number of octets comprising the value. No -padding is used. - -Expires December 25, 1999 [Page 8] -Internet Draft June 25, 1999 - -An option may appear multiple times in the Security Parameters. The -sequencing of the options is not significant. If two options - -contradict each other, this is an error, and is noted by the resolver. -A self-contradictory SEC RR is a security error and data from the zone -covered by it SHOULD be considered at risk. - -Option Values are - 0 Reserved - 1 Zone is unsigned - 2 Key Algorithm in use - 3 Signing policy - 0x70-0x7F Locally defined (no length field) - 0xF0-0xFF Locally defined (uses length field) - -All unassigned option values are under the control of IANA. Values 0 -to 127 do not use the length field, values 128 to 255 do use the -length field. The option value is to be treated as unsigned. - -2.2.1 Option 0 - -This option is reserved for future definition. - -2.2.2 Option 1 - -The parent has not signed a KEY RR for the child, therefore the child -zone has no DNSSEC approved signing keys. If this option is not -present, then the resolver SHOULD assume that there are zone keys in -the child zone. - -If the value of this is non-zero, this assertion is true. If the -value is zero, this assertion is false. If the parent has signed keys -for the child, the value is zero, however, in this case, the parent -SHOULD NOT include this option in the security parameters. - -It is tempting to exclude an unsigned zone option from this list, -relying on the absence of any in use key algorithms (option 2) to -imply that the zone is unsigned. The unsigned option is included to -make this information explicit, so that when analyzing a running zone, -it is obvious to an administrator that a zone is unsigned. - -2.2.3 Option 2 - -The parent has signed a key for the child which claims a particular -algorithm. This value field is equal to that of the algorithm field -of the triggering KEY RR. - -Option 2 can be repeated for different algorithms. It is not -necessary to have multiple Option 2 entries with the same key -algorithm value. - -If Option 1 and Option 2 appear in the same SEC RR, this is a -self-contradictory record. If neither Option 1 nor Option 2 appear, -this also constitues a self-contradictory record. - -Expires December 25, 1999 [Page 9] -Internet Draft June 25, 1999 - -2.2.4 Option 3 - -The child has the option to require that all material signatures -(those generated by DNSSEC-approved signing keys) must be validated -(within any temporal constraints) for the data to be considered valid. -The child may instead require that just one of the signatures be -validated. This may be a reflection of the manner in which a zone's -administration is shared amongst organizations. - -If Option 3 is not present (and Option 2 is), the resolver SHOULD -assume that ALL (temporally valid) signatures are required. If the -parent includes at least one Option 2, it SHOULD specify an Option 3, -with a value indicated by the child. - -Values for Option 3 are - 0 Reserved - 1 All signatures are required - 2 One signature is required - 256 Locally defined - -All remaining values are under the control of IANA. - -(Editorial note: whether the assumption that all signatures are -necessary or just one is sufficient in the absence of this option is -open to WG debate.) - -2.2.5 Options 0x70-0x7F - -This option is reserved for an organization to use locally, in an -experimental fashion. This option does not use the length field. -Global interpretation of this option is undefined. - -2.2.6 Options 0xF0-0xFF - -This option is reserved for an organization to use locally, in an -experimental fashion. This option uses the length field. Global -interpretation of this option is undefined. - -3. Master File Representation - -The SEC RR fields are to be represented as hexidecimal fields, with a -preceeding '0x', or in decimal format. Hexidecimal SHOULD be used. - -For example, the SEC RR representing a zone that use signed NXT -records, and has one or more DSA keys, one or more RSA keys, and -requires that just one signature be verified would be: - -myzone.test. 3500 IN SEC 0x5000 0x0201 0203 0302 - -(0x020102030302 is one field, hence one 0x prefix.) - -Hex values for the security parameters MAY BE separated by -whitespace, as shown. DNS data display routines SHOULD substitute - -Expires December 25, 1999 [Page 10] -Internet Draft June 25, 1999 - -mnemonics for these values, but MUST write the numeric form in master -files. - -4. Signature Policy - -The SEC RR must be signed by one or more zone keys of the parent -(delgating) zone, and the signatures must adhere to the parent's -policy. - -The SEC RR for the root zone is the lone exception, it appears at the -apex of the root zone, and must be signed sufficiently by the root's -zone key or keys. - -5. Cache Considerations - -When a SEC RR set for a name is held in a cache, it will have a -credibility rating indicating that the data came from the parent -(unless the parent and child share servers). When data about the same -name arrives from the child, with a higher credibility, the newly -arrived data MUST NOT cause the cache to remove the SEC RR. - -6. IANA Considerations - -IANA is requested to assign this RR an type parameter for DNS, and to -assign the indicated option numbers and values when requests are -approved. The procedure for requesting new options and values will be -defined in future versions of this specfication. - -7. Security Considerations - -This record is designed to address the concerns of securing delegation -points and resolving the security of DNS answers. This record is -important to the security because it supplies needed information and -eases the burden of security on the DNS. - -The SEC RR does require one piece of additional information not -addressed to date to be communicated from the parent to the child. -This is the signature policy. This will be needed in the operations -documents. - -Editorial Note: This document would benefit by a companion document -describing the process of evaluating the signatures in DNS. Such a -document would provide clearer input to the security parameters field. - -8. Editorial Considerations - -Although somewhat detailed in this current description, this record is -still in the formative state. The -00 document has been quickly -written to test the waters for interest. - -9. References - -RFC 2535 is the prime DNSSEC definition. RFC 2181 is the Clarify -document. EDNS0 reference needed... - -Expires December 25, 1999 [Page 11] -Internet Draft June 25, 1999 - -10. Acknowledgements - -This record is a successor to the Zone Key Referral, originally -promoted by John Gilmore and Jerry Scharf. A DNSSEC workshop -sponsored by the NIC-SE in May 1999 provided the enlightenment that -expanded the Zone Key Referral into the SEC RR proposal. - -11. Author's Addresses - -Edward Lewis Jerry Scharf Olafur Gudmundsson -NAI Labs Internet Software Consortium NAI Labs -3060 Washington Road 950 Charter St 3060 Washington Rd -Glenwood, MD 21738 Redwood City, CA 94063 Glenwood, MD 21738 -+1 443 259 2352 +1 650 779 7060 +1 443 259 2389 - - -12. Full Copyright Statement - -Copyright (C) The Internet Society (1999). 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 implmentation 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 December 25, 1999 [Page 12] diff --git a/doc/draft/draft-ietf-dnsind-sec-rr-01.txt b/doc/draft/draft-ietf-dnsind-sec-rr-01.txt new file mode 100644 index 0000000000..d09a2ded5b --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-sec-rr-01.txt @@ -0,0 +1,5 @@ +This Internet-Draft has expired and is no longer available. + +Unrevised documents placed in the Internet-Drafts directories have a +maximum life of six months. After that time, they must be updated, or +they will be deleted. This document was deleted on March 20, 2000.