diff --git a/doc/draft/draft-ietf-dnsext-2929bis-01.txt b/doc/draft/draft-ietf-dnsext-2929bis-01.txt new file mode 100644 index 0000000000..fa41e7635e --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-2929bis-01.txt @@ -0,0 +1,928 @@ + +INTERNET-DRAFT Donald E. Eastlake 3rd +Obsoletes RFC 2929, Updates RFC 1183 Motorola Laboratories +Expires: February 2006 August 2005 + + + + Domain Name System (DNS) IANA Considerations + ------ ---- ------ ----- ---- -------------- + + + + +Status of This Document + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Distribution of this draft is unlimited. It is intended to become + the new BCP 42 obsoleting RFC 2929. Comments should be sent to the + DNS Working Group mailing list . + + 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 a "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + + +Abstract + + Internet Assigned Number Authority (IANA) parameter assignment + considerations are given for the allocation of Domain Name System + (DNS) classes, RR types, operation codes, error codes, RR header + bits, and AFSDB subtypes. + + + + + + + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. DNS Query/Response Headers..............................3 + 2.1 One Spare Bit?.........................................4 + 2.2 Opcode Assignment......................................4 + 2.3 RCODE Assignment.......................................5 + 3. DNS Resource Records....................................6 + 3.1 RR TYPE IANA Considerations............................7 + 3.1.1 DNS TYPE Allocation Policy...........................8 + 3.1.2 Special Note on the OPT RR...........................9 + 3.1.3 The AFSDB RR Subtype Field...........................9 + 3.2 RR CLASS IANA Considerations...........................9 + 3.3 RR NAME Considerations................................11 + 4. Security Considerations................................11 + + Appendix: Changes from RFC 2929...........................12 + + Copyright and Disclaimer..................................13 + Normative References......................................13 + Informative References....................................14 + + Authors Addresses.........................................16 + Expiration and File Name..................................16 + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +1. Introduction + + The Domain Name System (DNS) provides replicated distributed secure + hierarchical databases which hierarchically store "resource records" + (RRs) under domain names. DNS data is structured into CLASSes and + zones which can be independently maintained. See [RFC 1034, 1035, + 2136, 2181, 4033] familiarity with which is assumed. + + This document provides, either directly or by reference, general IANA + parameter assignment considerations applying across DNS query and + response headers and all RRs. There may be additional IANA + considerations that apply to only a particular RR type or + query/response opcode. See the specific RFC defining that RR type or + query/response opcode for such considerations if they have been + defined, except for AFSDB RR considerations [RFC 1183] which are + included herein. This RFC obsoletes [RFC 2929]. + + IANA currently maintains a web page of DNS parameters. See + . + + "IETF Standards Action", "IETF Consensus", "Specification Required", + and "Private Use" are as defined in [RFC 2434]. + + + +2. DNS Query/Response Headers + + The header for DNS queries and responses contains field/bits in the + following diagram taken from [RFC 2136, 2929]: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ID | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | QDCOUNT/ZOCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ANCOUNT/PRCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | NSCOUNT/UPCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ARCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The ID field identifies the query and is echoed in the response so + they can be matched. + + The QR bit indicates whether the header is for a query or a response. + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful + only in queries or only in responses, depending on the bit. However, + many DNS implementations copy the query header as the initial value + of the response header without clearing bits. Thus any attempt to + use a "query" bit with a different meaning in a response or to define + a query meaning for a "response" bit is dangerous given existing + implementation. Such meanings may only be assigned by an IETF + Standards Action. + + The unsigned fields query count (QDCOUNT), answer count (ANCOUNT), + authority count (NSCOUNT), and additional information count (ARCOUNT) + express the number of records in each section for all opcodes except + Update. These fields have the same structure and data type for + Update but are instead the counts for the zone (ZOCOUNT), + prerequisite (PRCOUNT), update (UPCOUNT), and additional information + (ARCOUNT) sections. + + + +2.1 One Spare Bit? + + There have been ancient DNS implementations for which the Z bit being + on in a query meant that only a response from the primary server for + a zone is acceptable. It is believed that current DNS + implementations ignore this bit. + + Assigning a meaning to the Z bit requires an IETF Standards Action. + + + +2.2 Opcode Assignment + + Currently DNS OpCodes are assigned as follows: + + OpCode Name Reference + + 0 Query [RFC 1035] + 1 IQuery (Inverse Query, Obsolete) [RFC 3425] + 2 Status [RFC 1035] + 3 available for assignment + 4 Notify [RFC 1996] + 5 Update [RFC 2136] + 6-15 available for assignment + + New OpCode assignments require an IETF Standards Action as modified + by [RFC 4020]. + + + + + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +2.3 RCODE Assignment + + It would appear from the DNS header above that only four bits of + RCODE, or response/error code are available. However, RCODEs can + appear not only at the top level of a DNS response but also inside + OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930]. + The OPT RR provides an eight bit extension resulting in a 12 bit + RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field. + + Error codes appearing in the DNS header and in these three RR types + all refer to the same error code space with the single exception of + error code 16 which has a different meaning in the OPT RR from its + meaning in other contexts. See table below. + + RCODE Name Description Reference + Decimal + Hexadecimal + 0 NoError No Error [RFC 1035] + 1 FormErr Format Error [RFC 1035] + 2 ServFail Server Failure [RFC 1035] + 3 NXDomain Non-Existent Domain [RFC 1035] + 4 NotImp Not Implemented [RFC 1035] + 5 Refused Query Refused [RFC 1035] + 6 YXDomain Name Exists when it should not [RFC 2136] + 7 YXRRSet RR Set Exists when it should not [RFC 2136] + 8 NXRRSet RR Set that should exist does not [RFC 2136] + 9 NotAuth Server Not Authoritative for zone [RFC 2136] + 10 NotZone Name not contained in zone [RFC 2136] + 11 - 15 Available for assignment + 16 BADVERS Bad OPT Version [RFC 2671] + 16 BADSIG TSIG Signature Failure [RFC 2845] + 17 BADKEY Key not recognized [RFC 2845] + 18 BADTIME Signature out of time window [RFC 2845] + 19 BADMODE Bad TKEY Mode [RPC 2930] + 20 BADNAME Duplicate key name [RPF 2930] + 21 BADALG Algorithm not supported [RPF 2930] + + 22 - 3,840 + 0x0016 - 0x0F00 Available for assignment + + 3,841 - 4,095 + 0x0F01 - 0x0FFF Private Use + + 4,096 - 65,534 + 0x1000 - 0xFFFE Available for assignment + + 65,535 + 0xFFFF Reserved, can only be allocated by an IETF + Standards Action. + + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + Since it is important that RCODEs be understood for interoperability, + assignment of new RCODE listed above as "available for assignment" + requires an IETF Consensus. + + + +3. DNS Resource Records + + All RRs have the same top level format shown in the figure below + taken from [RFC 1035]: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | + / / + / NAME / + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TYPE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | CLASS | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TTL | + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | RDLENGTH | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| + / RDATA / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + NAME is an owner name, i.e., the name of the node to which this + resource record pertains. NAMEs are specific to a CLASS as described + in section 3.2. NAMEs consist of an ordered sequence of one or more + labels each of which has a label type [RFC 1035, 2671]. + + TYPE is a two octet unsigned integer containing one of the RR TYPE + codes. See section 3.1. + + CLASS is a two octet unsigned integer containing one of the RR CLASS + codes. See section 3.2. + + TTL is a four octet (32 bit) bit unsigned integer that specifies the + number of seconds that the resource record may be cached before the + source of the information should again be consulted. Zero is + interpreted to mean that the RR can only be used for the transaction + in progress. + + RDLENGTH is an unsigned 16 bit integer that specifies the length in + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + octets of the RDATA field. + + RDATA is a variable length string of octets that constitutes the + resource. The format of this information varies according to the TYPE + and in some cases the CLASS of the resource record. + + + +3.1 RR TYPE IANA Considerations + + There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs, + and MetaTYPEs. + + Data TYPEs are the primary means of storing data. QTYPES can only be + used in queries. Meta-TYPEs designate transient data associated with + an particular DNS message and in some cases can also be used in + queries. Thus far, data TYPEs have been assigned from 1 upwards plus + the block from 100 through 103 while Q and Meta Types have been + assigned from 255 downwards except for the OPT Meta-RR which is + assigned TYPE 41. There have been DNS implementations which made + caching decisions based on the top bit of the bottom byte of the RR + TYPE. + + There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG + [RFC 2845], and TKEY [RFC 2930]. + + There are currently five QTYPEs assigned: * (all), MAILA, MAILB, + AXFR, and IXFR. + + Considerations for the allocation of new RR TYPEs are as follows: + + Decimal + Hexadecimal + + 0 + 0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC + 2535] and in other circumstances and must never be allocated + for ordinary use. + + 1 - 127 + 0x0001 - 0x007F - remaining TYPEs in this range are assigned for data + TYPEs by the DNS TYPE Allocation Policy as specified in + section 3.1.1. + + 128 - 255 + 0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and + Meta TYPEs by the DNS TYPE Allocation Policy as specified in + section 3.1.1. + + + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + 256 - 32,767 + 0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS + TYPE Allocation Policy as specified in section 3.1.1. + + 32,768 - 65,279 + 0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434]. + + 65,280 - 65534 + 0xFF00 - 0xFFFE - Private Use. + + 65,535 + 0xFFFF - Reserved, can only be assigned by an IETF Standards Action. + + + +3.1.1 DNS TYPE Allocation Policy + + Parameter values specified above as assigned based on DNS TYPE + Allocation Policy. That is, Expert Review with the additional + requirement that the review be based on a complete template as + specified below which has been posted for three weeks to the + namedroppers@ops.ietf.org mailing list. + + Partial or draft templates may be posted with the intend of + soliciting feedback. + + + DNS RR TYPE PARAMETER ALLOCATION TEMPLATE + + Date: + + Name and email of originator: + + Pointer to internet-draft or other document giving a detailed + description of the protocol use of the new RR Type: + + What need is the new RR TYPE intended to fix? + + What existing RR TYPE(s) come closest to filling that need and why are + they unsatisfactory? + + Does the proposed RR TYPR require special handling within the DNS + different from an Unknown RR TYPE? + + Comments: + + + + + + + +D. Eastlake 3rd [Page 8] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +3.1.2 Special Note on the OPT RR + + The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its + primary purpose is to extend the effective field size of various DNS + fields including RCODE, label type, OpCode, flag bits, and RDATA + size. In particular, for resolvers and servers that recognize it, it + extends the RCODE field from 4 to 12 bits. + + + +3.1.3 The AFSDB RR Subtype Field + + The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same + RDATA field structure as the MX RR but the 16 bit unsigned integer + field at the beginning of the RDATA is interpreted as a subtype as + follows: + + Decimal + Hexadecimal + + 0 + 0x0000 - Allocation requires IETF Standards Action. + + 1 + 0x0001 - Andrews File Service v3.0 Location Service [RFC 1183]. + + 2 + 0x0002 - DCE/NCA root cell directory node [RFC 1183]. + + 3 - 65,279 + 0x0003 - 0xFEFF - Allocation by IETF Consensus. + + 65,280 - 65,534 + 0xFF00 - 0xFFFE - Private Use. + + 65,535 + 0xFFFF - Reserved, allocation requires IETF Standards Action. + + + +3.2 RR CLASS IANA Considerations + + DNS CLASSes have been little used but constitute another dimension of + the DNS distributed database. In particular, there is no necessary + relationship between the name space or root servers for one CLASS and + those for another CLASS. The same name can have completely different + meanings in different CLASSes; however, the label types are the same + and the null label is usable only as root in every CLASS. However, + as global networking and DNS have evolved, the IN, or Internet, CLASS + has dominated DNS use. + + +D. Eastlake 3rd [Page 9] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + There are two subcategories of DNS CLASSes: normal data containing + classes and QCLASSes that are only meaningful in queries or updates. + + The current CLASS assignments and considerations for future + assignments are as follows: + + Decimal + Hexadecimal + + 0 + 0x0000 - Reserved, assignment requires an IETF Standards Action. + + 1 + 0x0001 - Internet (IN). + + 2 + 0x0002 - Available for assignment by IETF Consensus as a data CLASS. + + 3 + 0x0003 - Chaos (CH) [Moon 1981]. + + 4 + 0x0004 - Hesiod (HS) [Dyer 1987]. + + 5 - 127 + 0x0005 - 0x007F - available for assignment by IETF Consensus for data + CLASSes only. + + 128 - 253 + 0x0080 - 0x00FD - available for assignment by IETF Consensus for + QCLASSes only. + + 254 + 0x00FE - QCLASS None [RFC 2136]. + + 255 + 0x00FF - QCLASS Any [RFC 1035]. + + 256 - 32,767 + 0x0100 - 0x7FFF - Assigned by IETF Consensus. + + 32,768 - 65,279 + 0x8000 - 0xFEFF - Assigned based on Specification Required as defined + in [RFC 2434]. + + 65,280 - 65,534 + 0xFF00 - 0xFFFE - Private Use. + + 65,535 + 0xFFFF - Reserved, can only be assigned by an IETF Standards Action. + + +D. Eastlake 3rd [Page 10] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +3.3 RR NAME Considerations + + DNS NAMEs are sequences of labels [RFC 1035]. The last label in each + NAME is "ROOT" which is the zero length label. By definition, the + null or ROOT label can not be used for any other NAME purpose. + + At the present time, there are two categories of label types, data + labels and compression labels. Compression labels are pointers to + data labels elsewhere within an RR or DNS message and are intended to + shorten the wire encoding of NAMEs. The two existing data label + types are sometimes referred to as Text and Binary. Text labels can, + in fact, include any octet value including zero value octets but most + current uses involve only [US-ASCII]. For retrieval, Text labels are + defined to treat ASCII upper and lower case letter codes as matching + [insensitive]. Binary labels are bit sequences [RFC 2673]. The + Binary label type is Experimental [RFC 3363]. + + IANA considerations for label types are given in [RFC 2671]. + + NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon + 1981] CLASSes are essentially for local use. The IN or Internet + CLASS is thus the only DNS CLASS in global use on the Internet at + this time. + + A somewhat out-of-date description of name allocation in the IN Class + is given in [RFC 1591]. Some information on reserved top level + domain names is in BCP 32 [RFC 2606]. + + + +4. Security Considerations + + This document addresses IANA considerations in the allocation of + general DNS parameters, not security. See [RFC 4033, 4034, 4035] for + secure DNS considerations. + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 11] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +Appendix: Changes from RFC 2929 + + RFC Editor: This Appendix should be deleted for publication. + + Changes from RFC 2929 to this draft: + + 1. Changed many "IETF Consensus" for RR TYPEs to be "DNS TYPE + Allocation Policy" and add the specification of that policy. Change + some remaining "IETF Standards Action" allocation requirements to say + "as modified by [RFC 4020]". + + 2. Updated various RFC references. + + 3. Mentioned that the Binary label type is now Experimental and + IQuery is Obsolete. + + 4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be + IETF Standards Action required. + + 5. Add an IANA allocation policy for the AFSDB RR Subtype field. + + 6. Addition of reference to case insensitive draft. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 12] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +Copyright and Disclaimer + + Copyright (C) The Internet Society (2005). This document is subject to + the rights, licenses and restrictions contained in BCP 78, and except + as set forth therein, the authors retain all their rights. + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + + + +Normative References + + [RFC 1034] - Mockapetris, P., "Domain Names - Concepts and + Facilities", STD 13, RFC 1034, November 1987. + + [RFC 1035] - Mockapetris, P., "Domain Names - Implementation and + Specifications", STD 13, RFC 1035, November 1987. + + [RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P. + Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990. + + [RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone + Changes (DNS NOTIFY)", RFC 1996, August 1996. + + [RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System", + RFC 2673, August 1999. + + [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B. + Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", + RFC 2845, May 2000. + + +D. Eastlake 3rd [Page 13] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + [RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", September 2000. + + [RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. + Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in + the Domain Name System (DNS)", RFC 3363, August 2002. + + [RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November + 2002. + + [RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of + Standards Track Code Points", BCP 100, RFC 4020, February 2005. + + [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC 4033, March + 2005. + + [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security Extensions", RFC + 4035, March 2005. + + [US-ASCII] - ANSI, "USA Standard Code for Information Interchange", + X3.4, American National Standards Institute: New York, 1968. + + + +Informative References + + [Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena + Technical Plan - Name Service, April 1987, + + [Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts + Institute of Technology Artificial Intelligence Laboratory, June + 1981. + + [RFC 1591] - Postel, J., "Domain Name System Structure and + Delegation", RFC 1591, March 1994. + + [RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, + "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, + September 2000. + + [RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS + Names", RFC 2606, June 1999. + + [insensitive] - Eastlake, D., "Domain Name System (DNS) Case + + +D. Eastlake 3rd [Page 14] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt, + work in progress. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 15] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +Authors Addresses + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1-508-786-7554 (w) + email: Donald.Eastlake@motorola.com + + + +Expiration and File Name + + This draft expires February 2006. + + Its file name is draft-ietf-dnsext-2929bis-01.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 16] + diff --git a/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt b/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt new file mode 100644 index 0000000000..438e8008a4 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt @@ -0,0 +1,1397 @@ +DNS Extensions Working Group G. Sisson +Internet-Draft B. Laurie +Expires: January 11, 2006 Nominet + July 10, 2005 + + + Derivation of DNS Name Predecessor and Successor + draft-ietf-dnsext-dns-name-p-s-00 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 11, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes two methods for deriving the canonically- + ordered predecessor and successor of a DNS name. These methods may + be used for dynamic NSEC resource record synthesis, enabling + security-aware name servers to provide authenticated denial of + existence without disclosing other owner names in a DNSSEC-secured + zone. + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 1] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 + 3. Absolute Method . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Derivation of DNS Name Predecessor . . . . . . . . . . . . 4 + 3.2. Derivation of DNS Name Successor . . . . . . . . . . . . . 4 + 4. Modified Method . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.1. Derivation of DNS Name Predecessor . . . . . . . . . . . . 6 + 4.2. Derivation of DNS Name Successor . . . . . . . . . . . . . 6 + 5. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5.1. Case Considerations . . . . . . . . . . . . . . . . . . . 7 + 5.2. Choice of Range . . . . . . . . . . . . . . . . . . . . . 7 + 5.3. Wild Card Considerations . . . . . . . . . . . . . . . . . 8 + 5.4. Possible Modifications . . . . . . . . . . . . . . . . . . 8 + 5.4.1. Restriction of Effective Maximum DNS Name Length . . . 8 + 5.4.2. Use of Modified Method With Zones Containing + SRV RRs . . . . . . . . . . . . . . . . . . . . . . . 9 + 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.1. Examples of Immediate Predecessors Using Absolute + Method . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.2. Examples of Immediate Successors Using Absolute Method . . 13 + 6.3. Examples of Predecessors Using Modified Method . . . . . . 19 + 6.4. Examples of Successors Using Modified Method . . . . . . . 20 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 + Appendix A. Change History . . . . . . . . . . . . . . . . . . . 22 + A.1. Changes from sisson-02 to ietf-00 . . . . . . . . . . . . 22 + A.2. Changes from sisson-01 to sisson-02 . . . . . . . . . . . 23 + A.3. Changes from sisson-00 to sisson-01 . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 + Intellectual Property and Copyright Statements . . . . . . . . . . 25 + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 2] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + +1. Introduction + + One of the proposals for avoiding the exposure of zone information + during the deployment DNSSEC is dynamic NSEC resource record (RR) + synthesis. This technique is described in [I-D.ietf-dnsext-dnssec- + trans] and [I-D.ietf-dnsext-dnssec-online-signing], and involves the + generation of NSEC RRs that just span the query name for non-existent + owner names. In order to do this, the DNS names which would occur + just prior to and just following a given query name must be + calculated in real time, as maintaining a list of all possible owner + names that might occur in a zone would be impracticable. + + Section 6.1 of [RFC4034] defines canonical DNS name order. This + document does not amend or modify this definition. However, the + derivation of immediate predecessor and successor, while trivial, is + non-obvious. Accordingly, several methods are described here as an + aid to implementors and a reference to other interested parties. + + This document describes two methods: + + 1. An ``absolute method'', which returns the immediate predecessor + or successor of a domain name such that no valid DNS name could + exist between that DNS name and the predecessor or successor. + + 2. A ``modified method'', which returns a predecessor and successor + which are more economical in size and computation. This method + is restricted to use with zones consisting only of single-label + owner names where a maximum-length owner name would not result in + a DNS name exceeding the maximum DNS name length. This is, + however, the type of zone for which the technique of online- + signing is most likely to be used. + + +2. Notational Conventions + + The following notational conventions are used in this document for + economy of expression: + + N: An unspecified DNS name. + + P(N): Immediate predecessor to N (absolute method). + + S(N): Immediate successor to N (absolute method). + + P'(N): Predecessor to N (modified method). + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 3] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + S'(N): Successor to N (modified method). + + +3. Absolute Method + + These derivations assume that all uppercase US-ASCII letters in N + have already been replaced by their corresponding lowercase + equivalents. Unless otherwise specified, processing stops after the + first step in which a condition is met. + +3.1. Derivation of DNS Name Predecessor + + To derive P(N): + + 1. If N is the same as the owner name of the zone apex, prepend N + repeatedly with labels of the maximum length possible consisting + of octets of the maximum sort value (e.g. 0xff) until N is the + maximum length possible; otherwise continue to the next step. + + 2. If the least significant (left-most) label of N consists of a + single octet of the minimum sort value (e.g. 0x00), remove that + label; otherwise continue to the next step. + + 3. If the least significant (right-most) octet in the least + significant (left-most) label of N is the minimum sort value, + remove the least significant octet and continue with step 5. + + 4. Decrement the value of the least significant (right-most) octet, + skipping any values that correspond to uppercase US-ASCII + letters, and then append the label with as many octets as + possible of the maximum sort value. Continue to the next step. + + 5. Prepend N repeatedly with labels of as long a length as possible + consisting of octets of the maximum sort value until N is the + maximum length possible. + +3.2. Derivation of DNS Name Successor + + To derive S(N): + + 1. If N is two or more octets shorter than the maximum DNS name + length, prepend N with a label containing a single octet of the + minimum sort value (e.g. 0x00); otherwise continue to the next + step. + + 2. If N is one or more octets shorter than the maximum DNS name + length and the least significant (left-most) label is one or more + octets shorter than the maximum label length, append an octet of + + + +Sisson & Laurie Expires January 11, 2006 [Page 4] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + the minimum sort value to the least significant label; otherwise + continue to the next step. + + 3. Increment the value of the least significant (right-most) octet + in the least significant (left-most) label that is less than the + maximum sort value (e.g. 0xff), skipping any values that + correspond to uppercase US-ASCII letters, and then remove any + octets to the right of that one. If all octets in the label are + the maximum sort value, then continue to the next step. + + 4. Remove the least significant (left-most) label. If N is now the + same as the owner name of the zone apex, do nothing. (This will + occur only if N is the maximum possible name in canonical DNS + name order, and thus has wrapped to the owner name of zone apex.) + Otherwise repeat starting at step 2. + + +4. Modified Method + + This method is for use with zones consisting only of single-label + owner names where an owner name consisting of label of maximum length + would not result in a DNS name which exceeded the maximum DNS name + length. This method is computationally simpler and returns values + which are more economical in size than the absolute method. It + differs from the absolute method detailed above in the following + ways: + + 1. Step 1 of the derivation P(N) has been omitted as the existence + of the owner name of the zone apex never requires denial. + + 2. A new step 1 has been introduced which removes unnecessary + labels. + + 3. Step 4 of the derivation P(N) has been omitted as it is only + necessary for zones containing owner names consisting of more + than one label. This omission generally results in a significant + reduction of the length of derived predecessors. + + 4. Step 1 of the derivation S(N) had been omitted as it is only + necessary for zones containing owner names consisting of more + than one label. This omission results in a tiny reduction of the + length of derived successors, and maintains consistency with the + modification of step 4 of the derivation P(N) described above. + + 5. Steps 2 and 4 of the derivation S(N) have been modified to + eliminate checks for maximum DNS name length, as it is an + assumption of this method that no DNS name in the zone can exceed + the maximum DNS name length. + + + +Sisson & Laurie Expires January 11, 2006 [Page 5] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + These derivations assume that all uppercase US-ASCII letters in N + have already been replaced by their corresponding lowercase + equivalents. Unless otherwise specified, processing stops after the + first step in which a condition is met. + +4.1. Derivation of DNS Name Predecessor + + To derive P'(N): + + 1. If N has more labels than the number of labels in the owner name + of the apex + 1, repeatedly remove the least significant (left- + most) label until N has no more labels than the number of labels + in the owner name of the apex + 1; otherwise continue to next + step. + + 2. If the least significant (left-most) label of N consists of a + single octet of the minimum sort value (e.g. 0x00), remove that + label; otherwise continue to the next step. + + 3. If the least significant (right-most) octet in the least + significant (left-most) label of N is the minimum sort value, + remove the least significant octet. + + 4. Decrement the value of the least significant (right-most) octet, + skipping any values which correspond to uppercase US-ASCII + letters, and then append the label with as many octets as + possible of the maximum sort value. + +4.2. Derivation of DNS Name Successor + + To derive S'(N): + + 1. If N has more labels than the number of labels in the owner name + of the apex + 1, repeatedly remove the least significant (left- + most) label until N has no more labels than the number of labels + in the owner name of the apex + 1. Continue to next step. + + 2. If the least significant (left-most) label of N is one or more + octets shorter than the maximum label length, append an octet of + the minimum sort value to the least significant label; otherwise + continue to the next step. + + 3. Increment the value of the least significant (right-most) octet + in the least significant (left-most) label that is less than the + maximum sort value (e.g. 0xff), skipping any values which + correspond to uppercase US-ASCII letters, and then remove any + octets to the right of that one. If all octets in the label are + the maximum sort value, then continue to the next step. + + + +Sisson & Laurie Expires January 11, 2006 [Page 6] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + 4. Remove the least significant (left-most) label. (This will occur + only if the least significant label is the maximum label length + and consists entirely of octets of the maximum sort value, and + thus has wrapped to the owner name of the zone apex.) + + +5. Notes + +5.1. Case Considerations + + Section 3.5 of [RFC1034] specifies that "while upper and lower case + letters are allowed in [DNS] names, no significance is attached to + the case". Additionally, Section 6.1 of [RFC4034] states that when + determining canonical DNS name order, "uppercase US-ASCII letters are + treated as if they were lowercase US-ASCII letters". Consequently, + values corresponding to US-ASCII uppercase letters must be skipped + when decrementing and incrementing octets in the derivations + described in Section 3.1 and Section 3.2. + + The following pseudo-code is illustrative: + + Decrement the value of an octet: + + if (octet == '[') // '[' is just after uppercase 'Z' + octet = '@'; // '@' is just prior to uppercase 'A' + else + octet--; + + Increment the value of an octet: + + if (octet == '@') // '@' is just prior to uppercase 'A' + octet = '['; // '[' is just after uppercase 'Z' + else + octet++; + +5.2. Choice of Range + + [RFC2181] makes the clarification that "any binary string whatever + can be used as the label of any resource record". Consequently the + minimum sort value may be set as 0x00 and the maximum sort value as + 0xff, and the range of possible values will be any DNS name which + contains octets of any value other than those corresponding to + uppercase US-ASCII letters. + + However, if all owner names in a zone are in the letter-digit-hyphen, + or LDH, format specified in [RFC1034], it may be desirable to + restrict the range of possible values to DNS names containing only + LDH values. This has the effect of: + + + +Sisson & Laurie Expires January 11, 2006 [Page 7] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + 1. making the output of tools such as `dig' and `nslookup' less + subject to confusion; + + 2. minimising the impact that NSEC RRs containing DNS names with + non-LDH values (or non-printable values) might have on faulty DNS + resolver implementations; and + + 3. preventing the possibility of results which are wildcard DNS + names (see Section 5.3). + + This may be accomplished by using a minimum sort value of 0x1f (US- + ASCII character `-') and a maximum sort value of 0x7a (US-ASCII + character lowercase `z'), and then skipping non-LDH, non-lowercase + values when incrementing or decrementing octets. + +5.3. Wild Card Considerations + + Neither derivation avoids the possibility that the result may be a + DNS name containing a wildcard label, i.e. a label containing a + single octet with the value 0x2a (US-ASCII character `*'). With + additional tests, wildcard DNS names may be explicitly avoided; + alternatively, if the range of octet values can be restricted to + those corresponding to letter-digit-hyphen, or LDH, characters (see + Section 5.2), such DNS names will not occur. + + Note that it is improbable that a result which is a wildcard DNS name + will occur unintentionally; even if one does occur either as the + owner name of, or in the RDATA of an NSEC RR, it is treated as a + literal DNS name with no special meaning. + +5.4. Possible Modifications + +5.4.1. Restriction of Effective Maximum DNS Name Length + + [RFC1034] specifies that "the total number of octets that represent a + [DNS] name (i.e., the sum of all label octets and label lengths) is + limited to 255", including the null (zero-length) label which + represents the root. For the purpose of deriving predecessors and + successors during NSEC RR synthesis, the maximum DNS name length may + be effectively restricted to the length of the longest DNS name in + the zone. This will minimise the size of responses containing + synthesised NSEC RRs but, especially in the case of the modified + method, may result in some additional computational complexity. + + Note that this modification will have the effect of revealing + information about the longest name in the zone. Moreover, when the + contents of the zone changes, e.g. during dynamic updates and zone + transfers, care must be taken to ensure that the effective maximum + + + +Sisson & Laurie Expires January 11, 2006 [Page 8] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + DNS name length agrees with the new contents. + +5.4.2. Use of Modified Method With Zones Containing SRV RRs + + Normally the modified method cannot be used in zones that contain + SRV RRs [RFC2782], as SRV RRs have owner names which contain multiple + labels. However the use of SRV RRs can be accommodated by various + techniques. There are at least four possible ways to do this: + + 1. Use conventional NSEC RRs for the region of the zone that + contains first-level labels beginning with the underscore (`_') + character. For the purposes of generating these NSEC RRs, the + existence of (possibly fictional) ownernames `9{63}' and `a' + could be assumed, providing a lower and upper bound for this + region. Then all queries where the QNAME doesn't exist but + contains a first-level label beginning with an underscore could + be handled using the normal DNSSEC protocol. + + This approach would make it possible to enumerate all DNS names + in the zone containing a first-level label beginning with + underscore, including all SRV RRs, but this may be of less a + concern to the zone administrator than incurring the overhead of + the absolute method or of the following variants of the modified + method. + + 2. The absolute method could be used for synthesising NSEC RRs for + all queries where the QNAME contains a leading underscore. + However this re-introduces the susceptibility of the absolute + method to denial of service activity, as an attacker could send + queries for an effectively inexhaustible supply of domain names + beginning with a leading underscore. + + 3. A variant of the modified method could be used for synthesising + NSEC RRs for all queries where the QNAME contains a leading + underscore. This variant would assume that all predecessors and + successors to queries where the QNAME contains a leading + underscore may consist of two lablels rather than only one. This + introduces a little additional complexity without incurring the + full increase in response size and computational complexity as + the absolute method. + + 4. Finally, a variant the modified method which assumes that all + owner names in the zone consist of one or two labels could be + used. However this negates much of the reduction in response + size of the modified method and may be nearly as computationally + complex as the absolute method. + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 9] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + +6. Examples + + In the following examples: + + the owner name of the zone apex is "example.com."; + + the range of octet values is 0x00 - 0xff excluding values + corresponding to uppercase US-ASCII letters; and + + non-printable octet values are expressed as three-digit decimal + numbers preceded by a backslash (as specified in Section 5.1 of + [RFC1035]). + +6.1. Examples of Immediate Predecessors Using Absolute Method + + Example of typical case: + + P(foo.example.com.) = + + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255.\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.fon\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255.example.com. + + or, in alternate notation: + + \255{49}.\255{63}.\255{63}.fon\255{60}.example.com. + + where {n} represents the number of repetitions of an octet. + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 10] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where least significant (left-most) label of DNS name + consists of a single octet of the minimum sort value: + + P(\000.foo.example.com.) = foo.example.com. + + Example where least significant (right-most) octet of least + significant (left-most) label has the minimum sort value: + + P(foo\000.example.com.) = + + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255.\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.foo.example.com. + + or, in alternate notation: + + \255{45}.\255{63}.\255{63}.\255{63}.foo.example.com. + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 11] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name contains an octet which must be decremented by + skipping values corresponding to US-ASCII uppercase letters: + + P(fo\[.example.com.) = + + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255.\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.fo\@\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255.example.com. + + or, in alternate notation: + + \255{49}.\255{63}.\255{63}.fo\@\255{60}.example.com. + + where {n} represents the number of repetitions of an octet. + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 12] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name is the owner name of the zone apex, and + consequently wraps to the DNS name with the maximum possible sort + order in the zone: + + P(example.com.) = + + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255.\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.example.com. + + or, in alternate notation: + + \255{49}.\255{63}.\255{63}.\255{63}.example.com. + +6.2. Examples of Immediate Successors Using Absolute Method + + Example of typical case: + + S(foo.example.com.) = \000.foo.example.com. + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 13] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name is one octet short of the maximum DNS name + length: + + N = fooooooooooooooooooooooooooooooooooooooooooooooo + .ooooooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooooo.ooooooooooooooooooooooooooooooo + oooooooooooooooooooooooooooooooo.ooooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo.example.com. + + or, in alternate notation: + + fo{47}.o{63}.o{63}.o{63}.example.com. + + S(N) = + + fooooooooooooooooooooooooooooooooooooooooooooooo + \000.ooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooooooooo.ooooooooooooooooooooooooooo + oooooooooooooooooooooooooooooooooooo.ooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + oooo.example.com. + + or, in alternate notation: + + fo{47}\000.o{63}.o{63}.o{63}.example.com. + + + + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 14] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name is the maximum DNS name length: + + N = fooooooooooooooooooooooooooooooooooooooooooooooo + o.oooooooooooooooooooooooooooooooooooooooooooooo + ooooooooooooooooo.oooooooooooooooooooooooooooooo + ooooooooooooooooooooooooooooooooo.oooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + o.example.com. + + or, in alternate notation: + + fo{48}.o{63}.o{63}.o{63}.example.com. + + S(N) = + + fooooooooooooooooooooooooooooooooooooooooooooooo + p.oooooooooooooooooooooooooooooooooooooooooooooo + ooooooooooooooooo.oooooooooooooooooooooooooooooo + ooooooooooooooooooooooooooooooooo.oooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + o.example.com. + + or, in alternate notation: + + fo{47}p.o{63}.o{63}.o{63}.example.com. + + + + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 15] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name is the maximum DNS name length and the least + significant (left-most) label has the maximum sort value: + + N = \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.ooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooooooooo.ooooooooooooooooooooooooooo + oooooooooooooooooooooooooooooooooooo.ooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + oooo.example.com. + + or, in alternate notation: + + \255{49}.o{63}.o{63}.o{63}.example.com. + + S(N) = + + oooooooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooop.oooooooooooooooooooooooooooooooo + ooooooooooooooooooooooooooooooo.oooooooooooooooo + ooooooooooooooooooooooooooooooooooooooooooooooo. + example.com. + + or, in alternate notation: + + o{62}p.o{63}.o{63}.example.com. + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 16] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name is the maximum DNS name length and the eight + least significant (right-most) octets of the least significant (left- + most) label have the maximum sort value: + + N = foooooooooooooooooooooooooooooooooooooooo\255 + \255\255\255\255\255\255\255.ooooooooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooo.ooo + oooooooooooooooooooooooooooooooooooooooooooooooo + oooooooooooo.ooooooooooooooooooooooooooooooooooo + oooooooooooooooooooooooooooo.example.com. + + or, in alternate notation: + + fo{40}\255{8}.o{63}.o{63}.o{63}.example.com. + + S(N) = + + fooooooooooooooooooooooooooooooooooooooop.oooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + ooooooooo.oooooooooooooooooooooooooooooooooooooo + ooooooooooooooooooooooooo.oooooooooooooooooooooo + ooooooooooooooooooooooooooooooooooooooooo.example.com. + + or, in alternate notation: + + fo{39}p.o{63}.o{63}.o{63}.example.com. + + + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 17] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name is the maximum DNS name length and contains an + octet which must be incremented by skipping values corresponding to + US-ASCII uppercase letters: + + N = fooooooooooooooooooooooooooooooooooooooooooooooo + \@.ooooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooooooo.ooooooooooooooooooooooooooooo + oooooooooooooooooooooooooooooooooo.ooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + oo.example.com. + + or, in alternate notation: + + fo{47}\@.o{63}.o{63}.o{63}.example.com. + + S(N) = + + fooooooooooooooooooooooooooooooooooooooooooooooo + \[.ooooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooooooo.ooooooooooooooooooooooooooooo + oooooooooooooooooooooooooooooooooo.ooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + oo.example.com. + + or, in alternate notation: + + fo{47}\[.o{63}.o{63}.o{63}.example.com. + + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 18] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name has the maximum possible sort order in the + zone, and consequently wraps to the owner name of the zone apex: + + N = \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255.\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.example.com. + + or, in alternate notation: + + \255{49}.\255{63}.\255{63}.\255{63}.example.com. + + S(N) = example.com. + +6.3. Examples of Predecessors Using Modified Method + + Example of typical case: + + P'(foo.example.com.) = + + fon\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.example.com. + + or, in alternate notation: + + fon\255{60}.example.com. + + + + +Sisson & Laurie Expires January 11, 2006 [Page 19] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name contains more labels than DNS names in the + zone: + + P'(bar.foo.example.com.) = foo.example.com. + + Example where least significant (right-most) octet of least + significant (left-most) label has the minimum sort value: + + P'(foo\000.example.com.) = foo.example.com. + + Example where least significant (left-most) label has the minimum + sort value: + + P'(\000.example.com.) = example.com. + + Example where DNS name is the owner name of the zone apex, and + consequently wraps to the DNS name with the maximum possible sort + order in the zone: + + P'(example.com.) = + + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255.example.com. + + or, in alternate notation: + + \255{63}.example.com. + +6.4. Examples of Successors Using Modified Method + + Example of typical case: + + S'(foo.example.com.) = foo\000.example.com. + + Example where DNS name contains more labels than DNS names in the + zone: + + S'(bar.foo.example.com.) = foo\000.example.com. + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 20] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where least significant (left-most) label has the maximum + sort value, and consequently wraps to the owner name of the zone + apex: + + N = \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255.example.com. + + or, in alternate notation: + + \255{63}.example.com. + + S'(N) = example.com. + + +7. Security Considerations + + The derivation of some predecessors/successors requires the testing + of more conditions than others. Consequently the effectiveness of a + denial-of-service attack may be enhanced by sending queries that + require more conditions to be tested. The modified method involves + the testing of fewer conditions than the absolute method and + consequently is somewhat less susceptible to this exposure. + + +8. IANA Considerations + + This document has no IANA actions. + + Note to RFC Editor: This section is included to make it clear during + pre-publication review that this document has no IANA actions. It + may therefore be removed should it be published as an RFC. + + +9. Acknowledgments + + The authors would like to thank Olaf Kolkman, Olafur Gudmundsson and + Niall O'Reilly for their review and input. + + +10. References + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 21] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + +10.1 Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + +10.2 Informative References + + [I-D.ietf-dnsext-dnssec-online-signing] + Ihren, J. and S. Weiler, "Minimally Covering NSEC Records + and DNSSEC On-line Signing", + draft-ietf-dnsext-dnssec-online-signing-00 (work in + progress), May 2005. + + [I-D.ietf-dnsext-dnssec-trans] + Arends, R., Koch, P., and J. Schlyter, "Evaluating DNSSEC + Transition Mechanisms", + draft-ietf-dnsext-dnssec-trans-02 (work in progress), + February 2005. + + +Appendix A. Change History + +A.1. Changes from sisson-02 to ietf-00 + + o Added notes on use of SRV RRs with modified method. + + o Changed reference from weiler-dnssec-online-signing to ietf- + dnsext-dnssec-online-signing. + + o Changed reference from ietf-dnsext-dnssec-records to RFC 4034. + + o Miscellaneous minor changes to text. + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 22] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + +A.2. Changes from sisson-01 to sisson-02 + + o Added modified version of derivation (with supporting examples). + + o Introduced notational conventions N, P(N), S(N), P'(N) and S'(N). + + o Added clarification to derivations about when processing stops. + + o Miscellaneous minor changes to text. + +A.3. Changes from sisson-00 to sisson-01 + + o Split step 3 of derivation of DNS name predecessor into two + distinct steps for clarity. + + o Added clarifying text and examples related to the requirement to + avoid uppercase characters when decrementing or incrementing + octets. + + o Added optimisation using restriction of effective maximum DNS name + length. + + o Changed examples to use decimal rather than octal notation as per + [RFC1035]. + + o Corrected DNS name length of some examples. + + o Added reference to weiler-dnssec-online-signing. + + o Miscellaneous minor changes to text. + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 23] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + +Authors' Addresses + + Geoffrey Sisson + Nominet + Sandford Gate + Sandy Lane West + Oxford + OX4 6LB + GB + + Phone: +44 1865 332339 + Email: geoff@nominet.org.uk + + + Ben Laurie + Nominet + 17 Perryn Road + London + W3 7LR + GB + + Phone: +44 20 8735 0686 + Email: ben@algroup.co.uk + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 24] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Sisson & Laurie Expires January 11, 2006 [Page 25] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt new file mode 100644 index 0000000000..3a800f9888 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt @@ -0,0 +1,616 @@ + + + +Network Working Group S. Weiler +Internet-Draft SPARTA, Inc +Updates: 4034, 4035 (if approved) May 23, 2005 +Expires: November 24, 2005 + + + Clarifications and Implementation Notes for DNSSECbis + draft-ietf-dnsext-dnssec-bis-updates-01 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on November 24, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document is a collection of minor technical clarifications to + the DNSSECbis document set. It is meant to serve as a resource to + implementors as well as an interim repository of possible DNSSECbis + errata. + + + + + + + +Weiler Expires November 24, 2005 [Page 1] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + +Proposed additions in future versions + + An index sorted by the section of DNSSECbis being clarified. + + A list of proposed protocol changes being made in other documents, + such as NSEC3 and Epsilon. This document would not make those + changes, merely provide an index into the documents that are making + changes. + +Changes between -00 and -01 + + Document significantly restructured. + + Added section on QTYPE=ANY. + +Changes between personal submission and first WG draft + + Added Section 2.1 based on namedroppers discussions from March 9-10, + 2005. + + Added Section 3.4, Section 3.3, Section 4.3, and Section 2.2. + + Added the DNSSECbis RFC numbers. + + Figured out the confusion in Section 4.1. + + + + + + + + + + + + + + + + + + + + + + + + + + +Weiler Expires November 24, 2005 [Page 2] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + +Table of Contents + + 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4 + 1.1 Structure of this Document . . . . . . . . . . . . . . . . 4 + 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Significant Concerns . . . . . . . . . . . . . . . . . . . . . 4 + 2.1 Clarifications on Non-Existence Proofs . . . . . . . . . . 4 + 2.2 Empty Non-Terminal Proofs . . . . . . . . . . . . . . . . 5 + 2.3 Validating Responses to an ANY Query . . . . . . . . . . . 5 + 3. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5 + 3.1 Unknown DS Message Digest Algorithms . . . . . . . . . . . 5 + 3.2 Private Algorithms . . . . . . . . . . . . . . . . . . . . 6 + 3.3 Caution About Local Policy and Multiple RRSIGs . . . . . . 6 + 3.4 Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7 + 4. Minor Corrections and Clarifications . . . . . . . . . . . . . 7 + 4.1 Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 7 + 4.2 Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 7 + 4.3 Errors in Examples . . . . . . . . . . . . . . . . . . . . 8 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 7.1 Normative References . . . . . . . . . . . . . . . . . . . 8 + 7.2 Informative References . . . . . . . . . . . . . . . . . . 9 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 + A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 + Intellectual Property and Copyright Statements . . . . . . . . 11 + + + + + + + + + + + + + + + + + + + + + + + + + +Weiler Expires November 24, 2005 [Page 3] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + +1. Introduction and Terminology + + This document lists some minor clarifications and corrections to + DNSSECbis, as described in [1], [2], and [3]. + + It is intended to serve as a resource for implementors and as a + repository of items that need to be addressed when advancing the + DNSSECbis documents from Proposed Standard to Draft Standard. + + In this version (-01 of the WG document), feedback is particularly + solicited on the structure of the document and whether the text in + the recently added sections is correct and sufficient. + + Proposed substantive additions to this document should be sent to the + namedroppers mailing list as well as to the editor of this document. + The editor would greatly prefer text suitable for direct inclusion in + this document. + +1.1 Structure of this Document + + The clarifications to DNSSECbis are sorted according to the editor's + impression of their importance, starting with ones which could, if + ignored, lead to security and stability problems and progressing down + to clarifications that are likely to have little operational impact. + Mere typos and awkward phrasings are not addressed unless they could + lead to misinterpretation of the DNSSECbis documents. + +1.2 Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [4]. + +2. Significant Concerns + + This section provides clarifications that, if overlooked, could lead + to security issues or major interoperability problems. + +2.1 Clarifications on Non-Existence Proofs + + RFC4035 Section 5.4 slightly underspecifies the algorithm for + checking non-existence proofs. In particular, the algorithm there + might incorrectly allow the NSEC from the parent side of a zone cut + to prove the non-existence of either other RRs at that name in the + child zone or other names in the child zone. It might also allow a + NSEC at the same name as a DNAME to prove the non-existence of names + beneath that DNAME. + + + + +Weiler Expires November 24, 2005 [Page 4] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + + A parent-side delegation NSEC (one with the NS bit set, but no SOA + bit set, and with a singer field that's shorter than the owner name) + must not be used to assume non-existence of any RRs below that zone + cut (both RRs at that ownername and at ownernames with more leading + labels, no matter their content). Similarly, an NSEC with the DNAME + bit set must not be used to assume the non-existence of any + descendant of that NSEC's owner name. + +2.2 Empty Non-Terminal Proofs + + To be written, based on Roy Arends' May 11th message to namedroppers. + +2.3 Validating Responses to an ANY Query + + RFC4035 does not address now to validate responses when QTYPE=*. As + described in Section 6.2.2 of RFC1034, a proper response to QTYPE=* + may include a subset of the RRsets at a given name -- it is not + necessary to include all RRsets at the QNAME in the response. + + When validating a response to QTYPE=*, validate all received RRsets + that match QNAME and QCLASS. If any of those RRsets fail validation, + treat the answer as Bogus. If there are no RRsets matching QNAME and + QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as + clarified in this document). To be clear, a validator must not + insist on receiving all records at the QNAME in response to QTYPE=*. + +3. Interoperability Concerns + +3.1 Unknown DS Message Digest Algorithms + + Section 5.2 of RFC4035 includes rules for how to handle delegations + to zones that are signed with entirely unsupported algorithms, as + indicated by the algorithms shown in those zone's DS RRsets. It does + not explicitly address how to handle DS records that use unsupported + message digest algorithms. In brief, DS records using unknown or + unsupported message digest algorithms MUST be treated the same way as + DS records referring to DNSKEY RRs of unknown or unsupported + algorithms. + + The existing text says: + + If the validator does not support any of the algorithms listed + in an authenticated DS RRset, then the resolver has no supported + authentication path leading from the parent to the child. The + resolver should treat this case as it would the case of an + authenticated NSEC RRset proving that no DS RRset exists, as + described above. + + + + +Weiler Expires November 24, 2005 [Page 5] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + + To paraphrase the above, when determining the security status of a + zone, a validator discards (for this purpose only) any DS records + listing unknown or unsupported algorithms. If none are left, the + zone is treated as if it were unsigned. + + Modified to consider DS message digest algorithms, a validator also + discards any DS records using unknown or unsupported message digest + algorithms. + +3.2 Private Algorithms + + As discussed above, section 5.2 of RFC4035 requires that validators + make decisions about the security status of zones based on the public + key algorithms shown in the DS records for those zones. In the case + of private algorithms, as described in RFC4034 Appendix A.1.1, the + eight-bit algorithm field in the DS RR is not conclusive about what + algorithm(s) is actually in use. + + If no private algorithms appear in the DS set or if any supported + algorithm appears in the DS set, no special processing will be + needed. In the remaining cases, the security status of the zone + depends on whether or not the resolver supports any of the private + algorithms in use (provided that these DS records use supported hash + functions, as discussed in Section 3.1). In these cases, the + resolver MUST retrieve the corresponding DNSKEY for each private + algorithm DS record and examine the public key field to determine the + algorithm in use. The security-aware resolver MUST ensure that the + hash of the DNSKEY RR's owner name and RDATA matches the digest in + the DS RR. If they do not match, and no other DS establishes that + the zone is secure, the referral should be considered BAD data, as + discussed in RFC4035. + + This clarification facilitates the broader use of private algorithms, + as suggested by [5]. + +3.3 Caution About Local Policy and Multiple RRSIGs + + When multiple RRSIGs cover a given RRset, RFC4035 Section 5.3.3 + suggests that "the local resolver security policy determines whether + the resolver also has to test these RRSIG RRs and how to resolve + conflicts if these RRSIG RRs lead to differing results." In most + cases, a resolver would be well advised to accept any valid RRSIG as + sufficient. If the first RRSIG tested fails validation, a resolver + would be well advised to try others, giving a successful validation + result if any can be validated and giving a failure only if all + RRSIGs fail validation. + + If a resolver adopts a more restrictive policy, there's a danger that + + + +Weiler Expires November 24, 2005 [Page 6] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + + properly-signed data might unnecessarily fail validation, perhaps + because of cache timing issues. Furthermore, certain zone management + techniques, like the Double Signature Zone-signing Key Rollover + method described in section 4.2.1.2 of [6] might not work reliably. + +3.4 Key Tag Calculation + + RFC4034 Appendix B.1 incorrectly defines the Key Tag field + calculation for algorithm 1. It correctly says that the Key Tag is + the most significant 16 of the least significant 24 bits of the + public key modulus. However, RFC4034 then goes on to incorrectly say + that this is 4th to last and 3rd to last octets of the public key + modulus. It is, in fact, the 3rd to last and 2nd to last octets. + +4. Minor Corrections and Clarifications + +4.1 Finding Zone Cuts + + Appendix C.8 of RFC4035 discusses sending DS queries to the servers + for a parent zone. To do that, a resolver may first need to apply + special rules to discover what those servers are. + + As explained in Section 3.1.4.1 of RFC4035, security-aware name + servers need to apply special processing rules to handle the DS RR, + and in some situations the resolver may also need to apply special + rules to locate the name servers for the parent zone if the resolver + does not already have the parent's NS RRset. Section 4.2 of RFC4035 + specifies a mechanism for doing that. + +4.2 Clarifications on DNSKEY Usage + + Questions of the form "can I use a different DNSKEY for signing the + X" have occasionally arisen. + + The short answer is "yes, absolutely". You can even use a different + DNSKEY for each RRset in a zone, subject only to practical limits on + the size of the DNSKEY RRset. However, be aware that there is no way + to tell resolvers what a particularly DNSKEY is supposed to be used + for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to + authenticate any RRset in the zone. For example, if a weaker or less + trusted DNSKEY is being used to authenticate NSEC RRsets or all + dynamically updated records, that same DNSKEY can also be used to + sign any other RRsets from the zone. + + Furthermore, note that the SEP bit setting has no effect on how a + DNSKEY may be used -- the validation process is specifically + prohibited from using that bit by RFC4034 section 2.1.2. It possible + to use a DNSKEY without the SEP bit set as the sole secure entry + + + +Weiler Expires November 24, 2005 [Page 7] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + + point to the zone, yet use a DNSKEY with the SEP bit set to sign all + RRsets in the zone (other than the DNSKEY RRset). It's also possible + to use a single DNSKEY, with or without the SEP bit set, to sign the + entire zone, including the DNSKEY RRset itself. + +4.3 Errors in Examples + + The text in RFC4035 Section C.1 refers to the examples in B.1 as + "x.w.example.com" while B.1 uses "x.w.example". This is painfully + obvious in the second paragraph where it states that the RRSIG labels + field value of 3 indicates that the answer was not the result of + wildcard expansion. This is true for "x.w.example" but not for + "x.w.example.com", which of course has a label count of 4 + (antithetically, a label count of 3 would imply the answer was the + result of a wildcard expansion). + + The first paragraph of RFC4035 Section C.6 also has a minor error: + the reference to "a.z.w.w.example" should instead be "a.z.w.example", + as in the previous line. + +5. IANA Considerations + + This document specifies no IANA Actions. + +6. Security Considerations + + This document does not make fundamental changes to the DNSSEC + protocol, as it was generally understood when DNSSECbis was + published. It does, however, address some ambiguities and omissions + in those documents that, if not recognized and addressed in + implementations, could lead to security failures. In particular, the + validation algorithm clarifications in Section 2 are critical for + preserving the security properties DNSSEC offers. Furthermore, + failure to address some of the interoperability concerns in Section 3 + could limit the ability to later change or expand DNSSEC, including + by adding new algorithms. + +7. References + +7.1 Normative References + + [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + + +Weiler Expires November 24, 2005 [Page 8] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + + [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + RFC 4035, March 2005. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + +7.2 Informative References + + [5] Blacka, D., "DNSSEC Experiments", + draft-blacka-dnssec-experiments-00 (work in progress), + December 2004. + + [6] Gieben, R. and O. Kolkman, "DNSSEC Operational Practices", + draft-ietf-dnsop-dnssec-operational-practices-04 (work in + progress), May 2005. + + +Author's Address + + Samuel Weiler + SPARTA, Inc + 7075 Samuel Morse Drive + Columbia, Maryland 21046 + US + + Email: weiler@tislabs.com + +Appendix A. Acknowledgments + + The editor is extremely grateful to those who, in addition to finding + errors and omissions in the DNSSECbis document set, have provided + text suitable for inclusion in this document. + + The lack of specificity about handling private algorithms, as + described in Section 3.2, and the lack of specificity in handling ANY + queries, as described in Section 2.3, were discovered by David + Blacka. + + The error in algorithm 1 key tag calculation, as described in + Section 3.4, was found by Abhijit Hayatnagarkar. Donald Eastlake + contributed text for Section 3.4. + + The bug relating to delegation NSEC RR's in Section 2.1 was found by + Roy Badami. Roy Arends found the related problem with DNAME. + + The errors in the RFC4035 examples were found by Roy Arends, who also + contributed text for Section 4.3 of this document. + + + +Weiler Expires November 24, 2005 [Page 9] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + + The editor would like to thank Olafur Gudmundsson and Scott Rose for + their substantive comments on the text of this document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Weiler Expires November 24, 2005 [Page 10] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Weiler Expires November 24, 2005 [Page 11] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-online-signing-00.txt b/doc/draft/draft-ietf-dnsext-dnssec-online-signing-00.txt new file mode 100644 index 0000000000..f7abddc43e --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-online-signing-00.txt @@ -0,0 +1,560 @@ + + + +Network Working Group S. Weiler +Internet-Draft SPARTA, Inc +Updates: 4034, 4035 (if approved) J. Ihren +Expires: November 13, 2005 Autonomica AB + May 12, 2005 + + + Minimally Covering NSEC Records and DNSSEC On-line Signing + draft-ietf-dnsext-dnssec-online-signing-00 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on November 13, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes how to construct DNSSEC NSEC resource records + that cover a smaller range of names than called for by RFC4034. By + generating and signing these records on demand, authoritative name + servers can effectively stop the disclosure of zone contents + otherwise made possible by walking the chain of NSEC records in a + signed zone. + + + + +Weiler & Ihren Expires November 13, 2005 [Page 1] + +Internet-Draft NSEC Epsilon May 2005 + + +Changes from weiler-01 to ietf-00 + + Inserted RFC numbers for 4033, 4034, and 4035. + + Specified contents of bitmap field in synthesized NSEC RR's, pointing + out that this relaxes a constraint in 4035. Added 4035 to the + Updates header. + +Changes from weiler-00 to weiler-01 + + Clarified that this updates RFC4034 by relaxing requirements on the + next name field. + + Added examples covering wildcard names. + + In the 'better functions' section, reiterated that perfect functions + aren't needed. + + Added a reference to RFC 2119. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Weiler & Ihren Expires November 13, 2005 [Page 2] + +Internet-Draft NSEC Epsilon May 2005 + + +Table of Contents + + 1. Introduction and Terminology . . . . . . . . . . . . . . . . 4 + 2. Minimally Covering NSEC Records . . . . . . . . . . . . . . 4 + 3. Better Increment & Decrement Functions . . . . . . . . . . . 6 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 + 5. Security Considerations . . . . . . . . . . . . . . . . . . 7 + 6. Normative References . . . . . . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 + A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 8 + Intellectual Property and Copyright Statements . . . . . . . 10 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Weiler & Ihren Expires November 13, 2005 [Page 3] + +Internet-Draft NSEC Epsilon May 2005 + + +1. Introduction and Terminology + + With DNSSEC [1], an NSEC record lists the next instantiated name in + its zone, proving that no names exist in the "span" between the + NSEC's owner name and the name in the "next name" field. In this + document, an NSEC record is said to "cover" the names between its + owner name and next name. + + Through repeated queries that return NSEC records, it is possible to + retrieve all of the names in the zone, a process commonly called + "walking" the zone. Some zone owners have policies forbidding zone + transfers by arbitrary clients; this side-effect of the NSEC + architecture subverts those policies. + + This document presents a way to prevent zone walking by constructing + NSEC records that cover fewer names. These records can make zone + walking take approximately as many queries as simply asking for all + possible names in a zone, making zone walking impractical. Some of + these records must be created and signed on demand, which requires + on-line private keys. Anyone contemplating use of this technique is + strongly encouraged to review the discussion of the risks of on-line + signing in Section 5. + + The technique presented here may be useful to a zone owner that wants + to use DNSSEC, is concerned about exposure of its zone contents via + zone walking, and is willing to bear the costs of on-line signing. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [4]. + +2. Minimally Covering NSEC Records + + This mechanism involves changes to NSEC records for instantiated + names, which can still be generated and signed in advance, as well as + the on-demand generation and signing of new NSEC records whenever a + name must be proven not to exist. + + In the 'next name' field of instantiated names' NSEC records, rather + than list the next instantiated name in the zone, list any name that + falls lexically after the NSEC's owner name and before the next + instantiated name in the zone, according to the ordering function in + RFC4034 [2] section 6.2. This relaxes the requirement in section + 4.1.1 of RFC4034 that the 'next name' field contains the next owner + name in the zone. This change is expected to be fully compatible + with all existing DNSSEC validators. These NSEC records are returned + whenever proving something specifically about the owner name (e.g. + that no resource records of a given type appear at that name). + + + +Weiler & Ihren Expires November 13, 2005 [Page 4] + +Internet-Draft NSEC Epsilon May 2005 + + + Whenever an NSEC record is needed to prove the non-existence of a + name, a new NSEC record is dynamically produced and signed. The new + NSEC record has an owner name lexically before the QNAME but + lexically following any existing name and a 'next name' lexically + following the QNAME but before any existing name. + + The generated NSEC record's type bitmap SHOULD have the RRSIG and + NSEC bits set and SHOULD NOT have any other bits set. This relaxes + the requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at + names that did not exist before the zone wsa signed. + + The functions to generate the lexically following and proceeding + names need not be perfect nor consistent, but the generated NSEC + records must not cover any existing names. Furthermore, this + technique works best when the generated NSEC records cover as few + names as possible. + + An NSEC record denying the existence of a wildcard may be generated + in the same way. Since the NSEC record covering a non-existent + wildcard is likely to be used in response to many queries, + authoritative name servers using the techniques described here may + want to pregenerate or cache that record and its corresponding RRSIG. + + For example, a query for an A record at the non-instantiated name + example.com might produce the following two NSEC records, the first + denying the existence of the name example.com and the second denying + the existence of a wildcard: + + exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC ) + + ).com 3600 IN NSEC +.com ( RRSIG NSEC ) + + Before answering a query with these records, an authoritative server + must test for the existence of names between these endpoints. If the + generated NSEC would cover existing names (e.g. exampldd.com or + *bizarre.example.com), a better increment or decrement function may + be used or the covered name closest to the QNAME could be used as the + NSEC owner name or next name, as appropriate. If an existing name is + used as the NSEC owner name, that name's real NSEC record MUST be + returned. Using the same example, assuming an exampldd.com + delegation exists, this record might be returned from the parent: + + exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC ) + + Like every authoritative record in the zone, each generated NSEC + record MUST have corresponding RRSIGs generated using each algorithm + (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as + described in RFC4035 [3] section 2.2. To minimize the number of + + + +Weiler & Ihren Expires November 13, 2005 [Page 5] + +Internet-Draft NSEC Epsilon May 2005 + + + signatures that must be generated, a zone may wish to limit the + number of algorithms in its DNSKEY RRset. + +3. Better Increment & Decrement Functions + + Section 6.2 of RFC4034 defines a strict ordering of DNS names. + Working backwards from that definition, it should be possible to + define increment and decrement functions that generate the + immediately following and preceding names, respectively. This + document does not define such functions. Instead, this section + presents functions that come reasonably close to the perfect ones. + As described above, an authoritative server should still ensure than + no generated NSEC covers any existing name. + + To increment a name, add a leading label with a single null (zero- + value) octet. + + To decrement a name, decrement the last character of the leftmost + label, then fill that label to a length of 63 octets with octets of + value 255. To decrement a null (zero-value) octet, remove the octet + -- if an empty label is left, remove the label. Defining this + function numerically: fill the left-most label to its maximum length + with zeros (numeric, not ASCII zeros) and subtract one. + + In response to a query for the non-existent name foo.example.com, + these functions produce NSEC records of: + + fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG ) + + )\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG ) + + The first of these NSEC RRs proves that no exact match for + foo.example.com exists, and the second proves that there is no + wildcard in example.com. + + Both of these functions are imperfect: they don't take into account + constraints on number of labels in a name nor total length of a name. + As noted in the previous section, though, this technique does not + depend on the use of perfect increment or decrement functions: it is + sufficient to test whether any instantiated names fall into the span + + + +Weiler & Ihren Expires November 13, 2005 [Page 6] + +Internet-Draft NSEC Epsilon May 2005 + + + covered by the generated NSEC and, if so, substitute those + instantiated owner names for the NSEC owner name or next name, as + appropriate. + +4. IANA Considerations + + Per RFC4041, IANA should think carefully about the protection of + their immortal souls. + +5. Security Considerations + + This approach requires on-demand generation of RRSIG records. This + creates several new vulnerabilities. + + First, on-demand signing requires that a zone's authoritative servers + have access to its private keys. Storing private keys on well-known + internet-accessible servers may make them more vulnerable to + unintended disclosure. + + Second, since generation of public key signatures tends to be + computationally demanding, the requirement for on-demand signing + makes authoritative servers vulnerable to a denial of service attack. + + Lastly, if the increment and decrement functions are predictable, on- + demand signing may enable a chosen-plaintext attack on a zone's + private keys. Zones using this approach should attempt to use + cryptographic algorithms that are resistant to chosen-plaintext + attacks. It's worth noting that while DNSSEC has a "mandatory to + implement" algorithm, that is a requirement on resolvers and + validators -- there is no requirement that a zone be signed with any + given algorithm. + + The success of using minimally covering NSEC record to prevent zone + walking depends greatly on the quality of the increment and decrement + functions chosen. An increment function that chooses a name + obviously derived from the next instantiated name may be easily + reverse engineered, destroying the value of this technique. An + increment function that always returns a name close to the next + instantiated name is likewise a poor choice. Good choices of + increment and decrement functions are the ones that produce the + immediately following and preceding names, respectively, though zone + administrators may wish to use less perfect functions that return + more human-friendly names than the functions described in Section 3 + above. + + Another obvious but misguided concern is the danger from synthesized + NSEC records being replayed. It's possible for an attacker to replay + an old but still validly signed NSEC record after a new name has been + + + +Weiler & Ihren Expires November 13, 2005 [Page 7] + +Internet-Draft NSEC Epsilon May 2005 + + + added in the span covered by that NSEC, incorrectly proving that + there is no record at that name. This danger exists with DNSSEC as + defined in [-bis]. The techniques described here actually decrease + the danger, since the span covered by any NSEC record is smaller than + before. Choosing better increment and decrement functions will + further reduce this danger. + +6. Normative References + + [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + RFC 4035, March 2005. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + +Authors' Addresses + + Samuel Weiler + SPARTA, Inc + 7075 Samuel Morse Drive + Columbia, Maryland 21046 + US + + Email: weiler@tislabs.com + + + Johan Ihren + Autonomica AB + Bellmansgatan 30 + Stockholm SE-118 47 + Sweden + + Email: johani@autonomica.se + +Appendix A. Acknowledgments + + Many individuals contributed to this design. They include, in + addition to the authors of this document, Olaf Kolkman, Ed Lewis, + + + +Weiler & Ihren Expires November 13, 2005 [Page 8] + +Internet-Draft NSEC Epsilon May 2005 + + + Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis, + Jakob Schlyter, Bill Manning, and Joao Damas. + + The key innovation of this document, namely that perfect increment + and decrement functions are not necessary, arose during a discussion + among the above-listed people at the RIPE49 meeting in September + 2004. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Weiler & Ihren Expires November 13, 2005 [Page 9] + +Internet-Draft NSEC Epsilon May 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Weiler & Ihren Expires November 13, 2005 [Page 10] + diff --git a/doc/draft/draft-ietf-dnsext-interop3597-01.txt b/doc/draft/draft-ietf-dnsext-interop3597-02.txt similarity index 64% rename from doc/draft/draft-ietf-dnsext-interop3597-01.txt rename to doc/draft/draft-ietf-dnsext-interop3597-02.txt index 123d3cc096..160afc356a 100644 --- a/doc/draft/draft-ietf-dnsext-interop3597-01.txt +++ b/doc/draft/draft-ietf-dnsext-interop3597-02.txt @@ -1,39 +1,39 @@ - DNS Extensions Working Group J. Schlyter -Internet-Draft August 24, 2004 -Expires: February 22, 2005 +Internet-Draft May 19, 2005 +Expires: November 20, 2005 RFC 3597 Interoperability Report - draft-ietf-dnsext-interop3597-01.txt + draft-ietf-dnsext-interop3597-02.txt Status of this Memo - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3667. + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. 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. + 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 + 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 current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on February 22, 2005. + This Internet-Draft will expire on November 20, 2005. Copyright Notice - Copyright (C) The Internet Society (2004). All Rights Reserved. + Copyright (C) The Internet Society (2005). Abstract @@ -49,11 +49,9 @@ Abstract +Schlyter Expires November 20, 2005 [Page 1] - -Schlyter Expires February 22, 2005 [Page 1] - -Internet-Draft RFC 3597 Interoperability Report August 2004 +Internet-Draft RFC 3597 Interoperability Report May 2005 Table of Contents @@ -61,14 +59,14 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Implementations . . . . . . . . . . . . . . . . . . . . . . . 3 3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3.1 Authoritative Primary Name Server . . . . . . . . . . . . . . 3 - 3.2 Authoritative Secondary Name Server . . . . . . . . . . . . . 3 - 3.3 Full Recursive Resolver . . . . . . . . . . . . . . . . . . . 3 - 3.4 Stub Resolver . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3.5 DNSSEC Signer . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1 Authoritative Primary Name Server . . . . . . . . . . . . 3 + 3.2 Authoritative Secondary Name Server . . . . . . . . . . . 3 + 3.3 Full Recursive Resolver . . . . . . . . . . . . . . . . . 4 + 3.4 Stub Resolver . . . . . . . . . . . . . . . . . . . . . . 4 + 3.5 DNSSEC Signer . . . . . . . . . . . . . . . . . . . . . . 4 4. Problems found . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - Normative References . . . . . . . . . . . . . . . . . . . . . 4 + 6. Normative References . . . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4 A. Test zone data . . . . . . . . . . . . . . . . . . . . . . . . 5 Intellectual Property and Copyright Statements . . . . . . . . 6 @@ -107,26 +105,26 @@ Table of Contents -Schlyter Expires February 22, 2005 [Page 2] +Schlyter Expires November 20, 2005 [Page 2] -Internet-Draft RFC 3597 Interoperability Report August 2004 +Internet-Draft RFC 3597 Interoperability Report May 2005 -1. Introduction +1. Introduction This memo documents the result from the RFC 3597 (Handling of Unknown DNS Resource Record Types) interoperability testing. The test was performed during June and July 2004 by request of the IETF DNS Extensions Working Group. -2. Implementations +2. Implementations - The following is a list, in alphabetic order, of implementations for - compliance of RFC 3597: + The following is a list, in alphabetic order, of implementations + tested for compliance with RFC 3597: DNSJava 1.6.4 - ISC BIND 8.4.5rc4 - ISC BIND 9.3.0rc2 + ISC BIND 8.4.5 + ISC BIND 9.3.0 NSD 2.1.1 Net::DNS 0.47 patchlevel 1 Nominum ANS 2.2.1.0.d @@ -139,43 +137,51 @@ Internet-Draft RFC 3597 Interoperability Report August 2004 Stub Resolver (4) DNSSEC Zone Signers (2) -3. Tests + All listed implementations are genetically different. -3.1 Authoritative Primary Name Server +3. Tests + + The following tests was been performed to validate compliance with + RFC 3597 section 3 ("Transparency"), 4 ("Domain Name Compression") + and 5 ("Text Representation"). + +3.1 Authoritative Primary Name Server The test zone data (Appendix A) was loaded into the name server implementation and the server was queried for the loaded information. -3.2 Authoritative Secondary Name Server +3.2 Authoritative Secondary Name Server The test zone data (Appendix A) was transferred using AXFR from another name server implementation and the server was queried for the transferred information. -3.3 Full Recursive Resolver + + + + + +Schlyter Expires November 20, 2005 [Page 3] + +Internet-Draft RFC 3597 Interoperability Report May 2005 + + +3.3 Full Recursive Resolver A recursive resolver was queried for resource records from a domain with the test zone data (Appendix A). -3.4 Stub Resolver +3.4 Stub Resolver A stub resolver was used to query resource records from a domain with - - - -Schlyter Expires February 22, 2005 [Page 3] - -Internet-Draft RFC 3597 Interoperability Report August 2004 - - the test zone data (Appendix A). -3.5 DNSSEC Signer +3.5 DNSSEC Signer - A DNSSEC signer was used to sign a zone with test zone data (Appendix - A). + A DNSSEC signer was used to sign a zone with test zone data + (Appendix A). -4. Problems found +4. Problems found Two implementations had problems with text presentation of zero length RDATA. @@ -185,14 +191,14 @@ Internet-Draft RFC 3597 Interoperability Report August 2004 Bug reports were filed for problems found. -5. Summary +5. Summary Unknown type codes works in the tested authoritative servers, recursive resolvers and stub clients. No changes are needed to advance RFC 3597 to draft standard. -Normative References +6. Normative References [1] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. @@ -202,7 +208,7 @@ Author's Address Jakob Schlyter - EMail: jakob@rfc.se + Email: jakob@rfc.se @@ -211,20 +217,12 @@ Author's Address +Schlyter Expires November 20, 2005 [Page 4] + +Internet-Draft RFC 3597 Interoperability Report May 2005 - - - - - - -Schlyter Expires February 22, 2005 [Page 4] - -Internet-Draft RFC 3597 Interoperability Report August 2004 - - -Appendix A. Test zone data +Appendix A. Test zone data ; A-record encoded as TYPE1 a TYPE1 \# 4 7f000001 @@ -275,9 +273,9 @@ Appendix A. Test zone data -Schlyter Expires February 22, 2005 [Page 5] +Schlyter Expires November 20, 2005 [Page 5] -Internet-Draft RFC 3597 Interoperability Report August 2004 +Internet-Draft RFC 3597 Interoperability Report May 2005 Intellectual Property Statement @@ -287,9 +285,9 @@ Intellectual Property Statement pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the IETF's procedures with respect to rights in IETF Documents can - be found in BCP 78 and BCP 79. + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an @@ -301,7 +299,7 @@ Intellectual Property Statement The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at + this standard. Please address the information to the IETF at ietf-ipr@ietf.org. @@ -318,7 +316,7 @@ Disclaimer of Validity Copyright Statement - Copyright (C) The Internet Society (2004). This document is subject + Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. @@ -331,5 +329,6 @@ Acknowledgment -Schlyter Expires February 22, 2005 [Page 6] +Schlyter Expires November 20, 2005 [Page 6] + diff --git a/doc/draft/draft-ietf-dnsext-mdns-41.txt b/doc/draft/draft-ietf-dnsext-mdns-43.txt similarity index 79% rename from doc/draft/draft-ietf-dnsext-mdns-41.txt rename to doc/draft/draft-ietf-dnsext-mdns-43.txt index a4d1d9ae25..5de6e85ecf 100644 --- a/doc/draft/draft-ietf-dnsext-mdns-41.txt +++ b/doc/draft/draft-ietf-dnsext-mdns-43.txt @@ -7,8 +7,8 @@ DNSEXT Working Group Bernard Aboba INTERNET-DRAFT Dave Thaler Category: Standards Track Levon Esibov - Microsoft -15 July 2005 + Microsoft Corporation +29 August 2005 Linklocal Multicast Name Resolution (LLMNR) @@ -35,7 +35,7 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on January 22, 2006. + This Internet-Draft will expire on March 15, 2006. Copyright Notice @@ -61,7 +61,7 @@ Aboba, Thaler & Esibov Standards Track [Page 1] -INTERNET-DRAFT LLMNR 15 July 2005 +INTERNET-DRAFT LLMNR 29 August 2005 Table of Contents @@ -72,35 +72,35 @@ Table of Contents 2. Name Resolution Using LLMNR ........................... 4 2.1 LLMNR Packet Format ............................. 6 2.2 Sender Behavior ................................. 9 - 2.3 Responder Behavior .............................. 9 - 2.4 Unicast Queries ................................. 11 - 2.5 Off-link Detection .............................. 12 + 2.3 Responder Behavior .............................. 10 + 2.4 Unicast Queries and Responses ................... 12 + 2.5 Off-link Detection .............................. 13 2.6 Responder Responsibilities ...................... 13 - 2.7 Retransmission and Jitter ....................... 13 + 2.7 Retransmission and Jitter ....................... 14 2.8 DNS TTL ......................................... 15 2.9 Use of the Authority and Additional Sections .... 15 -3. Usage model ........................................... 15 - 3.1 LLMNR Configuration ............................. 16 +3. Usage model ........................................... 16 + 3.1 LLMNR Configuration ............................. 17 4. Conflict Resolution ................................... 18 - 4.1 Uniqueness Verification ......................... 18 - 4.2 Conflict Detection and Defense .................. 19 - 4.3 Considerations for Multiple Interfaces .......... 20 - 4.4 API issues ...................................... 21 + 4.1 Uniqueness Verification ......................... 19 + 4.2 Conflict Detection and Defense .................. 20 + 4.3 Considerations for Multiple Interfaces .......... 21 + 4.4 API issues ...................................... 22 5. Security Considerations ............................... 22 - 5.1 Scope Restriction ............................... 22 - 5.2 Usage Restriction ............................... 23 - 5.3 Cache and Port Separation ....................... 24 - 5.4 Authentication .................................. 24 -6. IANA considerations ................................... 24 -7. Constants ............................................. 24 + 5.1 Denial of Service ............................... 23 + 5.2 Spoofing ...............,........................ 23 + 5.3 Authentication .................................. 24 + 5.4 Cache and Port Separation ....................... 25 +6. IANA considerations ................................... 25 +7. Constants ............................................. 25 8. References ............................................ 25 8.1 Normative References ............................ 25 - 8.2 Informative References .......................... 25 + 8.2 Informative References .......................... 26 Acknowledgments .............................................. 27 -Authors' Addresses ........................................... 27 -Intellectual Property Statement .............................. 27 -Disclaimer of Validity ....................................... 28 -Copyright Statement .......................................... 28 +Authors' Addresses ........................................... 28 +Intellectual Property Statement .............................. 28 +Disclaimer of Validity ....................................... 29 +Copyright Statement .......................................... 29 @@ -121,7 +121,7 @@ Aboba, Thaler & Esibov Standards Track [Page 2] -INTERNET-DRAFT LLMNR 15 July 2005 +INTERNET-DRAFT LLMNR 29 August 2005 1. Introduction @@ -181,7 +181,7 @@ Aboba, Thaler & Esibov Standards Track [Page 3] -INTERNET-DRAFT LLMNR 15 July 2005 +INTERNET-DRAFT LLMNR 29 August 2005 1.1. Requirements @@ -241,7 +241,7 @@ Aboba, Thaler & Esibov Standards Track [Page 4] -INTERNET-DRAFT LLMNR 15 July 2005 +INTERNET-DRAFT LLMNR 29 August 2005 to which a sender sends all queries, is FF02:0:0:0:0:0:1:3. @@ -263,35 +263,35 @@ INTERNET-DRAFT LLMNR 15 July 2005 be enabled by default, so that hosts will neither listen on the link- scope multicast address, nor will they send queries to that address. - An LLMNR sender may send a request for any name. However, by - default, LLMNR requests SHOULD be sent only when one of the following + By default, LLMNR queries MAY be sent only when one of the following conditions are met: [1] No manual or automatic DNS configuration has been performed. If DNS server address(es) have been configured, then LLMNR SHOULD NOT be used as the primary name resolution mechanism, although it MAY be used as a secondary name resolution - mechanism. For dual stack hosts configured with DNS server - address(es) for one protocol but not another, this implies - that DNS queries SHOULD be sent over the protocol configured - with a DNS server, prior to sending LLMNR queries. + mechanism. A dual stack host SHOULD attempt to reach DNS + servers overall protocols on which DNS server address(es) are + configured, prior to sending LLMNR queries. For dual stack + hosts configured with DNS server address(es) for one protocol + but not another, this inplies that DNS queries SHOULD be sent + over the protocol configured with a DNS server, prior to + sending LLMNR queries. [2] All attempts to resolve the name via DNS on all interfaces have failed after exhausting the searchlist. This can occur because DNS servers did not respond, or because they responded to DNS queries with RCODE=3 (Authoritative Name - Error) or RCODE=0, and an empty answer section. A dual - stack host SHOULD attempt to reach DNS servers over all - protocols on which DNS server address(es) are configured, - prior to use of LLMNR. + Error) or RCODE=0, and an empty answer section. Where a + single resolver call generates DNS queries for A and AAAA RRs, + an implementation MAY choose not to send LLMNR queries if any + of the DNS queries is successful. An LLMNR query SHOULD only + be sent for the originally requested name; a searchlist + is not used to form additional LLMNR queries. - A typical sequence of events for LLMNR usage is as follows: - - [a] DNS servers are not configured or attempts to resolve the - name via DNS have failed, after exhausting the searchlist. - - [b] An LLMNR sender sends an LLMNR query to the link-scope - multicast address(es) defined in Section 2, unless a + While these conditions are necessary for sending an LLMNR query, they + are not sufficient. While an LLMNR sender MAY send a query for any + name, it also MAY impose additional conditions on sending LLMNR @@ -301,11 +301,23 @@ Aboba, Thaler & Esibov Standards Track [Page 5] -INTERNET-DRAFT LLMNR 15 July 2005 +INTERNET-DRAFT LLMNR 29 August 2005 - unicast query is indicated. A sender SHOULD send LLMNR - queries for PTR RRs via unicast, as specified in Section 2.4. + queries. For example, a sender configured with a DNS server MAY send + LLMNR queries only for unqualified names and for fully qualified + domain names within configured zones. + + A typical sequence of events for LLMNR usage is as follows: + + [a] DNS servers are not configured or attempts to resolve the + name via DNS have failed, after exhausting the searchlist. + Also, the name to be queried satisfies the restrictions + imposed by the implementation. + + [b] An LLMNR sender sends an LLMNR query to the link-scope + multicast address(es), unless a unicast query is indicated, + as specified in Section 2.4. [c] A responder responds to this query only if it is authoritative for the domain name in the query. A responder responds to a @@ -314,8 +326,8 @@ INTERNET-DRAFT LLMNR 15 July 2005 [d] Upon reception of the response, the sender processes it. - Further details of sender and responder behavior are provided in the - sections that follow. + The sections that follow provide further details on sender and + responder behavior. 2.1. LLMNR Packet Format @@ -333,6 +345,25 @@ INTERNET-DRAFT LLMNR 15 July 2005 LLMNR queries and responses utilize the DNS header format defined in [RFC1035] with exceptions noted below: + + + + + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 6] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ @@ -351,19 +382,6 @@ INTERNET-DRAFT LLMNR 15 July 2005 where: - - - - -Aboba, Thaler & Esibov Standards Track [Page 6] - - - - - -INTERNET-DRAFT LLMNR 15 July 2005 - - ID A 16 bit identifier assigned by the program that generates any kind of query. This identifier is copied from the query to the response and can be used by the sender to match responses to outstanding @@ -393,6 +411,19 @@ C Conflict. When set within a request, the 'C'onflict bit indicates respond to LLMNR queries with the 'C' bit set, but may start the uniqueness verification process, as described in Section 4.2. + + + + +Aboba, Thaler & Esibov Standards Track [Page 7] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + TC TrunCation - specifies that this message was truncated due to length greater than that permitted on the transmission channel. The TC bit MUST NOT be set in an LLMNR query and if set is ignored @@ -404,25 +435,11 @@ TC TrunCation - specifies that this message was truncated due to T Tentative. The 'T'entative bit is set in a response if the responder is authoritative for the name, but has not yet verified - the uniqueness of one or more of the resource record(s) in the - answer section. A responder MUST ignore the 'T' bit in a query, if - set. If a uniqueness query elicits a response with the 'T' bit - set, a conflict has been detected and a responder MUST resolve the - conflict as described in Section 4.1. Otherwise, a response with - the 'T' bit set is silently discarded by the sender. - - - - - -Aboba, Thaler & Esibov Standards Track [Page 7] - - - - - -INTERNET-DRAFT LLMNR 15 July 2005 - + the uniqueness of the name. A responder MUST ignore the 'T' bit in + a query, if set. A response with the 'T' bit set is silently + discarded by the sender, except if it is a uniqueness query, in + which case a conflict has been detected and a responder MUST + resolve the conflict as described in Section 4.1. Z Reserved for future use. Implementations of this specification MUST set these bits to zero in both queries and responses. If @@ -455,6 +472,18 @@ RCODE with an RCODE of 3; instead, they should not respond at all. LLMNR implementations MUST support EDNS0 [RFC2671] and extended + + + +Aboba, Thaler & Esibov Standards Track [Page 8] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + RCODE values. QDCOUNT @@ -472,18 +501,6 @@ ANCOUNT NSCOUNT An unsigned 16 bit integer specifying the number of name server - - - -Aboba, Thaler & Esibov Standards Track [Page 8] - - - - - -INTERNET-DRAFT LLMNR 15 July 2005 - - resource records in the authority records section. Authority record section processing is described in Section 2.9. LLMNR responders MUST silently discard LLMNR queries with NSCOUNT not @@ -496,20 +513,43 @@ ARCOUNT 2.2. Sender Behavior - A sender may send an LLMNR query for any legal resource record type - (e.g., A, AAAA, SRV, etc.) to the link-scope multicast address. - - As described in Section 2.4, a sender may also send a unicast query. - Sections 2 and 3 describe the circumstances in which LLMNR queries - may be sent. + A sender MAY send an LLMNR query for any legal resource record type + (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address. + As described in Section 2.4, a sender MAY also send a unicast query. The sender MUST anticipate receiving no replies to some LLMNR queries, in the event that no responders are available within the - link-scope or in the event no positive non-null responses exist for - the transmitted query. If no positive response is received, a - resolver treats it as a response that no records of the specified - type and class exist for the specified name (it is treated the same - as a response with RCODE=0 and an empty answer section). + link-scope. If no response is received, a resolver treats it as a + response that the name does not exist (RCODE=3 is returned). A + sender can handle duplicate responses by discarding responses with a + source IP address and ID field that duplicate a response already + received. + + When multiple valid LLMNR responses are received with the 'C' bit + set, they SHOULD be concatenated and treated in the same manner that + multiple RRs received from the same DNS server would be. However, + responses with the 'C' bit set SHOULD NOT be concatenated with + responses with the 'C' bit clear; instead, only the responses with + the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are + received along with error response(s), then the error responses are + + + +Aboba, Thaler & Esibov Standards Track [Page 9] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + + silently discarded. + + If error responses are received from both DNS and LLMNR, then the + lowest RCODE value should be returned. For example, if either DNS or + LLMNR receives a response with RCODE=0, then this should returned to + the caller. Since the responder may order the RRs in the response so as to indicate preference, the sender SHOULD preserve ordering in the @@ -532,18 +572,6 @@ ARCOUNT 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be authoritative for the following records: - - - -Aboba, Thaler & Esibov Standards Track [Page 9] - - - - - -INTERNET-DRAFT LLMNR 15 July 2005 - - host1. IN A 192.0.2.1 IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 @@ -563,6 +591,19 @@ INTERNET-DRAFT LLMNR 15 July 2005 In responding to queries: + + + + +Aboba, Thaler & Esibov Standards Track [Page 10] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + [a] Responders MUST listen on UDP port 5355 on the link-scope multicast address(es) defined in Section 2, and on UDP and TCP port 5355 on the unicast address(es) that could be set as the source address(es) @@ -593,18 +634,7 @@ INTERNET-DRAFT LLMNR 15 July 2005 servers also MUST NOT send LLMNR queries in order to resolve DNS queries. - - -Aboba, Thaler & Esibov Standards Track [Page 10] - - - - - -INTERNET-DRAFT LLMNR 15 July 2005 - - -[g] If a responder is authoritative for a name, it SHOULD respond with +[g] If a responder is authoritative for a name, it MUST respond with RCODE=0 and an empty answer section, if the type of query does not match a RR that the responder has. @@ -623,6 +653,17 @@ INTERNET-DRAFT LLMNR 15 July 2005 conventional DNS terminology, an LLMNR responder is authoritative only for the zone apex. + + +Aboba, Thaler & Esibov Standards Track [Page 11] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + For example the host "foo.example.com." is not authoritative for the name "child.foo.example.com." unless the host is configured with multiple names, including "foo.example.com." and @@ -653,17 +694,6 @@ INTERNET-DRAFT LLMNR 15 July 2005 [a] A sender repeats a query after it received a response with the TC bit set to the previous LLMNR multicast query, or - - -Aboba, Thaler & Esibov Standards Track [Page 11] - - - - - -INTERNET-DRAFT LLMNR 15 July 2005 - - [b] The sender queries for a PTR RR of a fully formed IP address within the "in-addr.arpa" or "ip6.arpa" zones. @@ -681,6 +711,19 @@ INTERNET-DRAFT LLMNR 15 July 2005 treated the same as a response with RCODE=0 and an empty answer section). + + + + +Aboba, Thaler & Esibov Standards Track [Page 12] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + 2.5. "Off link" Detection A sender MUST select a source address for LLMNR queries that is @@ -713,17 +756,6 @@ INTERNET-DRAFT LLMNR 15 July 2005 Implementation note: - - -Aboba, Thaler & Esibov Standards Track [Page 12] - - - - - -INTERNET-DRAFT LLMNR 15 July 2005 - - In the sockets API for IPv4 [POSIX], the IP_TTL and IP_MULTICAST_TTL socket options are used to set the TTL of outgoing unicast and multicast packets. The IP_RECVTTL socket @@ -740,6 +772,18 @@ INTERNET-DRAFT LLMNR 15 July 2005 IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local addresses are defined in [RFC2373]. In particular: + + + +Aboba, Thaler & Esibov Standards Track [Page 13] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + [a] If a link-scope IPv6 address is returned in a AAAA RR, that address MUST be valid on the local link over which LLMNR is used. @@ -765,57 +809,46 @@ INTERNET-DRAFT LLMNR 15 July 2005 2.7. Retransmission and Jitter An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine - when to retransmit an LLMNR query. Rather than using a static - timeout, an LLMNR sender SHOULD dynamically compute the value of - LLMNR_TIMEOUT for each transmission, on a per-interface basis. - - For example, the algorithms described in RFC 2988 [RFC2988] compute - an RTO (including exponential backoff), which is used as the value of - LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO - - - -Aboba, Thaler & Esibov Standards Track [Page 13] - - - - - -INTERNET-DRAFT LLMNR 15 July 2005 - - - (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO - (discussed in Section 2 of [RFC2988], paragraph 2.4), and the - maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5). - Recommended values for constants (including LLMNR_TIMEOUT if it is - set statically) are given in Section 7. In order to take slow - responders into account, an LLMNR sender SHOULD include responses - received after LLMNR_TIMEOUT in the computations. + when to retransmit an LLMNR query. An LLMNR sender SHOULD either + estimate the LLMNR_TIMEOUT for each interface, or set a reasonably + high initial timeout. Suggested constants are described in Section + 7. If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, then a sender SHOULD repeat the transmission of the query in order to - assure that it was received by a host capable of responding to it. - Retransmission of UDP queries SHOULD NOT be attempted more than 3 - times. Where LLMNR queries are sent using TCP, retransmission is - handled by the transport layer. Queries with the 'C' bit set MUST be - sent over multicast UDP and MUST NOT be retransmitted. Responses to - queries with the 'C' bit set are not taken into account within - retransmission timeout computations. + assure that it was received by a host capable of responding to it, + while increasing the value of LLMNR_TIMEOUT exponentially. An LLMNR + query SHOULD NOT be sent more than three times. + + Where LLMNR queries are sent using TCP, retransmission is handled by + the transport layer. Queries with the 'C' bit set MUST be sent using + multicast UDP and MUST NOT be retransmitted. An LLMNR sender cannot know in advance if a query sent using multicast will receive no response, one response, or more than one - response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response + response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response has been received, or if it is necessary to collect all potential responses, such as if a uniqueness verification query is being made. Otherwise an LLMNR sender SHOULD consider a multicast query answered after the first response is received, if that response has the 'C' bit clear. + + +Aboba, Thaler & Esibov Standards Track [Page 14] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + However, if the first response has the 'C' bit set, then the sender SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses. When multiple valid answers are received, they may first be concatenated, and then treated in the same manner that multiple - RRs received from the same DNS server would. A unicast query sender + RRs received from the same DNS server would. A unicast query sender considers the query answered after the first response is received, so that it only waits for LLMNR_TIMEOUT if no response has been received. @@ -832,18 +865,6 @@ INTERNET-DRAFT LLMNR 15 July 2005 responders responding with names which they have previously determined to be UNIQUE (see Section 4 for details). - - - -Aboba, Thaler & Esibov Standards Track [Page 14] - - - - - -INTERNET-DRAFT LLMNR 15 July 2005 - - 2.8. DNS TTL The responder should insert a pre-configured TTL value in the records @@ -866,8 +887,25 @@ INTERNET-DRAFT LLMNR 15 July 2005 Responders SHOULD insert an SOA record into the authority section of a negative response, to facilitate negative caching as specified in - [RFC2308]. The owner name of this SOA record MUST be equal to the - query name. + [RFC2308]. The TTL of this record is set from the minimum of the + MINIMUM field of the SOA record and the TTL of the SOA itself, and + indicates how long a resolver may cache the negative answer. The + owner name of the SOA record (MNAME) MUST be set to the query name. + The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored + + + +Aboba, Thaler & Esibov Standards Track [Page 15] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + + by senders. Negative responses without SOA records SHOULD NOT be + cached. In LLMNR, the additional section is primarily intended for use by EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set, @@ -892,18 +930,6 @@ INTERNET-DRAFT LLMNR 15 July 2005 document does not specify any changes to DNS resolver behavior, such as searchlist processing or retransmission/failover policy. However, robust DNS resolver implementations are more likely to avoid - - - -Aboba, Thaler & Esibov Standards Track [Page 15] - - - - - -INTERNET-DRAFT LLMNR 15 July 2005 - - unnecessary LLMNR queries. As noted in [DNSPerf], even when DNS servers are configured, a @@ -926,6 +952,18 @@ INTERNET-DRAFT LLMNR 15 July 2005 policies are likely to avoid unnecessary LLMNR queries. [RFC1536] Section 3 describes zero answer bugs, which if addressed + + + +Aboba, Thaler & Esibov Standards Track [Page 16] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + will also reduce unnecessary LLMNR queries. [RFC1536] Section 6 describes name error bugs and recommended @@ -952,18 +990,6 @@ INTERNET-DRAFT LLMNR 15 July 2005 Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], IPv6-only hosts may not be configured with a DNS server. Where there - - - -Aboba, Thaler & Esibov Standards Track [Page 16] - - - - - -INTERNET-DRAFT LLMNR 15 July 2005 - - is no DNS server authoritative for the name of a host or the authoritative DNS server does not support dynamic client update over IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not @@ -986,6 +1012,18 @@ INTERNET-DRAFT LLMNR 15 July 2005 enables linklocal name resolution over IPv4. Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to + + + +Aboba, Thaler & Esibov Standards Track [Page 17] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + configure LLMNR on an interface. The LLMNR Enable Option, described in [LLMNREnable], can be used to explicitly enable or disable use of LLMNR on an interface. The LLMNR Enable Option does not determine @@ -1012,18 +1050,6 @@ INTERNET-DRAFT LLMNR 15 July 2005 LLMNR only enables linklocal name resolution, this represents a degradation in capabilities. As a result, hosts without a configured DNS server may wish to periodically attempt to obtain DNS - - - -Aboba, Thaler & Esibov Standards Track [Page 17] - - - - - -INTERNET-DRAFT LLMNR 15 July 2005 - - configuration if permitted by the configuration mechanism in use. In the absence of other guidance, a default retry interval of one (1) minute is RECOMMENDED. @@ -1043,6 +1069,21 @@ INTERNET-DRAFT LLMNR 15 July 2005 and potentially to intervene and reconfigure LLMNR responders who should not be configured to respond to the same name. + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 18] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + 4.1. Uniqueness Verification Prior to sending an LLMNR response with the 'T' bit clear, a @@ -1072,23 +1113,13 @@ INTERNET-DRAFT LLMNR 15 July 2005 queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify uniqueness of a name by sending a query for the name with type='ANY'. - - - -Aboba, Thaler & Esibov Standards Track [Page 18] - - - - - -INTERNET-DRAFT LLMNR 15 July 2005 - - If no response is received, the sender retransmits the query, as specified in Section 2.7. If a response is received, the sender MUST check if the source address matches the address of any of its interfaces; if so, then the response is not considered a conflict, - since it originates from the sender. + since it originates from the sender. To avoid triggering conflict + detection, a responder that detects that it is connected to the same + link on multiple interfaces SHOULD set the 'C' bit in responses. If a response is received with the 'T' bit clear, the responder MUST NOT use the name in response to LLMNR queries received over any @@ -1101,6 +1132,18 @@ INTERNET-DRAFT LLMNR 15 July 2005 the answer section in a response is irrelevant. Periodically carrying out uniqueness verification in an attempt to + + + +Aboba, Thaler & Esibov Standards Track [Page 19] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + detect name conflicts is not necessary, wastes network bandwidth, and may actually be detrimental. For example, if network links are joined only briefly, and are separated again before any new @@ -1128,22 +1171,15 @@ INTERNET-DRAFT LLMNR 15 July 2005 If the query is for a UNIQUE name, then the responder MUST send its own query for the same name, type and class, with the 'C' bit clear. - If a response is received, then a conflict has been detected. + If a response is received, the sender MUST check if the source + address matches the address of any of its interfaces; if so, then the + response is not considered a conflict, since it originates from the + sender. To avoid triggering conflict detection, a responder that + detects that it is connected to the same link on multiple interfaces + SHOULD set the 'C' bit in responses. An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD log them. Upon detecting a conflict, an LLMNR responder MUST - - - -Aboba, Thaler & Esibov Standards Track [Page 19] - - - - - -INTERNET-DRAFT LLMNR 15 July 2005 - - immediately stop using the conflicting name in response to LLMNR queries received over any supported protocol, if the source IP address in the response, interpreted as an unsigned integer, is less @@ -1157,6 +1193,17 @@ INTERNET-DRAFT LLMNR 15 July 2005 attempt uniqueness verification again after the expiration of the TTL of the conflicting response. + + +Aboba, Thaler & Esibov Standards Track [Page 20] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + 4.3. Considerations for Multiple Interfaces A multi-homed host may elect to configure LLMNR on only one of its @@ -1192,18 +1239,6 @@ INTERNET-DRAFT LLMNR 15 July 2005 result returned to the client is defined by the implementation. The situation is illustrated in figure 2. - - - -Aboba, Thaler & Esibov Standards Track [Page 20] - - - - - -INTERNET-DRAFT LLMNR 15 July 2005 - - ---------- ---------- | | | | [A] [myhost] [A] @@ -1217,6 +1252,18 @@ INTERNET-DRAFT LLMNR 15 July 2005 hosts on both interfaces. Host myhost cannot distinguish between the situation shown in Figure + + + +Aboba, Thaler & Esibov Standards Track [Page 21] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + 2, and that shown in Figure 3 where no conflict exists. [A] @@ -1252,66 +1299,19 @@ INTERNET-DRAFT LLMNR 15 July 2005 have a sin6_scope_id value that disambiguates which interface is used to reach the address. Of course, to the application, Figures 2 and 3 are still indistinguishable, but this API allows the application to - - - -Aboba, Thaler & Esibov Standards Track [Page 21] - - - - - -INTERNET-DRAFT LLMNR 15 July 2005 - - communicate successfully with any address in the list. 5. Security Considerations - LLMNR is by nature a peer-to-peer name resolution protocol. It is - therefore inherently more vulnerable than DNS, since existing DNS - security mechanisms are difficult to apply to LLMNR. While tools - exist to allow an attacker to spoof a response to a DNS query, - spoofing a response to an LLMNR query is easier since the query is - sent to a link-scope multicast address, where every host on the - logical link will be made aware of it. + LLMNR is a peer-to-peer name resolution protocol designed for use on + the local link. While LLMNR limits the vulnerability of responders + to off-link senders, it is possible for an off-link responder to + reach a sender. - In order to address the security vulnerabilities, the following - mechanisms are contemplated: - - [1] Scope restrictions. - [2] Usage restrictions. - [3] Cache and port separation. - [4] Authentication. - - These techniques are described in the following sections. - -5.1. Scope Restriction - - With LLMNR it is possible that hosts will allocate conflicting names - for a period of time, or that attackers will attempt to deny service - to other hosts by allocating the same name. Such attacks also allow - hosts to receive packets destined for other hosts. - - Since LLMNR is typically deployed in situations where no trust model - can be assumed, it is likely that LLMNR queries and responses will be - unauthenticated. In the absence of authentication, LLMNR reduces the - exposure to such threats by utilizing UDP queries sent to a link- - scope multicast address, as well as setting the TTL (IPv4) or Hop - Limit (IPv6) fields to one (1) on unicast queries and responses. - - Using a TTL of one (1) in order to send a unicast LLMNR query reduces - the likelihood of both denial of service attacks and spoofed - responses. Checking that an LLMNR query is sent to a link-scope - multicast address should prevent spoofing of multicast queries by - off-link attackers. - - While this limits the ability of off-link attackers to spoof LLMNR - queries and responses, it does not eliminate it. For example, it is - possible for an attacker to spoof a response to a query (such as an A - or AAAA query for a popular Internet host), and by using a TTL or Hop - Limit field larger than one (1), for the forged response to reach the - LLMNR sender. + In scenarios such as public "hotspots" attackers can be present on + the same link. These threats are most serious in wireless networks + such as 802.11, since attackers on a wired network will require + physical access to the network, while wireless attackers may mount @@ -1321,57 +1321,57 @@ Aboba, Thaler & Esibov Standards Track [Page 22] -INTERNET-DRAFT LLMNR 15 July 2005 +INTERNET-DRAFT LLMNR 29 August 2005 - When LLMNR queries are sent to a link-scope multicast address, it is + attacks from a distance. Link-layer security such as [IEEE-802.11i] + can be of assistance against these threats if it is available. + + This section details security measures available to mitigate threats + from on and off-link attackers. + +5.1. Denial of Service + + Attackers may take advantage of LLMNR conflict detection by + allocating the same name, denying service to other LLMNR responders + and possibly allowing an attacker to receive packets destined for + other hosts. By logging conflicts, LLMNR responders can provide + forensic evidence of these attacks. + + An attacker may spoof LLMNR queries from a victim's address in order + to mount a denial of service attack. Responders setting the IPv6 Hop + Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP + response may be able to reach the victim across the Internet. + + While LLMNR responders only respond to queries for which they are + authoritative and LLMNR does not provide wildcard query support, an + LLMNR response may be larger than the query, and an attacker can + generate multiple responses to a query for a name used by multiple + responders. A sender may protect itself against unsolicited + responses by silently discarding them as rapidly as possible. + +5.2. Spoofing + + LLMNR is designed to prevent reception of queries sent by an off-link + attacker. LLMNR requires that responders receiving UDP queries check + that they are sent to a link-scope multicast address. However, it is possible that some routers may not properly implement link-scope multicast, or that link-scope multicast addresses may leak into the - multicast routing system. - - Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than - one in an LLMNR UDP response may enable denial of service attacks - across the Internet. However, since LLMNR responders only respond to - queries for which they are authoritative, and LLMNR does not provide - wildcard query support, it is believed that this threat is minimal. - - There also are scenarios such as public "hotspots" where attackers - can be present on the same link. These threats are most serious in - wireless networks such as 802.11, since attackers on a wired network - will require physical access to the home network, while wireless - attackers may reside outside the home. Link-layer security can be of - assistance against these threats if it is available. - -5.2. Usage Restriction - - As noted in Sections 2 and 3, LLMNR is intended for usage in a - limited set of scenarios. - - Since an LLMNR query can be sent when DNS server(s) do not respond, - an attacker can execute a denial of service attack on the DNS - server(s) and then poison the LLMNR cache by responding to an LLMNR - query with incorrect information. To some extent, these - vulnerabilities exist today, since DNS response spoofing tools are - available that can allow an attacker to respond to a query more - quickly than a distant DNS server. - - Since LLMNR queries are sent and responded to on the local-link, an - attacker will need to respond more quickly to provide its own - response prior to arrival of the response from a legitimate - responder. If an LLMNR query is sent for an off-link host, spoofing - a response in a timely way is not difficult, since a legitimate - response will never be received. - - The vulnerability is more serious if LLMNR is given higher priority - than DNS among the enabled name resolution mechanisms. In such a - configuration, a denial of service attack on the DNS server would not - be necessary in order to poison the LLMNR cache, since LLMNR queries - would be sent even when the DNS server is available. In addition, - the LLMNR cache, once poisoned, would take precedence over the DNS - cache, eliminating the benefits of cache separation. As a result, - LLMNR is only used as a name resolution mechanism of last resort. + multicast routing system. To prevent successful setup of TCP + connections by an off-link sender, responders receiving a TCP SYN + reply with a TCP SYN-ACK with TTL set to one (1). + While it is difficult for an off-link attacker to send an LLMNR query + to a responder, it is possible for an off-link attacker to spoof a + response to a query (such as an A or AAAA query for a popular + Internet host), and by using a TTL or Hop Limit field larger than one + (1), for the forged response to reach the LLMNR sender. Since the + forged response will only be accepted if it contains a matching ID + field, choosing a pseudo-random ID field within queries provides some + protection against off-link responders. + Since LLMNR queries can be sent when DNS server(s) do not respond, an + attacker can execute a denial of service attack on the DNS server(s) @@ -1381,10 +1381,79 @@ Aboba, Thaler & Esibov Standards Track [Page 23] -INTERNET-DRAFT LLMNR 15 July 2005 +INTERNET-DRAFT LLMNR 29 August 2005 -5.3. Cache and Port Separation + and then poison the LLMNR cache by responding to an LLMNR query with + incorrect information. As noted in "Threat Analysis of the Domain + Name System (DNS)" [RFC3833] these threats also exist with DNS, since + DNS response spoofing tools are available that can allow an attacker + to respond to a query more quickly than a distant DNS server. + However, while switched networks or link layer security may make it + difficult for an on-link attacker to snoop unicast DNS queries, + multicast LLMNR queries are propagated to all hosts on the link, + making it possible for an on-link attacker to spoof LLMNR responses + without having to guess the value of the ID field in the query. + + Since LLMNR queries are sent and responded to on the local-link, an + attacker will need to respond more quickly to provide its own + response prior to arrival of the response from a legitimate + responder. If an LLMNR query is sent for an off-link host, spoofing + a response in a timely way is not difficult, since a legitimate + response will never be received. + + Limiting the situations in which LLMNR queries are sent, as described + in Section 2, is the best protection against these attacks. If LLMNR + is given higher priority than DNS among the enabled name resolution + mechanisms, a denial of service attack on the DNS server would not be + necessary in order to poison the LLMNR cache, since LLMNR queries + would be sent even when the DNS server is available. In addition, + the LLMNR cache, once poisoned, would take precedence over the DNS + cache, eliminating the benefits of cache separation. As a result, + LLMNR is only used as a name resolution mechanism of last resort. + +5.3. Authentication + + LLMNR is a peer-to-peer name resolution protocol, and as a result, + it is often deployed in situations where no trust model can be + assumed. This makes it difficult to apply existing DNS security + mechanisms to LLMNR. + + LLMNR does not support "delegated trust" (CD or AD bits). As a + result, unless LLMNR senders are DNSSEC aware, it is not feasible to + use DNSSEC [RFC4033] with LLMNR. + + If authentication is desired, and a pre-arranged security + configuration is possible, then the following security mechanisms may + be used: + +[a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0) + [RFC2931] security mechanisms. "DNS Name Service based on Secure + Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes + the use of TSIG to secure LLMNR responses, based on group keys. + + + + +Aboba, Thaler & Esibov Standards Track [Page 24] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + + +[b] IPsec ESP with a null-transform MAY be used to authenticate unicast + LLMNR queries and responses or LLMNR responses to multicast + queries. In a small network without a certificate authority, this + can be most easily accomplished through configuration of a group + pre-shared key for trusted hosts. + + Where these mechanisms cannot be supported, responses to LLMNR + queries may be unauthenticated. + +5.4. Cache and Port Separation In order to prevent responses to LLMNR queries from polluting the DNS cache, LLMNR implementations MUST use a distinct, isolated cache for @@ -1396,22 +1465,6 @@ INTERNET-DRAFT LLMNR 15 July 2005 LLMNR operates on a separate port from DNS, reducing the likelihood that a DNS server will unintentionally respond to an LLMNR query. -5.4. Authentication - - Since LLMNR does not support "delegated trust" (CD or AD bits), and - LLMNR senders are unlikely to be DNSSEC-aware, in practice LLMNR is - not compatible with DNSSEC. - - LLMNR implementations MAY support TSIG and/or SIG(0) security - mechanisms; where this is not supported, responses to LLMNR queries - may be unauthenticated. If authentication is desired, and a pre- - arranged security configuration is possible, then IPsec ESP with a - null-transform MAY be used to authenticate unicast LLMNR queries and - responses or LLMNR responses to multicast queries. In a small - network without a certificate authority, this can be most easily - accomplished through configuration of a group pre-shared key for - trusted hosts. - 6. IANA Considerations This specification creates one new name space: the reserved bits in @@ -1430,22 +1483,8 @@ INTERNET-DRAFT LLMNR 15 July 2005 not intended to be user configurable. JITTER_INTERVAL 100 ms - LLMNR_TIMEOUT 1 second (if set statically) - RTOinit 500 ms (initial value of LLMNR_TIMEOUT) - - - -Aboba, Thaler & Esibov Standards Track [Page 24] - - - - - -INTERNET-DRAFT LLMNR 15 July 2005 - - - RTOmax 5 seconds (maximum value of LLMNR_TIMEOUT) - RTOmin 100 ms (minimum value of LLMNR_TIMEOUT) + LLMNR_TIMEOUT 1 second (if set statically on all interfaces) + 100 ms (IEEE 802 media, including IEEE 802.11) 8. References @@ -1454,8 +1493,16 @@ INTERNET-DRAFT LLMNR 15 July 2005 [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987. -[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, - April 1992. + + +Aboba, Thaler & Esibov Standards Track [Page 25] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -1466,9 +1513,6 @@ INTERNET-DRAFT LLMNR 15 July 2005 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. -[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC - 2365, July 1998. - [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. @@ -1476,59 +1520,21 @@ INTERNET-DRAFT LLMNR 15 July 2005 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. -[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. -[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission - Timer", RFC 2988, November 2000. +[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + +[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures + (SIG(0)s)", RFC 2931, September 2000. 8.2. Informative References -[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested - Fixes", RFC 1536, October 1993. - -[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness - Recommendations for Security", RFC 1750, December 1994. - - - -Aboba, Thaler & Esibov Standards Track [Page 25] - - - - - -INTERNET-DRAFT LLMNR 15 July 2005 - - -[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, - March 1997. - -[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - -[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", - RFC 2292, February 1998. - -[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic - Socket Interface Extensions for IPv6", RFC 2553, March 1999. - -[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC - 2937, September 2000. - -[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for - IPv6 (DHCPv6)", RFC 3315, July 2003. - -[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration - of Link-Local IPv4 Addresses", RFC 3927, October 2004. - [Bonjour] Cheshire, S. and M. Krochmal, "Multicast DNS", Internet draft - (work in progress), draft-cheshire-dnsext-multicastdns-04.txt, - February 2004. + (work in progress), draft-cheshire-dnsext-multicastdns-05.txt, + June 2005. [DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of Caching", IEEE/ACM Transactions on Networking, Volume 10, @@ -1539,19 +1545,13 @@ INTERNET-DRAFT LLMNR 15 July 2005 Internet draft (work in progress), draft-ietf-ipv6-dns- discovery-07.txt, October 2002. -[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- - Portable Operating System Interface (POSIX). Open Group - Technical Standard: Base Specifications, Issue 6, December - 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin - -[LLMNREnable] - Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work - in progress), draft-guttman-mdns-enable-02.txt, April 2002. - -[NodeInfo] - Crawford, M., "IPv6 Node Information Queries", Internet draft - (work in progress), draft-ietf-ipn-gwg-icmp-name- - lookups-09.txt, May 2002. +[IEEE-802.11i] + Institute of Electrical and Electronics Engineers, "Supplement + to Standard for Telecommunications and Information Exchange + Between Systems - LAN/MAN Specific Requirements - Part 11: + Wireless LAN Medium Access Control (MAC) and Physical Layer + (PHY) Specifications: Specification for Enhanced Security", + IEEE 802.11i, July 2004. @@ -1561,7 +1561,67 @@ Aboba, Thaler & Esibov Standards Track [Page 26] -INTERNET-DRAFT LLMNR 15 July 2005 +INTERNET-DRAFT LLMNR 29 August 2005 + + +[LLMNREnable] + Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work + in progress), draft-guttman-mdns-enable-02.txt, April 2002. + +[LLMNRSec] + Jeong, J., Park, J. and H. Kim, "DNS Name Service based on + Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT + 2004, Phoenix Park, Korea, February 9-11, 2004. + +[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- + Portable Operating System Interface (POSIX). Open Group + Technical Standard: Base Specifications, Issue 6, December + 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin + +[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested + Fixes", RFC 1536, October 1993. + +[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1994. + +[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + +[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", + RFC 2292, February 1998. + +[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC + 2365, July 1998. + +[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic + Socket Interface Extensions for IPv6", RFC 2553, March 1999. + +[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC + 2937, September 2000. + +[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + +[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name + System (DNS)", RFC 3833, August 2004. + +[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration + of Link-Local IPv4 Addresses", RFC 3927, October 2004. + +[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "DNS Security Introduction and Requirement", RFC 4033, March + 2005. + + + + +Aboba, Thaler & Esibov Standards Track [Page 27] + + + + + +INTERNET-DRAFT LLMNR 29 August 2005 Acknowledgments @@ -1615,13 +1675,13 @@ Intellectual Property Statement -Aboba, Thaler & Esibov Standards Track [Page 27] +Aboba, Thaler & Esibov Standards Track [Page 28] -INTERNET-DRAFT LLMNR 15 July 2005 +INTERNET-DRAFT LLMNR 29 August 2005 Copies of IPR disclosures made to the IETF Secretariat and any @@ -1675,7 +1735,6 @@ Open Issues -Aboba, Thaler & Esibov Standards Track [Page 28] - +Aboba, Thaler & Esibov Standards Track [Page 29] diff --git a/doc/draft/draft-ietf-dnsext-nsec3-01.txt b/doc/draft/draft-ietf-dnsext-nsec3-01.txt deleted file mode 100644 index 10d8118412..0000000000 --- a/doc/draft/draft-ietf-dnsext-nsec3-01.txt +++ /dev/null @@ -1,1009 +0,0 @@ - - -Network Working Group B. Laurie -Internet-Draft G. Sisson -Expires: August 2, 2005 Nominet - R. Arends - Telematica Instituut - february 2005 - - - DNSSEC Hash Authenticated Denial of Existence - draft-ietf-dnsext-nsec3-01 - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 2, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be - used to provide authenticated denial of existence of DNS ownernames - and types; however, it permits any user to traverse a zone and obtain - a listing of all ownernames. - - - - -Laurie, et al. Expires August 2, 2005 [Page 1] - -Internet-Draft nsec3 february 2005 - - - A complete zone file can be used either directly as a source of - probable e-mail addresses for spam, or indirectly as a key for - multiple WHOIS queries to reveal registrant data which many - registries (particularly in Europe) may be under strict legal - obligations to protect. Many registries therefore prohibit copying - of their zone file; however the use of NSEC RRs makes renders - policies unenforceable. - - This document proposes a scheme which obscures original ownernames - while permitting authenticated denial of existence of non-existent - names. Non-authoritative delegation point NS RR types may be - excluded. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 5 - 2.1 NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 5 - 2.1.1 The Authoritative Only Flag Field . . . . . . . . . . 6 - 2.1.2 The Hash Function Field . . . . . . . . . . . . . . . 6 - 2.1.3 The Iterations Field . . . . . . . . . . . . . . . . . 6 - 2.1.4 The Salt Length Field . . . . . . . . . . . . . . . . 6 - 2.1.5 The Salt Field . . . . . . . . . . . . . . . . . . . . 6 - 2.1.6 The Next Hashed Ownername Field . . . . . . . . . . . 7 - 2.1.7 The list of Type Bit Map(s) Field . . . . . . . . . . 7 - 2.2 The NSEC3 RR Presentation Format . . . . . . . . . . . . . 8 - 3. Creating Additional NSEC3 RR for Empty Non Terminals . . . . . 9 - 4. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 9 - 5. Including NSEC3 RRs in a Zone . . . . . . . . . . . . . . . . 9 - 6. Special Considerations . . . . . . . . . . . . . . . . . . . . 10 - 6.1 delegation points . . . . . . . . . . . . . . . . . . . . 10 - 6.1.1 Unsigned Delegations . . . . . . . . . . . . . . . . . 11 - 6.2 Additional Complexity Caused by Wildcards . . . . . . . . 11 - 6.3 Salting . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 6.4 Hash Collision . . . . . . . . . . . . . . . . . . . . . . 12 - 6.4.1 Avoiding Hash Collisions during generation . . . . . . 12 - 6.4.2 Second Preimage Requirement Analysis . . . . . . . . . 12 - 6.4.3 Possible Hash Value Truncation Method . . . . . . . . 13 - 7. Performance Considerations . . . . . . . . . . . . . . . . . . 13 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 10. Requirements notation . . . . . . . . . . . . . . . . . . . 14 - 11. Security Considerations . . . . . . . . . . . . . . . . . . 14 - A. Example Zone . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 - - - -Laurie, et al. Expires August 2, 2005 [Page 2] - -Internet-Draft nsec3 february 2005 - - - 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 - 12.2 Informative References . . . . . . . . . . . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 - Intellectual Property and Copyright Statements . . . . . . . . 18 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires August 2, 2005 [Page 3] - -Internet-Draft nsec3 february 2005 - - -1. Introduction - - The DNS Security Extensions (DNSSEC) introduced the NSEC Resource - Record (RR) for Authenticated Denial of Existence. This document - introduces a new RR as an alternative to NSEC that provides measures - against zone traversal and allows for gradual expansion of - delegation-centric zones. - -1.1 Rationale - - The DNS Security Extensions included the NSEC RR to provide - authenticated denial of existence. Though the NSEC RR meets the - requirements for authenticated denial of Existence, it introduced a - side-effect in that the contents of a zone can be enumerated. This - property introduces undesired policy issues. - - A second requirement was that the existence of all record types in a - zone -including delegation point NS record types- can be accounted - for, despite the fact that delegation point NS RRsets are not - authoritative and not signed. This requirement has a side-effect - that the overhead of delegation centric signed zones is not related - to the increase in security of subzones. This requirement does not - allow delegation centric zones size to grow in relation to the growth - of signed subzones. - - In the past, solutions have been proposed as a measure against these - side effects but at the time were regarded as secondary over the need - to have a stable DNSSEC specification. With (draft-vixie-dnssec-ter) - a graceful transition path to future enhancements is introduced, - while current DNSSEC deployment can continue. This document - accumulates measures against the side effects introduced by NSEC, and - presents the NSEC3 Resource Record. - - The reader is assumed to be familiar with the basic DNS concepts - described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs - that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308 - [RFC2308]. - -1.2 Reserved Words - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - -1.3 Terminology - - In this document the term "original ownername" refers to a standard - ownername. Because this proposal uses the result of a hash function - - - -Laurie, et al. Expires August 2, 2005 [Page 4] - -Internet-Draft nsec3 february 2005 - - - over the original (unmodified) ownername, this result is referred to - as "hashed ownername". - -2. The NSEC3 Resource Record - - The NSEC3 RR provides Authenticated Denial of Existence for DNS - Resource Record Sets. - - The NSEC3 Resource Record lists RR types present at the NSEC3 RR's - original ownername. It includes the next hashed ownername in the - canonical ordering of the zone. The complete set of NSEC3 RRs in a - zone indicates which RRsets exist for the original ownername of the - RRset and form a chain of hashed ownernames in the zone. This - information is used to provide authenticated denial of existence for - DNS data, as described in RFC 2535 [RFC2535]. Unsigned delegation - point NS RR sets can optionally be excluded. To provide protection - against zone traversal, the ownernames used in the NSEC3 RR are - cryptographic hash-value prepended to the name of the zone. The - NSEC3 RR record indicates which Hash Function is used to construct to - hash, which Salt is used, and how many iterations of the Hash - Function are performed over the original ownername. - - The type value for the NSEC3 RR is XX. - - The NSEC3 RR RDATA format is class independent. - - The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL - field. This is in the spirit of negative caching [RFC2308]. - -2.1 NSEC3 RDATA Wire Format - - The RDATA of the NSEC3 RR is as shown below: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |A|Hash Function| Iterations | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Salt Length | Salt / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Next Hashed Ownername / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Type Bit Maps / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - -Laurie, et al. Expires August 2, 2005 [Page 5] - -Internet-Draft nsec3 february 2005 - - -2.1.1 The Authoritative Only Flag Field - - The Authoritative Only Flag field indicates whether the Type Bit Maps - include delegation point NS record types. - - If the flag is set to 1, the NS RR type bit for a delegation point - ownername SHOULD be clear when the NSEC3 RR is generated. The NS RR - type bit MUST be ignored during processing of the NSEC3 RR. The NS - RR type bit has no meaning in this context (it is not authoritative), - hence the NSEC3 does not contest the existence of a NS RR type record - for this ownername. When a delegation is not secured, there exist no - DS RR type nor any other authoritative types for this delegation, - hence the unsecured delegation has no NSEC3 record associated. - Please see the Special Consideration section for implications for - unsigned delegations. - - If the flag is set to 0, the NS RR type bit for a delegation point - ownername MUST be set if the NSEC3 covers a delegation, even though - the NS RR itself is not authoritative. This implies that all - delegations, signed or unsigned, have an NSEC3 record associated. - This behaviour is identical to NSEC behaviour. - -2.1.2 The Hash Function Field - - The Hash Function field identifies the cryptographic hash function - used to construct the hash-value. - - This document defines Value 1 for SHA-1 and Value 127 for - Experimental. All other values are reserved. - - On reception, a resolver MUST discard an NSEC3 RR with an unknown - Hash Function value. - -2.1.3 The Iterations Field - - The Iterations field defines the number of times the hash has been - iterated. More iterations results in greater resiliency of the hash - value against dictionary attacks, but at a higher cost for both the - server and resolver. - -2.1.4 The Salt Length Field - - The Salt Length Field defines the length of the salt in octets. - -2.1.5 The Salt Field - - The salt field is not present when the Salt Length Field has a value - of 0. - - - -Laurie, et al. Expires August 2, 2005 [Page 6] - -Internet-Draft nsec3 february 2005 - - - The salt field is prepended to the original ownername before hashing - in order to defend against precalculated dictionary attacks. - - The salt is not prepended during iterations of the hash function. - - The Salt field value MUST be identical for all NSEC3 RRs generated - for the zone. If the salt were different for each NSEC3 RR, - collisions could occur where an NSEC3 denies the existence of - existing RRs due to the application of different salt values. - -2.1.6 The Next Hashed Ownername Field - - The Next Hashed Ownername Field contains the hash of the ownername of - the next RR in the canonical ordering of the hashed ownernames of the - zone. The value of the Next Hashed Ownername Field in the last NSEC3 - record in the zone is the same as the ownername of the first NSEC3 RR - in the zone in canonical order. - - A sender MUST NOT use DNS name compression on the Next Hashed - Ownername field when transmitting an NSEC3 RR. - - Hashed ownernames of RRsets not authoritative for the given zone - (such as glue records) MUST NOT be listed in the Hash of Next Domain - Name unless at least one authoritative RRset exists at the same owner - name. - -2.1.7 The list of Type Bit Map(s) Field - - The Type Bit Maps field identifies the RRset types which exist at the - NSEC3 RR's ownername. - - The Type bit for the NSEC3 and RRSIG MUST be set during generation, - and MUST be ignored during processing. - - The RR type space is split into 256 window blocks, each representing - the low-order 8 bits of the 16-bit RR type space. Each block that - has at least one active RR type is encoded using a single octet - window number (from 0 to 255), a single octet bitmap length (from 1 - to 32) indicating the number of octets used for the window block's - bitmap, and up to 32 octets (256 bits) of bitmap. - - Blocks are present in the NSEC3 RR RDATA in increasing numerical - order. - - "|" denotes concatenation - - Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + - - - - -Laurie, et al. Expires August 2, 2005 [Page 7] - -Internet-Draft nsec3 february 2005 - - - Each bitmap encodes the low-order 8 bits of RR types within the - window block, in network bit order. The first bit is bit 0. For - window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds - to RR type 2 (NS), and so forth. For window block 1, bit 1 - corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to - 1, it indicates that an RRset of that type is present for the NSEC3 - RR's ownername. If a bit is set to 0, it indicates that no RRset of - that type is present for the NSEC3 RR's ownername. - - The RR type 2 (NS) is authoritative at the apex of a zone and is not - authoritative at delegation points. If the Authoritative Only Flag - is set to 1, the delegation point NS RR type MUST NOT be included in - the type bit maps. If the Authoritative Only Flag is set to 0, the - NS RR type at a delegation point MUST be included in the type bit - maps. - - Since bit 0 in window block 0 refers to the non-existing RR type 0, - it MUST be set to 0. After verification, the validator MUST ignore - the value of bit 0 in window block 0. - - Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [4] - (section 3.1) or within the range reserved for assignment only to - QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in - zone data. If encountered, they must be ignored upon reading. - - Blocks with no types present MUST NOT be included. Trailing zero - octets in the bitmap MUST be omitted. The length of each block's - bitmap is determined by the type code with the largest numerical - value, within that block, among the set of RR types present at the - NSEC3 RR's actual ownername. Trailing zero octets not specified MUST - be interpreted as zero octets. - -2.2 The NSEC3 RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Authoritative Only Field is represented as an unsigned decimal - integer. The value are either 0 or 1. - - The Hash field is presented as the name of the hash or as an unsigned - decimal integer. The value has a maximum of 127. - - The Iterations field is presented as an unsigned decimal integer. - - The Salt Length field is not presented. - - The Salt field is represented as a sequence of case-insensitive - hexadecimal digits. Whitespace is not allowed within the sequence. - - - -Laurie, et al. Expires August 2, 2005 [Page 8] - -Internet-Draft nsec3 february 2005 - - - The Salt Field is represented as 00 when the Salt Length field has - value 0. - - The Hash of Next Domain Name field is represented as a sequence of - case-insensitive base32 digits. Whitespace is allowed within the - sequence. - - The List of Type Bit Map(s) Field is represented as a sequence of RR - type mnemonics. When the mnemonic is not known, the TYPE - representation as described in RFC 3597 [5] (section 5) MUST be used. - -3. Creating Additional NSEC3 RR for Empty Non Terminals - - In order to prove the non-existence of a record that might be covered - by a wildcard, it is necessary to prove the existence of its closest - encloser. A closest encloser might be an Empty Non Terminal. - - Additional NSEC3 RRs cover every existing intermediate label level. - Additional NSEC3 RRs are identical in format to NSEC3 RRs that cover - existing RRs in the zone. The difference is that the type-bit-maps - only indicate the existence of an NSEC3 RR and a RRSIG type. - -4. Calculation of the Hash - - Define H(x) to be the hash of x using the hash function selected by - the NSEC3 record and || to indicate concatenation. Then define: - - IH(salt,x,0)=H(x || salt) - - IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0 - - Then the calculated hash of an ownername is - IH(salt,ownername,iterations-1), where the ownername is the canonical - form. - - The canonical form of the ownername is the wire format of the - ownername where: - 1. The ownername is fully expanded (no DNS name compression) and - fully qualified; - 2. All uppercase US-ASCII letters are replaced by the corresponding - lowercase US-ASCII letters; - 3. If the ownername is a wildcard name, the ownername is in its - original unexpanded form, including the "*" label (no wildcard - substitution); - -5. Including NSEC3 RRs in a Zone - - Each owner name in the zone which has authoritative data or a secured - - - -Laurie, et al. Expires August 2, 2005 [Page 9] - -Internet-Draft nsec3 february 2005 - - - delegation point NS RRset MUST have an NSEC3 resource record. - - An unsecured delegation point NS RRset MAY have an NSEC3 resource - record. This is different from NSEC records where an unsecured - delegation point NS RRset MUST have an NSEC record. - - The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL - value field in the zone SOA RR. - - The type bitmap of every NSEC3 resource record in a signed zone MUST - indicate the presence of both the NSEC3 record itself and its - corresponding RRSIG record. - - The bitmap for the NSEC3 RR at a delegation point requires special - attention. Bits corresponding to the delegation NS RRset and any - RRsets for which the parent zone has authoritative data MUST be set; - bits corresponding to any non-NS RRset for which the parent is not - authoritative MUST be clear. - - The following steps describe the proper construction of NSEC3 - records. - 1. Sort the zone in canonical order. - 2. For each unique original owner name, add a NSEC3 RRset, where the - ownername of the NSEC3 RR is the hashed equivalent of the - original owner name, prepended to the zone name. - 3. For each RRset at the original owner, set the corresponding bit - in the type bit map. If the RRset signifies an unsecured - delegation point, and the policy is to have Authoritative Only - RRsets, mark this NSEC3 RR. - 4. If the difference in labels between the apex and the original - ownername is greater then 1, additional NSEC3 need to be added - for every intermediate label level between the apex and the - original ownername. - 5. sort the set of NSEC3 RRs. - 6. In each NSEC3 RR, insert the Next Hashed Ownername. If the next - hashed ownername is a marked NSEC3 (from step 3), delete the - marked NSEC3 from the zone, set the Authoritative Only bit in the - current NSEC3 RRs, and repeat this step. The last NSEC3 in the - zone will contain the value of the first NSEC3 in the zone. - -6. Special Considerations - - The following paragraphs clarify specific behaviour explain special - considerations for implementations. - -6.1 delegation points - - This proposal introduces the Authoritative Only Flag which indicates - - - -Laurie, et al. Expires August 2, 2005 [Page 10] - -Internet-Draft nsec3 february 2005 - - - whether non authoritative delegation point NS records are included in - the type bit Maps. As discussed in paragraph 2.1.1, a flag value of - 0 indicates that the interpretation of the type bit maps is identical - to NSEC records. - - The following subsections describe behaviour when the flag value is - 1. - -6.1.1 Unsigned Delegations - - Delegation point NS records are not authoritative. They are - authoritative in the delegated zone. No other data exists at the - ownername of an unsigned delegation point. - - Since no authoritative data exist at this ownername, it is excluded - from the NSEC3 chain. This is an optimization since it relieves the - zone of including an NSEC3 record and its associated signature for - this name. - - An NSEC3 that denies existence of ownernames between X and X' with - the Authoritative Only Flag set to 1 can not be used to proof - presence nor absence of the delegation point NS records for unsigned - delegations in the interval X, X'. The Authoritative Only Flag - effectively states No Contest on the presence of delegation point NS - resource records. - - Since proof is absent, there exists a new attack vector. Unsigned - delegation point NS records can be deleted during a man in the middle - attack, effectively denying existence of the delegation. This is a - form of Denial of Service, where the victim has no information it is - under attack, since all signatures are valid and the fabricated - response form is a known type of response. - - The only possible mitigation is to either not use this method, hence - proving existence or absence of unsigned delegations, or signing the - delegated zone, changing the unsigned delegation into a signed - delegation. - - A second attack vector exists in that an adversary is able to - successfully fabricate a response claiming a not existent delegation - to exist, though unsigned. - - The only possible mitigation is to either not use this method, hence - proving absence of unsigned delegations. - -6.2 Additional Complexity Caused by Wildcards - - If a wildcard ownername appears in a zone, the wildcard label ("*") - - - -Laurie, et al. Expires August 2, 2005 [Page 11] - -Internet-Draft nsec3 february 2005 - - - is treated as a literal symbol and is treated in the same way as any - other ownername for purposes of generating NSEC3 RRs. RFC 2535 - [RFC2525] describes the impact of wildcards on authenticated denial - of existence. - - In order to prove there are no wildcards for a domain, as well as no - RRs that match directly, an RR must be shown for the closest - encloser, and non-existence must be shown for all enclosers that - could be closer. - -6.3 Salting - - Augmenting original ownernames with salt before hashing increases the - cost of a dictionary of pre-generated hash-values. For every bit of - salt, the cost of the dictionary doubles. The NSEC3 RR can use - maximum 2040 bits of salt, multiplying the cost by 2^2040. - - The salt value for each NSEC3 RR MUST be equal for a single version - of the zone. - -6.4 Hash Collision - - Hash collisions occur when different messages have the same hash - value. The expected number of domain names needed to give a 1 in 2 - chance of a single collision is about 2^80. Though this probability - is extremely low, the following paragraphs deal with avoiding - collisions and assessing possible damage in the event of an attack - using Hash collisions. - -6.4.1 Avoiding Hash Collisions during generation - - During generation of NSEC3 RRs, hash values are supposedly unique. - In the (academic) case of a collision occurring, an alternative salt - SHOULD be chosen and all hash values SHOULD be regenerated. - - If hash values are not regenerated on collision, the NSEC3 RR MUST - list all authoritative RR types that exist for both owners, to avoid - a replay attack, spoofing an existing type as non-existent. - -6.4.2 Second Preimage Requirement Analysis - - A collision resistant hash function has a second-preimage resistance - property. The second-preimage resistance property means that it is - computationally infeasible to find another message with the same hash - value as a given message, i.e. given preimage X, to find a second - preimage X' <> X such that hash(X) = hash(X'). The probability of - finding a second preimage is 1 in 2^160 for SHA-1 on average. To - mount an attack using an existing NSEC3 RR, an adversary needs to - - - -Laurie, et al. Expires August 2, 2005 [Page 12] - -Internet-Draft nsec3 february 2005 - - - find a second preimage. - - Assuming an adversary is capable of mounting such an extreme attack, - the actual damage is that a response message can be generated which - claims that a certain QNAME (i.e. the second pre-image) does exist, - while in reality QNAME does not exist (a false positive), which will - either cause a security aware resolver to re-query for the - non-existent name, or to fail the initial query. Note that the - adversary can't mount this attack on an existing name but only on a - name that the adversary can't choose and does not yet exist. - -6.4.3 Possible Hash Value Truncation Method - - The previous sections outlined the low probability and low impact of - a second-preimage attack. When impact and probability are low, while - space in a DNS message is costly, truncation is tempting. Truncation - might be considered to allow for shorter ownernames and rdata for - hashed labels. In general, if a cryptographic hash is truncated to n - bits, then the expected number of domains required to give a 1 in 2 - probability of a single collision is approximately 2^(n/2) and the - work factor to produce a second preimage resistance is 2^n. - - An extreme hash value truncation would be truncating to the shortest - possible unique label value. Considering that hash values are - presented in base32, which represents 5 bits per label character, - truncation must be done on a 5 bit boundary. This would be unwise, - since the work factor to produce collisions would then approximate - the size of the zone. - - Though the mentioned truncation can be maximized to a certain - extreme, the probability of collision increases exponentially for - every truncated bit. Given the low impact of hash value collisions - and limited space in DNS messages, the balance between truncation - profit and collision damage may be determined by local policy. - -7. Performance Considerations - - Iterated hashes will obviously impose a performance penalty on both - authoritative servers and resolvers. Therefore, the number of - iterations should be carefully chosen. - -8. IANA Considerations - - IANA has to create a new registry for NSEC3 Hash Functions. The - range for this registry is 0-127. Value 1 is marked as SHA-1. - Values 0, 2-126 are marked as Reserved For Future Use. Value 127 is - marked as Experimental. - - - - -Laurie, et al. Expires August 2, 2005 [Page 13] - -Internet-Draft nsec3 february 2005 - - -9. Security Considerations - - The NSEC3 records are still susceptible to dictionary attacks (i.e. - the attacker retrieves all the NSEC3 records, then calculates the - hashes of all likely domain names, comparing against the hashes found - in the NSEC3 records, and thus enumerating the zone). These are - substantially more expensive than traversing the original NSEC - records would have been, and in any case, such an attack could also - be used directly against the name server itself by performing queries - for all likely names. The expense of this attack can be chosen by - setting the iterations in the NSEC3 RR. - - High-value domains are also susceptible to a precalculated dictionary - attack - that is, a list of hashes for all likely names is computed - once, then NSEC3 is scanned periodically and compared against the - precomputed hashes. This attack is prevented by changing the salt on - a regular basis. - - Walking the NSEC3 RRs will reveal the total number of records in the - zone, and also what types they are. This could be mitigated by - adding dummy entries, but certainly an upper limit can always be - found. - - Hash collisions may occur. If they do, it will be impossible to - prove the non-existence of the colliding domain - however, this is - fantastically unlikely, and, in any case, DNSSEC already relies on - SHA-1 to not collide. - -10. Requirements notation - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - -11. Security Considerations - -Appendix A. Example Zone - - This is a zone showing its NSEC3 records. They can also be used as - test vectors for the hash algorithm. RRSIG records have been elided. - - - - - - - - - - - -Laurie, et al. Expires August 2, 2005 [Page 14] - -Internet-Draft nsec3 february 2005 - - - example.com. 1000 IN SOA localhost. - postmaster.localhost.example.com. ( - 1 ; serial - 3600 ; refresh (1 hour) - 1800 ; retry (30 minutes) - 604800 ; expire (1 week) - 3600 ; minimum (1 hour) - ) - 1000 NS ns1.example.com. - 1000 NS ns2.example.com. - f519593e82969842a136e0f47814c881fa163833.example.com. 3600 IN NSEC3 \ - SHA-1 200 31323334 4EF8239D95C18403A509D7C336A5D0FA48FD1107 \ - NS SOA RRSIG DNSKEY NSEC3 - a.example.com. 1000 IN A 1.2.3.4 - 1000 IN A 1.2.3.5 - 1000 TXT "An example" - bfe6ea21dee9d228889ae11fa58c4bd551d15801.example.com. 3600 IN NSEC3 \ - SHA-1 200 31323334 F519593E82969842A136E0F47814C881FA163833 \ - A TXT RRSIG NSEC3 - b.example.com. 1000 IN A 1.2.3.7 - 83c06d3b7d01fbc9576c71af2bec1a1163435153.example.com. 3600 IN NSEC3 \ - SHA-1 200 31323334 A33559360EECB02F36B5C1B72C109126CA4F5A0D \ - A RRSIG NSEC3 - a.b.c.example.com. 1000 IN A 1.2.3.6 - a33559360eecb02f36b5c1b72c109126ca4f5a0d.example.com. 3600 IN NSEC3 \ - SHA-1 200 31323334 BFE6EA21DEE9D228889AE11FA58C4BD551D15801 \ - A RRSIG NSEC3 - ns1.example.com. 1000 IN A 1.2.3.8 - 4ef8239d95c18403a509d7c336a5d0fa48fd1107.example.com. 3600 IN NSEC3 \ - SHA-1 200 31323334 50016B56FD2F0FFC7B563C50FAF0E34259763BBB \ - A RRSIG NSEC3 - ns2.example.com. 1000 IN A 1.2.3.9 - 50016b56fd2f0ffc7b563c50faf0e34259763bbb.example.com. 3600 IN NSEC3 \ - SHA-1 200 31323334 83C06D3B7D01FBC9576C71AF2BEC1A1163435153 \ - A RRSIG NSEC3 - - -12. References - -12.1 Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - - - -Laurie, et al. Expires August 2, 2005 [Page 15] - -Internet-Draft nsec3 february 2005 - - - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - -12.2 Informative References - - [RFC2026] Bradner, S., "The Internet Standards Process -- Revision - 3", BCP 9, RFC 2026, October 1996. - - [RFC2418] Bradner, S., "IETF Working Group Guidelines and - Procedures", BCP 25, RFC 2418, September 1998. - - [rollover] - Ihren, J., Kolkman, O. and B. Manning, "An In-Band - Rollover Algorithm and a Out-Of-Band Priming Method for - DNS Trust Anchors.", July 2004. - - -Authors' Addresses - - Ben Laurie - Nominet - 17 Perryn Road - London W3 7LR - England - - Phone: +44 (20) 8735 0686 - EMail: ben@algroup.co.uk - - - Geoffrey Sisson - Nominet - - - - - - - - -Laurie, et al. Expires August 2, 2005 [Page 16] - -Internet-Draft nsec3 february 2005 - - - Roy Arends - Telematica Instituut - Brouwerijstraat 1 - 7523 XC Enschede - The Netherlands - - Phone: +31 (53) 485 0485 - EMail: roy.arends@telin.nl - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires August 2, 2005 [Page 17] - -Internet-Draft nsec3 february 2005 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM 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. - - -Copyright Statement - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Laurie, et al. Expires August 2, 2005 [Page 18] - - diff --git a/doc/draft/draft-ietf-dnsext-nsec3-02.txt b/doc/draft/draft-ietf-dnsext-nsec3-02.txt new file mode 100644 index 0000000000..cc3c276b99 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-nsec3-02.txt @@ -0,0 +1,2072 @@ + + + +Network Working Group B. Laurie +Internet-Draft G. Sisson +Expires: December 3, 2005 Nominet + R. Arends + Telematica Instituut + june 2005 + + + DNSSEC Hash Authenticated Denial of Existence + draft-ietf-dnsext-nsec3-02 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on December 3, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be + used to provide authenticated denial of existence of DNS ownernames + and types; however, it permits any user to traverse a zone and obtain + a listing of all ownernames. + + A complete zone file can be used either directly as a source of + + + +Laurie, et al. Expires December 3, 2005 [Page 1] + +Internet-Draft nsec3 june 2005 + + + probable e-mail addresses for spam, or indirectly as a key for + multiple WHOIS queries to reveal registrant data which many + registries (particularly in Europe) may be under strict legal + obligations to protect. Many registries therefore prohibit copying + of their zone file; however the use of NSEC RRs renders policies + unenforceable. + + This document proposes a scheme which obscures original ownernames + while permitting authenticated denial of existence of non-existent + names. Non-authoritative delegation point NS RR types may be + excluded. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 5 + 2.1 NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 5 + 2.1.1 The Authoritative Only Flag Field . . . . . . . . . . 6 + 2.1.2 The Hash Function Field . . . . . . . . . . . . . . . 6 + 2.1.3 The Iterations Field . . . . . . . . . . . . . . . . . 7 + 2.1.4 The Salt Length Field . . . . . . . . . . . . . . . . 7 + 2.1.5 The Salt Field . . . . . . . . . . . . . . . . . . . . 7 + 2.1.6 The Next Hashed Ownername Field . . . . . . . . . . . 7 + 2.1.7 The list of Type Bit Map(s) Field . . . . . . . . . . 8 + 2.2 The NSEC3 RR Presentation Format . . . . . . . . . . . . . 9 + 3. Creating Additional NSEC3 RRs for Empty Non Terminals . . . . 9 + 4. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 10 + 5. Including NSEC3 RRs in a Zone . . . . . . . . . . . . . . . . 10 + 6. Special Considerations . . . . . . . . . . . . . . . . . . . . 11 + 6.1 Delegation Points . . . . . . . . . . . . . . . . . . . . 11 + 6.1.1 Unsigned Delegations . . . . . . . . . . . . . . . . . 11 + 6.2 Proving Nonexistence . . . . . . . . . . . . . . . . . . . 12 + 6.3 Salting . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 6.4 Hash Collision . . . . . . . . . . . . . . . . . . . . . . 13 + 6.4.1 Avoiding Hash Collisions during generation . . . . . . 14 + 6.4.2 Second Preimage Requirement Analysis . . . . . . . . . 14 + 6.4.3 Possible Hash Value Truncation Method . . . . . . . . 14 + 7. Performance Considerations . . . . . . . . . . . . . . . . . . 15 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 10.1 Normative References . . . . . . . . . . . . . . . . . . . 16 + 10.2 Informative References . . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 + A. Example Zone . . . . . . . . . . . . . . . . . . . . . . . . . 18 + + + +Laurie, et al. Expires December 3, 2005 [Page 2] + +Internet-Draft nsec3 june 2005 + + + B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 23 + B.1 answer . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + B.1.1 Authenticating the Example DNSKEY RRset . . . . . . . 25 + B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 26 + B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 28 + B.3.1 No Data Error, Empty Non-Terminal . . . . . . . . . . 29 + B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 30 + B.5 Referral to Unsigned Zone using Opt-In . . . . . . . . . . 31 + B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 32 + B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 34 + B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 35 + Intellectual Property and Copyright Statements . . . . . . . . 37 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 3] + +Internet-Draft nsec3 june 2005 + + +1. Introduction + + The DNS Security Extensions (DNSSEC) introduced the NSEC Resource + Record (RR) for authenticated denial of existence. This document + introduces a new RR as an alternative to NSEC that provides measures + against zone traversal and allows for gradual expansion of + delegation-centric zones. + +1.1 Rationale + + The DNS Security Extensions included the NSEC RR to provide + authenticated denial of existence. Though the NSEC RR meets the + requirements for authenticated denial of existence, it introduced a + side-effect in that the contents of a zone can be enumerated. This + property introduces undesired policy issues. + + A second problem was the requirement that the existence of all record + types in a zone - including delegation point NS record types - must + be accounted for, despite the fact that delegation point NS RRsets + are not authoritative and not signed. This requirement has a side- + effect that the overhead of delegation-centric signed zones is not + related to the increase in security of subzones. This requirement + does not allow delegation-centric zones size to grow in relation to + the growth of signed subzones. + + In the past, solutions have been proposed as a measure against these + side effects but at the time were regarded as secondary over the need + to have a stable DNSSEC specification. With (draft-vixie-dnssec-ter) + a graceful transition path to future enhancements is introduced, + while current DNSSEC deployment can continue. This document presents + the NSEC3 Resource Record which mitigates these issues with the NSEC + RR. + + The reader is assumed to be familiar with the basic DNS concepts + described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs + that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308 + [RFC2308]. + +1.2 Reserved Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +1.3 Terminology + + In this document the term "original ownername" refers to a standard + ownername. Because this proposal uses the result of a hash function + + + +Laurie, et al. Expires December 3, 2005 [Page 4] + +Internet-Draft nsec3 june 2005 + + + over the original (unmodified) ownername, this result is referred to + as "hashed ownername". + + "Canonical ordering of the zone" means the order in which hashed + ownernames are arranged according to their numerical value, treating + the leftmost (lowest numbered) byte as the most significant byte. + +2. The NSEC3 Resource Record + + The NSEC3 RR provides Authenticated Denial of Existence for DNS + Resource Record Sets. + + The NSEC3 Resource Record lists RR types present at the NSEC3 RR's + original ownername. It includes the next hashed ownername in the + canonical ordering of the zone. The complete set of NSEC3 RRs in a + zone indicates which RRsets exist for the original ownername of the + RRset and form a chain of hashed ownernames in the zone. This + information is used to provide authenticated denial of existence for + DNS data, as described in RFC 4035 [RFC4035]. Unsigned delegation + point NS RRsets can optionally be excluded. To provide protection + against zone traversal, the ownernames used in the NSEC3 RR are + cryptographic hashes of the original ownername prepended to the name + of the zone. The NSEC3 RR indicates which hash function is used to + construct the hash, which salt is used, and how many iterations of + the hash function are performed over the original ownername. + + The ownername for the NSEC3 RR is the base32 encoding of the hashed + ownername. + + The type value for the NSEC3 RR is XX. + + The NSEC3 RR RDATA format is class independent. + + The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL + field. This is in the spirit of negative caching [RFC2308]. + +2.1 NSEC3 RDATA Wire Format + + The RDATA of the NSEC3 RR is as shown below: + + + + + + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 5] + +Internet-Draft nsec3 june 2005 + + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |A|Hash Function| Iterations | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Salt Length | Salt / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Next Hashed Ownername / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Type Bit Maps / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +2.1.1 The Authoritative Only Flag Field + + The Authoritative Only Flag field indicates whether the Type Bit Maps + include delegation point NS record types. + + If the flag is set to 1, the NS RR type bit for a delegation point + ownername SHOULD be clear when the NSEC3 RR is generated. The NS RR + type bit MUST be ignored during processing of the NSEC3 RR. The NS + RR type bit has no meaning in this context (it is not authoritative), + hence the NSEC3 does not contest the existence of a NS RRset for this + ownername. When a delegation is not secured, there exist no DS RR + type nor any other authoritative types for this delegation, hence the + unsecured delegation has no NSEC3 record associated. Please see the + Special Consideration section for implications for unsigned + delegations. + + If the flag is set to 0, the NS RR type bit for a delegation point + ownername MUST be set if the NSEC3 covers a delegation, even though + the NS RR itself is not authoritative. This implies that all + delegations, signed or unsigned, have an NSEC3 record associated. + This behaviour is identical to NSEC behaviour. + +2.1.2 The Hash Function Field + + The Hash Function field identifies the cryptographic hash function + used to construct the hash-value. + + This document defines Value 1 for SHA-1 and Value 127 for + experimental. All other values are reserved. + + On reception, a resolver MUST discard an NSEC3 RR with an unknown + hash function value. + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 6] + +Internet-Draft nsec3 june 2005 + + +2.1.3 The Iterations Field + + The Iterations field defines the number of times the hash has been + iterated. More iterations results in greater resiliency of the hash + value against dictionary attacks, but at a higher cost for both the + server and resolver. + +2.1.4 The Salt Length Field + + The salt length field defines the length of the salt in octets. + +2.1.5 The Salt Field + + The Salt field is not present when the Salt Length Field has a value + of 0. + + The Salt field is prepended to the original ownername before hashing + in order to defend against precalculated dictionary attacks. + + The salt is also prepended during iterations of the hash function. + + Note that although it is theoretically possible to cover the entire + possible ownername space with different salt values, it is + computationally infeasible to do so, and so there MUST be at least + one salt which is the same for all NSEC3 records. This means that no + matter what name is asked for in a query, it is guaranteed to be + possible to find a covering NSEC3 record. Note that this does not + preclude the use of two different salts at the same time - indeed + this may well occur naturally, due to rolling the salt value + periodically. + + The salt value SHOULD be changed from time to time - this is to + prevent the use of a precomputed dictionary to reduce the cost of + enumeration. + +2.1.6 The Next Hashed Ownername Field + + The Next Hashed Ownername field contains the hash of the ownername of + the next RR in the canonical ordering of the hashed ownernames of the + zone. The value of the Next Hashed Ownername Field in the last NSEC3 + record in the zone is the same as the ownername of the first NSEC3 RR + in the zone in canonical order. + + Hashed ownernames of RRsets not authoritative for the given zone + (such as glue records) MUST NOT be listed in the Next Hashed + Ownername unless at least one authoritative RRset exists at the same + ownername. + + + + +Laurie, et al. Expires December 3, 2005 [Page 7] + +Internet-Draft nsec3 june 2005 + + + Note that the Next Hashed Ownername field is not encoded, unlike the + NSEC3 RR's ownername. It is the unmodified binary hash value. + +2.1.7 The list of Type Bit Map(s) Field + + The Type Bit Maps field identifies the RRset types which exist at the + NSEC3 RR's ownername. + + The Type bits for the NSEC3 RR and RRSIG RR MUST be set during + generation, and MUST be ignored during processing. + + The RR type space is split into 256 window blocks, each representing + the low-order 8 bits of the 16-bit RR type space. Each block that + has at least one active RR type is encoded using a single octet + window number (from 0 to 255), a single octet bitmap length (from 1 + to 32) indicating the number of octets used for the window block's + bitmap, and up to 32 octets (256 bits) of bitmap. + + Blocks are present in the NSEC3 RR RDATA in increasing numerical + order. + + "|" denotes concatenation + + Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + + + Each bitmap encodes the low-order 8 bits of RR types within the + window block, in network bit order. The first bit is bit 0. For + window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds + to RR type 2 (NS), and so forth. For window block 1, bit 1 + corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to + 1, it indicates that an RRset of that type is present for the NSEC3 + RR's ownername. If a bit is set to 0, it indicates that no RRset of + that type is present for the NSEC3 RR's ownername. + + The RR type 2 (NS) is authoritative at the apex of a zone and is not + authoritative at delegation points. If the Authoritative Only Flag + is set to 1, the delegation point NS RR type MUST NOT be included in + the type bit maps. If the Authoritative Only Flag is set to 0, the + NS RR type at a delegation point MUST be included in the type bit + maps. + + Since bit 0 in window block 0 refers to the non-existing RR type 0, + it MUST be set to 0. After verification, the validator MUST ignore + the value of bit 0 in window block 0. + + Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 + [RFC2929] (section 3.1) or within the range reserved for assignment + only to QTYPEs and Meta-TYPEs MUST be set to 0, since they do not + + + +Laurie, et al. Expires December 3, 2005 [Page 8] + +Internet-Draft nsec3 june 2005 + + + appear in zone data. If encountered, they must be ignored upon + reading. + + Blocks with no types present MUST NOT be included. Trailing zero + octets in the bitmap MUST be omitted. The length of each block's + bitmap is determined by the type code with the largest numerical + value, within that block, among the set of RR types present at the + NSEC3 RR's actual ownername. Trailing zero octets not specified MUST + be interpreted as zero octets. + +2.2 The NSEC3 RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Authoritative Only Field is represented as an unsigned decimal + integer. The value are either 0 or 1. + + The Hash field is presented as the name of the hash or as an unsigned + decimal integer. The value has a maximum of 127. + + The Iterations field is presented as an unsigned decimal integer. + + The Salt Length field is not presented. + + The Salt field is represented as a sequence of case-insensitive + hexadecimal digits. Whitespace is not allowed within the sequence. + The Salt Field is represented as 00 when the Salt Length field has + value 0. + + The Next Hashed Ownername field is represented as a sequence of case- + insensitive base32 digits. Whitespace is allowed within the + sequence. + + The List of Type Bit Map(s) Field is represented as a sequence of RR + type mnemonics. When the mnemonic is not known, the TYPE + representation as described in RFC 3597 [RFC3597] (section 5) MUST be + used. + +3. Creating Additional NSEC3 RRs for Empty Non Terminals + + In order to prove the non-existence of a record that might be covered + by a wildcard, it is necessary to prove the existence of its closest + encloser. A closest encloser might be an Empty Non Terminal. + + Additional NSEC3 RRs are synthesized which cover every existing + intermediate label level. Additional NSEC3 RRs are identical in + format to NSEC3 RRs that cover existing RRs in the zone. The + difference is that the type-bit-maps only indicate the existence of + + + +Laurie, et al. Expires December 3, 2005 [Page 9] + +Internet-Draft nsec3 june 2005 + + + an NSEC3 RR type and an RRSIG RR type. + +4. Calculation of the Hash + + Define H(x) to be the hash of x using the hash function selected by + the NSEC3 record and || to indicate concatenation. Then define: + + IH(salt,x,0)=H(x || salt) + + IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0 + + Then the calculated hash of an ownername is + IH(salt,ownername,iterations-1), where the ownername is the canonical + form. + + The canonical form of the ownername is the wire format of the + ownername where: + 1. The ownername is fully expanded (no DNS name compression) and + fully qualified; + 2. All uppercase US-ASCII letters are replaced by the corresponding + lowercase US-ASCII letters; + 3. If the ownername is a wildcard name, the ownername is in its + original unexpanded form, including the "*" label (no wildcard + substitution); + +5. Including NSEC3 RRs in a Zone + + Each owner name in the zone which has authoritative data or a secured + delegation point NS RRset MUST have an NSEC3 resource record. + + An unsecured delegation point NS RRset MAY have an NSEC3 resource + record. This is different from NSEC records where an unsecured + delegation point NS RRset MUST have an NSEC record. + + The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL + value field in the zone SOA RR. + + The type bitmap of every NSEC3 resource record in a signed zone MUST + indicate the presence of both the NSEC3 RR type itself and its + corresponding RRSIG RR type. + + The bitmap for the NSEC3 RR at a delegation point requires special + attention. Bits corresponding to the delegation NS RRset and any + RRsets for which the parent zone has authoritative data MUST be set; + bits corresponding to any non-NS RRset for which the parent is not + authoritative MUST be clear. + + The following steps describe the proper construction of NSEC3 + + + +Laurie, et al. Expires December 3, 2005 [Page 10] + +Internet-Draft nsec3 june 2005 + + + records. + 1. For each unique original owner name in the zone, add an NSEC3 + RRset. This includes NSEC3 RRsets for unsigned delegation point + NS RRsets, unless the policy is to have Authoritative Only NSEC3 + RRsets. The ownername of the NSEC3 RR is the hashed equivalent + of the original owner name, prepended to the zone name. + 2. For each RRset at the original owner, set the corresponding bit + in the type bit map. + 3. If the difference in number of labels between the apex and the + original ownername is greater then 1, additional NSEC3s need to + be added for every empty non-terminal between the apex and the + original ownername. + 4. Sort the set of NSEC3 RRs. + 5. In each NSEC3 RR, insert the Next Hashed Ownername. The Next + Hashed Ownername of the last NSEC3 in the zone contains the value + of the hashed ownername of the first NSEC3 in the zone. + 6. If the policy is to have authoritative only, set the + Authoritative Only bit in those NSEC3 RRs that cover unsecured + delegation points. + +6. Special Considerations + + The following paragraphs clarify specific behaviour explain special + considerations for implementations. + +6.1 Delegation Points + + This proposal introduces the Authoritative Only Flag which indicates + whether non authoritative delegation point NS records are included in + the type bit Maps. As discussed in paragraph 2.1.1, a flag value of + 0 indicates that the interpretation of the type bit maps is identical + to NSEC records. + + The following subsections describe behaviour when the flag value is + 1. + +6.1.1 Unsigned Delegations + + Delegation point NS records are not authoritative. They are + authoritative in the delegated zone. No other data exists at the + ownername of an unsigned delegation point. + + Since no authoritative data exist at this ownername, it is excluded + from the NSEC3 chain. This is an optimization, since it relieves the + zone of including an NSEC3 record and its associated signature for + this name. + + An NSEC3 that denies existence of ownernames between X and X' with + + + +Laurie, et al. Expires December 3, 2005 [Page 11] + +Internet-Draft nsec3 june 2005 + + + the Authoritative Only Flag set to 1 can not be used to prove the + presence or the absence of delegation point NS records for unsigned + delegations in the interval (X, X'). The Authoritative Only Flag + effectively states No Contest on the presence of delegation point NS + resource records. + + Since proof is absent, there exists a new attack vector. Unsigned + delegation point NS records can be deleted during a man in the middle + attack, effectively denying existence of the delegation. This is a + form of Denial of Service, where the victim has no information it is + under attack, since all signatures are valid and the fabricated + response form is a known type of response. + + The only possible mitigation is to either not use this method, hence + proving existence or absence of unsigned delegations, or to sign all + delegations, regardless of whether the delegated zone is signed or + not. + + A second attack vector exists in that an adversary is able to + successfully fabricate an (unsigned) response claiming a nonexistent + delegation exists. + + The only possible mitigation is to mandate the signing of all + delegations. + +6.2 Proving Nonexistence + + If a wildcard resource record appears in a zone, its asterisk label + is treated as a literal symbol and is treated in the same way as any + other ownername for purposes of generating NSEC3 RRs. RFC 4035 + [RFC4035] describes the impact of wildcards on authenticated denial + of existence. + + In order to prove there exist no RRs for a domain, as well as no + source of synthesis, an RR must be shown for the closest encloser, + and non-existence must be shown for all closer labels and for the + wildcard at the closest encloser. + + This can be done as follows. If the QNAME in the query is + omega.alfa.beta.example, and the closest encloser is beta.example + (the nearest ancestor to omega.alfa.beta.example), then the server + should return an NSEC3 that demonstrates the nonexistence of + alfa.beta.example, an NSEC3 that demonstrates the nonexistence of + *.beta.example, and an NSEC3 that demonstrates the existence of + beta.example. This takes between one and three NSEC3 records, since + a single record can, by chance, prove more than one of these facts. + + When a verifier checks this response, then the existence of + + + +Laurie, et al. Expires December 3, 2005 [Page 12] + +Internet-Draft nsec3 june 2005 + + + beta.example together with the non-existence of alfa.beta.example + proves that the closest encloser is indeed beta.example. The non- + existence of *.beta.example shows that there is no wildcard at the + closest encloser, and so no source of synthesis for + omega.alfa.beta.example. These two facts are sufficient to satisfy + the resolver that the QNAME cannot be resolved. + + In practice, since the NSEC3 owner and next names are hashed, if the + server responds with an NSEC3 for beta.example, the resolver will + have to try successively longer names, starting with example, moving + to beta.example, alfa.beta.example, and so on, until one of them + hashes to a value that matches the interval (but not the ownername + nor next owner name) of one of the returned NSEC3s (this name will be + alfa.beta.example). Once it has done this, it knows the closest + encloser (i.e. beta.example), and can then easily check the other two + required proofs. + + Note that it is not possible for one of the shorter names tried by + the resolver to be denied by one of the returned NSEC3s, since, by + definition, all these names exist and so cannot appear within the + range covered by an NSEC3. Note, however, that the first name that + the resolver tries MUST be the apex of the zone, since names above + the apex could be denied by one of the returned NSEC3s. + +6.3 Salting + + Augmenting original ownernames with salt before hashing increases the + cost of a dictionary of pre-generated hash-values. For every bit of + salt, the cost of the dictionary doubles. The NSEC3 RR can use a + maximum of 2040 bits of salt, multiplying the cost by 2^2040. + + There MUST be a complete set of NSEC3s for the zone using the same + salt value. The salt value for each NSEC3 RR MUST be equal for a + single version of the zone. + + The salt SHOULD be changed every time the zone is resigned to prevent + precomputation using a single salt. + +6.4 Hash Collision + + Hash collisions occur when different messages have the same hash + value. The expected number of domain names needed to give a 1 in 2 + chance of a single collision is about 2^(n/2) for a hash of length n + bits (i.e. 2^80 for SHA-1). Though this probability is extremely + low, the following paragraphs deal with avoiding collisions and + assessing possible damage in the event of an attack using hash + collisions. + + + + +Laurie, et al. Expires December 3, 2005 [Page 13] + +Internet-Draft nsec3 june 2005 + + +6.4.1 Avoiding Hash Collisions during generation + + During generation of NSEC3 RRs, hash values are supposedly unique. + In the (academic) case of a collision occurring, an alternative salt + SHOULD be chosen and all hash values SHOULD be regenerated. + + If hash values are not regenerated on collision, the NSEC3 RR MUST + list all authoritative RR types that exist for both owners, to avoid + a replay attack, spoofing an existing type as non-existent. + +6.4.2 Second Preimage Requirement Analysis + + A cryptographic hash function has a second-preimage resistance + property. The second-preimage resistance property means that it is + computationally infeasible to find another message with the same hash + value as a given message, i.e. given preimage X, to find a second + preimage X' <> X such that hash(X) = hash(X'). The work factor for + finding a second preimage is of the order of 2^160 for SHA-1. To + mount an attack using an existing NSEC3 RR, an adversary needs to + find a second preimage. + + Assuming an adversary is capable of mounting such an extreme attack, + the actual damage is that a response message can be generated which + claims that a certain QNAME (i.e. the second pre-image) does exist, + while in reality QNAME does not exist (a false positive), which will + either cause a security aware resolver to re-query for the non- + existent name, or to fail the initial query. Note that the adversary + can't mount this attack on an existing name but only on a name that + the adversary can't choose and does not yet exist. + +6.4.3 Possible Hash Value Truncation Method + + The previous sections outlined the low probability and low impact of + a second-preimage attack. When impact and probability are low, while + space in a DNS message is costly, truncation is tempting. Truncation + might be considered to allow for shorter ownernames and rdata for + hashed labels. In general, if a cryptographic hash is truncated to n + bits, then the expected number of domains required to give a 1 in 2 + probability of a single collision is approximately 2^(n/2) and the + work factor to produce a second preimage resistance is 2^n. + + An extreme hash value truncation would be truncating to the shortest + possible unique label value. Considering that hash values are + presented in base32, which represents 5 bits per label character, + truncation must be done on a 5 bit boundary. This would be unwise, + since the work factor to produce collisions would then approximate + the size of the zone. + + + + +Laurie, et al. Expires December 3, 2005 [Page 14] + +Internet-Draft nsec3 june 2005 + + + Though the mentioned truncation can be maximized to a certain + extreme, the probability of collision increases exponentially for + every truncated bit. Given the low impact of hash value collisions + and limited space in DNS messages, the balance between truncation + profit and collision damage may be determined by local policy. Of + course, the size of the corresponding RRSIG RR is not reduced, so + truncation is of limited benefit. + + Truncation could be signalled simply by reducing the length of the + first label in the ownername. Note that there would have to be a + corresponding reduction in the length of the Next Hashed Ownername + field. + +7. Performance Considerations + + Iterated hashes will obviously impose a performance penalty on both + authoritative servers and resolvers. Therefore, the number of + iterations should be carefully chosen. In particular it should be + noted that a high value for iterations gives an attacker a very good + denial of service attack, since the attacker need not bother to + verify the results of their queries, and hence has no performance + penalty of his own. + + On the other hand, nameservers with low query rates and limited + bandwidth are already subject to a bandwidth based denial of service + attack, since responses are typically an order of magnitude larger + than queries, and hence these servers may choose a high value of + iterations in order to increase the difficulty of offline attempts to + enumerate their namespace without significantly increasing their + vulnerability to denial of service attacks. + +8. IANA Considerations + + IANA has to create a new registry for NSEC3 Hash Functions. The + range for this registry is 0-127. Value 0 is the identity function. + Value 1 is SHA-1. Values 2-126 are Reserved For Future Use. Value + 127 is marked as Experimental. + +9. Security Considerations + + The NSEC3 records are still susceptible to dictionary attacks (i.e. + the attacker retrieves all the NSEC3 records, then calculates the + hashes of all likely domain names, comparing against the hashes found + in the NSEC3 records, and thus enumerating the zone). These are + substantially more expensive than traversing the original NSEC + records would have been, and in any case, such an attack could also + be used directly against the name server itself by performing queries + for all likely names, though this would obviously be more detectable. + + + +Laurie, et al. Expires December 3, 2005 [Page 15] + +Internet-Draft nsec3 june 2005 + + + The expense of this off-line attack can be chosen by setting the + number of iterations in the NSEC3 RR. + + High-value domains are also susceptible to a precalculated dictionary + attack - that is, a list of hashes for all likely names is computed + once, then NSEC3 is scanned periodically and compared against the + precomputed hashes. This attack is prevented by changing the salt on + a regular basis. + + Walking the NSEC3 RRs will reveal the total number of records in the + zone, and also what types they are. This could be mitigated by + adding dummy entries, but certainly an upper limit can always be + found. + + Hash collisions may occur. If they do, it will be impossible to + prove the non-existence of the colliding domain - however, this is + fantastically unlikely, and, in any case, DNSSEC already relies on + SHA-1 to not collide. + +10. References + +10.1 Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning, + "Domain Name System (DNS) IANA Considerations", BCP 42, + RFC 2929, September 2000. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + + +Laurie, et al. Expires December 3, 2005 [Page 16] + +Internet-Draft nsec3 june 2005 + + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + +10.2 Informative References + + [I-D.ietf-dnsext-trustupdate-threshold] + Ihren, J., "An In-Band Rollover Mechanism and an Out-Of- + Band Priming Method for DNSSEC Trust Anchors.", + draft-ietf-dnsext-trustupdate-threshold-00 (work in + progress), October 2004. + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + [RFC2418] Bradner, S., "IETF Working Group Guidelines and + Procedures", BCP 25, RFC 2418, September 1998. + + +Authors' Addresses + + Ben Laurie + Nominet + 17 Perryn Road + London W3 7LR + England + + Phone: +44 (20) 8735 0686 + Email: ben@algroup.co.uk + + + Geoffrey Sisson + Nominet + + + + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 17] + +Internet-Draft nsec3 june 2005 + + + Roy Arends + Telematica Instituut + Brouwerijstraat 1 + 7523 XC Enschede + The Netherlands + + Phone: +31 (53) 485 0485 + Email: roy.arends@telin.nl + +Appendix A. Example Zone + + This is a zone showing its NSEC3 records. They can also be used as + test vectors for the hash algorithm. + + + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1 + 3600 + 300 + 3600000 + 3600 ) + 3600 RRSIG SOA 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK + mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g + qYIt90txzE/4+g== ) + 3600 NS ns1.example. + 3600 NS ns2.example. + 3600 RRSIG NS 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l + m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d + 1SH5r/wfjuCg+g== ) + 3600 MX 1 xx.example. + 3600 RRSIG MX 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + L/ZDLMSZJKITmSxmM9Kni37/wKQsdSg6FT0l + NMm14jy2Stp91Pwp1HQ1hAMkGWAqCMEKPMtU + S/o/g5C8VM6ftQ== ) + 3600 DNSKEY 257 3 5 ( + AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX + cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1 + zsYKWJ7BvR2894hX + ) ; Key ID = 21960 + 3600 DNSKEY 256 3 5 ( + AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU + 5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL + ExXT48OGGdbfIme5 + + + +Laurie, et al. Expires December 3, 2005 [Page 18] + +Internet-Draft nsec3 june 2005 + + + ) ; Key ID = 62699 + 3600 RRSIG DNSKEY 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + e6EB+K21HbyZzoLUeRDb6+g0+n8XASYe6h+Z + xtnB31sQXZgq8MBHeNFDQW9eZw2hjT9zMClx + mTkunTYzqWJrmQ== ) + 3600 RRSIG DNSKEY 5 1 3600 20050712112304 ( + 20050612112304 21960 example. + SnWLiNWLbOuiKU/F/wVMokvcg6JVzGpQ2VUk + ZbKjB9ON0t3cdc+FZbOCMnEHRJiwgqlnncik + 3w7ZY2UWyYIvpw== ) + 5pe7ctl7pfs2cilroy5dcofx4rcnlypd.example. 3600 NSEC3 0 1 1 ( + deadbeaf + 7nomf47k3vlidh4vxahhpp47l3tgv7a2 + NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + PTWYq4WZmmtgh9UQif342HWf9DD9RuuM4ii5 + Z1oZQgRi5zrsoKHAgl2YXprF2Rfk1TLgsiFQ + sb7KfbaUo/vzAg== ) + 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 NSEC3 0 1 1 ( + deadbeaf + dw4o7j64wnel3j4jh7fb3c5n7w3js2yb + MX NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA + ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo + MEFQmc/gEuxojA== ) + a.example. 3600 IN NS ns1.a.example. + 3600 IN NS ns2.a.example. + 3600 DS 58470 5 1 3079F1593EBAD6DC121E202A8B + 766A6A4837206C ) + 3600 RRSIG DS 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn + cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2 + 0kx7rGKTc3RQDA== ) + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + ai.example. 3600 IN A 192.0.2.9 + 3600 RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU + 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq + ZXW5S+1VjMZYzQ== ) + 3600 HINFO "KLH-10" "ITS" + 3600 RRSIG HINFO 5 2 3600 20050712112304 ( + + + +Laurie, et al. Expires December 3, 2005 [Page 19] + +Internet-Draft nsec3 june 2005 + + + 20050612112304 62699 example. + AR0hG/Z/e+vlRhxRQSVIFORzrJTBpdNHhwUk + tiuqg+zGqKK84eIqtrqXelcE2szKnF3YPneg + VGNmbgPnqDVPiA== ) + 3600 AAAA 2001:db8:0:0:0:0:f00:baa9 + 3600 RRSIG AAAA 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV + ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns + l5/UqLCJJ9BDMg== ) + b.example. 3600 IN NS ns1.b.example. + 3600 IN NS ns2.b.example. + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 NSEC3 0 1 1 ( + deadbeaf + gmnfcccja7wkax3iv26bs75myptje3qk + MX DNSKEY NS SOA NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D + C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R + MOiKMSHozVebqw== ) + gmnfcccja7wkax3iv26bs75myptje3qk.example. 3600 NSEC3 0 1 1 ( + deadbeaf + jt4bbfokgbmr57qx4nqucvvn7fmo6ab6 + DS NS NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + ZqkdmF6eICpHyn1Cj7Yvw+nLcbji46Qpe76/ + ZetqdZV7K5sO3ol5dOc0dZyXDqsJp1is5StW + OwQBGbOegrW/Zw== ) + jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 NSEC3 0 1 1 ( + deadbeaf + kcll7fqfnisuhfekckeeqnmbbd4maanu + NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V + IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK + 94Zbq3k8lgdpZA== ) + kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 NSEC3 1 1 1 ( + deadbeaf + n42hbhnjj333xdxeybycax5ufvntux5d + MX NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA + + + +Laurie, et al. Expires December 3, 2005 [Page 20] + +Internet-Draft nsec3 june 2005 + + + IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx + TOLtc5jPrkL4zQ== ) + n42hbhnjj333xdxeybycax5ufvntux5d.example. 3600 NSEC3 0 1 1 ( + deadbeaf + nimwfwcnbeoodmsc6npv3vuaagaevxxu + A NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + MZGzllh+YFqZbY8SkHxARhXFiMDPS0tvQYyy + 91tj+lbl45L/BElD3xxB/LZMO8vQejYtMLHj + xFPFGRIW3wKnrA== ) + nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 NSEC3 0 1 1 ( + deadbeaf + vhgwr2qgykdkf4m6iv6vkagbxozphazr + HINFO A AAAA NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx + z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG + jL33Wm1p07TBdw== ) + ns1.example. 3600 A 192.0.2.1 + 3600 RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb + BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr + nWWLepz1PjjShQ== ) + ns2.example. 3600 A 192.0.2.2 + 3600 RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3 + P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz + AkeTJu3J3auUiA== ) + vhgwr2qgykdkf4m6iv6vkagbxozphazr.example. 3600 NSEC3 0 1 1 ( + deadbeaf + wbyijvpnyj33pcpi3i44ecnibnaj7eiw + HINFO A AAAA NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + leFhoF5FXZAiNOxK4OBOOA0WKdbaD5lLDT/W + kLoyWnQ6WGBwsUOdsEcVmqz+1n7q9bDf8G8M + 5SNSHIyfpfsi6A== ) + *.w.example. 3600 MX 1 ai.example. + 3600 RRSIG MX 5 3 3600 20050712112304 ( + 20050612112304 62699 example. + sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF + xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ + gQlgxEwhvQDEaQ== ) + x.w.example. 3600 MX 1 xx.example. + + + +Laurie, et al. Expires December 3, 2005 [Page 21] + +Internet-Draft nsec3 june 2005 + + + 3600 RRSIG MX 5 3 3600 20050712112304 ( + 20050612112304 62699 example. + s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w + lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP + U9VazOa1KEIq1w== ) + x.y.w.example. 3600 MX 1 xx.example. + 3600 RRSIG MX 5 4 3600 20050712112304 ( + 20050612112304 62699 example. + aKVCGO/Fx9rm04UUsHRTTYaDA8o8dGfyq6t7 + uqAcYxU9xiXP+xNtLHBv7er6Q6f2JbOs6SGF + 9VrQvJjwbllAfA== ) + wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 NSEC3 0 1 1 ( + deadbeaf + zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui + A NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN + ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd + oorBv4xkb0flXw== ) + xx.example. 3600 A 192.0.2.10 + 3600 RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9 + tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj + cxwCXWj82GVGdw== ) + 3600 HINFO "KLH-10" "TOPS-20" + 3600 RRSIG HINFO 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + ghS2DimOqPSacG9j6KMgXSfTMSjLxvoxvx3q + OKzzPst4tEbAmocF2QX8IrSHr67m4ZLmd2Fk + KMf4DgNBDj+dIQ== ) + 3600 AAAA 2001:db8:0:0:0:0:f00:baaa + 3600 RRSIG AAAA 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo + w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy + rzKKwb8J04/ILw== ) + zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 NSEC3 0 1 1 ( + deadbeaf + 5pe7ctl7pfs2cilroy5dcofx4rcnlypd + MX NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt + 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny + OcFlrPGPMm48/A== ) + + + + +Laurie, et al. Expires December 3, 2005 [Page 22] + +Internet-Draft nsec3 june 2005 + + +Appendix B. Example Responses + + The examples in this section show response messages using the signed + zone example in Appendix A. + +B.1 answer + + A successful query to an authoritative server. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 23] + +Internet-Draft nsec3 june 2005 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + x.w.example. IN MX + + ;; Answer + x.w.example. 3600 IN MX 1 xx.example. + x.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 ( + 20050612112304 62699 example. + s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w + lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP + U9VazOa1KEIq1w== ) + + ;; Authority + example. 3600 IN NS ns1.example. + example. 3600 IN NS ns2.example. + example. 3600 IN RRSIG NS 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l + m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d + 1SH5r/wfjuCg+g== ) + + ;; Additional + xx.example. 3600 IN A 192.0.2.10 + xx.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9 + tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj + cxwCXWj82GVGdw== ) + xx.example. 3600 IN AAAA 2001:db8::f00:baaa + xx.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo + w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy + rzKKwb8J04/ILw== ) + ns1.example. 3600 IN A 192.0.2.1 + ns1.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb + BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr + nWWLepz1PjjShQ== ) + ns2.example. 3600 IN A 192.0.2.2 + ns2.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3 + P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz + AkeTJu3J3auUiA== ) + + + + +Laurie, et al. Expires December 3, 2005 [Page 24] + +Internet-Draft nsec3 june 2005 + + + The query returned an MX RRset for "x.w.example". The corresponding + RRSIG RR indicates that the MX RRset was signed by an "example" + DNSKEY with algorithm 5 and key tag 62699. The resolver needs the + corresponding DNSKEY RR in order to authenticate this answer. The + discussion below describes how a resolver might obtain this DNSKEY + RR. + + The RRSIG RR indicates the original TTL of the MX RRset was 3600, + and, for the purpose of authentication, the current TTL is replaced + by 3600. The RRSIG RR's labels field value of 3 indicates that the + answer was not the result of wildcard expansion. The "x.w.example" + MX RRset is placed in canonical form, and, assuming the current time + falls between the signature inception and expiration dates, the + signature is authenticated. + +B.1.1 Authenticating the Example DNSKEY RRset + + This example shows the logical authentication process that starts + from a configured root DNSKEY RRset (or DS RRset) and moves down the + tree to authenticate the desired "example" DNSKEY RRset. Note that + the logical order is presented for clarity. An implementation may + choose to construct the authentication as referrals are received or + to construct the authentication chain only after all RRsets have been + obtained, or in any other combination it sees fit. The example here + demonstrates only the logical process and does not dictate any + implementation rules. + + We assume the resolver starts with a configured DNSKEY RRset for the + root zone (or a configured DS RRset for the root zone). The resolver + checks whether this configured DNSKEY RRset is present in the root + DNSKEY RRset (or whether a DS RR in the DS RRset matches some DNSKEY + RR in the root DNSKEY RRset), whether this DNSKEY RR has signed the + root DNSKEY RRset, and whether the signature lifetime is valid. If + all these conditions are met, all keys in the DNSKEY RRset are + considered authenticated. The resolver then uses one (or more) of + the root DNSKEY RRs to authenticate the "example" DS RRset. Note + that the resolver may have to query the root zone to obtain the root + DNSKEY RRset or "example" DS RRset. + + Once the DS RRset has been authenticated using the root DNSKEY, the + resolver checks the "example" DNSKEY RRset for some "example" DNSKEY + RR that matches one of the authenticated "example" DS RRs. If such a + matching "example" DNSKEY is found, the resolver checks whether this + DNSKEY RR has signed the "example" DNSKEY RRset and the signature + lifetime is valid. If these conditions are met, all keys in the + "example" DNSKEY RRset are considered authenticated. + + Finally, the resolver checks that some DNSKEY RR in the "example" + + + +Laurie, et al. Expires December 3, 2005 [Page 25] + +Internet-Draft nsec3 june 2005 + + + DNSKEY RRset uses algorithm 5 and has a key tag of 62699. This + DNSKEY is used to authenticate the RRSIG included in the response. + If multiple "example" DNSKEY RRs match this algorithm and key tag, + then each DNSKEY RR is tried, and the answer is authenticated if any + of the matching DNSKEY RRs validate the signature as described above. + +B.2 Name Error + + An authoritative name error. The NSEC3 RRs prove that the name does + not exist and that no covering wildcard exists. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 26] + +Internet-Draft nsec3 june 2005 + + + ;; Header: QR AA DO RCODE=3 + ;; + ;; Question + a.c.x.w.example. IN A + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK + mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g + qYIt90txzE/4+g== ) + 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN NSEC3 0 1 1 ( + deadbeaf + dw4o7j64wnel3j4jh7fb3c5n7w3js2yb + MX NSEC3 RRSIG ) + 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA + ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo + MEFQmc/gEuxojA== ) + nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN NSEC3 0 1 1 ( + deadbeaf + vhgwr2qgykdkf4m6iv6vkagbxozphazr + HINFO A AAAA NSEC3 RRSIG ) + nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx + z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG + jL33Wm1p07TBdw== ) + ;; Additional + ;; (empty) + + The query returned two NSEC3 RRs that prove that the requested data + does not exist and no wildcard applies. The negative reply is + authenticated by verifying both NSEC3 RRs. The NSEC3 RRs are + authenticated in a manner identical to that of the MX RRset discussed + + + +Laurie, et al. Expires December 3, 2005 [Page 27] + +Internet-Draft nsec3 june 2005 + + + above. At least one of the owner names of the NSEC3 RRs will match + the closest encloser. At least one of the NSEC3 RRs prove that there + exists no longer name. At least one of the NSEC3 RRs prove that + there exists no wildcard RRsets that should have been expanded. The + closest encloser can be found by hasing the apex ownername (The SOA + RR's ownername, or the ownername of the DNSKEY RRset referred by an + RRSIG RR), matching it to the ownername of one of the NSEC3 RRs, and + if that fails, continue by adding labels. + + In the above example, the name 'x.w.example' hashes to + '7nomf47k3vlidh4vxahhpp47l3tgv7a2'. This indicates that this might + be the closest encloser. To prove that 'c.x.w.example' and + '*.x.w.example' do not exists, these names are hashed to respectively + 'qsgoxsf2lanysajhtmaylde4tqwnqppl' and + 'cvljzyf6nsckjowghch4tt3nohocpdka'. The two NSEC3 records prove that + these hashed ownernames do not exists, since the names are within the + given intervals. + +B.3 No Data Error + + A "no data" response. The NSEC3 RR proves that the name exists and + that the requested RR type does not. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 28] + +Internet-Draft nsec3 june 2005 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + ns1.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK + mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g + qYIt90txzE/4+g== ) + wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN NSEC3 0 1 1 ( + deadbeaf + zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui + A NSEC3 RRSIG ) + wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN + ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd + oorBv4xkb0flXw== ) + ;; Additional + ;; (empty) + + The query returned an NSEC3 RR that proves that the requested name + exists ("ns1.example." hashes to "wbyijvpnyj33pcpi3i44ecnibnaj7eiw"), + but the requested RR type does not exist (type MX is absent in the + type code list of the NSEC RR). The negative reply is authenticated + by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner + identical to that of the MX RRset discussed above. + +B.3.1 No Data Error, Empty Non-Terminal + + A "no data" response because of an empty non-terminal. The NSEC3 RR + proves that the name exists and that the requested RR type does not. + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 29] + +Internet-Draft nsec3 june 2005 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + y.w.example. IN A + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK + mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g + qYIt90txzE/4+g== ) + jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN NSEC3 0 1 1 ( + deadbeaf + kcll7fqfnisuhfekckeeqnmbbd4maanu + NSEC3 RRSIG ) + jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V + IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK + 94Zbq3k8lgdpZA== ) + + The query returned an NSEC3 RR that proves that the requested name + exists ("y.w.example." hashes to "jt4bbfokgbmr57qx4nqucvvn7fmo6ab6"), + but the requested RR type does not exist (Type A is absent in the + type-bit-maps of the NSEC3 RR). The negative reply is authenticated + by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner + identical to that of the MX RRset discussed above. Note that, unlike + generic empty non terminal proof using NSECs, this is identical to + proving a No Data Error. This example is solely mentioned to be + complete. + +B.4 Referral to Signed Zone + + Referral to a signed zone. The DS RR contains the data which the + resolver will need to validate the corresponding DNSKEY RR in the + child zone's apex. + + + + +Laurie, et al. Expires December 3, 2005 [Page 30] + +Internet-Draft nsec3 june 2005 + + + ;; Header: QR DO RCODE=0 + ;; + + ;; Question + mc.a.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + a.example. 3600 IN NS ns1.a.example. + a.example. 3600 IN NS ns2.a.example. + a.example. 3600 IN DS 58470 5 1 ( + 3079F1593EBAD6DC121E202A8B766A6A4837 + 206C ) + a.example. 3600 IN RRSIG DS 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn + cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2 + 0kx7rGKTc3RQDA== ) + + ;; Additional + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + + The query returned a referral to the signed "a.example." zone. The + DS RR is authenticated in a manner identical to that of the MX RRset + discussed above. This DS RR is used to authenticate the "a.example" + DNSKEY RRset. + + Once the "a.example" DS RRset has been authenticated using the + "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset + for some "a.example" DNSKEY RR that matches the DS RR. If such a + matching "a.example" DNSKEY is found, the resolver checks whether + this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether + the signature lifetime is valid. If all these conditions are met, + all keys in the "a.example" DNSKEY RRset are considered + authenticated. + +B.5 Referral to Unsigned Zone using Opt-In + + Referral to an unsigned zone using Opt-In. The NSEC3 RR proves that + nothing for this delegation was signed in the parent zone. There is + no proof that the delegation exists + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 31] + +Internet-Draft nsec3 june 2005 + + + ;; Header: QR DO RCODE=0 + ;; + ;; Question + mc.b.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + b.example. 3600 IN NS ns1.b.example. + b.example. 3600 IN NS ns2.b.example. + kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN NSEC3 1 1 1 ( + deadbeaf + n42hbhnjj333xdxeybycax5ufvntux5d + MX NSEC3 RRSIG ) + kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA + IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx + TOLtc5jPrkL4zQ== ) + + ;; Additional + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + + The query returned a referral to the unsigned "b.example." zone. The + NSEC3 proves that no authentication leads from "example" to + "b.example", since the hash of "b.example" + ("ldjpfcucebeks5azmzpty4qlel4cftzo") is within the NSEC3 interval and + the NSEC3 opt-in bit is set. The NSEC3 RR is authenticated in a + manner identical to that of the MX RRset discussed above. + +B.6 Wildcard Expansion + + A successful query that was answered via wildcard expansion. The + label count in the answer's RRSIG RR indicates that a wildcard RRset + was expanded to produce this response, and the NSEC3 RR proves that + no closer match exists in the zone. + + + + + + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 32] + +Internet-Draft nsec3 june 2005 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN MX + + ;; Answer + a.z.w.example. 3600 IN MX 1 ai.example. + a.z.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 ( + 20050612112304 62699 example. + sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF + xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ + gQlgxEwhvQDEaQ== ) + ;; Authority + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 IN RRSIG NS 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l + m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d + 1SH5r/wfjuCg+g== ) + zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 ( + deadbeaf + 5pe7ctl7pfs2cilroy5dcofx4rcnlypd + MX NSEC3 RRSIG ) + zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt + 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny + OcFlrPGPMm48/A== ) + ;; Additional + ai.example. 3600 IN A 192.0.2.9 + ai.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU + 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq + ZXW5S+1VjMZYzQ== ) + ai.example. 3600 AAAA 2001:db8::f00:baa9 + ai.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV + ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns + l5/UqLCJJ9BDMg== ) + + The query returned an answer that was produced as a result of + wildcard expansion. The answer section contains a wildcard RRset + expanded as it would be in a traditional DNS response, and the + corresponding RRSIG indicates that the expanded wildcard MX RRset was + + + +Laurie, et al. Expires December 3, 2005 [Page 33] + +Internet-Draft nsec3 june 2005 + + + signed by an "example" DNSKEY with algorithm 5 and key tag 62699. + The RRSIG indicates that the original TTL of the MX RRset was 3600, + and, for the purpose of authentication, the current TTL is replaced + by 3600. The RRSIG labels field value of 2 indicates that the answer + is the result of wildcard expansion, as the "a.z.w.example" name + contains 4 labels. The name "a.z.w.example" is replaced by + "*.w.example", the MX RRset is placed in canonical form, and, + assuming that the current time falls between the signature inception + and expiration dates, the signature is authenticated. + + The NSEC3 proves that no closer match (exact or closer wildcard) + could have been used to answer this query, and the NSEC3 RR must also + be authenticated before the answer is considered valid. + +B.7 Wildcard No Data Error + + A "no data" response for a name covered by a wildcard. The NSEC3 RRs + prove that the matching wildcard name does not have any RRs of the + requested type and that no closer match exists in the zone. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 34] + +Internet-Draft nsec3 june 2005 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN AAAA + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK + mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g + qYIt90txzE/4+g== ) + zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 ( + deadbeaf + 5pe7ctl7pfs2cilroy5dcofx4rcnlypd + MX NSEC3 RRSIG ) + zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt + 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny + OcFlrPGPMm48/A== ) + ;; Additional + ;; (empty) + + The query returned NSEC3 RRs that prove that the requested data does + not exist and no wildcard applies. The negative reply is + authenticated by verifying both NSEC3 RRs. + +B.8 DS Child Zone No Data Error + + A "no data" response for a QTYPE=DS query that was mistakenly sent to + a name server for the child zone. + + + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 35] + +Internet-Draft nsec3 june 2005 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + example. IN DS + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK + mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g + qYIt90txzE/4+g== ) + dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN NSEC3 0 1 1 ( + deadbeaf + gmnfcccja7wkax3iv26bs75myptje3qk + MX DNSKEY NS SOA NSEC3 RRSIG ) + dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D + C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R + MOiKMSHozVebqw== ) + + ;; Additional + ;; (empty) + + The query returned NSEC RRs that shows the requested was answered by + a child server ("example" server). The NSEC RR indicates the + presence of an SOA RR, showing that the answer is from the child . + Queries for the "example" DS RRset should be sent to the parent + servers ("root" servers). + + + + + + + + + + + +Laurie, et al. Expires December 3, 2005 [Page 36] + +Internet-Draft nsec3 june 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Laurie, et al. Expires December 3, 2005 [Page 37] + diff --git a/doc/draft/draft-ietf-dnsext-rfc2538bis-01.txt b/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt similarity index 52% rename from doc/draft/draft-ietf-dnsext-rfc2538bis-01.txt rename to doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt index 0d0451ace1..2ec9dbec51 100644 --- a/doc/draft/draft-ietf-dnsext-rfc2538bis-01.txt +++ b/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt @@ -1,26 +1,25 @@ + Network Working Group S. Josefsson -Internet-Draft January 2005 -Expires: July 2, 2005 +Internet-Draft August 30, 2005 +Expires: March 3, 2006 Storing Certificates in the Domain Name System (DNS) - draft-ietf-dnsext-rfc2538bis-01 + draft-ietf-dnsext-rfc2538bis-04 Status of this Memo - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. 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. + 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 @@ -33,7 +32,7 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on July 2, 2005. + This Internet-Draft will expire on March 3, 2006. Copyright Notice @@ -41,46 +40,48 @@ Copyright Notice Abstract - Cryptographic public key are frequently published and their + Cryptographic public keys are frequently published and their authenticity demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). + This document obsoletes RFC 2538. -Josefsson Expires July 2, 2005 [Page 1] +Josefsson Expires March 3, 2006 [Page 1] -Internet-Draft Storing Certificates in the DNS January 2005 +Internet-Draft Storing Certificates in the DNS August 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3 - 2.1 Certificate Type Values . . . . . . . . . . . . . . . . . 4 - 2.2 Text Representation of CERT RRs . . . . . . . . . . . . . 5 - 2.3 X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.1. Certificate Type Values . . . . . . . . . . . . . . . . . 4 + 2.2. Text Representation of CERT RRs . . . . . . . . . . . . . 5 + 2.3. X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6 - 3.1 Content-based X.509 CERT RR Names . . . . . . . . . . . . 7 - 3.2 Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8 - 3.3 Content-based OpenPGP CERT RR Names . . . . . . . . . . . 8 - 3.4 Purpose-based OpenPGP CERT RR Names . . . . . . . . . . . 9 - 3.5 Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . . 9 - 4. Performance Considerations . . . . . . . . . . . . . . . . . . 9 - 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 8. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 - 9.2 Informative References . . . . . . . . . . . . . . . . . . . 12 - A. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 12 - Intellectual Property and Copyright Statements . . . . . . . . 14 + 3.1. Content-based X.509 CERT RR Names . . . . . . . . . . . . 7 + 3.2. Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8 + 3.3. Content-based OpenPGP CERT RR Names . . . . . . . . . . . 9 + 3.4. Purpose-based OpenPGP CERT RR Names . . . . . . . . . . . 9 + 3.5. Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . . 9 + 4. Performance Considerations . . . . . . . . . . . . . . . . . . 10 + 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 9. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11 + Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 12 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 + Intellectual Property and Copyright Statements . . . . . . . . . . 15 @@ -107,10 +108,9 @@ Table of Contents - -Josefsson Expires July 2, 2005 [Page 2] +Josefsson Expires March 3, 2006 [Page 2] -Internet-Draft Storing Certificates in the DNS January 2005 +Internet-Draft Storing Certificates in the DNS August 2005 1. Introduction @@ -127,7 +127,7 @@ Internet-Draft Storing Certificates in the DNS January 2005 certificates/revocations used by OpenPGP software. Section 2 below specifies a CERT resource record (RR) for the storage - of certificates in the Domain Name System. + of certificates in the Domain Name System [1] [2]. Section 3 discusses appropriate owner names for CERT RRs. @@ -136,7 +136,8 @@ Internet-Draft Storing Certificates in the DNS January 2005 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [10]. + document are to be interpreted as described in [3]. + 2. The CERT Resource Record @@ -153,26 +154,21 @@ Internet-Draft Storing Certificates in the DNS January 2005 / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - The type field is the certificate type as define in section 2.1 + The type field is the certificate type as defined in section 2.1 below. - The algorithm field has the same meaning as the algorithm field in - DNSKEY and RRSIG RRs [9] except that a zero algorithm field indicates - the algorithm is unknown to a secure DNS, which may simply be the - result of the algorithm not having been standardized for DNSSEC. - - - - -Josefsson Expires July 2, 2005 [Page 3] - -Internet-Draft Storing Certificates in the DNS January 2005 - - The key tag field is the 16 bit value computed for the key embedded - in the certificate, using the RRSIG Key Tag Algorithm described in - Appendix B of [9]. This field is used as an efficiency measure to + in the certificate, using the RRSIG Key Tag algorithm described in + Appendix B of [10]. This field is used as an efficiency measure to pick which CERT RRs may be applicable to a particular key. The key + + + +Josefsson Expires March 3, 2006 [Page 3] + +Internet-Draft Storing Certificates in the DNS August 2005 + + tag can be calculated for the key in question and then only CERT RRs with the same key tag need be examined. However, the key must always be transformed to the format it would have as the public key portion @@ -181,61 +177,68 @@ Internet-Draft Storing Certificates in the DNS January 2005 limits) defined for DNS security. If it is not, the algorithm field MUST BE zero and the tag field is meaningless and SHOULD BE zero. -2.1 Certificate Type Values + The algorithm field has the same meaning as the algorithm field in + DNSKEY and RRSIG RRs [10], except that a zero algorithm field + indicates the algorithm is unknown to a secure DNS, which may simply + be the result of the algorithm not having been standardized for + DNSSEC. + +2.1. Certificate Type Values The following values are defined or reserved: - Value Mnemonic Certificate Type - ----- -------- ----------- ---- - 0 reserved - 1 PKIX X.509 as per PKIX - 2 SPKI SPKI certificate - 3 PGP OpenPGP packet - 4 IPKIX The URL of an X.509 data object - 5 ISPKI The URL of an SPKI certificate - 6 IPGP The URL of an OpenPGP packet - 7-252 available for IANA assignment - 253 URI URI private - 254 OID OID private - 255-65534 available for IANA assignment - 65535 reserved + Value Mnemonic Certificate Type + ----- -------- ---------------- + 0 reserved + 1 PKIX X.509 as per PKIX + 2 SPKI SPKI certificate + 3 PGP OpenPGP packet + 4 IPKIX The URL of an X.509 data object + 5 ISPKI The URL of an SPKI certificate + 6 IPGP The URL of an OpenPGP packet + 7-252 available for IANA assignment + 253 URI URI private + 254 OID OID private + 255-65534 available for IANA assignment + 65535 reserved The PKIX type is reserved to indicate an X.509 certificate conforming to the profile being defined by the IETF PKIX working group. The - certificate section will start with a one byte unsigned OID length + certificate section will start with a one-byte unsigned OID length and then an X.500 OID indicating the nature of the remainder of the certificate section (see 2.3 below). (NOTE: X.509 certificates do not include their X.500 directory type designating OID as a prefix.) - The SPKI type is reserved to indicate a certificate formated as to be - specified by the IETF SPKI working group. + The SPKI type is reserved to indicate the SPKI certificate format + [13], for use when the SPKI documents are moved from experimental + status. - The PGP type indicates an OpenPGP packet as described in [5] and its + The PGP type indicates an OpenPGP packet as described in [6] and its extensions and successors. Two uses are to transfer public key material and revocation signatures. The data is binary, and MUST NOT be encoded into an ASCII armor. An implementation SHOULD process - transferable public keys as described in section 10.1 of [5], but it - MAY handle additional OpenPGP packets. - -Josefsson Expires July 2, 2005 [Page 4] +Josefsson Expires March 3, 2006 [Page 4] -Internet-Draft Storing Certificates in the DNS January 2005 +Internet-Draft Storing Certificates in the DNS August 2005 + transferable public keys as described in section 10.1 of [6], but it + MAY handle additional OpenPGP packets. + The IPKIX, ISPKI and IPGP types indicate a URL which will serve the content that would have been in the "certificate, CRL or URL" field of the corresponding (PKIX, SPKI or PGP) packet types. These types are known as "indirect". These packet types MUST be used when the content is too large to fit in the CERT RR, and MAY be used at the - implementations discretion. They SHOULD NOT be used where the entire + implementer's discretion. They SHOULD NOT be used where the entire UDP packet would have fit in 512 bytes. The URI private type indicates a certificate format defined by an absolute URI. The certificate portion of the CERT RR MUST begin with - a null terminated URI [4] and the data after the null is the private + a null terminated URI [5] and the data after the null is the private format certificate itself. The URI SHOULD be such that a retrieval from it will lead to documentation on the format of the certificate. Recognition of private certificate types need not be based on URI @@ -244,16 +247,16 @@ Internet-Draft Storing Certificates in the DNS January 2005 URI. The OID private type indicates a private format certificate specified - by a an ISO OID prefix. The certificate section will start with a - one byte unsigned OID length and then a BER encoded OID indicating - the nature of the remainder of the certificate section. This can be - an X.509 certificate format or some other format. X.509 certificates + by an ISO OID prefix. The certificate section will start with a one- + byte unsigned OID length and then a BER encoded OID indicating the + nature of the remainder of the certificate section. This can be an + X.509 certificate format or some other format. X.509 certificates that conform to the IETF PKIX profile SHOULD be indicated by the PKIX type, not the OID private type. Recognition of private certificate types need not be based on OID equality but can use various forms of pattern matching such as OID prefix. -2.2 Text Representation of CERT RRs +2.2. Text Representation of CERT RRs The RDATA portion of a CERT RR has the type field as an unsigned decimal integer or as a mnemonic symbol as listed in section 2.1 @@ -262,35 +265,35 @@ Internet-Draft Storing Certificates in the DNS January 2005 The key tag field is represented as an unsigned decimal integer. The algorithm field is represented as an unsigned decimal integer or - a mnemonic symbol as listed in [9]. + a mnemonic symbol as listed in [10]. - The certificate / CRL portion is represented in base 64 [11] and may + The certificate / CRL portion is represented in base 64 [14] and may be divided up into any number of white space separated substrings, down to single base 64 digits, which are concatenated to obtain the full signature. These substrings can span lines using the standard parenthesis. - Note that the certificate / CRL portion may have internal sub-fields + + + +Josefsson Expires March 3, 2006 [Page 5] + +Internet-Draft Storing Certificates in the DNS August 2005 + + + Note that the certificate / CRL portion may have internal sub-fields, but these do not appear in the master file representation. For example, with type 254, there will be an OID size, an OID, and then - - - -Josefsson Expires July 2, 2005 [Page 5] - -Internet-Draft Storing Certificates in the DNS January 2005 - - the certificate / CRL proper. But only a single logical base 64 string will appear in the text representation. -2.3 X.509 OIDs +2.3. X.509 OIDs OIDs have been defined in connection with the X.500 directory for user certificates, certification authority certificates, revocations of certification authority, and revocations of user certificates. The following table lists the OIDs, their BER encoding, and their - length prefixed hex format for use in CERT RRs: + length-prefixed hex format for use in CERT RRs: id-at-userCertificate = { joint-iso-ccitt(2) ds(5) at(4) 36 } @@ -317,45 +320,43 @@ Internet-Draft Storing Certificates in the DNS January 2005 Following some of the guidelines below may result in the use in DNS names of characters that require DNS quoting which is to use a backslash followed by the octal representation of the ASCII code for - the character such as \000 for NULL. + the character (e.g., \000 for NULL). The choice of name under which CERT RRs are stored is important to - clients that perform CERT queries. In some situations, the client + clients that perform CERT queries. In some situations, the clients may not know all information about the CERT RR object it wishes to retrieve. For example, a client may not know the subject name of an X.509 certificate, or the e-mail address of the owner of an OpenPGP key. Further, the client might only know the hostname of a service that uses X.509 certificates or the Key ID of an OpenPGP key. - This motivates describing two different owner name guidelines. We - call the two rules content-based owner names and purpose-based owner - -Josefsson Expires July 2, 2005 [Page 6] +Josefsson Expires March 3, 2006 [Page 6] -Internet-Draft Storing Certificates in the DNS January 2005 +Internet-Draft Storing Certificates in the DNS August 2005 - names. A content-based owner name is derived from the content of the - CERT RR data; for example the Subject field in an X.509 certificate - or the User ID field in OpenPGP keys. A purpose-based owner name is - selected to be a name that clients that wishes to retrieve CERT RRs - are expected to know; for example the host name of a X.509 protected - service or a Key ID of an OpenPGP key. Note that in some situations, - the content-based and purpose-based owner name can be the same; for - example when a client look up keys based on e-mail addresses for - incoming e-mail. + Therefore, two owner name guidelines are defined: content-based owner + names and purpose-based owner names. A content-based owner name is + derived from the content of the CERT RR data; for example, the + Subject field in an X.509 certificate or the User ID field in OpenPGP + keys. A purpose-based owner name is a name that a client retrieving + CERT RRs MUST already know; for example, the host name of an X.509 + protected service or the Key ID of an OpenPGP key. The content-based + and purpose-based owner name MAY be the same; for example, when a + client looks up a key based on the From: address of an incoming + e-mail. Implementations SHOULD use the purpose-based owner name guidelines - described in this document, and MAY use CNAMEs at content-based owner + described in this document, and MAY use CNAMEs of content-based owner names (or other names), pointing to the purpose-based owner name. -3.1 Content-based X.509 CERT RR Names +3.1. Content-based X.509 CERT RR Names Some X.509 versions permit multiple names to be associated with subjects and issuers under "Subject Alternate Name" and "Issuer - Alternate Name". For example, x.509v3 has such Alternate Names with + Alternate Name". For example, X.509v3 has such Alternate Names with an ASN.1 specification as follows: GeneralName ::= CHOICE { @@ -377,96 +378,97 @@ Internet-Draft Storing Certificates in the DNS January 2005 2. If a domain name is not included but an IP address is included, then the translation of that IP address into the appropriate inverse domain name should be used. - 3. If neither of the above it used but a URI containing a domain + 3. If neither of the above is used, but a URI containing a domain name is present, that domain name should be used. 4. If none of the above is included but a character string name is included, then it should be treated as described for OpenPGP names below. - 5. If none of the above apply, then the distinguished name (DN) - should be mapped into a domain name as specified in [3]. -Josefsson Expires July 2, 2005 [Page 7] + +Josefsson Expires March 3, 2006 [Page 7] -Internet-Draft Storing Certificates in the DNS January 2005 +Internet-Draft Storing Certificates in the DNS August 2005 - Example 1: Assume that an X.509v3 certificate is issued to /CN=John - Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative - names of (a) string "John (the Man) Doe", (b) domain name john- - doe.com, and (c) uri . Then - the storage locations recommended, in priority order, would be + 5. If none of the above apply, then the distinguished name (DN) + should be mapped into a domain name as specified in [4]. + + Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/ + DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a) + string "John (the Man) Doe", (b) domain name john-doe.com, and (c) + uri . The storage locations + recommended, in priority order, would be 1. john-doe.com, 2. www.secure.john-doe.com, and 3. Doe.com.xy. - Example 2: Assume that an X.509v3 certificate is issued to /CN=James - Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names - of (a) domain name widget.foo.example, (b) IPv4 address - 10.251.13.201, and (c) string "James Hacker - ". Then the storage locations - recommended, in priority order, would be + Example 2: An X.509v3 certificate is issued to /CN=James Hacker/ + L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a) + domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and + (c) string "James Hacker ". The + storage locations recommended, in priority order, would be 1. widget.foo.example, 2. 201.13.251.10.in-addr.arpa, and 3. hacker.mail.widget.foo.example. -3.2 Purpose-based X.509 CERT RR Names +3.2. Purpose-based X.509 CERT RR Names - It is difficult for clients that do not already posses a certificate - to reconstruct the content-based owner name that should be used to - retrieve the certificate. For this reason, purpose-based owner names - are recommended in this section. Because purpose-based owner names - by nature depend on the specific scenario, or purpose, for which the - certificate will be used, there are more than one recommendation. - The following table summarize the purpose-based X.509 CERT RR owner - name guidelines. + Due to the difficulty for clients that do not already possess a + certificate to reconstruct the content-based owner name, purpose- + based owner names are recommended in this section. Recommendations + for purpose-based owner names vary per scenario. The following table + summarizes the purpose-based X.509 CERT RR owner name guidelines for + use with S/MIME [16], SSL/TLS [11], and IPSEC [12]: - Scenario Owner name - ------------------------------------------------------------------- - S/MIME Certificate Standard translation of RFC 822 email address. - Example: A S/MIME certificate for - "postmaster@example.org" will use a standard - hostname translation of the owner name, - i.e. "postmaster.example.org". + Scenario Owner name + ------------------ ---------------------------------------------- + S/MIME Certificate Standard translation of an RFC 2822 email + address. Example: An S/MIME certificate for + "postmaster@example.org" will use a standard + hostname translation of the owner name, + "postmaster.example.org". - SSL Certificate Hostname of the SSL server. + TLS Certificate Hostname of the TLS server. - IPSEC Certificate Hostname of the IPSEC machine, and/or - for the in-addr.arpa reverse lookup IP address. + IPSEC Certificate Hostname of the IPSEC machine and/or, for IPv4 + or IPv6 addresses, the fully qualified domain + name in the appropriate reverse domain. - An alternative approach for IPSEC is to store raw public keys [12]. + An alternate approach for IPSEC is to store raw public keys [15]. -3.3 Content-based OpenPGP CERT RR Names + + + + + +Josefsson Expires March 3, 2006 [Page 8] + +Internet-Draft Storing Certificates in the DNS August 2005 + + +3.3. Content-based OpenPGP CERT RR Names OpenPGP signed keys (certificates) use a general character string - - - -Josefsson Expires July 2, 2005 [Page 8] - -Internet-Draft Storing Certificates in the DNS January 2005 - - - User ID [5]. However, it is recommended by OpenPGP that such names - include the RFC 2822 [7] email address of the party, as in "Leslie + User ID [6]. However, it is recommended by OpenPGP that such names + include the RFC 2822 [8] email address of the party, as in "Leslie Example ". If such a format is used, the CERT should be under the standard translation of the email address into a domain name, which would be leslie.host.example in this case. If no - RFC 2822 name can be extracted from the string name no specific + RFC 2822 name can be extracted from the string name, no specific domain name is recommended. If a user has more than one email address, the CNAME type can be used - to reduce the amount of data stored in the DNS. For example: + to reduce the amount of data stored in the DNS. Example: $ORIGIN example.org. smith IN CERT PGP 0 0 john.smith IN CNAME smith js IN CNAME smith - -3.4 Purpose-based OpenPGP CERT RR Names +3.4. Purpose-based OpenPGP CERT RR Names Applications that receive an OpenPGP packet containing encrypted or signed data but do not know the email address of the sender will have @@ -474,205 +476,171 @@ Internet-Draft Storing Certificates in the DNS January 2005 content-based owner name guidelines. However, these clients commonly know the key fingerprint or the Key ID. The key ID is found in OpenPGP packets, and the key fingerprint is commonly found in - auxilliary data that may be available. For these situations, it is - recommended to use an owner name identical to the key fingerprint and - key ID expressed in hexadecimal [11]. For example: + auxilliary data that may be available. In this case, use of an owner + name identical to the key fingerprint and the key ID expressed in + hexadecimal [14] is recommended. Example: $ORIGIN example.org. 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ... F835EDA21E94B565716F IN CERT PGP ... B565716F IN CERT PGP ... - If the same key material is stored at several owner names, the use of - CNAME may be used to avoid data duplication. Note that CNAME is not - always applicable, because it map an owner names to the other for all - purposes, and this may be sub-optimal when two keys with the same Key - ID are stored. + If the same key material is stored for several owner names, the use + of CNAME may be used to avoid data duplication. Note that CNAME is + not always applicable, because it maps one owner name to the other + for all purposes, which may be sub-optimal when two keys with the + same Key ID are stored. -3.5 Owner names for IPKIX, ISPKI, and IPGP +3.5. Owner names for IPKIX, ISPKI, and IPGP These types are stored under the same owner names, both purpose- and - content-based, as the PKIX, SPKI and PGP types, respectively. + content-based, as the PKIX, SPKI and PGP types. + + + + + +Josefsson Expires March 3, 2006 [Page 9] + +Internet-Draft Storing Certificates in the DNS August 2005 + 4. Performance Considerations Current Domain Name System (DNS) implementations are optimized for - - - -Josefsson Expires July 2, 2005 [Page 9] - -Internet-Draft Storing Certificates in the DNS January 2005 - - small transfers, typically not more than 512 bytes including overhead. While larger transfers will perform correctly and work is underway to make larger transfers more efficient, it is still advisable at this time to make every reasonable effort to minimize the size of certificates stored within the DNS. Steps that can be - taken may include using the fewest possible optional or extensions - fields and using short field values for variable length fields that - must be included. + taken may include using the fewest possible optional or extension + fields and using short field values for necessary variable length + fields. The RDATA field in the DNS protocol may only hold data of size 65535 - octets (64kb) or less. This means that each CERT RR cannot contain - more than 64kb worth of payload, even if the corresponding - certificate or certificate revocation list is larger. This document - address this by defining "indirect" data types for each normal type. + octets (64kb) or less. This means that each CERT RR MUST NOT contain + more than 64kb of payload, even if the corresponding certificate or + certificate revocation list is larger. This document addresses this + by defining "indirect" data types for each normal type. -5. Acknowledgements + +5. Contributors The majority of this document is copied verbatim from RFC 2538, by Donald Eastlake 3rd and Olafur Gudmundsson. - The author wishes to thank David Shaw and Michael Graff for their - contributions to the earlier work that motivated this revised + +6. Acknowledgements + + Thanks to David Shaw and Michael Graff for their contributions to + earlier works that motivated, and served as inspiration for, this document. This document was improved by suggestions and comments from Olivier - Dubuisson, Ben Laurie, Samuel Weiler, and Florian Weimer. No doubt - the list is incomplete. We apologize to anyone we left out. + Dubuisson, Olaf M. Kolkman, Ben Laurie, Edward Lewis, Jason + Sloderbeck, Samuel Weiler, and Florian Weimer. No doubt the list is + incomplete. We apologize to anyone we left out. -6. Security Considerations + +7. Security Considerations By definition, certificates contain their own authenticating - signature. Thus it is reasonable to store certificates in non-secure - DNS zones or to retrieve certificates from DNS with DNS security - checking not implemented or deferred for efficiency. The results MAY - be trusted if the certificate chain is verified back to a known - trusted key and this conforms with the user's security policy. + signature. Thus, it is reasonable to store certificates in non- + secure DNS zones or to retrieve certificates from DNS with DNS + security checking not implemented or deferred for efficiency. The + results MAY be trusted if the certificate chain is verified back to a + known trusted key and this conforms with the user's security policy. Alternatively, if certificates are retrieved from a secure DNS zone with DNS security checking enabled and are verified by DNS security, + + + +Josefsson Expires March 3, 2006 [Page 10] + +Internet-Draft Storing Certificates in the DNS August 2005 + + the key within the retrieved certificate MAY be trusted without verifying the certificate chain if this conforms with the user's security policy. + If an organization chooses to issue certificates for it's employees, + placing CERT RR's in the DNS by owner name, and if DNSSEC (with NSEC) + is in use, it is possible for someone to enumerate all employees of + the organization. This is usually not considered desirable, for the + same reason enterprise phone listings are not often publicly + published and are even mark confidential. + When the URI type is used, it should be understood that it introduces an additional indirection that may allow for a new attack vector. One method to secure that indirection is to include a hash of the certificate in the URI itself. - - - -Josefsson Expires July 2, 2005 [Page 10] - -Internet-Draft Storing Certificates in the DNS January 2005 - - - CERT RRs are not used by DNSSEC [8] so there are no security + CERT RRs are not used by DNSSEC [9], so there are no security considerations related to CERT RRs and securing the DNS itself. - If DNSSEC [8] is used then the non-existence of a CERT RR, and - consequently certificates or revocation lists, can be securely + If DNSSEC is used, then the non-existence of a CERT RR and, + consequently, certificates or revocation lists can be securely asserted. Without DNSSEC, this is not possible. -7. IANA Considerations + +8. IANA Considerations Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can - only be assigned by an IETF standards action [6]. This document + only be assigned by an IETF standards action [7]. This document assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE. Certificate - types 0x0100 through 0xFEFF are assigned through IETF Consensus [6] + types 0x0100 through 0xFEFF are assigned through IETF Consensus [7] based on RFC documentation of the certificate type. The availability of private types under 0x00FD and 0x00FE should satisfy most requirements for proprietary or private types. -8. Changes since RFC 2538 + The CERT RR reuses the DNS Security Algorithm Numbers registry. In + particular, the CERT RR requires that algorithm number 0 remain + reserved, as described in Section 2. The IANA is directed to + reference the CERT RR as a user of this registry and value 0, in + particular. - 1. Editorial changes to conform with new document requirements, - including splitting reference section into two parts and updating - the references to point at latest versions, and to add some - additional references. - 2. Improve terminology. For example replace "PGP" with "OpenPGP", - to align with RFC 2440. - 3. In section 2.1, clarify that OpenPGP public key data are binary, - not the ASCII armored format, and reference 10.1 in RFC 2440 on - how to deal with OpenPGP keys, and acknowledge that - implementations may handle additional packet types. - 4. Clarify that integers in the representation format are decimal. - 5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis - terminology. Improve reference for Key Tag Algorithm - calculations. - 6. Add examples that suggest use of CNAME to reduce bandwidth. - 7. In section 3, appended the last paragraphs that discuss - "content-based" vs "purpose-based" owner names. Add section 3.2 - for purpose-based X.509 CERT owner names, and section 3.4 for - purpose-based OpenPGP CERT owner names. - 8. Added size considerations. - 9. Added indirect types IPKIX, ISPKI, and IPGP. -9. References +9. Changes since RFC 2538 -9.1 Normative References - - [1] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. + 1. Editorial changes to conform with new document requirements, + including splitting reference section into two parts and + updating the references to point at latest versions, and to add + some additional references. -Josefsson Expires July 2, 2005 [Page 11] +Josefsson Expires March 3, 2006 [Page 11] -Internet-Draft Storing Certificates in the DNS January 2005 +Internet-Draft Storing Certificates in the DNS August 2005 - [2] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. + 2. Improve terminology. For example replace "PGP" with "OpenPGP", + to align with RFC 2440. + 3. In section 2.1, clarify that OpenPGP public key data are binary, + not the ASCII armored format, and reference 10.1 in RFC 2440 on + how to deal with OpenPGP keys, and acknowledge that + implementations may handle additional packet types. + 4. Clarify that integers in the representation format are decimal. + 5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis + terminology. Improve reference for Key Tag Algorithm + calculations. + 6. Add examples that suggest use of CNAME to reduce bandwidth. + 7. In section 3, appended the last paragraphs that discuss + "content-based" vs "purpose-based" owner names. Add section 3.2 + for purpose-based X.509 CERT owner names, and section 3.4 for + purpose-based OpenPGP CERT owner names. + 8. Added size considerations. + 9. The SPKI types has been reserved, until RFC 2692/2693 is moved + from the experimental status. + 10. Added indirect types IPKIX, ISPKI, and IPGP. - [3] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri, - "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, - January 1998. - - [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource - Identifiers (URI): Generic Syntax", RFC 2396, August 1998. - - [5] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP - Message Format", RFC 2440, November 1998. - - [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - - [7] Resnick, P., "Internet Message Format", RFC 2822, April 2001. - - [8] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, - "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-13 (work in progress), October - 2004. - - [9] Arends, R., "Resource Records for the DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-11 (work in progress), October - 2004. - -9.2 Informative References - - [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [11] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", - RFC 3548, July 2003. - - [12] Richardson, M., "A method for storing IPsec keying material in - DNS", draft-ietf-ipseckey-rr-11 (work in progress), July 2004. - - -Author's Address - - Simon Josefsson - - EMail: simon@josefsson.org Appendix A. Copying conditions Regarding the portion of this document that was written by Simon - - - -Josefsson Expires July 2, 2005 [Page 12] - -Internet-Draft Storing Certificates in the DNS January 2005 - - Josefsson ("the author", for the remainder of this section), the author makes no guarantees and is not responsible for any damage resulting from its use. The author grants irrevocable permission to @@ -683,50 +651,138 @@ Internet-Draft Storing Certificates in the DNS January 2005 be licensed under similar terms. +10. References + +10.1. Normative References + + [1] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [4] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri, - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Josefsson Expires July 2, 2005 [Page 13] +Josefsson Expires March 3, 2006 [Page 12] -Internet-Draft Storing Certificates in the DNS January 2005 +Internet-Draft Storing Certificates in the DNS August 2005 + + + "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, + January 1998. + + [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, + August 1998. + + [6] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, + "OpenPGP Message Format", RFC 2440, November 1998. + + [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [8] Resnick, P., "Internet Message Format", RFC 2822, April 2001. + + [9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [10] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + +10.2. Informative References + + [11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + [12] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + [13] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., + and T. Ylonen, "SPKI Certificate Theory", RFC 2693, + September 1999. + + [14] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", + RFC 3548, July 2003. + + [15] Richardson, M., "A Method for Storing IPsec Keying Material in + DNS", RFC 4025, March 2005. + + [16] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions + (S/MIME) Version 3.1 Message Specification", RFC 3851, + July 2004. + + + + + + +Josefsson Expires March 3, 2006 [Page 13] + +Internet-Draft Storing Certificates in the DNS August 2005 + + +Author's Address + + Simon Josefsson + + Email: simon@josefsson.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires March 3, 2006 [Page 14] + +Internet-Draft Storing Certificates in the DNS August 2005 Intellectual Property Statement @@ -780,6 +836,5 @@ Acknowledgment -Josefsson Expires July 2, 2005 [Page 14] +Josefsson Expires March 3, 2006 [Page 15] - diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-timers-00.txt b/doc/draft/draft-ietf-dnsext-trustupdate-timers-00.txt deleted file mode 100644 index 32460b89b4..0000000000 --- a/doc/draft/draft-ietf-dnsext-trustupdate-timers-00.txt +++ /dev/null @@ -1,729 +0,0 @@ - - -Network Working Group M. StJohns -Internet-Draft Nominum, Inc. -Expires: April 14, 2005 October 14, 2004 - - - Automated Updates of DNSSEC Trust Anchors - draft-ietf-dnsext-trustupdate-timers-00 - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on April 14, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). - -Abstract - - This document describes a means for automated, authenticated and - authorized updating of DNSSEC "trust anchors". The method provides - protection against single key compromise of a key in the trust point - key set. Based on the trust established by the presence of a current - anchor, other anchors may be added at the same place in the - hierarchy, and, ultimately, supplant the existing anchor. - - This mechanism, if adopted, will require changes to resolver - - - -StJohns Expires April 14, 2005 [Page 1] - -Internet-Draft trustanchor-update October 2004 - - - management behavior (but not resolver resolution behavior), and the - addition of a single flag bit to the DNSKEY record. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1 Compliance Nomenclature . . . . . . . . . . . . . . . . . 3 - 1.2 Changes since -00 . . . . . . . . . . . . . . . . . . . . 3 - 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 - 2.1 Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.2 Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5 - 2.3 Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5 - 2.4 Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6 - 2.5 Resolver Parameters . . . . . . . . . . . . . . . . . . . 6 - 2.5.1 Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6 - 2.5.2 Remove Hold-Down Time . . . . . . . . . . . . . . . . 6 - 2.5.3 Minimum Trust Anchors per Trust Point . . . . . . . . 6 - 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6 - 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 4.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.2 States . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 5.1 Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 8 - 5.2 Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9 - 5.3 Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9 - 5.4 Active Key Compromised . . . . . . . . . . . . . . . . . . 9 - 5.5 Stand-by Key Compromised . . . . . . . . . . . . . . . . . 9 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 6.1 Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10 - 6.2 Multiple Key Compromise . . . . . . . . . . . . . . . . . 10 - 6.3 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 10 - 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 - Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 - Intellectual Property and Copyright Statements . . . . . . . . 12 - - - - - - - - - - - - - - - - -StJohns Expires April 14, 2005 [Page 2] - -Internet-Draft trustanchor-update October 2004 - - -1. Introduction - - As part of the reality of fielding DNSSEC (Domain Name System - Security Extensions) [RFC2535][DSINTRO][DSPROT][DSREC], the community - has come to the realization that there will not be one signed name - space, but rather islands of signed name space each originating from - specific points (i.e. 'trust points') in the DNS tree. Each of - those islands will be identified by the trust point name, and - validated by at least one associated public key. For the purpose of - this document we'll call the association of that name and a - particular key a 'trust anchor'. A particular trust point can have - more than one key designated as a trust anchor. - - For a DNSSEC-aware resolver to validate information in a DNSSEC - protected branch of the hierarchy, it must have knowledge of a trust - anchor applicable to that branch. It may also have more than one - trust anchor for any given trust point. Under current rules, a chain - of trust for DNSSEC-protected data that chains its way back to ANY - known trust anchor is considered 'secure'. - - Because of the probable balkanization of the DNSSEC tree due to - signing voids at key locations, a resolver may need to know literally - thousands of trust anchors to perform its duties. (e.g. Consider an - unsigned ".COM".) Requiring the owner of the resolver to manually - manage this many relationships is problematic. It's even more - problematic when considering the eventual requirement for key - replacement/update for a given trust anchor. The mechanism described - herein won't help with the initial configuration of the trust anchors - in the resolvers, but should make trust point key - replacement/rollover more viable. - - As mentioned above, this document describes a mechanism whereby a - resolver can update the trust anchors for a given trust point, mainly - without human intervention at the resolver. There are some corner - cases discussed (e.g. multiple key compromise) that may require - manual intervention, but they should be few and far between. This - document DOES NOT discuss the general problem of the initial - configuration of trust anchors for the resolver. - -1.1 Compliance Nomenclature - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14, [RFC2119]. - -1.2 Changes since -00 - - Resubmitted draft-stjohns-dnssec-trustupdate as a working group - - - -StJohns Expires April 14, 2005 [Page 3] - -Internet-Draft trustanchor-update October 2004 - - - draft. - - Added the concept of timer triggered resolver queries to refresh the - resolvers view of the trust anchor key RRSet. - -2. Theory of Operation - - The general concept of this mechanism is that existing trust anchors - can be used to authenticate new trust anchors at the same point in - the DNS hierarchy. When a new SEP key is added to a trust point - DNSKEY RRSet, and when that RRSet is validated by an existing trust - anchor, then the new key can be added to the set of trust anchors. - - There are some issues with this approach which need to be mitigated. - For example, a compromise of one of the existing keys could allow an - attacker to add their own 'valid' data. This implies a need for a - method to revoke an existing key regardless of whether or not that - key is compromised. As another example assuming a single key - compromise, an attacker could add a new key and revoke all the other - old keys. - -2.1 Revocation - - Assume two trust anchor keys A and B. Assume that B has been - compromised. Without a specific revocation bit, B could invalidate A - simply by sending out a signed trust point key set which didn't - contain A. To fix this, we add a mechanism which requires knowledge - of the private key of a DNSKEY to revoke that DNSKEY. - - A key is considered revoked when the resolver sees the key in a - self-signed RRSet and the key has the REVOKE bit set to '1'. Once - the resolver sees the REVOKE bit, it MUST NOT use this key as a trust - anchor or for any other purposes except validating the RRSIG over the - DNSKEY RRSet specifically for the purpose of validating the - revocation. Unlike the 'Add' operation below, revocation is - immediate and permanent upon receipt of a valid revocation at the - resolver. - - N.B. A DNSKEY with the REVOKE bit set has a different fingerprint - than one without the bit set. This affects the matching of a DNSKEY - to DS records in the parent, or the fingerprint stored at a resolver - used to configure a trust point. [msj3] - - In the given example, the attacker could revoke B because it has - knowledge of B's private key, but could not revoke A. - - - - - - -StJohns Expires April 14, 2005 [Page 4] - -Internet-Draft trustanchor-update October 2004 - - -2.2 Add Hold-Down - - Assume two trust point keys A and B. Assume that B has been - compromised. An attacker could generate and add a new trust anchor - key - C (by adding C to the DNSKEY RRSet and signing it with B), and - then invalidate the compromised key. This would result in the both - the attacker and owner being able to sign data in the zone and have - it accepted as valid by resolvers. - - To mitigate, but not completely solve, this problem, we add a - hold-down time to the addition of the trust anchor. When the - resolver sees a new SEP key in a validated trust point DNSKEY RRSet, - the resolver starts an acceptance timer, and remembers all the keys - that validated the RRSet. If the resolver ever sees the DNSKEY RRSet - without the new key but validly signed, it stops the acceptance - process and resets the acceptance timer. If all of the keys which - were originally used to validate this key are revoked prior to the - timer expiring, the resolver stops the acceptance process and resets - the timer. - - Once the timer expires, the new key will be added as a trust anchor - the next time the validated RRSet with the new key is seen at the - resolver. The resolver MUST NOT treat the new key as a trust anchor - until the hold down time expires AND it has retrieved and validated a - DNSKEY RRSet after the hold down time which contains the new key. - - N.B.: Once the resolver has accepted a key as a trust anchor, the key - MUST be considered a valid trust anchor by that resolver until - explictly revoked as described above. - - In the given example, the zone owner can recover from a compromise by - revoking B and adding a new key D and signing the DNSKEY RRSet with - both A and B. - - The reason this does not completely solve the problem has to do with - the distributed nature of DNS. The resolver only knows what it sees. - A determined attacker who holds one compromised key could keep a - single resolver from realizing that key had been compromised by - intercepting 'real' data from the originating zone and substituting - their own (e.g. using the example, signed only by B). This is no - worse than the current situation assuming a compromised key. - -2.3 Remove Hold-down - - A new key which has been seen by the resolver, but hasn't reached - it's add hold-down time, MAY be removed from the DNSKEY RRSet by the - zone owner. If the resolver sees a validated DNSKEY RRSet without - this key, it waits for the remove hold-down time and then, if the key - - - -StJohns Expires April 14, 2005 [Page 5] - -Internet-Draft trustanchor-update October 2004 - - - hasn't reappeared, SHOULD discard any information about the key. - -2.4 Active Refresh - - A resolver which has been configured for automatic update of keys - from a particular trust point MUST query that trust point (e.g. do a - lookup for the DNSKEY RRSet and related RRSIG records) no less often - than the lesser of 15 days or half the original TTL for the DNSKEY - RRSet or half the RRSIG expiration interval. The expiration interval - is the amount of time from when the RRSIG was last retrieved until - the expiration time in the RRSIG. - - If the query fails, the resolver MUST repeat the query until - satisfied no more often than once an hour and no less often than the - lesser of 1 day or 10% of the original TTL or 10% of the original - expiration interval. - -2.5 Resolver Parameters - -2.5.1 Add Hold-Down Time - - The add hold-down time is 30 days or the expiration time of the TTL - of the first trust point DNSKEY RRSet which contained the key, - whichever is greater. This ensures that at least two validated - DNSKEY RRSets which contain the new key MUST be seen by the resolver - prior to the key's acceptance. - -2.5.2 Remove Hold-Down Time - - The remove hold-down time is 30 days. - -2.5.3 Minimum Trust Anchors per Trust Point - - A compliant resolver MUST be able to manage at least five SEP keys - per trust point. - -3. Changes to DNSKEY RDATA Wire Format - - Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE' - flag. If this bit is set to '1', AND the resolver sees an - RRSIG(DNSKEY) signed by the associated key, then the resolver MUST - consider this key permanently invalid for all purposes except for - validing the revocation. - -4. State Table - - The most important thing to understand is the resolver's view of any - key at a trust point. The following state table describes that view - - - -StJohns Expires April 14, 2005 [Page 6] - -Internet-Draft trustanchor-update October 2004 - - - at various points in the key's lifetime. The table is a normative - part of this specification. The initial state of the key is 'Start'. - The resolver's view of the state of the key changes as various events - occur. - - [msj1] This is the state of a trust point key as seen from the - resolver. The column on the left indicates the current state. The - header at the top shows the next state. The intersection of the two - shows the event that will cause the state to transition from the - current state to the next. - - NEXT STATE - -------------------------------------------------- - FROM |Start |AddPend |Valid |Missing|Revoked|Removed| - ---------------------------------------------------------- - Start | |NewKey | | | | | - ---------------------------------------------------------- - AddPend |KeyRem | |AddTime| | | - ---------------------------------------------------------- - Valid | | | |KeyRem |Revbit | | - ---------------------------------------------------------- - Missing | | |KeyPres| |Revbit | | - ---------------------------------------------------------- - Revoked | | | | | |RemTime| - ---------------------------------------------------------- - Removed | | | | | | | - ---------------------------------------------------------- - - -4.1 Events - NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. - That key will become a new trust anchor for the named trust point - after its been present in the RRSet for at least 'add time'. - KeyPres The key has returned to the valid DNSKEY RRSet. - KeyRem The resolver sees a valid DNSKEY RRSet that does not contain - this key. - AddTime The key has been in every valid DNSKEY RRSet seen for at - least the 'add time'. - RemTime A revoked key has been missing from the trust point DNSKEY - RRSet for sufficient time to be removed from the trust set. - RevBit The key has appeared in the trust anchor DNSKEY RRSet with its - "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet - signed by this key. - -4.2 States - - - - - - -StJohns Expires April 14, 2005 [Page 7] - -Internet-Draft trustanchor-update October 2004 - - - Start The key doesn't yet exist as a trust anchor at the resolver. - It may or may not exist at the zone server, but hasn't yet been - seen at the resolver. - AddPend The key has been seen at the resolver, has its 'SEP' bit set, - and has been included in a validated DNSKEY RRSet. There is a - hold-down time for the key before it can be used as a trust - anchor. - Valid The key has been seen at the resolver and has been included in - all validated DNSKEY RRSets from the time it was first seen up - through the hold-down time. It is now valid for verifying RRSets - that arrive after the hold down time. Clarification: The DNSKEY - RRSet does not need to be continuously present at the resolver - (e.g. its TTL might expire). If the RRSet is seen, and is - validated (i.e. verifies against an existing trust anchor), this - key MUST be in the RRSet otherwise a 'KeyRem' event is triggered. - Missing This is an abnormal state. The key remains as a valid trust - point key, but was not seen at the resolver in the last validated - DNSKEY RRSet. This is an abnormal state because the zone operator - should be using the REVOKE bit prior to removal. [Discussion - item: Should a missing key be considered revoked after some - period of time?] - Revoked This is the state a key moves to once the resolver sees an - RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains - this key with its REVOKE bit set to '1'. Once in this state, this - key MUST permanently be considered invalid as a trust anchor. - Removed After a fairly long hold-down time, information about this - key may be purged from the resolver. A key in the removed state - MUST NOT be considered a valid trust anchor. - -5. Scenarios - - The suggested model for operation is to have one active key and one - stand-by key at each trust point. The active key will be used to - sign the DNSKEY RRSet. The stand-by key will not normally sign this - RRSet, but the resolver will accept it as a trust anchor if/when it - sees the signature on the trust point DNSKEY RRSet. - - Since the stand-by key is not in active signing use, the associated - private key may (and SHOULD) be provided with additional protections - not normally available to a key that must be used frequently. E.g. - locked in a safe, split among many parties, etc. Notionally, the - stand-by key should be less subject to compromise than an active key, - but that will be dependent on operational concerns not addressed - here. - -5.1 Adding A Trust Anchor - - Assume an existing trust anchor key 'A'. - - - -StJohns Expires April 14, 2005 [Page 8] - -Internet-Draft trustanchor-update October 2004 - - - 1. Generate a new key pair. - 2. Create a DNSKEY record from the key pair and set the SEP and Zone - Key bits. - 3. Add the DNSKEY to the RRSet. - 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - - 'A'. - 5. Wait a while. - -5.2 Deleting a Trust Anchor - - Assume existing trust anchors 'A' and 'B' and that you want to revoke - and delete 'A'. - 1. Set the revolcation bit on key 'A'. - 2. Sign the DNSKEY RRSet with both 'A' and 'B'. - 'A' is now revoked. The operator SHOULD include the revoked 'A' in - the RRSet for at least the remove hold-down time, but then may remove - it from the DNSKEY RRSet. - -5.3 Key Roll-Over - - Assume existing keys A and B. 'A' is actively in use (i.e. has been - signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has - been in the DNSKEY RRSet and is a valid trust anchor, but wasn't - being used to sign the RRSet.) - 1. Generate a new key pair 'C'. - 2. Add 'C' to the DNSKEY RRSet. - 3. Set the revocation bit on key 'A'. - 4. Sign the RRSet with 'A' and 'B'. - 'A' is now revoked, 'B' is now the active key, and 'C' will be the - stand-by key once the hold-down expires. The operator SHOULD include - the revoked 'A' in the RRSet for at least the remove hold-down time, - but may then remove it from the DNSKEY RRSet. - -5.4 Active Key Compromised - - This is the same as the mechanism for Key Roll-Over (Section 5.3) - above assuming 'A' is the active key. - -5.5 Stand-by Key Compromised - - Using the same assumptions and naming conventions as Key Roll-Over - (Section 5.3) above: - 1. Generate a new key pair 'C'. - 2. Add 'C' to the DNSKEY RRSet. - 3. Set the revocation bit on key 'B'. - 4. Sign the RRSet with 'A' and 'B'. - 'B' is now revoked, 'A' remains the active key, and 'C' will be the - stand-by key once the hold-down expires. 'B' SHOULD continue to be - - - -StJohns Expires April 14, 2005 [Page 9] - -Internet-Draft trustanchor-update October 2004 - - - included in the RRSet for the remove hold-down time. - -6. Security Considerations - -6.1 Key Ownership vs Acceptance Policy - - The reader should note that, while the zone owner is responsible - creating and distributing keys, it's wholly the decision of the - resolver owner as to whether to accept such keys for the - authentication of the zone information. This implies the decision - update trust anchor keys based on trust for a current trust anchor - key is also the resolver owner's decision. - - The resolver owner (and resolver implementers) MAY choose to permit - or prevent key status updates based on this mechanism for specific - trust points. If they choose to prevent the automated updates, they - will need to establish a mechanism for manual or other out-of-band - updates outside the scope of this document. - -6.2 Multiple Key Compromise - - This scheme permits recovery as long as at least one valid trust - anchor key remains uncompromised. E.g. if there are three keys, you - can recover if two of them are compromised. The zone owner should - determine their own level of comfort with respect to the number of - active valid trust anchors in a zone and should be prepared to - implement recovery procedures once they detect a compromise. A - manual or other out-of-band update of all resolvers will be required - if all trust anchor keys at a trust point are compromised. - -6.3 Dynamic Updates - - Allowing a resolver to update its trust anchor set based in-band key - information is potentially less secure than a manual process. - However, given the nature of the DNS, the number of resolvers that - would require update if a trust anchor key were compromised, and the - lack of a standard management framework for DNS, this approach is no - worse than the existing situation. - -7 Normative References - - [DSINTRO] Arends, R., "DNS Security Introduction and Requirements", - ID draft-ietf-dnsext-dnssec-intro-09.txt, October 2004, - . - - [DSPROT] Arends, R., "Protocol Modifications for the DNS Security - Extensions", ID draft-ietf-dnsext-dnssec-protocol-05.txt, - - - -StJohns Expires April 14, 2005 [Page 10] - -Internet-Draft trustanchor-update October 2004 - - - October 2004, - . - - [DSREC] Arends, R., "Resource Records for the DNS Security - Extensions", ID draft-ietf-dnsext-dnssec-records-07.txt, - October 2004, - . - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - -Editorial Comments - - [msj1] msj: N.B. This table is preliminary and will be revised to - match implementation experience. For example, should there - be a state for "Add hold-down expired, but haven't seen the - new RRSet"? - - [msj2] msj: To be assigned. - - [msj3] msj: For discussion: What's the implementation guidance for - resolvers currently with respect to the non-assigned flag - bits? If they consider the flag bit when doing key matching - at the trust anchor, they won't be able to match. - - -Author's Address - - Michael StJohns - Nominum, Inc. - 2385 Bay Road - Redwood City, CA 94063 - USA - - Phone: +1-301-528-4729 - EMail: Mike.StJohns@nominum.com - URI: www.nominum.com - - - - - - - - - -StJohns Expires April 14, 2005 [Page 11] - -Internet-Draft trustanchor-update October 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - The IETF has been notified of intellectual property rights claimed in - regard to some or all of the specification contained in this - document. For more information consult the online list of claimed - rights. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM 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. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - - - - -StJohns Expires April 14, 2005 [Page 12] - -Internet-Draft trustanchor-update October 2004 - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -StJohns Expires April 14, 2005 [Page 13] - - diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-timers-01.txt b/doc/draft/draft-ietf-dnsext-trustupdate-timers-01.txt new file mode 100644 index 0000000000..df702b41ec --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-trustupdate-timers-01.txt @@ -0,0 +1,730 @@ + + + + +Network Working Group M. StJohns +Internet-Draft Nominum, Inc. +Expires: February 16, 2006 August 15, 2005 + + + Automated Updates of DNSSEC Trust Anchors + draft-ietf-dnsext-trustupdate-timers-01 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on February 16, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes a means for automated, authenticated and + authorized updating of DNSSEC "trust anchors". The method provides + protection against single key compromise of a key in the trust point + key set. Based on the trust established by the presence of a current + anchor, other anchors may be added at the same place in the + hierarchy, and, ultimately, supplant the existing anchor. + + This mechanism, if adopted, will require changes to resolver + management behavior (but not resolver resolution behavior), and the + + + +StJohns Expires February 16, 2006 [Page 1] + +Internet-Draft trustanchor-update August 2005 + + + addition of a single flag bit to the DNSKEY record. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Compliance Nomenclature . . . . . . . . . . . . . . . . . 3 + 1.2 Changes since -00 . . . . . . . . . . . . . . . . . . . . 3 + 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 + 2.1 Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2 Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 4 + 2.3 Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5 + 2.4 Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6 + 2.5 Resolver Parameters . . . . . . . . . . . . . . . . . . . 6 + 2.5.1 Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6 + 2.5.2 Remove Hold-Down Time . . . . . . . . . . . . . . . . 6 + 2.5.3 Minimum Trust Anchors per Trust Point . . . . . . . . 6 + 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6 + 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.2 States . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 5.1 Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 8 + 5.2 Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9 + 5.3 Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9 + 5.4 Active Key Compromised . . . . . . . . . . . . . . . . . . 9 + 5.5 Stand-by Key Compromised . . . . . . . . . . . . . . . . . 9 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 6.1 Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10 + 6.2 Multiple Key Compromise . . . . . . . . . . . . . . . . . 10 + 6.3 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 10 + 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 + Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 + Intellectual Property and Copyright Statements . . . . . . . . 12 + + + + + + + + + + + + + + + + + +StJohns Expires February 16, 2006 [Page 2] + +Internet-Draft trustanchor-update August 2005 + + +1. Introduction + + As part of the reality of fielding DNSSEC (Domain Name System + Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the + community has come to the realization that there will not be one + signed name space, but rather islands of signed name space each + originating from specific points (i.e. 'trust points') in the DNS + tree. Each of those islands will be identified by the trust point + name, and validated by at least one associated public key. For the + purpose of this document we'll call the association of that name and + a particular key a 'trust anchor'. A particular trust point can have + more than one key designated as a trust anchor. + + For a DNSSEC-aware resolver to validate information in a DNSSEC + protected branch of the hierarchy, it must have knowledge of a trust + anchor applicable to that branch. It may also have more than one + trust anchor for any given trust point. Under current rules, a chain + of trust for DNSSEC-protected data that chains its way back to ANY + known trust anchor is considered 'secure'. + + Because of the probable balkanization of the DNSSEC tree due to + signing voids at key locations, a resolver may need to know literally + thousands of trust anchors to perform its duties. (e.g. Consider an + unsigned ".COM".) Requiring the owner of the resolver to manually + manage this many relationships is problematic. It's even more + problematic when considering the eventual requirement for key + replacement/update for a given trust anchor. The mechanism described + herein won't help with the initial configuration of the trust anchors + in the resolvers, but should make trust point key replacement/ + rollover more viable. + + As mentioned above, this document describes a mechanism whereby a + resolver can update the trust anchors for a given trust point, mainly + without human intervention at the resolver. There are some corner + cases discussed (e.g. multiple key compromise) that may require + manual intervention, but they should be few and far between. This + document DOES NOT discuss the general problem of the initial + configuration of trust anchors for the resolver. + +1.1 Compliance Nomenclature + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, [RFC2119]. + +1.2 Changes since -00 + + Added the concept of timer triggered resolver queries to refresh the + + + +StJohns Expires February 16, 2006 [Page 3] + +Internet-Draft trustanchor-update August 2005 + + + resolvers view of the trust anchor key RRSet. + + Re-submitted expired draft as -01. Updated DNSSEC RFC References. + +2. Theory of Operation + + The general concept of this mechanism is that existing trust anchors + can be used to authenticate new trust anchors at the same point in + the DNS hierarchy. When a new SEP key is added to a trust point + DNSKEY RRSet, and when that RRSet is validated by an existing trust + anchor, then the new key can be added to the set of trust anchors. + + There are some issues with this approach which need to be mitigated. + For example, a compromise of one of the existing keys could allow an + attacker to add their own 'valid' data. This implies a need for a + method to revoke an existing key regardless of whether or not that + key is compromised. As another example assuming a single key + compromise, an attacker could add a new key and revoke all the other + old keys. + +2.1 Revocation + + Assume two trust anchor keys A and B. Assume that B has been + compromised. Without a specific revocation bit, B could invalidate A + simply by sending out a signed trust point key set which didn't + contain A. To fix this, we add a mechanism which requires knowledge + of the private key of a DNSKEY to revoke that DNSKEY. + + A key is considered revoked when the resolver sees the key in a self- + signed RRSet and the key has the REVOKE bit set to '1'. Once the + resolver sees the REVOKE bit, it MUST NOT use this key as a trust + anchor or for any other purposes except validating the RRSIG over the + DNSKEY RRSet specifically for the purpose of validating the + revocation. Unlike the 'Add' operation below, revocation is + immediate and permanent upon receipt of a valid revocation at the + resolver. + + N.B. A DNSKEY with the REVOKE bit set has a different fingerprint + than one without the bit set. This affects the matching of a DNSKEY + to DS records in the parent, or the fingerprint stored at a resolver + used to configure a trust point. [msj3] + + In the given example, the attacker could revoke B because it has + knowledge of B's private key, but could not revoke A. + +2.2 Add Hold-Down + + Assume two trust point keys A and B. Assume that B has been + + + +StJohns Expires February 16, 2006 [Page 4] + +Internet-Draft trustanchor-update August 2005 + + + compromised. An attacker could generate and add a new trust anchor + key - C (by adding C to the DNSKEY RRSet and signing it with B), and + then invalidate the compromised key. This would result in the both + the attacker and owner being able to sign data in the zone and have + it accepted as valid by resolvers. + + To mitigate, but not completely solve, this problem, we add a hold- + down time to the addition of the trust anchor. When the resolver + sees a new SEP key in a validated trust point DNSKEY RRSet, the + resolver starts an acceptance timer, and remembers all the keys that + validated the RRSet. If the resolver ever sees the DNSKEY RRSet + without the new key but validly signed, it stops the acceptance + process and resets the acceptance timer. If all of the keys which + were originally used to validate this key are revoked prior to the + timer expiring, the resolver stops the acceptance process and resets + the timer. + + Once the timer expires, the new key will be added as a trust anchor + the next time the validated RRSet with the new key is seen at the + resolver. The resolver MUST NOT treat the new key as a trust anchor + until the hold down time expires AND it has retrieved and validated a + DNSKEY RRSet after the hold down time which contains the new key. + + N.B.: Once the resolver has accepted a key as a trust anchor, the key + MUST be considered a valid trust anchor by that resolver until + explictly revoked as described above. + + In the given example, the zone owner can recover from a compromise by + revoking B and adding a new key D and signing the DNSKEY RRSet with + both A and B. + + The reason this does not completely solve the problem has to do with + the distributed nature of DNS. The resolver only knows what it sees. + A determined attacker who holds one compromised key could keep a + single resolver from realizing that key had been compromised by + intercepting 'real' data from the originating zone and substituting + their own (e.g. using the example, signed only by B). This is no + worse than the current situation assuming a compromised key. + +2.3 Remove Hold-down + + A new key which has been seen by the resolver, but hasn't reached + it's add hold-down time, MAY be removed from the DNSKEY RRSet by the + zone owner. If the resolver sees a validated DNSKEY RRSet without + this key, it waits for the remove hold-down time and then, if the key + hasn't reappeared, SHOULD discard any information about the key. + + + + + +StJohns Expires February 16, 2006 [Page 5] + +Internet-Draft trustanchor-update August 2005 + + +2.4 Active Refresh + + A resolver which has been configured for automatic update of keys + from a particular trust point MUST query that trust point (e.g. do a + lookup for the DNSKEY RRSet and related RRSIG records) no less often + than the lesser of 15 days or half the original TTL for the DNSKEY + RRSet or half the RRSIG expiration interval. The expiration interval + is the amount of time from when the RRSIG was last retrieved until + the expiration time in the RRSIG. + + If the query fails, the resolver MUST repeat the query until + satisfied no more often than once an hour and no less often than the + lesser of 1 day or 10% of the original TTL or 10% of the original + expiration interval. + +2.5 Resolver Parameters + +2.5.1 Add Hold-Down Time + + The add hold-down time is 30 days or the expiration time of the TTL + of the first trust point DNSKEY RRSet which contained the key, + whichever is greater. This ensures that at least two validated + DNSKEY RRSets which contain the new key MUST be seen by the resolver + prior to the key's acceptance. + +2.5.2 Remove Hold-Down Time + + The remove hold-down time is 30 days. + +2.5.3 Minimum Trust Anchors per Trust Point + + A compliant resolver MUST be able to manage at least five SEP keys + per trust point. + +3. Changes to DNSKEY RDATA Wire Format + + Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE' + flag. If this bit is set to '1', AND the resolver sees an + RRSIG(DNSKEY) signed by the associated key, then the resolver MUST + consider this key permanently invalid for all purposes except for + validing the revocation. + +4. State Table + + The most important thing to understand is the resolver's view of any + key at a trust point. The following state table describes that view + at various points in the key's lifetime. The table is a normative + part of this specification. The initial state of the key is 'Start'. + + + +StJohns Expires February 16, 2006 [Page 6] + +Internet-Draft trustanchor-update August 2005 + + + The resolver's view of the state of the key changes as various events + occur. + + [msj1] This is the state of a trust point key as seen from the + resolver. The column on the left indicates the current state. The + header at the top shows the next state. The intersection of the two + shows the event that will cause the state to transition from the + current state to the next. + + NEXT STATE + -------------------------------------------------- + FROM |Start |AddPend |Valid |Missing|Revoked|Removed| + ---------------------------------------------------------- + Start | |NewKey | | | | | + ---------------------------------------------------------- + AddPend |KeyRem | |AddTime| | | + ---------------------------------------------------------- + Valid | | | |KeyRem |Revbit | | + ---------------------------------------------------------- + Missing | | |KeyPres| |Revbit | | + ---------------------------------------------------------- + Revoked | | | | | |RemTime| + ---------------------------------------------------------- + Removed | | | | | | | + ---------------------------------------------------------- + + +4.1 Events + NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. + That key will become a new trust anchor for the named trust point + after its been present in the RRSet for at least 'add time'. + KeyPres The key has returned to the valid DNSKEY RRSet. + KeyRem The resolver sees a valid DNSKEY RRSet that does not contain + this key. + AddTime The key has been in every valid DNSKEY RRSet seen for at + least the 'add time'. + RemTime A revoked key has been missing from the trust point DNSKEY + RRSet for sufficient time to be removed from the trust set. + RevBit The key has appeared in the trust anchor DNSKEY RRSet with its + "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet + signed by this key. + +4.2 States + Start The key doesn't yet exist as a trust anchor at the resolver. + It may or may not exist at the zone server, but hasn't yet been + seen at the resolver. + + + + + +StJohns Expires February 16, 2006 [Page 7] + +Internet-Draft trustanchor-update August 2005 + + + AddPend The key has been seen at the resolver, has its 'SEP' bit set, + and has been included in a validated DNSKEY RRSet. There is a + hold-down time for the key before it can be used as a trust + anchor. + Valid The key has been seen at the resolver and has been included in + all validated DNSKEY RRSets from the time it was first seen up + through the hold-down time. It is now valid for verifying RRSets + that arrive after the hold down time. Clarification: The DNSKEY + RRSet does not need to be continuously present at the resolver + (e.g. its TTL might expire). If the RRSet is seen, and is + validated (i.e. verifies against an existing trust anchor), this + key MUST be in the RRSet otherwise a 'KeyRem' event is triggered. + Missing This is an abnormal state. The key remains as a valid trust + point key, but was not seen at the resolver in the last validated + DNSKEY RRSet. This is an abnormal state because the zone operator + should be using the REVOKE bit prior to removal. [Discussion + item: Should a missing key be considered revoked after some + period of time?] + Revoked This is the state a key moves to once the resolver sees an + RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains + this key with its REVOKE bit set to '1'. Once in this state, this + key MUST permanently be considered invalid as a trust anchor. + Removed After a fairly long hold-down time, information about this + key may be purged from the resolver. A key in the removed state + MUST NOT be considered a valid trust anchor. + +5. Scenarios + + The suggested model for operation is to have one active key and one + stand-by key at each trust point. The active key will be used to + sign the DNSKEY RRSet. The stand-by key will not normally sign this + RRSet, but the resolver will accept it as a trust anchor if/when it + sees the signature on the trust point DNSKEY RRSet. + + Since the stand-by key is not in active signing use, the associated + private key may (and SHOULD) be provided with additional protections + not normally available to a key that must be used frequently. E.g. + locked in a safe, split among many parties, etc. Notionally, the + stand-by key should be less subject to compromise than an active key, + but that will be dependent on operational concerns not addressed + here. + +5.1 Adding A Trust Anchor + + Assume an existing trust anchor key 'A'. + 1. Generate a new key pair. + + + + + +StJohns Expires February 16, 2006 [Page 8] + +Internet-Draft trustanchor-update August 2005 + + + 2. Create a DNSKEY record from the key pair and set the SEP and Zone + Key bits. + 3. Add the DNSKEY to the RRSet. + 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - + 'A'. + 5. Wait a while. + +5.2 Deleting a Trust Anchor + + Assume existing trust anchors 'A' and 'B' and that you want to revoke + and delete 'A'. + 1. Set the revolcation bit on key 'A'. + 2. Sign the DNSKEY RRSet with both 'A' and 'B'. + 'A' is now revoked. The operator SHOULD include the revoked 'A' in + the RRSet for at least the remove hold-down time, but then may remove + it from the DNSKEY RRSet. + +5.3 Key Roll-Over + + Assume existing keys A and B. 'A' is actively in use (i.e. has been + signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been + in the DNSKEY RRSet and is a valid trust anchor, but wasn't being + used to sign the RRSet.) + 1. Generate a new key pair 'C'. + 2. Add 'C' to the DNSKEY RRSet. + 3. Set the revocation bit on key 'A'. + 4. Sign the RRSet with 'A' and 'B'. + 'A' is now revoked, 'B' is now the active key, and 'C' will be the + stand-by key once the hold-down expires. The operator SHOULD include + the revoked 'A' in the RRSet for at least the remove hold-down time, + but may then remove it from the DNSKEY RRSet. + +5.4 Active Key Compromised + + This is the same as the mechanism for Key Roll-Over (Section 5.3) + above assuming 'A' is the active key. + +5.5 Stand-by Key Compromised + + Using the same assumptions and naming conventions as Key Roll-Over + (Section 5.3) above: + 1. Generate a new key pair 'C'. + 2. Add 'C' to the DNSKEY RRSet. + 3. Set the revocation bit on key 'B'. + 4. Sign the RRSet with 'A' and 'B'. + 'B' is now revoked, 'A' remains the active key, and 'C' will be the + stand-by key once the hold-down expires. 'B' SHOULD continue to be + included in the RRSet for the remove hold-down time. + + + +StJohns Expires February 16, 2006 [Page 9] + +Internet-Draft trustanchor-update August 2005 + + +6. Security Considerations + +6.1 Key Ownership vs Acceptance Policy + + The reader should note that, while the zone owner is responsible + creating and distributing keys, it's wholly the decision of the + resolver owner as to whether to accept such keys for the + authentication of the zone information. This implies the decision + update trust anchor keys based on trust for a current trust anchor + key is also the resolver owner's decision. + + The resolver owner (and resolver implementers) MAY choose to permit + or prevent key status updates based on this mechanism for specific + trust points. If they choose to prevent the automated updates, they + will need to establish a mechanism for manual or other out-of-band + updates outside the scope of this document. + +6.2 Multiple Key Compromise + + This scheme permits recovery as long as at least one valid trust + anchor key remains uncompromised. E.g. if there are three keys, you + can recover if two of them are compromised. The zone owner should + determine their own level of comfort with respect to the number of + active valid trust anchors in a zone and should be prepared to + implement recovery procedures once they detect a compromise. A + manual or other out-of-band update of all resolvers will be required + if all trust anchor keys at a trust point are compromised. + +6.3 Dynamic Updates + + Allowing a resolver to update its trust anchor set based in-band key + information is potentially less secure than a manual process. + However, given the nature of the DNS, the number of resolvers that + would require update if a trust anchor key were compromised, and the + lack of a standard management framework for DNS, this approach is no + worse than the existing situation. + +7. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + + +StJohns Expires February 16, 2006 [Page 10] + +Internet-Draft trustanchor-update August 2005 + + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + +Editorial Comments + + [msj1] msj: N.B. This table is preliminary and will be revised to + match implementation experience. For example, should there + be a state for "Add hold-down expired, but haven't seen the + new RRSet"? + + [msj2] msj: To be assigned. + + [msj3] msj: For discussion: What's the implementation guidance for + resolvers currently with respect to the non-assigned flag + bits? If they consider the flag bit when doing key matching + at the trust anchor, they won't be able to match. + + +Author's Address + + Michael StJohns + Nominum, Inc. + 2385 Bay Road + Redwood City, CA 94063 + USA + + Phone: +1-301-528-4729 + Email: Mike.StJohns@nominum.com + URI: www.nominum.com + + + + + + + + + + + + + + + + + +StJohns Expires February 16, 2006 [Page 11] + +Internet-Draft trustanchor-update August 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + The IETF has been notified of intellectual property rights claimed in + regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + + + + +StJohns Expires February 16, 2006 [Page 12] + +Internet-Draft trustanchor-update August 2005 + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +StJohns Expires February 16, 2006 [Page 13] + + diff --git a/doc/draft/draft-ietf-dnsext-tsig-sha-03.txt b/doc/draft/draft-ietf-dnsext-tsig-sha-04.txt similarity index 89% rename from doc/draft/draft-ietf-dnsext-tsig-sha-03.txt rename to doc/draft/draft-ietf-dnsext-tsig-sha-04.txt index cb3c44bd14..a59595f590 100644 --- a/doc/draft/draft-ietf-dnsext-tsig-sha-03.txt +++ b/doc/draft/draft-ietf-dnsext-tsig-sha-04.txt @@ -1,21 +1,20 @@ - INTERNET-DRAFT Donald E. Eastlake 3rd UPDATES RFC 2845 Motorola Laboratories -Expires: October 2005 April 2005 +Expires: December 2005 June 2005 HMAC SHA TSIG Algorithm Identifiers ---- --- ---- --------- ----------- - + Status of This Document - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - or will be disclosed, and any of which I become aware will be - disclosed, in accordance with RFC 3668. + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. This draft is intended to be become a Proposed Standard RFC. Distribution of this document is unlimited. Comments should be sent @@ -188,16 +187,16 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers authentication codes. The only specified HMAC based TSIG algorithm identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321]. - The use of SHA-1 [FIPS 180-1, RFC 3174], which is a 160 bit hash, as + The use of SHA-1 [FIPS 180-2, RFC 3174], which is a 160 bit hash, as compared with the 128 bits for MD5, and additional hash algorithms in - the SHA family [FIPS 180-2, RFC 3874] with 224, 256, 384, and 512 - bits, may be preferred in some cases particularly since increasingly - successful cryptanalytic attacks are being made on the shorter - hashes. Use of TSIG between a DNS resolver and server is by mutual - agreement. That agreement can include the support of additional - algorithms and may specify policies as to which algorithms and - truncations are acceptable subject to the restrication and guidelines - in Section 3 and 4 below. + the SHA family [FIPS 180-2, RFC 3874, SHA2draft] with 224, 256, 384, + and 512 bits, may be preferred in some cases particularly since + increasingly successful cryptanalytic attacks are being made on the + shorter hashes. Use of TSIG between a DNS resolver and server is by + mutual agreement. That agreement can include the support of + additional algorithms and may specify policies as to which algorithms + and truncations are acceptable subject to the restrication and + guidelines in Section 3 and 4 below. The current HMAC-MD5.SIG-ALG.REG.INT identifier is included in the table below for convenience. Implementations which support TSIG MUST @@ -435,15 +434,16 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers the stronger SHA-1 and SHA-256 algorithms are being made mandatory due to caution. - See also the Security Considerations section of [RFC 2845] from which - the limits on truncation in this RFC were taken. + See the Security Considerations section of [RFC 2845]. See also the + Security Considerations section of [RFC 2104] from which the limits + on truncation in this RFC were taken. 6. Copyright and Disclaimer - Copyright (C) The Internet Society 2005. This document is subject to - the rights, licenses and restrictions contained in BCP 78 and except + Copyright (C) The Internet Society (2005). This document is subject to + the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. @@ -460,7 +460,6 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers - D. Eastlake 3rd [Page 8] @@ -501,11 +500,11 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October 2003. - [RFC 3874] - "A 224-bit One-way Hash Function: SHA-224", R. Housley, + [RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224", September 2004, - - + [SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms + (SHA)", work in progress. @@ -540,9 +539,9 @@ Author's Address Expiration and File Name - This draft expires in October 2005. + This draft expires in December 2005. - Its file name is draft-ietf-dnsext-tsig-sha-03.txt + Its file name is draft-ietf-dnsext-tsig-sha-04.txt @@ -579,4 +578,3 @@ Expiration and File Name D. Eastlake 3rd [Page 10] -