diff --git a/doc/draft/draft-ietf-dnsext-ad-is-secure-01.txt b/doc/draft/draft-ietf-dnsext-ad-is-secure-02.txt similarity index 84% rename from doc/draft/draft-ietf-dnsext-ad-is-secure-01.txt rename to doc/draft/draft-ietf-dnsext-ad-is-secure-02.txt index 6717bf2a2d..e3025e99a9 100644 --- a/doc/draft/draft-ietf-dnsext-ad-is-secure-01.txt +++ b/doc/draft/draft-ietf-dnsext-ad-is-secure-02.txt @@ -1,12 +1,7 @@ - - - - - -DNSEXT Working Group Brian Wellington (Nominum) -INTERNET-DRAFT Olafur Gudmundsson (NAI Labs) - January 2001 +DNSEXT Working Group Brian Wellington +INTERNET-DRAFT Olafur Gudmundsson + June 2001 Updates: RFC 2535 @@ -37,7 +32,7 @@ Status of this Memo Comments should be sent to the authors or the DNSEXT WG mailing list namedroppers@ops.ietf.org - This draft expires on July 19, 2001. + This draft expires on December 18, 2001. Copyright Notice @@ -55,9 +50,9 @@ Abstract -Expires July 2001 [Page 1] +Expires December 2001 [Page 1] -INTERNET-DRAFT AD bit set on secure answers January 2001 +INTERNET-DRAFT AD bit set on secure answers June 2001 1 - Introduction @@ -111,14 +106,14 @@ INTERNET-DRAFT AD bit set on secure answers January 2001 -Expires July 2001 [Page 2] +Expires December 2001 [Page 2] -INTERNET-DRAFT AD bit set on secure answers January 2001 +INTERNET-DRAFT AD bit set on secure answers June 2001 - If the answer section contains any data, the server MUST NOT include - data in the authority section that would cause the AD bit to be - unset. + AD should be set if and only if all RRs in the answer section, and + any relevant negative response RRs in the authority section are + Authenticated. The AD bit MUST NOT be set on a response unless all of the RRsets in the answer and authority sections are Authenticated. @@ -161,15 +156,15 @@ References: [RFC1035] P. Mockapetris, ``Domain Names - Implementation and Specification'', STD 13, RFC 1035, November 1987. - [RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC 2535, March 1999. -Expires July 2001 [Page 3] + +Expires December 2001 [Page 3] -INTERNET-DRAFT AD bit set on secure answers January 2001 +INTERNET-DRAFT AD bit set on secure answers June 2001 [RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, @@ -183,12 +178,11 @@ INTERNET-DRAFT AD bit set on secure answers January 2001 Authors Addresses Brian Wellington Olafur Gudmundsson - Nominum Inc. NAI Labs - 950 Charter Street 3060 Washington Road (Rt. 97) - Redwood City, CA, 94063 Glenwood, MD, 21738 + Nominum Inc. + 950 Charter Street 3826 Legation Street, NW + Redwood City, CA, 94063 Washington, DC, 20015 USA USA - +1 650 381 6022 +1 443 259 2389 - + Full Copyright Statement @@ -223,4 +217,6 @@ Full Copyright Statement -Expires July 2001 [Page 4] + +Expires December 2001 [Page 4] + diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-01.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-02.txt similarity index 69% rename from doc/draft/draft-ietf-dnsext-axfr-clarify-01.txt rename to doc/draft/draft-ietf-dnsext-axfr-clarify-02.txt index 7c1d45e565..2482529c86 100644 --- a/doc/draft/draft-ietf-dnsext-axfr-clarify-01.txt +++ b/doc/draft/draft-ietf-dnsext-axfr-clarify-02.txt @@ -1,6 +1,7 @@ + INTERNET-DRAFT Andreas Gustafsson -draft-ietf-dnsext-axfr-clarify-01.txt Nominum Inc. - November 2000 +draft-ietf-dnsext-axfr-clarify-02.txt Nominum Inc. + June 2001 DNS Zone Transfer Protocol Clarifications @@ -49,9 +50,9 @@ Abstract -Expires May 2001 [Page 1] +Expires December 2001 [Page 1] -draft-ietf-dnsext-axfr-clarify-01.txt November 2000 +draft-ietf-dnsext-axfr-clarify-02.txt June 2001 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", @@ -75,6 +76,11 @@ draft-ietf-dnsext-axfr-clarify-01.txt November 2000 transfer, it MUST respond with a single DNS message containing an appropriate RCODE other than NOERROR. + Slave servers should note that some master server implementations + will simply close the connection when denying the slave access to the + zone. Therefore, slaves MAY interpret an immediate graceful close of + the TCP connection as equivalent to a "Refused" response (RCODE 5). + If a zone transfer can be provided, the master server sends one or more DNS messages containing the zone data as described below. @@ -98,18 +104,17 @@ draft-ietf-dnsext-axfr-clarify-01.txt November 2000 DNS message size. In the case of a small zone, this can cause the entire transfer to be transmitted in a single response message. + + +Expires December 2001 [Page 2] + +draft-ietf-dnsext-axfr-clarify-02.txt June 2001 + + Slaves MUST accept messages containing any number of answer RRs. For compatibility with old slaves, masters that support sending multiple answers per message SHOULD be configurable to revert to the historical mode of one answer per message, and the configuration - - - -Expires May 2001 [Page 2] - -draft-ietf-dnsext-axfr-clarify-01.txt November 2000 - - SHOULD be settable on a per-slave basis. 3.2. DNS message header contents @@ -121,19 +126,20 @@ draft-ietf-dnsext-axfr-clarify-01.txt November 2000 ID Copy from request QR 1 OPCODE QUERY - AA 1 (but MAY be 0 when RCODE is nonzero) + AA 1, but MAY be 0 when RCODE is not NOERROR TC 0 - RD Copy from request - RA Set according to availability of recursion S Z 0 + RD Copy from request, or 0 + RA Set according to availability of recursion, or 0 + Z 0 AD 0 CD 0 - RCODE 0 or error code + RCODE NOERROR on success, error code otherwise - The slave MUST check the RCODE and abort the transfer if it is - nonzero. It SHOULD check the ID of the first message received and - abort the transfer if it does not match the ID of the request. The - ID SHOULD be ignored in subsequent messages, and fields other than - RCODE and ID SHOULD be ignored in all messages, to ensure + The slave MUST check the RCODE in each message and abort the transfer + if it is not NOERROR. It SHOULD check the ID of the first message + received and abort the transfer if it does not match the ID of the + request. The ID SHOULD be ignored in subsequent messages, and fields + other than RCODE and ID SHOULD be ignored in all messages, to ensure interoperability with certain older implementations which transmit incorrect or arbitrary values in these fields. @@ -154,51 +160,50 @@ draft-ietf-dnsext-axfr-clarify-01.txt November 2000 3.5. The authority section + + +Expires December 2001 [Page 3] + +draft-ietf-dnsext-axfr-clarify-02.txt June 2001 + + The master server MUST transmit messages with an empty authority section. Slaves MUST ignore any authority section contents they may receive from masters that do not comply with this requirement. - - - -Expires May 2001 [Page 3] - -draft-ietf-dnsext-axfr-clarify-01.txt November 2000 - - 3.6. The additional section The additional section MAY contain additional RRs such as transaction signatures. The slave MUST ignore any unexpected RRs in the additional section. -4. Glue +4. Zone data - A master transmitting a zone transfer MUST include the full set of - zone data it loaded from the zone's master file, from an incoming - zone transfer, or other similar means of configuring zone data. This - includes any nonauthoritative data ("glue") associated with the zone - by being present in the zone's master file or the incoming transfer - along with the authoritative data. This glue data includes any - configured zone data obscured by zone cuts or otherwise outside the - zone in case; it is not limited to RRs pointed to by NS records. + The purpose of the zone transfer mechanism is to exactly replicate at + each slave the set of RRs associated with a particular zone at its + primary master. An RR is associated with a zone by being loaded from + the master file of that zone at the primary master server, or by some + other, equivalent method for configuring zone data. - The glue RRs are transmitted in the answer section along with the - authoritative data. This is unlike ordinary DNS responses where glue - is transmitted in the authority or additional section. + This replication shall be complete and unaltered, regardless of how + many and which intermediate masters/slaves are involved, and + regardless of what other zones those intermediate masters/slaves do + or do not serve, and regardless of what data may be cached in + resolvers associated with the intermediate masters/slaves. - Zone transfers MUST NOT contain RRs from the authoritative data of - zones other than the one being transferred or from the cache, even - when such RRs are pointed to by NS records in the zone being - transferred. + Therefore, in a zone transfer the master MUST send exactly those + records that are associated with the zone, whether or not their owner + names would be considered to be "in" the zone for purposes of + resolution, and whether or not they would be eligible for use as glue + in responses. The transfer MUST NOT include any RRs that are not + associated with the zone, such as RRs associated with zones other + than the one being transferred or present in the cache of the local + resolver, even if their owner names are in the zone being transferred + or are pointed to by NS records in the zone being transferred. - A slave receiving a zone transfer MUST accept glue data and recognize - it as such; glue MUST NOT be treated as authoritative data nor - entered into the cache. Note that classifying an RR as glue or non- - glue may not be possible until the entire zone has been received so - that the zone cuts defined by the zone's NS records can be - determined. Glue data that is not below the zone origin ("cross-zone - glue") MAY be discarded by the slave. + The slave MUST associate the RRs received in a zone transfer with the + specific zone being transferred, and maintain that association for + purposes of acting as a master in outgoing transfers. 5. Transmission order @@ -210,30 +215,33 @@ draft-ietf-dnsext-axfr-clarify-01.txt November 2000 zone's apex are transmitted only once. Therefore, the quoted sentence is hereby changed to read "The first + + + +Expires December 2001 [Page 4] + +draft-ietf-dnsext-axfr-clarify-02.txt June 2001 + + and last RR transmitted must be the SOA record of the zone". The initial and final SOA record MUST be identical, with the possible exception of case and compression. In particular, they MUST have the - - - -Expires May 2001 [Page 4] - -draft-ietf-dnsext-axfr-clarify-01.txt November 2000 - - same serial number. - The transmission order of all other RRs in the zone, including glue - records, is undefined. + The transmission order of all other RRs in the zone is undefined. + Each of them MUST be transmitted exactly once. As some older masters + do not comply with this requirement, slaves SHOULD silently ignore + duplicate RRs for interoperability. 6. Security Considerations The zone transfer protocol as defined in [RFC1034] and clarified by this memo does not have any built-in mechanisms for the slave to securely verify the identity of the master server and the integrity - of the transferred zone data. The use of TSIG [RFC2845] for this - purpose is RECOMMENDED. + of the transferred zone data. The use of a cryptographic mechanism + for ensuring authenticity and integrity, such as TSIG [RFC2845], + IPSEC, or TLS, is RECOMMENDED. The zone transfer protocol allows read-only public access to the complete zone data. Since data in the DNS is public by definition, @@ -244,6 +252,13 @@ draft-ietf-dnsext-axfr-clarify-01.txt November 2000 These clarifications are not believed to themselves introduce any new security problems, nor to solve any existing ones. +Acknowledgements + + Many people have contributed input and commentary to earlier versions + of this document, including but not limited to Bob Halley, Dan + Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Levon Esibov, + Mark Andrews, Michael Patton, Peter Koch, and Sam Trenholme. + References [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, @@ -256,6 +271,14 @@ References S. Bradner, BCP 14, March 1997. [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG). P. + + + +Expires December 2001 [Page 5] + +draft-ietf-dnsext-axfr-clarify-02.txt June 2001 + + Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000. Author's Address @@ -266,21 +289,14 @@ Author's Address Redwood City, CA 94063 USA - Phone: +1 650 779 6004 + Phone: +1 650 381 6004 Email: gson@nominum.com - - -Expires May 2001 [Page 5] - -draft-ietf-dnsext-axfr-clarify-01.txt November 2000 - - Full Copyright Statement - Copyright (C) The Internet Society (2000). All Rights Reserved. + Copyright (C) The Internet Society (2000, 2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it @@ -314,20 +330,5 @@ Full Copyright Statement - - - - - - - - - - - - - - - -Expires May 2001 [Page 6] +Expires December 2001 [Page 6] diff --git a/doc/draft/draft-ietf-dnsext-dnssec-roadmap-03.txt b/doc/draft/draft-ietf-dnsext-dnssec-roadmap-04.txt similarity index 86% rename from doc/draft/draft-ietf-dnsext-dnssec-roadmap-03.txt rename to doc/draft/draft-ietf-dnsext-dnssec-roadmap-04.txt index 9f35184a65..79fda2e9de 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-roadmap-03.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-roadmap-04.txt @@ -6,52 +6,52 @@ DNEXT Working Group S. Rose Internet Draft NIST -Expires: November 2001 April 2001 +Expires: January 2001 July 2001 Category: Informational - DNS Security Document Roadmap - ------------------------------ - + DNS Security Document Roadmap + ------------------------------ + Status of this Document - This document is an Internet-Draft and is in full - conformance with all provisions of Section 10 of RFC2026. - Distribution of this document is unlimited. Comments - regarding this document should be sent to the author. + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. Distribution of this + document is unlimited. Comments regarding this document should be + sent to the author. - 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." + 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. + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. Abstract - DNS Security (DNSSEC)technology is composed of extensions - to the Domain Name System (DNS) protocol that provide - data integrity and authentication to security aware - resolvers and applications through the use of - cryptographic digital signatures. Several documents - exist to describe these extensions and the - implementation-specific details regarding specific - digital signing schemes. The interrelationship between - these different documents is discussed here. A brief + DNS Security (DNSSEC)technology is composed of extensions to the + Domain Name System (DNS) protocol that provide data integrity and + authentication to security aware resolvers and applications through + the use of cryptographic digital signatures. Several documents exist + to describe these extensions and the implementation-specific details + regarding specific digital signing schemes. The interrelationship + between these different documents is discussed here. A brief + overview of what to find in which document and author guidelines for + what to include in new DNS Security documents, or revisions to + existing documents, is described. + @@ -64,11 +64,6 @@ Rose [Page 1] INTERNET-DRAFT DNS Security Document Roadmap April 2001 - overview of what to find in which document and author - guidelines for what to include in new DNS Security - documents, or revisions to existing documents, is - described. - @@ -108,6 +103,11 @@ Table of Contents + + + + + @@ -206,13 +206,14 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001 | RRs | | | | Uses | | [RFC2538, | | [RFC2535, | | [SSH-DNS] | | RFC2931, | | RFC3007, | +-------------+ - | NO] | | RFC3008, | + | NO, DSIG] | | RFC3008, | +------------+ | RFC3090, | | SIZE ] | | OKBIT, | | ADBIT, | | OPTIN, | - | PARSIG ] | + | PARSIG, | + | PARKEY ] | +-----------+ | | @@ -224,16 +225,15 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001 | Algorithm | | Transactions | * Notes * | Impl. | | | | | | [RFC2536, | | [RFC2845, | * [CAIRN, * - | RFC2537 | | RFC2930] | | ROLLOVER ] | - | RFC2539 | | | * * + | RFC2537 | | RFC2930] | | ROLLOVER, | + | RFC2539 | | | * RESROLLOVER ] * | GSS-TSIG, | | | +-*-*-*-*-*-*-*-*-+ - | RSA-SHA] | +---------------+ + | RFC3110] | +---------------+ +------------+ Figure 1 DNSSEC Document Roadmap - Rose [Page 4] @@ -259,8 +259,8 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001 of the specification to be modified SHOULD be synopsized in the new document for the benefit of the reader. The "DNSSEC protocol" set includes the documents [RFC2535], [RFC3007], [RFC3008], [RFC3090], - [SIZE], [OKBIT], [ADBIT], [OPTIN], [PARSIG] and their derivative - documents. + [SIZE], [OKBIT], [ADBIT], [OPTIN], [PARSIG], [PARKEY] and their + derivative documents. The "New Security RRs" set refers to the group of documents that seek to add additional Resource Records to the set of base DNS Record @@ -272,7 +272,7 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001 that describe how a specific digital signature algorithm is imple- mented to fit the DNSSEC Resource Record format. Each one of these documents deals with one specific digital signature algorithm. Exam- - ples of this set include [RFC2536], [RFC2537], [RFC2539], [RSA-SHA] + ples of this set include [RFC2536], [RFC2537], [RFC2539], [RFC3110] and [GSS-TSIG]. The "Transactions" document set refers to the group of documents that @@ -316,9 +316,10 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001 tions, but can also point to places in the protocol specifications that need improvement. Documents in this set may be offspring of both the DNSEXT and/or DNSOP Working Groups. Currently, there are - two Internet Drafts that fall under this category: the report on the - CAIRN DNSSEC testbed [CAIRN] and a draft on security key rollover - [ROLLOVER]. These documents were submitted through the DNSOP Working + three Internet Drafts that fall under this category: the report on + the CAIRN DNSSEC testbed [CAIRN] and a draft on security key rollover + [ROLLOVER] and the draft on resolver configured key rollover [RES- + ROLLOVER]. These documents were submitted through the DNSOP Working Group, however the main concern of these documents is the implementa- tion and limitations of the DNS security extensions, hence their interest to the DNS security community. The CAIRN draft deals with @@ -350,7 +351,6 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001 SHOULD be interpreted as a minimum set of information required/needed in a document, any additional information regarding the specific extension should also be included in the document. These criteria - are not officially part of the IETF guidelines regarding RFC/Internet @@ -363,6 +363,7 @@ Rose [Page 6] INTERNET-DRAFT DNS Security Document Roadmap April 2001 + are not officially part of the IETF guidelines regarding RFC/Internet Drafts, but should be considered as guidance to promote uniformity to Working Group documents. @@ -410,7 +411,6 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001 In addition, authors are encouraged to include any necessary descrip- tion of the algorithm itself, as well as any know/suspected weaknesses as an appendix to the document. This is for reference - only, as the goals of the DNSEXT working group is to propose @@ -423,7 +423,8 @@ Rose [Page 7] INTERNET-DRAFT DNS Security Document Roadmap April 2001 - extensions to the DNS protocol, not cryptographic research. + only, as the goals of the DNSEXT working group is to propose exten- + sions to the DNS protocol, not cryptographic research. 4.3 Refinement of Security Procedures @@ -470,7 +471,6 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001 6. Acknowledgements - In addition to the RFCs mentioned in this document, there are also @@ -483,6 +483,7 @@ Rose [Page 8] INTERNET-DRAFT DNS Security Document Roadmap April 2001 + In addition to the RFCs mentioned in this document, there are also numerous Internet drafts that fall in one or more of the categories of DNS Security documents mentioned above. Depending on where (and if) these documents are on the IETF standards track, the reader may @@ -505,8 +506,6 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001 with Minimum Disclosure". * OKBIT: D. Conrad. "Indicting Resolver Support of DNSSEC". - * RSA-SHA: D. Eastlake. "RSA/SHA-1 SIGs and RSA KEYs in the - Domain Name System (DNS)" * ROLLOVER: M. Andrews, D. Eastlake. "Domain Name System (DNS) Security Key Rollover" . * ADBIT: B. Wellington. "Redefinition of DNS AD bit" * SSH-DNS: W. Griffin. "Storing SSH Host Keys in DNS" - * PARSIG: R. Geiben, T. Lindgreen. "Parent's SIG Over Child's - KEY" + * PARKEY: R. Geiben, T. Lindgreen. "Parent stores the child's + zone KEYs" + * PARSIG: R. Geiben, T. Lindgreen. "Parent's SIG over Child's KEY" + + * DSIG: O. Gudmundsson. "Delegation Signer Record in Parent". + + * RESROLLOVER: O. Kolkman, M. Gieben, R. Arends. "Rollover of + statically configured resolver keys". 7. References @@ -524,13 +530,7 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001 [RFC2535] D. Eastlake, "Domain Name System Security Extensions", RFC 2535, March 1999. - [RFC2537] D. Eastlake, "RSA/MD5 KEYs and SIGs in the Domain Name Sys- - tem (DNS)", RFC 2537, March 1999. - - [RFC2536] D. Eastlake, "DSA KEYs and SIGs in the Domain Name System - (DNS)", RFC 2536, March 1999. - - [RFC2137] D. Eastlake, "Secure Domain Name System Dynamic Update", + [RFC2537] D. Eastlake, "RSA/MD5 KEYs and SIGs in the Domain Name @@ -543,6 +543,12 @@ Rose [Page 9] INTERNET-DRAFT DNS Security Document Roadmap April 2001 + System (DNS)", RFC 2537, March 1999. + + [RFC2536] D. Eastlake, "DSA KEYs and SIGs in the Domain Name System + (DNS)", RFC 2536, March 1999. + + [RFC2137] D. Eastlake, "Secure Domain Name System Dynamic Update", RFC 2137, April 1997. [RFC2539] D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain @@ -554,9 +560,12 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001 [RFC2930] D. Eastlake, "Secret Key Establishment for DNS" RFC 2930, September 2000. - [RFC2931] D. Eastlake "DNS Request and Transaction Signatures + [RFC2931] D. Eastlake, "DNS Request and Transaction Signatures (SIG(0))" RFC 2931, September 2000. + [RFC3110] D. Eastlake, "RSA/SHA-1 SIGs and RSA KEYs in the Domain + Name System (DNS)", May 2001. + [RFC3090] E. Lewis "DNS Security Extensions Clarification on Zone Status" RFC 3090, March 2001. @@ -585,15 +594,6 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001 -8. Authors' Addresses - - Scott Rose - National Institute for Standards and Technology - Gaithersburg, MD - Email: scott.rose@nist.gov - - - Rose [Page 10] @@ -603,9 +603,18 @@ Rose [Page 10] INTERNET-DRAFT DNS Security Document Roadmap April 2001 +8. Author's Addresses + + Scott Rose + National Institute for Standards and Technology + Gaithersburg, MD + Email: scott.rose@nist.gov + + + Expiration and File Name: - This draft, titled expires November + This draft, titled expires January 2001. @@ -642,15 +651,6 @@ Full Copyright Statement This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of develop- - ing Internet standards in which case the procedures for copyrights - defined in the Internet Standards process must be followed, or as @@ -663,6 +663,15 @@ Rose [Page 11] INTERNET-DRAFT DNS Security Document Roadmap April 2001 + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of develop- + ing Internet standards in which case the procedures for copyrights + defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be @@ -695,15 +704,6 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001 - - - - - - - - - diff --git a/doc/draft/draft-ietf-dnsext-rfc2782bis-00.txt b/doc/draft/draft-ietf-dnsext-rfc2782bis-01.txt similarity index 88% rename from doc/draft/draft-ietf-dnsext-rfc2782bis-00.txt rename to doc/draft/draft-ietf-dnsext-rfc2782bis-01.txt index a58f052d7e..be5911d953 100644 --- a/doc/draft/draft-ietf-dnsext-rfc2782bis-00.txt +++ b/doc/draft/draft-ietf-dnsext-rfc2782bis-01.txt @@ -5,10 +5,10 @@ Network Working Group A. Gulbrandsen Category: INTERNET-DRAFT Trolltech AS -Obsoletes: 2052 P. Vixie -draft-ietf-dnsext-rfc2782bis-00.txt Internet Software Consortium -November 16, 2000 L. Esibov -Expires: May 16, 2001 Microsoft Corp. +Obsoletes: 2782 P. Vixie +draft-ietf-dnsext-rfc2782bis-01.txt Internet Software Consortium +June 6, 2001 L. Esibov +Expires: December 6, 2001 Microsoft Corp. @@ -35,7 +35,7 @@ Status of this Memo Copyright Notice - Copyright (C) The Internet Society (2000). All Rights Reserved. + Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract @@ -63,9 +63,9 @@ Overview and rationale -Expires May 2001 [Page 1] +Expires December 2001 [Page 1] -INTERNET-DRAFT DNS SRV RR Novemeber 2000 +INTERNET-DRAFT DNS SRV RR June 2001 Definitions @@ -119,9 +119,9 @@ The format of the SRV RR -Expires May 2001 [Page 2] +Expires December 2001 [Page 2] -INTERNET-DRAFT DNS SRV RR Novemeber 2000 +INTERNET-DRAFT DNS SRV RR June 2001 Some widely used services, notably POP, don't have a single @@ -175,9 +175,9 @@ INTERNET-DRAFT DNS SRV RR Novemeber 2000 -Expires May 2001 [Page 3] +Expires December 2001 [Page 3] -INTERNET-DRAFT DNS SRV RR Novemeber 2000 +INTERNET-DRAFT DNS SRV RR June 2001 specified by the SRV RRs, will be contacted. The following @@ -231,9 +231,9 @@ Domain administrator advice -Expires May 2001 [Page 4] +Expires December 2001 [Page 4] -INTERNET-DRAFT DNS SRV RR Novemeber 2000 +INTERNET-DRAFT DNS SRV RR June 2001 suboptimal) fallback hosts for Telnet, NNTP and other protocols @@ -287,9 +287,9 @@ The "Weight" field -Expires May 2001 [Page 5] +Expires December 2001 [Page 5] -INTERNET-DRAFT DNS SRV RR Novemeber 2000 +INTERNET-DRAFT DNS SRV RR June 2001 The only way the authors can see of getting a "better" load figure is @@ -337,15 +337,17 @@ Usage rules the reply: If there is precisely one SRV RR, and its Target is "." - (the root domain), abort. + (the root domain), abort and do not attempt lookup for + QNAME=domain, QCLASS=IN, QTYPE=A. -Expires May 2001 [Page 6] -INTERNET-DRAFT DNS SRV RR Novemeber 2000 +Expires December 2001 [Page 6] + +INTERNET-DRAFT DNS SRV RR June 2001 Else, for all such RR's, build a list of (Priority, Weight, @@ -399,9 +401,9 @@ Notes: -Expires May 2001 [Page 7] +Expires December 2001 [Page 7] -INTERNET-DRAFT DNS SRV RR Novemeber 2000 +INTERNET-DRAFT DNS SRV RR June 2001 - Future protocols could be designed to use SRV RR lookups as the @@ -455,9 +457,9 @@ Fictional example -Expires May 2001 [Page 8] +Expires December 2001 [Page 8] -INTERNET-DRAFT DNS SRV RR Novemeber 2000 +INTERNET-DRAFT DNS SRV RR June 2001 In this example, a client of the "foobar" service in the @@ -483,22 +485,40 @@ IANA Considerations The IANA has assigned RR type value 33 to the SRV RR. No other IANA services are required by this document. -Changes from RFC 2052 +Changes from RFC 2782 + + This document obsoletes RFC 2782 + Only editorial clarifications were made to this document. Namely + + - it was clarified that "Weight" subsection refers to real "random + number" rather than integer number; + + - it was clarified that the "Name" used in the owner name of the SRV + record used in "The format of the SRV RR" section is a "Domain" + name; + + - the "QNAME=_service._protocol.target" was replaced by + "QNAME=_service._protocol.domain" in "Usage rules" section to + eliminate a possibility of confusion with the Target field of the + SRV record. + + - client's behavior when response to a query contains a single SRV + RR and its Target is "." is clarified in "Usage rules" section. - This document obsoletes RFC 2052. The major change from that - previous, experimental, version of this specification is that now the - protocol and service labels are prepended with an underscore, to - lower the probability of an accidental clash with a similar name used - for unrelated purposes. Aside from that, changes are only intended - to increase the clarity and completeness of the document. This - document especially clarifies the use of the Weight field of the SRV - records. Security Considerations The authors believe this RR to not cause any new security problems. Some problems become more visible, though. + + + + +Expires December 2001 [Page 9] + +INTERNET-DRAFT DNS SRV RR June 2001 + - The ability to specify ports on a fine-grained basis obviously changes how a router can filter packets. It becomes impossible to block internal clients from accessing specific external @@ -510,18 +530,14 @@ Security Considerations as servers. This could lead to denial of service. - -Expires May 2001 [Page 9] - -INTERNET-DRAFT DNS SRV RR Novemeber 2000 - - - With SRV, DNS spoofers can supply false port numbers, as well as host names and addresses. Because this vulnerability exists already, with names and addresses, this is not a new vulnerability, merely a slightly extended one, with little practical effect. + + References STD 2: Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC @@ -557,19 +573,9 @@ References +Expires December 2001 [Page 10] - - - - - - - - - -Expires May 2001 [Page 10] - -INTERNET-DRAFT DNS SRV RR Novemeber 2000 +INTERNET-DRAFT DNS SRV RR June 2001 Acknowledgements @@ -623,14 +629,14 @@ Authors' Addresses -Expires May 2001 [Page 11] +Expires December 2001 [Page 11] -INTERNET-DRAFT DNS SRV RR Novemeber 2000 +INTERNET-DRAFT DNS SRV RR June 2001 Full Copyright Statement - Copyright (C) The Internet Society (2000). All Rights Reserved. + Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it @@ -679,4 +685,4 @@ Acknowledgement -Expires May 16, 2001 [Page 12] \ No newline at end of file +Expires December 6, 2001 [Page 12] \ No newline at end of file diff --git a/doc/draft/draft-ietf-idn-aceid-01.txt b/doc/draft/draft-ietf-idn-aceid-02.txt similarity index 93% rename from doc/draft/draft-ietf-idn-aceid-01.txt rename to doc/draft/draft-ietf-idn-aceid-02.txt index deaf3cb69c..896781021f 100644 --- a/doc/draft/draft-ietf-idn-aceid-01.txt +++ b/doc/draft/draft-ietf-idn-aceid-02.txt @@ -1,7 +1,8 @@ + Internet Draft Naomasa Maruyama -draft-ietf-idn-aceid-01.txt Yoshiro Yoneya -Dec 11, 2000 JPNIC -Expires June 11, 2001 +draft-ietf-idn-aceid-02.txt Yoshiro Yoneya +Jun 19, 2000 JPNIC +Expires Dec 19, 2001 Proposal for a determining process of ACE identifier @@ -87,14 +88,15 @@ domain name and those which have an ACE suffix identifier candidate at the tail of at least one label of the name. These domain names are collectively called "relevant domain names". - This suspension should be continued until March 1, 2001 00:00:00 UTC. + This suspension should be continued until September 1, 2001 +00:00:00 UTC. 2.2 Survey of relevant domain name registration All registries recognized by ICANN SHOULD conduct a survey about relevant domain names registered in their zone, and report, no later -than February 10, 2001 00:00:00 UTC, all of the ACE identifier +than August 11, 2001 00:00:00 UTC, all of the ACE identifier candidates which are used by relevant domain names. @@ -103,7 +105,7 @@ candidates which are used by relevant domain names. The IDN WG or other organ of IETF or ICANN MUST summarize the reports and list ACE identifier candidates that are not reported to be -used in registered domain names by February 17, 2001 00:00:00 UTC, and +used in registered domain names by August 18, 2001 00:00:00 UTC, and select ten to twenty ACE prefix identifier candidates and ten to twenty ACE suffix identifier candidates for ACE identifiers. Among these twenty to forty ACE identifiers, one prefix identifier and one @@ -111,7 +113,7 @@ suffix identifier will be used for experiments. Others will be used, one by one as ACE standard evolves. The list of ACE identifiers will be sent to IANA, and will be -maintained by IANA from February 24, 2001 00:00:00 UTC. Domain names +maintained by IANA from August 25, 2001 00:00:00 UTC. Domain names relevant to these identifiers SHOULD NOT be registered in any DNS zone, except for registration of multilingual domain names compliant to one of future IDN standards. This new restriction about the domain @@ -125,13 +127,13 @@ immediately after it receives the list. described in section 2.3 SHOULD NOT be registered in any zone of ICANN recognized registries except for registration of multilingual domain names compliant to one of future IDN standards. All ICANN recognized -registries SHOULD implement this restriction no later than March 1, +registries SHOULD implement this restriction no later than September 1, 2001 00:00:00 UTC. Registration for domain names relevant to ACE identifier candidates, tentatively suspended by 2.1, but not relevant to ACE -identifiers selected by section 2.3 MAY be reopened from March 1, 2001 -00:00:00 UTC. +identifiers selected by section 2.3 MAY be reopened from September 1, +2001 00:00:00 UTC. 3. Use of an ACE identifier in writing an ACE proposal diff --git a/doc/draft/draft-ietf-idn-idna-01.txt b/doc/draft/draft-ietf-idn-idna-02.txt similarity index 57% rename from doc/draft/draft-ietf-idn-idna-01.txt rename to doc/draft/draft-ietf-idn-idna-02.txt index 7ea20e776d..4d9afbcf86 100644 --- a/doc/draft/draft-ietf-idn-idna-01.txt +++ b/doc/draft/draft-ietf-idn-idna-02.txt @@ -1,9 +1,9 @@ - Internet Draft Patrik Faltstrom -draft-ietf-idn-idna-01.txt Cisco - Paul Hoffman +Internet Draft Patrik Faltstrom +draft-ietf-idn-idna-02.txt Cisco +June 16, 2001 Paul Hoffman Expires in six months IMC & VPNC - Internationalizing Host Names In Applications (IDNA) + Internationalizing Host Names In Applications (IDNA) Status of this Memo @@ -19,13 +19,11 @@ 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 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. - +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html. Abstract @@ -58,8 +56,8 @@ the body of the message. 1.1 Design philosophy -To date, the proposals for IDN protocols have required that DNS servers -be updated to handle internationalized host names. Because of this, the +Many proposals for IDN protocols have required that DNS servers be +updated to handle internationalized host names. Because of this, the person who wanted to use an internationalized host name had to be sure that their request went to a DNS server that was updated for IDN. Further, that server could only send queries to other servers that had @@ -69,13 +67,24 @@ these proposals require that resolvers must be updated to use the new protocols, and in most cases the applications would need to be updated as well. -Updating all (or even a significant percentage) of the DNS servers in -the world will be difficult, to say the least. Because of this, we have -designed a protocol that requires no updating of any name servers. IDNA -still requires the updating of applications, but once a user has updated -these, she or he could immediately start using internationalized host -names. The cost of implementing IDN would thus be much lower, and the -speed of implementation will be much higher. +These proposals would require that the application protocols that use +host names as protocol elements to change. This is due to the +assumptions and requirements made in those protocols about the +characters that have always been used for host names, and the encoding +of those characters. Other proposals for IDN protocols do not require +changes to DNS servers but still require changes to most application +protocols to handle the new names. + +Updating all (or even a significant percentage) of the existing servers +in the world will be difficult, to say the least. Updating applications, +application gateways, and clients to handle changes to the application +protocols is also daunting. Because of this, we have designed a protocol +that requires no updating of any name servers. IDNA still requires the +updating of applications, but only for input and display of names, not +for changes to the protocols. Once a user has updated these, she or he +could immediately start using internationalized host names. The cost of +implementing IDN may thus be much lower, and the speed of implementation +could be much higher. 1.2 Terminology @@ -98,26 +107,29 @@ The interfaces in IDNA can be represented pictorially as: +------+ | User | +------+ - ^ - | Input and display: local interface methods - | (pen, keyboard, glowing phosphorus, ...) - +--------------- v -------------------------------+ - | +-------------+ | - | | Application | | End system - | +-------------+ - | ^ - | | API call and return: nameprepped ACE - | v - | +----------+ - | | Resolver | - | +----------+ | - +----------------^--------------------------------+ - | DNS query and response: nameprepped ACE - v - +-------------+ - | DNS servers | - +-------------+ - + ^ + |Input and display: local interface methods + |(pen, keyboard, glowing phosphorus, ...) + +-----------------|------------------------------+ + | v | + | +--------------------------+ | + | | Application | | + | +--------------------------+ | + | ^ ^ | + | Call to resolver:| |Application-specific | + | nameprepped ACE| |protocol: | + | v |predefined by the | End system + | +----------+ |protocol or defaults | + | | Resolver | |to nameprepped ACE | + | +----------+ | | + | ^ | | + +---------------|----------|---------------------+ + DNS protocol:| | + nameprepped ACE| | + v v + +-------------+ +---------------------+ + | DNS servers | | Application servers | + +-------------+ +---------------------+ This document uses the generic term "ACE" for an ASCII-compatible encoding. After the IDN Working Group has chosen a specific ACE, this @@ -125,7 +137,7 @@ document will be updated to refer to just that single ACE. Until that time, an implementor creating experimental software must choose an ACE to use, such as RACE or LACE or DUDE. -2.1.1 Users and applications +2.1.1 Entry and display in applications Applications can accept host names using any character set or sets desired by the application developer, and can display host names in any @@ -145,6 +157,23 @@ glyphs, the rendering engine for an application SHOULD have an option for the user to select the preferred display; if it does, rendering the ACE SHOULD NOT be the default. +Host names are often stored and transported in many places. For example, +they are part of documents such as mail messages and web pages. They are +transported in the many parts of many protocols, such as both the +control commands and the RFC 2822 body parts of SMTP, and the headers +and the body content in HTTP. + +In protocols and document formats that define how to handle +specification or negotiation of charsets, IDN host name parts can be +given in any charset allowed by the protocol or document format. If a +protocol or document format only allows one charset, IDN host name parts +must be given in that charset. + +All protocols that have host names as protocol elements already have the +capacity for handling host names in the ASCII charset. Thus, IDN host +name parts can be specified in those protocols in the ACE charset, which +is a superset of the ASCII charset that uses the same set of octets. + 2.1.2 Applications and resolvers Applications communicate with resolver libraries through a programming @@ -193,6 +222,42 @@ possible in order to prevent users from seeing the ACE. However, this is not considered a big problem because so few applications show this type of resolution to users. +If an application decodes an ACE name but cannot show all of the +characters in the decoded name, such as if the name contains characters +that the output system cannot display, the application SHOULD show the +name in ACE format instead of displaying the name with the replacement +character (U+FFFD). This is to make it easier for the user to transfer +the name correctly to other programs using copy-and-paste techniques. +Programs that by default show the ACE form when they cannot show all the +characters in a name part SHOULD also have a mechanism to show the name +with as many characters as possible and replacement characters in the +positions where characters cannot be displayed. + +2.1.5 Automatic detection of ACE + +An application which receives a host name SHOULD verify whether or not +the host name is in ACE. This is possible by verifying the prefix in +each of the labels, and seeing whether or not the label is in ACE. This +MUST be done regardless of whether or not the communication channel used +(such as keyboard input, cut and paste, application protocol, +application payload, and so on) has negotiated ACE. + +The reason for this requirement is that many applications are not +ACE-aware. Applications that are not ACE-aware will send host names in +ACE but mark the charset as being US-ASCII or some other charset which +has the characters that are valid in [STD13] as a subset. + +2.1.6 Bidirectional text + +In IDNA, bidirectional text is entered and displayed exactly as it is +specified in ISO/IEC 10646. Both ISO/IEC 10646 and the Unicode standard +have extensive discussion of how to deal with bidirectional text. Any +input mechanism and display mechanism that handles characters from +bidirectional scripts should already conform to those specifications. +Note that the formatting characters that manually change the direction +of display are prohibited by nameprep, thus making the task for input +and display mechanisms easier. + 3. Name Server Considerations @@ -209,6 +274,8 @@ passed to an application, it will result in an error being passed to the application with no error being reported to the name server. Further, no application will ever ask for a name that is not legal in [NAMEPREP] because requests always go through [NAMEPREP] before getting to the DNS. +Note that [NAMEPREP] describes how to handle versioning of unallocated +codepoints. The host name data in zone files (as specified by section 5 of RFC 1035) MUST be both nameprepped and ACE encoded. @@ -217,7 +284,7 @@ MUST be both nameprepped and ACE encoded. 4. Root Server Considerations Because there are no changes to the DNS protocols, adopting this -protocol has no effect on the root servers. +protocol has no effect on the DNS root servers. 5. Security Considerations @@ -226,6 +293,17 @@ Much of the security of the Internet relies on the DNS. Thus, any change to the characteristics of the DNS can change the security of much of the Internet. +This memo describes an algorithm which encodes characters that are not +valid according to STD3 and STD13 into octet values that are valid. No +security issues such as string length increases or new allowed values +are introduced by the encoding process or the use of these encoded +values, apart from those introduced by the ACE encoding itself. + +When detecting an ACE-encoded host name, and decoding the ACE, care must +be taken that the resulting value(s) are valid characters which can be +handled by the application. This is described in more detail in section +2.1.4. + Host names are used by users to connect to Internet servers. The security of the Internet would be compromised if a user entering a single internationalized name could be connected to different servers @@ -243,9 +321,6 @@ Internationalized Host Names", draft-ietf-idn-nameprep. [RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate Requirement Levels", March 1997, RFC 2119. -[RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO -10646", January 1998, RFC 2279. - [STD3] Bob Braden, "Requirements for Internet Hosts -- Communication Layers" (RFC 1122) and "Requirements for Internet Hosts -- Application and Support" (RFC 1123), STD 3, October 1989. @@ -255,26 +330,23 @@ and Support" (RFC 1123), STD 3, October 1989. STD 13, November 1987. -B. Changes from the -00 draft +B. Changes from the -01 draft -Throughout: Changed "RACE" to "ACE" and removed RACE-specific wording. +1.1: Revised whole section to deal with more proposals. -1: Added pointer to the mailing list. +2.1: Clarified the ASCII art -1.3: Removed the [IDNCOMP] comparison section. +2.1.1: Changed the section title. Added the last three paragraphs. -2.1: Added the last paragraph discussing ACEs. +2.1.4: Added the second paragraph. -2.1.2: Changed the discussion of IPv6 APIs to say they are not -standards. Added reference to [STD3]. +2.1.6: Added this section. -2.1.3: Added reference to [STD3]. Removed the sentence about making -things smaller. +2.1.5: Added this section. -3: Added reference to [STD3]. +3: Added note in the last sentence of second paragraph. -6: Added [STD3], and updated the reference info for [STD13]. -Removed [IDNCOMP]. +5: Added second and third paragraphs. C. Authors' Addresses @@ -290,11 +362,4 @@ Paul Hoffman Internet Mail Consortium and VPN Consortium 127 Segre Place Santa Cruz, CA 95060 USA -phoffman@imc.org - - --- -Patrik F„ltstr÷m Cisco Systems -Consulting Engineer Office of the CSO -Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-8509 - PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC +phoffman@imc.org \ No newline at end of file