diff --git a/doc/draft/draft-ietf-dnsext-delegation-signer-08.txt b/doc/draft/draft-ietf-dnsext-delegation-signer-10.txt similarity index 84% rename from doc/draft/draft-ietf-dnsext-delegation-signer-08.txt rename to doc/draft/draft-ietf-dnsext-delegation-signer-10.txt index b5bcad3146..1c20262ef0 100644 --- a/doc/draft/draft-ietf-dnsext-delegation-signer-08.txt +++ b/doc/draft/draft-ietf-dnsext-delegation-signer-10.txt @@ -4,9 +4,10 @@ + DNSEXT Working Group Olafur Gudmundsson - INTERNET-DRAFT June 2002 - + INTERNET-DRAFT October 2002 + Updates: RFC 1035, RFC 2535, RFC 3008, RFC 3090. @@ -38,7 +39,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 December 30, 2002. + This draft expires on April 16, 2003. Copyright Notice @@ -56,9 +57,9 @@ Abstract -Gudmundsson Expires December 2002 [Page 1] - -INTERNET-DRAFT Delegation Signer Record June 2002 +Gudmundsson Expires April 2003 [Page 1] + +INTERNET-DRAFT Delegation Signer Record October 2002 operational considerations. The intent is to use this resource record @@ -85,7 +86,7 @@ INTERNET-DRAFT Delegation Signer Record June 2002 on the Internet have differing NS RRsets at parent and child. There are a number of reasons for this, including a lack of communication between parent and child and bogus name servers being listed to meet - registrar requirements. + registry requirements. DNSSEC [RFC2535,RFC3008,RFC3090] specifies that a child zone needs to have its KEY RRset signed by its parent to create a verifiable chain @@ -113,9 +114,9 @@ INTERNET-DRAFT Delegation Signer Record June 2002 -Gudmundsson Expires December 2002 [Page 2] - -INTERNET-DRAFT Delegation Signer Record June 2002 +Gudmundsson Expires April 2003 [Page 2] + +INTERNET-DRAFT Delegation Signer Record October 2002 Another complication of the DNSSEC key model is that the KEY record @@ -170,9 +171,9 @@ INTERNET-DRAFT Delegation Signer Record June 2002 -Gudmundsson Expires December 2002 [Page 3] - -INTERNET-DRAFT Delegation Signer Record June 2002 +Gudmundsson Expires April 2003 [Page 3] + +INTERNET-DRAFT Delegation Signer Record October 2002 This is cryptographically equivalent to using just KEY records. @@ -215,34 +216,38 @@ INTERNET-DRAFT Delegation Signer Record June 2002 RRset. If a query contains the OK bit, a server returning a referral for the delegation MUST include the following RRsets in the authority section in this order: + If DS RRset is present: parent NS RRset - DS and SIG(DS) (if DS is present) - parent NXT and SIG(NXT) (If no DS) + DS and SIG(DS) + If no DS RRset is present: + parent NS RRset + parent NXT and SIG(NXT) This increases the size of referral messages and may cause some or all glue to be omitted. If the DS or NXT RRsets with signatures do + + + +Gudmundsson Expires April 2003 [Page 4] + +INTERNET-DRAFT Delegation Signer Record October 2002 + + not fit in the DNS message, the TC bit MUST be set. Additional section processing is not changed. - - - -Gudmundsson Expires December 2002 [Page 4] - -INTERNET-DRAFT Delegation Signer Record June 2002 - - A DS RRset accompanying an NS RRset indicates that the child zone is secure. If an NS RRset exists without a DS RRset, the child zone is - unsecure. DS RRsets MUST NOT appear at non-delegation points or at a - zone's apex. + unsecure (from the parents point of view). DS RRsets MUST NOT appear + at non-delegation points or at a zone's apex. - The following section 2.2.1 replaces RFC2535 sections 2.3.4 and 3.4, - section 2.2.2 replaces RFC3008 section 2.7, and RFC3090 updates are - in section 2.2.3. + Section 2.2.1 defines special considerations related to authoritative + servers responding to DS queries. Section 2.2.2 replaces RFC2535 + sections 2.3.4 and 3.4, section 2.2.3 replaces RFC3008 section 2.7, + and section 2.2.4 updates RFC3090. -2.2.1 RFC2535 2.3.4 and 3.4: Special Considerations at Delegation Points +2.2.2 RFC2535 2.3.4 and 3.4: Special Considerations at Delegation Points DNS security views each zone as a unit of data completely under the control of the zone owner with each entry (RRset) signed by a special @@ -255,13 +260,13 @@ INTERNET-DRAFT Delegation Signer Record June 2002 since one server could be serving both the zone above and below a delegation point [RFC 2181]. - Each DS RRset stored in the parent zone MUST be signed by one of the - parent zone's private key. The parent zone MUST NOT contain a KEY - RRset at any delegation point. Delegations in the parent MAY contain - only the following RR types: NS, DS, NXT and SIG. The NS RRset MUST - NOT be signed. The NXT RRset is the exceptional case: it will always - appear differently and authoritatively in both the parent and child - zones if both are secure. + Each DS RRset stored in the parent zone MUST be signed by, at least, + one of the parent zone's private key. The parent zone MUST NOT + contain a KEY RRset at any delegation point. Delegations in the + parent MAY contain only the following RR types: NS, DS, NXT and SIG. + The NS RRset MUST NOT be signed. The NXT RRset is the exceptional + case: it will always appear differently and authoritatively in both + the parent and child zones if both are secure. A secure zone MUST contain a self-signed KEY RRset at its apex. Upon verifying the DS RRset from the parent, a resolver MAY trust any KEY @@ -275,20 +280,51 @@ INTERNET-DRAFT Delegation Signer Record June 2002 in the answer section. -2.2.2 Signer's Name (replaces RFC3008 section 2.7) + + + + + +Gudmundsson Expires April 2003 [Page 5] + +INTERNET-DRAFT Delegation Signer Record October 2002 + + +2.2.2.1 Special processing for DS queries + + When a server is authoritative for the parent zone at a delegation + point and receives a query for the DS record at that name, it will + return the DS from the parent zone. This is true whether or not it + is also authoritative for the child zone. + + When the server is authoritative for the child zone at a delegation + point but not the parent zone, there is no natural response, since + the child zone is not authoritative for the DS record at the zone's + apex. As these queries are only expected to originate from recursive + servers which are not DS-aware, the authoritative server MUST answer + with: + RCODE: NOERROR + AA bit: set + Answer Section: Empty + Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)] + + That is, it answers as if it is authoritative and the DS record does + not exist. DS-aware recursive servers will query the parent zone at + delegation points, so will not be affected by this. + + A server authoritative for only the child zone at a delegation point + that is also a caching server MAY (if the RD bit is set in the query) + perform recursion to find the DS record at the delegation point, and + may return the DS record from its cache. In this case, the AA bit + MUST not be set in the response. + + +2.2.3 Signer's Name (replaces RFC3008 section 2.7) The signer's name field of a SIG RR MUST contain the name of the zone to which the data and signature belong. The combination of signer's name, key tag, and algorithm MUST identify a zone key if the SIG is to be considered material. This document defines a standard policy - - - -Gudmundsson Expires December 2002 [Page 5] - -INTERNET-DRAFT Delegation Signer Record June 2002 - - for DNSSEC validation; local policy may override the standard policy. There are no restrictions on the signer field of a SIG(0) record. @@ -302,6 +338,15 @@ INTERNET-DRAFT Delegation Signer Record June 2002 record. + + + + +Gudmundsson Expires April 2003 [Page 6] + +INTERNET-DRAFT Delegation Signer Record October 2002 + + 2.2.4.1 RFC3090: Updates to section 1: Introduction Most of the text is still relevant but the words ``NULL key'' are to @@ -338,26 +383,27 @@ INTERNET-DRAFT Delegation Signer Record June 2002 DNS delegation model, declaring it to be broken because there is no good way to assert if a delegation exists. In the RFC2535 version of DNSSEC, the presence of the NS bit in the NXT bit map proves there is - - - -Gudmundsson Expires December 2002 [Page 6] - -INTERNET-DRAFT Delegation Signer Record June 2002 - - a delegation at this name. Something more explicit is needed and the DS record addresses this need for secure delegations. The DS record is a major change to DNS: it is the first resource record that can appear only on the upper side of a delegation. Adding - it will cause interoperability problems and requires a flag day for + it will cause interoperabilty problems and requires a flag day for DNSSEC. Many old servers and resolvers MUST be upgraded to take advantage of DS. Some old servers will be able to be authoritative for zones with DS records but will not add the NXT or DS records to the authority section. The same is true for caching servers; in fact, some may even refuse to pass on the DS or NXT records. + + + + +Gudmundsson Expires April 2003 [Page 7] + +INTERNET-DRAFT Delegation Signer Record October 2002 + + 2.4 Wire Format of the DS record The DS (type=TDB) record contains these fields: key tag, algorithm, @@ -393,16 +439,8 @@ INTERNET-DRAFT Delegation Signer Record June 2002 KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key Digest type value 0 is reserved, value 1 is SHA-1, and reserving - other types requires IETF standards action. For interoperability + other types requires IETF standards action. For interoperabilty reasons, as few digest algorithms as possible should be reserved. The - - - -Gudmundsson Expires December 2002 [Page 7] - -INTERNET-DRAFT Delegation Signer Record June 2002 - - only reason to reserve additional digest types is to increase security. @@ -415,6 +453,14 @@ INTERNET-DRAFT Delegation Signer Record June 2002 The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless of key size, new digest types probably will have larger digests. + + + +Gudmundsson Expires April 2003 [Page 8] + +INTERNET-DRAFT Delegation Signer Record October 2002 + + 2.4.1 Justifications for Fields The algorithm and key tag fields are present to allow resolvers to @@ -452,14 +498,6 @@ INTERNET-DRAFT Delegation Signer Record June 2002 delegations are locally secure. This is bad, but the DNSEXT Working Group has determined that rather than dealing with both RFC2535-secured zones and DS-secured zones, a rapid adoption of DS is - - - -Gudmundsson Expires December 2002 [Page 8] - -INTERNET-DRAFT Delegation Signer Record June 2002 - - preferable. Thus the only option for early adopters is to upgrade to DS as soon as possible. @@ -473,6 +511,13 @@ INTERNET-DRAFT Delegation Signer Record June 2002 RFC2535 adds the following two cases: + + +Gudmundsson Expires April 2003 [Page 9] + +INTERNET-DRAFT Delegation Signer Record October 2002 + + Secure RFC2535: NS + NXT + SIG(NXT) NXT bit map contains: NS SIG NXT Unsecure RFC2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT) @@ -512,9 +557,22 @@ INTERNET-DRAFT Delegation Signer Record June 2002 -Gudmundsson Expires December 2002 [Page 9] - -INTERNET-DRAFT Delegation Signer Record June 2002 + + + + + + + + + + + + + +Gudmundsson Expires April 2003 [Page 10] + +INTERNET-DRAFT Delegation Signer Record October 2002 3 Resolver @@ -547,9 +605,12 @@ INTERNET-DRAFT Delegation Signer Record June 2002 secure.example. SOA secure.example. NS ns1.secure.example. secure.example. KEY + secure.example. KEY + secure.example. NXT secure.example. SIG(KEY) - secure.example. SIG(SOA) - secure.example. SIG(NS) + secure.example. SIG(SOA) + secure.example. SIG(NS) + secure.example. SIG(NXT) In this example the private key for "example." signs the DS record for "secure.example.", making that a secure delegation. The DS record @@ -559,20 +620,22 @@ INTERNET-DRAFT Delegation Signer Record June 2002 and trusted. This example has only one DS record for the child, but parents MUST - allow multiple DS records to facilitate key rollover. It is strongly - recommended that the DS RRset be kept small: two or three DS records - SHOULD be sufficient in all cases. + allow multiple DS records to facilitate key rollover and multiple KEY + algorithms. + + + + + +Gudmundsson Expires April 2003 [Page 11] + +INTERNET-DRAFT Delegation Signer Record October 2002 + The resolver determines the security status of "unsecure.example." by examining the parent zone's NXT record for this name. The absence of - the DS bit indicates an unsecure delegation. - - - -Gudmundsson Expires December 2002 [Page 10] - -INTERNET-DRAFT Delegation Signer Record June 2002 - + the DS bit indicates an unsecure delegation. Note the NXT record + SHOULD only be examined after verifying the corresponding signature. 3.1 Resolver Cost Estimates for DS Records @@ -618,19 +681,18 @@ INTERNET-DRAFT Delegation Signer Record June 2002 The DS record represents a change to the DNSSEC protocol and there is an installed base of implementations, as well as textbooks on how to + + + +Gudmundsson Expires April 2003 [Page 12] + +INTERNET-DRAFT Delegation Signer Record October 2002 + + set up secure delegations. Implementations that do not understand the DS record will not be able to follow the KEY to DS to KEY chain and will consider all zones secured that way as unsecure. - - - - -Gudmundsson Expires December 2002 [Page 11] - -INTERNET-DRAFT Delegation Signer Record June 2002 - - 5 IANA Considerations: IANA needs to allocate an RR type code for DS from the standard RR @@ -675,19 +737,19 @@ Normative References: [RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC 3225, December 2001. + + + + +Gudmundsson Expires April 2003 [Page 13] + +INTERNET-DRAFT Delegation Signer Record October 2002 + + [RFC3226] O. Gudmundsson, ``DNSSEC and IPv6 A6 aware server/resolver message size requirements'', RFC 3226, December 2001. - - - - -Gudmundsson Expires December 2002 [Page 12] - -INTERNET-DRAFT Delegation Signer Record June 2002 - - Author Address Olafur Gudmundsson @@ -736,8 +798,5 @@ Full Copyright Statement +Gudmundsson Expires April 2003 [Page 14] - - - -Gudmundsson Expires December 2002 [Page 13] diff --git a/doc/draft/draft-ietf-dnsext-dnssec-intro-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-intro-03.txt similarity index 78% rename from doc/draft/draft-ietf-dnsext-dnssec-intro-02.txt rename to doc/draft/draft-ietf-dnsext-dnssec-intro-03.txt index 6637146e52..570e1edd3d 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-intro-02.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-intro-03.txt @@ -1,18 +1,18 @@ -Network Working Group R. Arends -Internet-Draft Nominum -Expires: January 21, 2003 M. Larson +DNS Extensions R. Arends +Internet-Draft +Expires: April 24, 2003 M. Larson VeriSign D. Massey USC/ISI S. Rose NIST - July 23, 2002 + October 24, 2002 DNS Security Introduction and Requirements - draft-ietf-dnsext-dnssec-intro-02 + draft-ietf-dnsext-dnssec-intro-03 Status of this Memo @@ -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 21, 2003. + This Internet-Draft will expire on April 24, 2003. Copyright Notice @@ -52,9 +52,9 @@ Abstract -Arends, et al. Expires January 21, 2003 [Page 1] +Arends, et al. Expires April 24, 2003 [Page 1] -Internet-Draft DNSSEC Intro. and Requirements July 2002 +Internet-Draft DNSSEC Intro. and Requirements October 2002 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", @@ -108,9 +108,9 @@ Table of Contents -Arends, et al. Expires January 21, 2003 [Page 2] +Arends, et al. Expires April 24, 2003 [Page 2] -Internet-Draft DNSSEC Intro. and Requirements July 2002 +Internet-Draft DNSSEC Intro. and Requirements October 2002 1. Introduction @@ -164,34 +164,34 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002 -Arends, et al. Expires January 21, 2003 [Page 3] +Arends, et al. Expires April 24, 2003 [Page 3] -Internet-Draft DNSSEC Intro. and Requirements July 2002 +Internet-Draft DNSSEC Intro. and Requirements October 2002 2. Definitions of Important DNSSEC Terms - trusted key: A public key, for a zone or a host, that a resolver - trusts and that can therefore be used to verify data. A key can - become trusted in two ways. First, it can be statically - configured and declared as trusted in the resolver's - configuration. Second, if a new key is referenced by a DS record - that is signed by an already trusted key, and the signature - verifies, the new key becomes trusted. + authentication key: A public key, for a zone or a host, that a + resolver trusts and that can therefore be used to verify data. A + key can become trusted in two ways: First, it can be statically + configured and declared in the resolver's initial configuration. + Second, if a new key is referenced by a DS record that is signed + by an already known authentication key, and the signature + verifies, the new key becomes trusted by the resolver. - chain of trust: In DNSSEC, a key signs a DS record, which points to - another key, which in turn signs another DS record, which points - to yet another key, etc. This alternating succession of KEY and - DS records forms a chain of signed data, with each link in the - chain vouching for the next. A resolver starting at a piece of - data in the chain signed by a trusted key can verify all - subsequent signatures. Thus all subsequent data in the chain is - trusted. + authentication path: In DNSSEC, a key signs a DS record, which points + to another key, which in turn signs another DS record, which + points to yet another key, etc. This alternating succession of + KEY and DS records forms a chain of signed data, with each link in + the chain vouching for the next. A resolver starting at a piece + of data in the chain signed by a known authentication key can + verify all subsequent signatures. Thus all subsequent data in the + chain is verified and authenticated. security-aware resolver: A resolver (defined in section 2.4 of [4]) that understands the DNS security extensions. In particular, a - security-aware resolver uses trusted keys to verify signatures - over RRsets and (optionally) DNS messages. + security-aware resolver uses known authentication keys to verify + signatures over RRsets and (optionally) DNS messages. security-aware server: A name server (also defined in section 2.4 of [4]) that understands the DNS security extensions. In particular, @@ -204,7 +204,7 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002 unsigned zone: The proper term for the opposite of a secure zone. - secure zone: A zone whose RRsets are signed and which contains + signed zone: A zone whose RRsets are signed and which contains properly constructed KEY, SIG, NXT and (optionally) DS records. @@ -220,9 +220,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002 -Arends, et al. Expires January 21, 2003 [Page 4] +Arends, et al. Expires April 24, 2003 [Page 4] -Internet-Draft DNSSEC Intro. and Requirements July 2002 +Internet-Draft DNSSEC Intro. and Requirements October 2002 3. Services Provided by DNS Security @@ -258,34 +258,36 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002 record (see Section 3.2 below). (Note that the private keys used to sign zone data must be kept secure and best practices call for them to be stored offline.) To reliably discover a public key by DNS - resolution, the key itself needs to be signed by another key that the - resolver trusts. Zone information is authenticated by forming a - chain of trust from a newly learned public key back to a trusted - public key (which is either statically configured or previously - learned and verified). Therefore, the resolver must be configured - with at least one public key that authenticates one zone as a - starting point. To establish this chain of trust, security-aware - servers attempt to send the signature(s) needed to authenticate a - zone's public key in the DNS reply message along with the public key - itself, provided there is space available in the message. + resolution, the key itself needs to be signed by either a statically + configured authentication key or another key that has been previously + authenticated. Zone information is authenticated by forming a chain + from a newly learned public key back to a previously known + authentication public key (which is either statically configured or + previously learned and verified). Therefore, the resolver must be + configured with at least one public key that authenticates one zone + as a starting point. To establish this authentication chain, + security-aware servers attempt to send the signature(s) needed to + authenticate a zone's public key in the DNS reply message along with + the public key itself, provided there is space available in the + message. - The chain of trust specified in the original DNS security extensions - proceeded from signed KEY record to signed KEY record, as necessary, - and finally to the queried RRset. A new record, the delegation - signer (DS), has been added for additional flexibility. The DS RRset + The authentication chain specified in the original DNS security + extensions proceeded from signed KEY record to signed KEY record, as -Arends, et al. Expires January 21, 2003 [Page 5] +Arends, et al. Expires April 24, 2003 [Page 5] -Internet-Draft DNSSEC Intro. and Requirements July 2002 +Internet-Draft DNSSEC Intro. and Requirements October 2002 - resides at a delegation point in a parent zone and specifies the keys - used by the specified child zone to self-sign the KEY RRset at its - apex. The child, in turn, uses one of these keys to sign its zone - data. The chain of trust is therefore DS->KEY->[DS->KEY->...]- - >RRset. + necessary, and finally to the queried RRset. A new record, the + delegation signer (DS), has been added for additional flexibility. + The DS RRset resides at a delegation point in a parent zone and + specifies the keys used by the specified child zone to self-sign the + KEY RRset at its apex. The child, in turn, uses one of these keys to + sign its zone data. The authentication chain is therefore DS->KEY- + >[DS->KEY->...]->RRset. Adding data origin authentication and data integrity requires minor changes to the on-the-wire DNS protocol. Several new resource record @@ -313,8 +315,8 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002 The KEY resource record is defined to associate public keys with DNS names. This record permits the DNS to be used as a public key distribution mechanism in support of DNSSEC. Security-aware - resolvers can query for a zone's public key when establishing a chain - of trust. + resolvers can query for a zone's public key when establishing a + authentication chain. The syntax of the KEY resource record (and the other additional resource records required for DNSSEC) is described in [9]. It @@ -327,17 +329,19 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002 now restricted for use with DNSSEC only. Work is in progress on storing public keys [14] and certificates [15] used by other protocols and applications in the DNS. A secure DNS tree could then - be used as a lightweight trust mechanism. Some administrators and - users may consider a validated DNSSEC signature to be sufficient to -Arends, et al. Expires January 21, 2003 [Page 6] +Arends, et al. Expires April 24, 2003 [Page 6] -Internet-Draft DNSSEC Intro. and Requirements July 2002 +Internet-Draft DNSSEC Intro. and Requirements October 2002 - trust a public key stored in the DNS. + be used as a lightweight key distribution mechanism that could + support other protocols. However, this should not lead to the + conclusion that the DNS is then safe to use as a trusted protocol or + a Public Key Infrastructure. DNSSEC lacks many features found in a + PKI such as a Certificate Revocation List (CRL). 3.3 Transaction Security @@ -384,13 +388,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002 - - - - -Arends, et al. Expires January 21, 2003 [Page 7] +Arends, et al. Expires April 24, 2003 [Page 7] -Internet-Draft DNSSEC Intro. and Requirements July 2002 +Internet-Draft DNSSEC Intro. and Requirements October 2002 4. Services Not Provided by DNS Security @@ -444,9 +444,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002 -Arends, et al. Expires January 21, 2003 [Page 8] +Arends, et al. Expires April 24, 2003 [Page 8] -Internet-Draft DNSSEC Intro. and Requirements July 2002 +Internet-Draft DNSSEC Intro. and Requirements October 2002 5. Resolver Considerations @@ -454,11 +454,12 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002 A security-aware resolver needs to be able to perform necessary cryptographic functions to verify digital signatures using at least the mandatory-to-implement algorithms. Also, security-aware - resolvers must be capable of forming a chain of trust from a newly - learned zone back to a trusted key. This might require additional - queries to intermediate DNS zones for necessary KEY, DS and SIG - records. It is assumed that a security-aware resolver will be - configured with at least one trusted key to aid this process. + resolvers must be capable of forming a authentication chain from a + newly learned zone back to a trusted authentication key. This might + require additional queries to intermediate DNS zones for necessary + KEY, DS and SIG records. It is assumed that a security-aware + resolver will be configured with at least one authentication key to + aid this process. The stub resolver found in many hosts may be augmented to provide a different set of security features instead of the full security @@ -472,7 +473,7 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002 part of the DNS resolution path, the resolver cannot ensure security. If a security-aware resolver must rely on an unsecure server (or unsigned zone), the resolver cannot verify DNS responses and should - rely on local policy when trusting responses. + rely on local policy when following responses. @@ -499,10 +500,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002 - -Arends, et al. Expires January 21, 2003 [Page 9] +Arends, et al. Expires April 24, 2003 [Page 9] -Internet-Draft DNSSEC Intro. and Requirements July 2002 +Internet-Draft DNSSEC Intro. and Requirements October 2002 6. Zone Considerations @@ -556,9 +556,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002 -Arends, et al. Expires January 21, 2003 [Page 10] +Arends, et al. Expires April 24, 2003 [Page 10] -Internet-Draft DNSSEC Intro. and Requirements July 2002 +Internet-Draft DNSSEC Intro. and Requirements October 2002 7. Server Considerations @@ -612,9 +612,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002 -Arends, et al. Expires January 21, 2003 [Page 11] +Arends, et al. Expires April 24, 2003 [Page 11] -Internet-Draft DNSSEC Intro. and Requirements July 2002 +Internet-Draft DNSSEC Intro. and Requirements October 2002 8. DNS Security Document Family @@ -638,7 +638,7 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002 | +-----------+ +-------------+ | DNSSEC | | New | - | Protocol |<-------->| Security | + | Protocol |--------->| Security | | Documents | | Uses | +-----------+ +-------------+ | @@ -668,9 +668,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002 -Arends, et al. Expires January 21, 2003 [Page 12] +Arends, et al. Expires April 24, 2003 [Page 12] -Internet-Draft DNSSEC Intro. and Requirements July 2002 +Internet-Draft DNSSEC Intro. and Requirements October 2002 2. Resource Records for DNS Security Extensions [9] @@ -724,9 +724,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002 -Arends, et al. Expires January 21, 2003 [Page 13] +Arends, et al. Expires April 24, 2003 [Page 13] -Internet-Draft DNSSEC Intro. and Requirements July 2002 +Internet-Draft DNSSEC Intro. and Requirements October 2002 9. IANA Considerations @@ -780,9 +780,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002 -Arends, et al. Expires January 21, 2003 [Page 14] +Arends, et al. Expires April 24, 2003 [Page 14] -Internet-Draft DNSSEC Intro. and Requirements July 2002 +Internet-Draft DNSSEC Intro. and Requirements October 2002 10. Security Considerations @@ -836,9 +836,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002 -Arends, et al. Expires January 21, 2003 [Page 15] +Arends, et al. Expires April 24, 2003 [Page 15] -Internet-Draft DNSSEC Intro. and Requirements July 2002 +Internet-Draft DNSSEC Intro. and Requirements October 2002 11. Acknowledgements @@ -892,9 +892,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002 -Arends, et al. Expires January 21, 2003 [Page 16] +Arends, et al. Expires April 24, 2003 [Page 16] -Internet-Draft DNSSEC Intro. and Requirements July 2002 +Internet-Draft DNSSEC Intro. and Requirements October 2002 Normative References @@ -948,9 +948,9 @@ Normative References -Arends, et al. Expires January 21, 2003 [Page 17] +Arends, et al. Expires April 24, 2003 [Page 17] -Internet-Draft DNSSEC Intro. and Requirements July 2002 +Internet-Draft DNSSEC Intro. and Requirements October 2002 Informative References @@ -968,12 +968,11 @@ Informative References Authors' Addresses Roy Arends - Nominum, Inc. - 2385 Bay Street - Redwood City, CA 94063 - USA + Bankastraat 41-E + 1094 EB Amsterdam + NL - EMail: roy.arends@nominum.com + EMail: roy@logmess.com Matt Larson @@ -997,16 +996,17 @@ Authors' Addresses Scott Rose National Institute for Standards and Technology 100 Bureau Drive - Gaithersburg, MD 20899-3460 + Gaithersburg, MD 20899-8920 USA EMail: scott.rose@nist.gov -Arends, et al. Expires January 21, 2003 [Page 18] + +Arends, et al. Expires April 24, 2003 [Page 18] -Internet-Draft DNSSEC Intro. and Requirements July 2002 +Internet-Draft DNSSEC Intro. and Requirements October 2002 Full Copyright Statement @@ -1060,5 +1060,5 @@ Acknowledgement -Arends, et al. Expires January 21, 2003 [Page 19] +Arends, et al. Expires April 24, 2003 [Page 19] diff --git a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-03.txt similarity index 54% rename from doc/draft/draft-ietf-dnsext-dnssec-opt-in-02.txt rename to doc/draft/draft-ietf-dnsext-dnssec-opt-in-03.txt index 8f716aecfb..e0702cb557 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-02.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-03.txt @@ -1,13 +1,15 @@ + + Network Working Group R. Arends -Internet-Draft Nominum, Inc. -Expires: December 26, 2002 M. Kosters +Internet-Draft +Expires: April 14, 2003 M. Kosters D. Blacka Verisign, Inc. - June 27, 2002 + October 14, 2002 DNSSEC Opt-In - draft-ietf-dnsext-dnssec-opt-in-02 + draft-ietf-dnsext-dnssec-opt-in-03 Status of this Memo @@ -30,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 December 26, 2002. + This Internet-Draft will expire on April 14, 2003. Copyright Notice @@ -42,7 +44,7 @@ Abstract secured. Maintaining this cryptography is not practical or necessary. This document describes an "Opt-In" model that allows administrators to omit this cryptography and manage the cost of - adopting DNSSEC. + adopting DNSSEC with large zones. @@ -50,28 +52,36 @@ Abstract -Arends, et al. Expires December 26, 2002 [Page 1] +Arends, et al. Expires April 14, 2003 [Page 1] -Internet-Draft DNSSEC Opt-In June 2002 +Internet-Draft DNSSEC Opt-In October 2002 Table of Contents - 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 - 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 5 - 3.1 Server Considerations . . . . . . . . . . . . . . . . . . . . 5 - 3.2 Client Considerations . . . . . . . . . . . . . . . . . . . . 6 - 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 - References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 - A. Implementing Opt-In using "Views" . . . . . . . . . . . . . . 16 - B. Changes from Prior Versions . . . . . . . . . . . . . . . . . 18 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19 + 1. Definitions and Terminology . . . . . . . . . . . . . . . . 3 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Protocol Additions . . . . . . . . . . . . . . . . . . . . . 5 + 3.1 Server Considerations . . . . . . . . . . . . . . . . . . . 6 + 3.1.1 Delegations Only . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1.2 Insecure Delegation Responses . . . . . . . . . . . . . . . 6 + 3.1.3 Wildcards and Opt-In . . . . . . . . . . . . . . . . . . . . 6 + 3.2 Client Considerations . . . . . . . . . . . . . . . . . . . 7 + 3.2.1 Delegations Only . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2.2 Validation Process Changes . . . . . . . . . . . . . . . . . 7 + 3.2.3 NXT Record Caching . . . . . . . . . . . . . . . . . . . . . 8 + 3.2.4 Use of the AD bit . . . . . . . . . . . . . . . . . . . . . 8 + 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6. Transition Issues . . . . . . . . . . . . . . . . . . . . . 12 + 7. Security Considerations . . . . . . . . . . . . . . . . . . 13 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 + References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 + A. Implementing Opt-In using "Views" . . . . . . . . . . . . . 18 + B. Changes from Prior Versions . . . . . . . . . . . . . . . . 20 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 21 @@ -98,17 +108,9 @@ Table of Contents - - - - - - - - -Arends, et al. Expires December 26, 2002 [Page 2] +Arends, et al. Expires April 14, 2003 [Page 2] -Internet-Draft DNSSEC Opt-In June 2002 +Internet-Draft DNSSEC Opt-In October 2002 1. Definitions and Terminology @@ -121,16 +123,19 @@ Internet-Draft DNSSEC Opt-In June 2002 RR: is used to refer to a DNS resource record. - RRset: refers to a Resource Record Set, as defined by [3]. + RRset: refers to a Resource Record Set, as defined by [3]. In this + document, the RRset is also defined to include the covering SIG + records, if any exist. covering NXT record/RRset: is the NXT record used to prove - (non)existance of a particular name or RRset. This means that for + (non)existence of a particular name or RRset. This means that for a RRset or name 'N', the covering NXT record has the name 'N', or has an owner name less than 'N' and "next" name greater than 'N'. delegation: refers to a NS RRset with a name different from the current zone apex (non-zone-apex), signifying a delegation to a - subzone. + subzone. A delegation returned in a DNS response is also called a + "referral". secure delegation: refers to the NS, DS, NXT and SIG RRsets for a non-zone-apex owner name, signifying a delegation to a DNSSEC @@ -159,12 +164,9 @@ Internet-Draft DNSSEC Opt-In June 2002 - - - -Arends, et al. Expires December 26, 2002 [Page 3] +Arends, et al. Expires April 14, 2003 [Page 3] -Internet-Draft DNSSEC Opt-In June 2002 +Internet-Draft DNSSEC Opt-In October 2002 2. Overview @@ -218,9 +220,9 @@ Internet-Draft DNSSEC Opt-In June 2002 -Arends, et al. Expires December 26, 2002 [Page 4] +Arends, et al. Expires April 14, 2003 [Page 4] -Internet-Draft DNSSEC Opt-In June 2002 +Internet-Draft DNSSEC Opt-In October 2002 3. Protocol Additions @@ -228,12 +230,12 @@ Internet-Draft DNSSEC Opt-In June 2002 In RFC 2535, delegation NS RRsets are not signed, but instead are accompanied by a NXT RRset of the same name, and possibly a ("no- key") KEY RR [4] or DS record [7]. The security status of the - subzone is determined by the presence or absence of the KEY or DS - records, cryptographically proven by the NXT record. Opt-In expands - this definition by allowing insecure delegations to exist within an + subzone is determined by the presence of the KEY or DS records, + cryptographically proven by the NXT record. Opt-In expands this + definition by allowing insecure delegations to exist within an otherwise signed zone without the corresponding NXT record at the delegation's owner name. These insecure delegations are proven - insecure by using the covering NXT record. + insecure by using a covering NXT record. Since this represents a change of the interpretation of NXT records, resolvers must be able to distinguish between RFC 2535 NXT records @@ -264,79 +266,174 @@ Internet-Draft DNSSEC Opt-In June 2002 o A RFC2535 NXT type is identified by a one-valued NXT bit in the type bit map of the NXT record. + and, + + o An Opt-In NXT record does not assert the non-existence of a name + between its owner name and "next" name, although it does assert + that any name in this span MUST be an insecure delegation. + + o An Opt-In NXT record does assert the (non)existence of RRsets with + + + +Arends, et al. Expires April 14, 2003 [Page 5] + +Internet-Draft DNSSEC Opt-In October 2002 + + + the same owner name. + 3.1 Server Considerations - This protocol change dictates a number of changes to the operation of - an authoritative server: + Opt-In imposes some new requirements on authoritative DNS servers. - o The server MUST enforce the protocol requirement that ONLY +3.1.1 Delegations Only + + This specification dictates that only insecure delegations may exist + between the owner and "next" names of an Opt-In tagged NXT record. + Servers and signing tools MUST enforce this restriction. + +3.1.2 Insecure Delegation Responses + + When returning an Opt-In insecure delegation, the server MUST return + the covering NXT RRset in the Authority section. + + This presents a change from RFC 2535, where the "no-key" KEY RRset + would be returned instead. However, in the delegation signer + proposal, NXT records already must be returned along with the + insecure delegation. The primary difference that this proposal + introduces is that the Opt-In tagged NXT record will have a different + owner name from the delegation RRset. This may require + implementations to do a NXT search on cached responses. + +3.1.3 Wildcards and Opt-In + + RFC 2535, in section 5.3, describes the practice of returning NXT + records to prove the non-existence of an applicable wildcard in non- + existent name responses. This NXT record can be described as a + "negative wildcard proof". The use of Opt-In NXT records changes the + necessity for this practice. For both non-existent name (NXDOMAIN) + responses and Opt-In insecure delegation responses, servers MUST NOT + return negative wildcard proof records when the query name (qname) is + covered by an Opt-In tagged NXT record. + + The intent of the RFC 2535 negative wildcard proof requirement is to + prevent malicious users from undetectably removing valid wildcard + responses. In order for this cryptographic proof to work, the + resolver must be able to prove: + + 1. The exact qname does not exist. This is done by the "normal" NXT + record. + + 2. No applicable wildcard exists. This is done by returning one or + more NXT records proving that the wildcards do not exist + (negative wildcard proofs). -Arends, et al. Expires December 26, 2002 [Page 5] +Arends, et al. Expires April 14, 2003 [Page 6] -Internet-Draft DNSSEC Opt-In June 2002 +Internet-Draft DNSSEC Opt-In October 2002 - insecure delegation nodes may exist between the secure nodes of - the zone. + However, if the NXT record covering the exact qname is an Opt-In NXT + record, the resolver will not be able to prove the first part of this + equation, as the qname might exist as an insecure delegation. Thus, + since the total proof cannot be completed, the negative wildcard + proof records are not useful. - o The server must be able to retrieve the proper NXT records along - with referrals to insecure subzone. + The negative wildcard proofs are also not useful when returned as + part of an Opt-In insecure delegation response for a similar reason: + the resolver cannot prove that the qname does or does not exist, and + therefore cannot prove that a wildcard expansion is valid. - In the delegation signer proposal, NXT records already must be - returned along with referrals to insecure delegations. The primary - difference that this proposal introduces is that the appropriate NXT - record will have a different owner name. + The presence of an Opt-In tagged NXT record does not change the + practice of returning a NXT along with a wildcard expansion. Even + though the Opt-In NXT will not be able to prove that the wildcard + expansion is valid, it will prove that the wildcard expansion is not + masking any signed records. 3.2 Client Considerations - Opt-In imposes some new requirements on the DNS resolver (caching or - otherwise): + Opt-In imposes some new requirements on DNS resolvers (caching or + otherwise). - o Resolvers MUST be able to use Opt-In style NXT records to - cryptographically prove the validity and security status (as - insecure) of a referral: +3.2.1 Delegations Only - * In RFC 2535, this is proven by existence of a verified "no-key" - KEY RRset. + As stated in the "Server Considerations" section above, this + specification restricts the namespace covered by Opt-In tagged NXT + records to insecure delegations only. Thus, resolvers MUST reject as + invalid any records that fall within an Opt-In NXT record's span that + are not NS records or corresponding glue records. - * Using Delegation Signer, this is proven by the existence of a - verified NXT record. This NXT record has same name as the - delegation RRset and does not have the DS bit set in the type - map. +3.2.2 Validation Process Changes - * Using Opt-In, this is proven by the existence of a verified - Opt-In NXT record. This NXT record does not have the NXT bit - set in the type map (that is, it is an Opt-In style NXT record) - and the name of the delegation RRset is lexicographically - between the owner and next names of the NXT record. + This specification does not change the resolver's resolution + algorithm. However, it does change the DNSSEC validation process. + Resolvers MUST be able to use Opt-In tagged NXT records to + cryptographically prove the validity and security status (as + insecure) of a referral. Resolvers determine the security status of + the referred-to zone as follows: - Note that using Opt-In does not substantially change the nature of - following referrals within DNSSEC. At every delegation point, the - resolver will have cryptographic proof that the subzone is secure - or insecure. + o In RFC 2535, the security status is proven by existence of a + verified "no-key" KEY RRset. The absence of the "no-key" KEY + RRset indicates that the referred-to zone is secure. - o Resolvers MUST reject as invalid non-NS RRsets that fall within an - Opt-In tagged NXT record's span. - - o Caching resolvers must be able to retrieve the appropriate - covering Opt-In NXT record when returning referrals that need - them. This is only a difference when you consider that the - covering NXT record will not have the same name as the delegation - RRset itself. + o Using Delegation Signer, the security status is proven by the + existence or absence of a DS record at the same name as the + delegation. The absence is proven using a verified NXT record of + the same name that does not have the DS bit set in the type map. + This NXT record MAY also be tagged as Opt-In. - -Arends, et al. Expires December 26, 2002 [Page 6] +Arends, et al. Expires April 14, 2003 [Page 7] -Internet-Draft DNSSEC Opt-In June 2002 +Internet-Draft DNSSEC Opt-In October 2002 - o The AD bit (as defined by [8]) MUST NOT be set in a response - containing an Opt-In tagged NXT record in the authority section. + o Using Opt-In, the security status is proven by the existence of a + DS record (for secure) or the presence of a verified Opt-In tagged + NXT record that covers the delegation name. That is, the NXT + record does not have the NXT bit set in the type map, and the + delegation name falls between the NXT's owner and "next" name. + + Using Opt-In does not substantially change the nature of following + referrals within DNSSEC. At every delegation point, the resolver + will have cryptographic proof that the subzone is secure or insecure. + + When receiving either an Opt-In insecure delegation response or a + non-existent name response where that name is covered by an Opt-In + tagged NXT record, the resolver MUST NOT require proof (in the form + of a NXT record) that a wildcard did not exist. + +3.2.3 NXT Record Caching + + Caching resolvers MUST be able to retrieve the appropriate covering + Opt-In NXT record when returning referrals that need them. This + requirement differs from Delegation Signer in that the covering NXT + will not have the same owner name as the delegation. Some + implementations may have to use new methods for finding these NXT + records. + +3.2.4 Use of the AD bit + + The AD bit, as defined by [8], MUST NOT be set when: + + o sending a non-existent name (NXDOMAIN) response where the covering + NXT is tagged as Opt-In, unless the NXT record's owner name equals + the qname. + + o sending an Opt-In insecure delegation response, unless the + covering (Opt-In) NXT record's owner name equals the delegation + name. + + This rule is based on what the Opt-In NXT record actually proves. + For names that exist between the Opt-In NXT record's owner and "next" + names, the Opt-In NXT record cannot prove the non-existence or + existence of the name. As such, not all data in the response has + been cryptographically verified, so the AD bit cannot be set. @@ -347,48 +444,9 @@ Internet-Draft DNSSEC Opt-In June 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires December 26, 2002 [Page 7] +Arends, et al. Expires April 14, 2003 [Page 8] -Internet-Draft DNSSEC Opt-In June 2002 +Internet-Draft DNSSEC Opt-In October 2002 4. Benefits @@ -442,9 +500,9 @@ Internet-Draft DNSSEC Opt-In June 2002 -Arends, et al. Expires December 26, 2002 [Page 8] +Arends, et al. Expires April 14, 2003 [Page 9] -Internet-Draft DNSSEC Opt-In June 2002 +Internet-Draft DNSSEC Opt-In October 2002 5. Example @@ -483,10 +541,12 @@ Internet-Draft DNSSEC Opt-In June 2002 In this example, a query for a signed RRset (e.g., "FIRST- SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND- - SECURE.EXAMPLE A") will result in a standard RFC 2535 response. A - query for a nonexistent RRset will result in a response that differs - from RFC 2535 only in the fact that the NXT record will be tagged as - Opt-In. + SECURE.EXAMPLE A") will result in a standard RFC 2535 response. + + A query for a nonexistent RRset will result in a response that + differs from RFC 2535 by: the NXT record will be tagged as Opt-In, + there will be no NXT record proving the non-existence of a matching + wildcard record, and the AD bit will not be set. A query for an insecure delegation RRset (or a referral) will return both the answer (in the Authority section) and the corresponding Opt- @@ -496,17 +556,15 @@ Internet-Draft DNSSEC Opt-In June 2002 - - -Arends, et al. Expires December 26, 2002 [Page 9] +Arends, et al. Expires April 14, 2003 [Page 10] -Internet-Draft DNSSEC Opt-In June 2002 +Internet-Draft DNSSEC Opt-In October 2002 - Example A.1: Response to query for WWW.UNSECURE.EXAMPLE. A + Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A - RCODE=NOERROR + RCODE=NOERROR, AD=0 Answer Section: @@ -554,19 +612,79 @@ Internet-Draft DNSSEC Opt-In June 2002 -Arends, et al. Expires December 26, 2002 [Page 10] +Arends, et al. Expires April 14, 2003 [Page 11] -Internet-Draft DNSSEC Opt-In June 2002 +Internet-Draft DNSSEC Opt-In October 2002 -6. Security Considerations +6. Transition Issues - Opt-In allows for unsigned delegations. All unsigned names are - insecure, and their validity (or existence) can not be + Opt-In is not backwards compatible with RFC 2535. RFC 2535 compliant + DNSSEC implementations will not recognize Opt-In tagged NXT records + as different from RFC 2535 NXT records. Because of this, RFC 2535 + implementations will reject all Opt-In insecure delegations within a + zone as invalid. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 14, 2003 [Page 12] + +Internet-Draft DNSSEC Opt-In October 2002 + + +7. Security Considerations + + Opt-In allows for unsigned names. All unsigned names are, by + definition, insecure, and their validity (or existence) can not be cryptographically proven. With Opt-In, a malicious entity is able - to: insert, modify, or delete insecure delegation RRsets within a - secured zone. For example, if a resolver received the following - response from the example zone above: + to: insert, modify, or delete insecure delegation RRsets within the + Opt-In spans of a otherwise secured zone. In addition, a malicious + entity is able to replay or delete wildcard expansions (if there is + an existing applicable wildcard) in the Opt-In spans of the zone. + + For example, if a resolver received the following response from the + example zone above: Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A @@ -606,16 +724,12 @@ Internet-Draft DNSSEC Opt-In June 2002 - - - - -Arends, et al. Expires December 26, 2002 [Page 11] +Arends, et al. Expires April 14, 2003 [Page 13] -Internet-Draft DNSSEC Opt-In June 2002 +Internet-Draft DNSSEC Opt-In October 2002 -7. IANA Considerations +8. IANA Considerations None. @@ -666,12 +780,12 @@ Internet-Draft DNSSEC Opt-In June 2002 -Arends, et al. Expires December 26, 2002 [Page 12] +Arends, et al. Expires April 14, 2003 [Page 14] -Internet-Draft DNSSEC Opt-In June 2002 +Internet-Draft DNSSEC Opt-In October 2002 -8. Acknowledgments +9. Acknowledgments The contributions, suggestions and remarks of the following persons (in alphabetic order) to this draft are acknowledged: @@ -722,9 +836,9 @@ Internet-Draft DNSSEC Opt-In June 2002 -Arends, et al. Expires December 26, 2002 [Page 13] +Arends, et al. Expires April 14, 2003 [Page 15] -Internet-Draft DNSSEC Opt-In June 2002 +Internet-Draft DNSSEC Opt-In October 2002 References @@ -748,39 +862,22 @@ References December 2001. [7] Gudmundsson, O., "Delegation Signer Resource Record", draft- - ietf-dnsext-delegation-signer-07 (work in progress), March 2002. + ietf-dnsext-delegation-signer-09 (work in progress), September + 2002. [8] Gudmundsson, O. and B. Wellington, "Redefinition of DNS AD bit", - draft-ietf-dnsext-ad-is-secure-05 (work in progress), March - 2002. + draft-ietf-dnsext-ad-is-secure-06 (work in progress), June 2002. Authors' Addresses Roy Arends - Nominum, Inc. - 950 Charter Street - Redwood City, CA 94063 - US + Bankastraat 41-E + 1094 EB Amsterdam + NL - Phone: +1 650 381 6000 - EMail: Roy.Arends@nominum.com - URI: http://www.nominum.com - - - - - - - - - - - - -Arends, et al. Expires December 26, 2002 [Page 14] - -Internet-Draft DNSSEC Opt-In June 2002 + Phone: +31206931681 + EMail: roy@logmess.com Mark Kosters @@ -794,6 +891,12 @@ Internet-Draft DNSSEC Opt-In June 2002 URI: http://www.verisignlabs.com + +Arends, et al. Expires April 14, 2003 [Page 16] + +Internet-Draft DNSSEC Opt-In October 2002 + + David Blacka Verisign, Inc. 21355 Ridgetop Circle @@ -834,9 +937,20 @@ Internet-Draft DNSSEC Opt-In June 2002 -Arends, et al. Expires December 26, 2002 [Page 15] + + + + + + + + + + + +Arends, et al. Expires April 14, 2003 [Page 17] -Internet-Draft DNSSEC Opt-In June 2002 +Internet-Draft DNSSEC Opt-In October 2002 Appendix A. Implementing Opt-In using "Views" @@ -890,9 +1004,9 @@ Appendix A. Implementing Opt-In using "Views" -Arends, et al. Expires December 26, 2002 [Page 16] +Arends, et al. Expires April 14, 2003 [Page 18] -Internet-Draft DNSSEC Opt-In June 2002 +Internet-Draft DNSSEC Opt-In October 2002 For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the @@ -946,13 +1060,20 @@ Internet-Draft DNSSEC Opt-In June 2002 -Arends, et al. Expires December 26, 2002 [Page 17] +Arends, et al. Expires April 14, 2003 [Page 19] -Internet-Draft DNSSEC Opt-In June 2002 +Internet-Draft DNSSEC Opt-In October 2002 Appendix B. Changes from Prior Versions + Changes from version 02: + + Added text on changes to validation process, use of the AD bit, + and interactions with wildcards. Added wildcard caveats to the + "Security Considerations" section. Added "Transition Issues" + section. + Changes from version 01: Changed to "delegation only". Strengthened "Security @@ -995,16 +1116,9 @@ Appendix B. Changes from Prior Versions - - - - - - - -Arends, et al. Expires December 26, 2002 [Page 18] +Arends, et al. Expires April 14, 2003 [Page 20] -Internet-Draft DNSSEC Opt-In June 2002 +Internet-Draft DNSSEC Opt-In October 2002 Full Copyright Statement @@ -1058,4 +1172,5 @@ Acknowledgement -Arends, et al. Expires December 26, 2002 [Page 19] +Arends, et al. Expires April 14, 2003 [Page 21] + diff --git a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-00.txt b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-00.txt deleted file mode 100644 index e8fb4665a4..0000000000 --- a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-00.txt +++ /dev/null @@ -1,336 +0,0 @@ - - -DNS Extentions O. Kolkman -Internet-Draft RIPE NCC -Expires: March 4, 2003 September 3, 2002 - - - KEY RR Key Signing (KS) Flag - draft-ietf-dnsext-keyrr-key-signing-flag-00.txt - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on March 4, 2003. - -Copyright Notice - - Copyright (C) The Internet Society (2002). All Rights Reserved. - -Abstract - - The Introduction of the DS [1] record has introduced the concept of - KEY signing and zone signing keys. In general, KEY signing keys are - the keys that are pointed to by DS records and are the secure entry - points to a zone. The key signing keys only sign the KEY RRset at - the apex of a zone, zone signing keys sign all data in a zone. We - propose a flag to distinguish the KEY signing key from other keys in - the KEY RR set during DNSSEC operations. - - The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", - "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be - interpreted as described in RFC2119. - - - - -Kolkman Expires March 4, 2003 [Page 1] - -Internet-Draft KEY RR Key Signing (KS) Flag September 2002 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. The Key Signing flag . . . . . . . . . . . . . . . . . . . . . . 3 - 3. DNSSEC Protocol changes . . . . . . . . . . . . . . . . . . . . 3 - 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 4 - 5. Security considerations . . . . . . . . . . . . . . . . . . . . 4 - 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 - References . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 6 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kolkman Expires March 4, 2003 [Page 2] - -Internet-Draft KEY RR Key Signing (KS) Flag September 2002 - - -1. Introduction - - The Introduction of the DS record has introduced the concept of KEY - signing keys. In general these are the keys that are pointed to by - DS records and are the secure entry points to a zone. These key - signing keys may also be configured in resolver systems that use - zones as a root for a secure island. - - Early deployment tests have shown that during DNSSEC parent-child - interactions it is useful to indicate which keys are to be used as - the secure entry point to a zone. We introduce the Key Signing Key - flag to indicate this special 'administrative' status of the key. - - During DNSSEC parent-child interactions it is useful to indicate - which keys are to be used as the secure entry point to a zone. - During key rollovers the KS-flag can be used by the parent to - determine from which key the DS RR is to be generated from. - -2. The Key Signing flag - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | flags |K| protocol | algorithm | - | |S| | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | / - / public key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - KEY RR Format - - - - The bit 15th bit (TBD) in the flags field is assigned to be the key - signing flag. If set the key is intended to be used as key signing - key. If the bit is not set then no special meaning should be - assigned. The 15th bit is currently reserved [2]. - -3. DNSSEC Protocol changes - - The use of the KS flag does NOT change the DNS resolution and - resolution protocol. The KS flag is only used to provide a hint - about the different administrative properties and MUST NOT be used - during the resolving process. - - - - -Kolkman Expires March 4, 2003 [Page 3] - -Internet-Draft KEY RR Key Signing (KS) Flag September 2002 - - -4. Operational Guidelines - - By setting the KS-flag on a particular key, zone administrators - indicate that that key should be used as the secure entry point for - their zone. Therefore zone administrators SHOULD set the bit only - for zone keys that are used to sign the KEY RRset and are intended to - act as the top of the chain of trust for their zone. - - Parent zone administrators and resolver administrators MAY choose to - ignore the flag. - - Even with the KS-flag there is no mechanism to distinguish between - keys that should be used by the parent to point DS records to or keys - to be used by resolver administrators as statically configured keys. - - If the bit is modified during the lifetime of the key then this would - have impact on the keytag and on the hash data in the DS RRs - intending to point to this key. The bit SHOULD NOT be modified once - the key has been put into use. - -5. Security considerations - - The flag MUST NOT be used in the resolution protocol or to determine - the security status of a key. The flag is to be used for - administrative purposes only. - - If the flag is used to determine which key is to be used as the - secure entry point then the trust in the key should be inferred from - an existing DNS chain of trust or by an out of band key exchange. - -6. Acknowledgments - - The ideas documented in this draft are inspired by communications we - had with numerous people and ideas published by other folk, Jakob - Schlyter and Olafur Gudmundsson and Dan Massey have been most - substantial in providing ideas and feedback. - - This document saw the light during a workshop on DNSSEC operations - hosted by USC/ISI. - - "Animal Farm; a Fairy Story" was first published by George Orwell in - 1945, The version illustrated by Ralph Steadman is one we recommend ( - ISBN: 0151002177 ). - -References - - [1] Gudmundsson, "Delegation Signer Resource Record", work in - progress draft-ietf-dnsext-delegation-signer-08.txt, June 2002. - - - -Kolkman Expires March 4, 2003 [Page 4] - -Internet-Draft KEY RR Key Signing (KS) Flag September 2002 - - - [2] Massey and Rose, "Limiting the Scope of the KEY Resource - Record", work in progress draft-ietf-dnsext-restrict-key-for- - dnssec-03, June 28 2002. - - -Author's Address - - Olaf M. Kolkman - RIPE NCC - Singel 256 - Amsterdam 1016 AB - NL - - Phone: +31 20 535 4444 - EMail: olaf@ripe.net - URI: http://www.ripe.net/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kolkman Expires March 4, 2003 [Page 5] - -Internet-Draft KEY RR Key Signing (KS) Flag September 2002 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2002). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Kolkman Expires March 4, 2003 [Page 6] - diff --git a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-01.txt b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-01.txt new file mode 100644 index 0000000000..c7cccbff2f --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-01.txt @@ -0,0 +1,392 @@ + + +DNS Extensions O. Kolkman +Internet-Draft RIPE NCC +Expires: March 2, 2003 J. Schlyter + Carlstedt Research & + Technology + September 2002 + + + KEY RR Key Signing (KS) Flag + draft-ietf-dnsext-keyrr-key-signing-flag-01 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on March 2, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + With the DS record [1] the concept of key signing and zone signing + keys has been introduced. Key signing keys are the keys that sign + the keyset only. In general, key signing keys are the keys that are + pointed to by DS records and are the first keys to be used when + following a chain of trust into the zone. The key signing keys only + sign the KEY RRset at the apex of a zone, zone signing keys sign all + data in a zone. We propose a flag to distinguish the key signing key + from other keys in the KEY RR set during DNSSEC operations. + + + + +Kolkman & Schlyter Expires March 2, 2003 [Page 1] + +Internet-Draft KEY RR Key Signing (KS) Flag September 2002 + + + The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", + "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be + interpreted as described in RFC2119. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The Key Signing Flag . . . . . . . . . . . . . . . . . . . . . 3 + 3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . 3 + 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 + 6. Document Changes . . . . . . . . . . . . . . . . . . . . . . . 4 + 6.1 draft version 00 -> 01 . . . . . . . . . . . . . . . . . . . . 5 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 + References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman & Schlyter Expires March 2, 2003 [Page 2] + +Internet-Draft KEY RR Key Signing (KS) Flag September 2002 + + +1. Introduction + + "All keys are equal but some keys are more equal than others" [2] + + With the DS record [1] the concept of key signing and zone signing + keys has been introduced. In general these are the keys that are + pointed to by DS records and are the first keys to be used when + following the chain of trust into a zone ( secure entry points of the + zone). These key signing keys may also be configured in resolver + systems that use zones as a trusted root[4] for a secure island. + + Early deployment tests have shown that during the key-exchange + between the parent and the child it is useful to indicate which keys + are to be used as the secure entry point to a zone. We introduce the + Key Signing Key flag to indicate this special 'administrative' status + of the key. The availability of the flag allows the key exchange to + be automated where, without the flag, some additional out-of-band + communication is needed. + +2. The Key Signing Flag + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | flags |K| protocol | algorithm | + | |S| | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + / public key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + KEY RR Format + + + + The bit 15th bit (TBD) in the flags field is assigned to be the key + signing flag. If set the key is intended to be used as key signing + key. If the bit is not set, no special meaning should be assigned. + The 15th bit is currently reserved [3]. + +3. DNSSEC Protocol Changes + + The use of the KS flag does not change the DNS resolution and + resolution protocol. The KS flag is only used to provide a hint + about the different administrative properties and MUST NOT be used + during the resolving process. + + + +Kolkman & Schlyter Expires March 2, 2003 [Page 3] + +Internet-Draft KEY RR Key Signing (KS) Flag September 2002 + + +4. Operational Guidelines + + By setting the KS flag on a particular key, zone administrators + indicate that that key should be used as the secure entry point for + their zone. Therefore zone administrators SHOULD set the bit only + for zone keys that are used to sign the KEY RRset and are intended to + act as the first link in the chain of trust for their zone. + + Parent zone administrators and resolver administrators that want to + configure a keysigning key as their 'trusted key' MAY choose to + ignore the flag. + + Using the flag a key rollover can be automated. The parent can use + an existing trust relation to verify keysets in which a new key with + the KS flag appears. + + If the bit is modified during the lifetime of the key then this would + have impact on the keytag and on the hash data in the DS RRs + intending to point to this key. The bit SHOULD NOT be modified once + the key has been put into use. + +5. Security Considerations + + The flag MUST NOT be used in the resolution protocol or to determine + the security status of a key. The flag is to be used for + administrative purposes only. + + No trust in a key should be inferred from this flag - trust must be + inferred from an existing chain of trust or an out-of-band exchange. + + Since this flag MAY be used for automating key exchanges, we think + the following consideration is in place. + + Automated mechanisms for rollover of the DS RR may be vulnerable to a + class of replay attacks. This may happen after a key exchange where + a keyset, containing two keys with the KS flag set, is sent to the + parent. The parent verifies the keyset with the existing trust + relation and creates the new DS RR from the key that the current DS + is not pointing to. This key exchange may be replayed, if the parent + does not maintain state of which DS RRs where used previously so that + the new DS RR is replaced by the old DS RR again. These kinds of + attacks can be prevented by maintaining a registry of keys that have + been used to generate DS RRs from previously. + +6. Document Changes + + + + + + +Kolkman & Schlyter Expires March 2, 2003 [Page 4] + +Internet-Draft KEY RR Key Signing (KS) Flag September 2002 + + +6.1 draft version 00 -> 01 + + Clean up of references and correction of typos; + + modified Abstract text a little; + + Added explicit warning for replay attacks to the security section; + + Removed the text that hinted on a distinction between a keysigning + key configured in resolvers and in parent zones. + + +7. Acknowledgments + + The ideas documented in this draft are inspired by communications we + had with numerous people and ideas published by other folk, Olafur + Gudmundsson, Daniel Karrenberg, Dan Massey and Sam Weiler have been + helping with providing ideas and feedback. + + This document saw the light during a workshop on DNSSEC operations + hosted by USC/ISI. + +References + + [1] Gudmundsson, "Delegation Signer Resource Record", work in + progress draft-ietf-dnsext-delegation-signer-08.txt, June 2002. + + [2] Orwell, "Animal Farm; a Fairy Story"", 1945, . + + [3] Massey and Rose, "Limiting the Scope of the KEY Resource + Record", work in progress draft-ietf-dnsext-restrict-key-for- + dnssec-03, June 28 2002. + + [4] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + + + + + + + + + + + + + + +Kolkman & Schlyter Expires March 2, 2003 [Page 5] + +Internet-Draft KEY RR Key Signing (KS) Flag September 2002 + + +Authors' Addresses + + Olaf M. Kolkman + RIPE NCC + Singel 256 + Amsterdam 1016 AB + NL + + Phone: +31 20 535 4444 + EMail: olaf@ripe.net + URI: http://www.ripe.net/ + + + Jakob Schlyter + Carlstedt Research & Technology + Stora Badhusgatan 18-20 + Goteborg SE-411 21 + Sweden + + EMail: jakob@crt.se + URI: http://www.crt.se/~jakob/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman & Schlyter Expires March 2, 2003 [Page 6] + +Internet-Draft KEY RR Key Signing (KS) Flag September 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kolkman & Schlyter Expires March 2, 2003 [Page 7] + diff --git a/doc/draft/draft-ietf-idn-punycode-02.txt b/doc/draft/draft-ietf-idn-punycode-03.txt similarity index 98% rename from doc/draft/draft-ietf-idn-punycode-02.txt rename to doc/draft/draft-ietf-idn-punycode-03.txt index dc63027a4d..9240e60cf7 100644 --- a/doc/draft/draft-ietf-idn-punycode-02.txt +++ b/doc/draft/draft-ietf-idn-punycode-03.txt @@ -1,8 +1,8 @@ INTERNET-DRAFT Adam M. Costello -draft-ietf-idn-punycode-02.txt 2002-May-23 -Expires 2002-Nov-23 +draft-ietf-idn-punycode-03.txt 2002-Oct-08 +Expires 2003-Apr-08 - Punycode: An encoding of Unicode for use with IDNA + Punycode: A Bootstring encoding of Unicode for IDNA Status of this Memo @@ -81,6 +81,12 @@ Contents constraints. For the details of the prefix and constraints, see [IDNA] and [NAMEPREP]. + Punycode is an instance of a more general algorithm called + Bootstring, which allows strings composed from a small set of + "basic" code points to uniquely represent any string of code points + drawn from a larger set. Punycode is Bootstring with particular + parameter values appropriate for IDNA. + 1.1 Features Bootstring has been designed to have the following features: @@ -92,7 +98,7 @@ Contents * Uniqueness: There is at most one basic string that represents a given extended string. - + * Reversibility: Any extended string mapped to a basic string can be recovered from that basic string. @@ -100,7 +106,7 @@ Contents extended string length is small. This is important in the context of domain names because RFC 1034 [RFC1034] restricts the length of a domain label to 63 characters. - + * Simplicity: The encoding and decoding algorithms are reasonably simple to implement. The goals of efficiency and simplicity are at odds; Bootstring aims at a good balance between them. @@ -145,7 +151,7 @@ Contents An overflow is an attempt to compute a value that exceeds the maximum value of an integer variable. - + 3. Bootstring description Bootstring represents an arbitrary sequence of code points (the @@ -154,7 +160,7 @@ Contents "Bootstring algorithms" presents the algorithms as pseudocode. Sections 7.1 "Decoding traces" and 7.2 "Encoding traces" trace the algorithms for sample inputs. - + The following sections describe the four techniques used in Bootstring. "Basic code point segregation" is a very simple and efficient encoding for basic code points occurring in the @@ -541,7 +547,7 @@ Contents code points less than initial_n are basic code points (which is true for Punycode if code points are unsigned). - The brace-enclosed conditions "non-basic" and "or m is basic" can be + The brace-enclosed conditions "non-basic" and "or c is basic" can be omitted if initial_n exceeds all basic code points (which is true for Punycode), because the code point being tested is never less than initial_n. @@ -965,13 +971,13 @@ C. Disclaimer and license D. Punycode sample implementation /* -punycode.c from draft-ietf-idn-punycode-02 +punycode.c from draft-ietf-idn-punycode-03 http://www.nicemice.net/idn/ Adam M. Costello http://www.nicemice.net/amc/ This is ANSI C code (C89) implementing -Punycode (draft-ietf-idn-punycode-02). +Punycode (draft-ietf-idn-punycode-03). */ @@ -1486,4 +1492,4 @@ int main(int argc, char **argv) - INTERNET-DRAFT expires 2002-Nov-23 + INTERNET-DRAFT expires 2003-Apr-08