This commit was manufactured by cvs2git to create tag 'v9_7_0b3'.

doc/draft/draft-baba-dnsext-acl-reqts-01.txt

@@ -0,0 +1,336 @@
+
+
+
+
+Internet-Draft                                                   T. Baba
+Expires: March 11, 2004                                         NTT Data
+                                                      September 11, 2003
+
+
+         Requirements for Access Control in Domain Name Systems
+                   draft-baba-dnsext-acl-reqts-01.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to 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/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+   Distribution of this memo is unlimited.
+
+   This Internet-Draft will expire on March 11, 2004.
+
+Abstract
+
+   This document describes the requirements for access control
+   mechanisms in the Domain Name System (DNS), which authenticate
+   clients and then allow or deny access to resource records in the
+   zone according to the access control list (ACL).
+
+1. Introduction
+
+   The Domain Name System (DNS) is a hierarchical, distributed, highly
+   available database used for bi-directional mapping between domain
+   names and IP addresses, for email routing, and for other information
+   [RFC1034, 1035].  DNS security extensions (DNSSEC) have been defined
+   to authenticate the data in DNS and provide key distribution services
+   using SIG, KEY, and NXT resource records (RRs) [RFC2535].
+
+
+
+Baba                     Expires March 11, 2004                 [Page 1]
+
+Internet-Draft       DNS Access Control Requirements      September 2003
+
+
+   At the 28th IETF Meeting in Houston in 1993, DNS security design team
+   started a discussion about DNSSEC and agreed to accept the assumption
+   that "DNS data is public".  Accordingly, confidentiality for queries
+   or responses is not provided by DNSSEC, nor are any sort of access
+   control lists or other means to differentiate inquirers.  However,
+   about ten years has passed, access control in DNS has been more
+   important than before.  Currently, new RRs are proposed to add new
+   functionality to DNS such as ENUM [RFC2916].  Such new RRs may
+   contain private information.  Thus, DNS access control will be
+   needed.
+
+   Furthermore, with DNS access control mechanism, access from
+   unauthorized clients can be blocked when they perform DNS name
+   resolution.  Thus, for example, Denial of Service (DoS) attacks
+   against a server used by a closed user group can be prevented using
+   this mechanism if IP address of the server is not revealed by other
+   sources.
+
+   This document describes the requirements for access control
+   mechanisms in DNS.
+
+2. Terminology
+
+   AC-aware client
+      This is the client that understands the DNS access control
+      extensions. This client may be an end host which has a stub
+      resolver, or a cashing/recursive name server which has a
+      full-service resolver.
+
+   AC-aware server
+      This is the authoritative name server that understands the DNS
+      access control extensions.
+
+   ACE
+      An Access Control Entry.  This is the smallest unit of access
+      control policy.  It grants or denies a given set of access
+      rights to a set of principals.  An ACE is a component of an ACL,
+      which is associated with a resource.
+
+   ACL
+      An Access Control List.  This contains all of the access control
+      policies which are directly associated with a particular
+      resource.  These policies are expressed as ACEs.
+
+   Client
+      A program or host which issues DNS requests and accepts its
+      responses. A client may be an end host or a cashing/recursive name
+      server.
+
+
+
+Baba                     Expires March 11, 2004                 [Page 2]
+
+Internet-Draft       DNS Access Control Requirements      September 2003
+
+
+   RRset
+      All resource records (RRs) having the same NAME, CLASS and TYPE
+      are called a Resource Record Set (RRset).
+
+3. Requirements
+
+   This section describes the requirements for access control in DNS.
+
+3.1 Authentication
+
+3.1.1 Client Authentication Mechanism
+
+   The AC-aware server must identify AC-aware clients based on IP
+   address and/or domain name (user ID or host name), and must
+   authenticate them using strong authentication mechanism such as
+   digital signature or message authentication code (MAC).
+
+   SIG(0) RR [RFC2931] contains a domain name associated with sender's
+   public key in its signer's name field, and TSIG RR [RFC2845] also
+   contains a domain name associated with shared secret key in its key
+   name field.  Each of these domain names can be a host name or a user
+   name, and can be used as a sender's identifier for access control.
+   Furthermore, SIG(0) uses digital signatures, and TSIG uses MACs for
+   message authentication.  These mechanisms can be used to authenticate
+   AC-aware clients.
+
+   Server authentication may be also provided.
+
+3.1.2 End-to-End Authentication
+
+   In current DNS model, caching/recursive name servers are deployed
+   between end hosts and authoritative name servers.  Although
+   authoritative servers can authenticate caching/recursive name servers
+   using SIG(0) or TSIG, they cannot authenticate end hosts behind them.
+   For end-to-end authentication, the mechanism for an end host to
+   discover the target authoritative name server and directly access to
+   it bypassing caching/recursive name servers is needed.  For example,
+   an end host can get the IP addresses of the authoritative name
+   servers by retrieving NS RRs for the zone via local caching/recursive
+   name server.
+
+   In many enterprise networks, however, there are firewalls that block
+   all DNS packets other than those going to/from the particular
+   caching/recursive servers.  To deal with this problem, one can
+   implement packet forwarding function on the caching/recursive servers
+   and enable end-to-end authentication via the caching/recursive
+   servers.
+
+
+
+
+Baba                     Expires March 11, 2004                 [Page 3]
+
+Internet-Draft       DNS Access Control Requirements      September 2003
+
+
+3.1.3 Authentication Key Retrieval
+
+   Keys which are used to authenticate clients should be able to be
+   automatically retrieved.  The KEY RR is used to store a public key
+   for a zone or a host that is associated with a domain name.  SIG(0)
+   RR uses a public key in KEY RR for verifying the signature.  If
+   DNSSEC is available, the KEY RR would be protected by the SIG RR.
+   KEY RR or newly defined RR can be used to automatic key retrieval.
+
+3.2 Confidentiality
+
+3.2.1 Data Encryption
+
+   To avoid disclosure to eavesdroppers, the response containing the
+   RRsets which are restricted to access from particular users should be
+   encrypted.  Currently, no encryption mechanism is specified in DNS.
+   Therefore, new RRs should be defined for DNS message encryption.
+   Instead, IPsec [RFC2401] can be used to provide confidentiality if
+   name server and resolver can set up security associations dynamically
+   using IPsec API [IPSECAPI] when encryption is required.
+
+   In case encryption is applied, entire DNS message including DNS
+   header should be encrypted to hide information including error code.
+
+   Query encryption may be also provided for hiding query information.
+
+3.2.2 Key Exchange
+
+   If DNS message encryption is provided, automatic key exchange
+   mechanism should be also provided.  [RFC2930] specifies a TKEY RR
+   that can be used to establish and delete shared secret keys used by
+   TSIG between a client and a server.  With minor extensions, TKEY can
+   be used to establish shared secret keys used for message encryption.
+
+3.2.3 Caching
+
+   The RRset that is restricted to access from particular users must not
+   be cached.  To avoid caching, the TTL of the RR that is restricted to
+   access should be set to zero during transit.
+
+3.3 Access Control
+
+3.3.1 Granularity of Access Control
+
+   Control of access on a per-user/per-host granularity must be
+   supported.  Control of access to individual RRset (not just the
+   entire zone) must be also supported.  However, SOA, NS, SIG, NXT,
+   KEY, and DS RRs must be publicly accessible to avoid unexpected
+   results.
+   
+
+Baba                     Expires March 11, 2004                 [Page 4]
+
+Internet-Draft       DNS Access Control Requirements      September 2003
+
+
+3.3.2 ACL Representation
+
+   Access Control List (ACL) format must be standardized so that both
+   the primary and secondary AC-aware servers can recognize the same
+   ACL.  Although ACL may appear in or out of zone data, it must be
+   transferred to the secondary AC-aware server with associated zone
+   data.  It is a good idea to contain ACL in zone data, because ACL can
+   be transferred with zone data using existing zone transfer mechanisms
+   automatically.  However, ACL must not be published except for
+   authorized secondary master servers.
+   
+   In zone data master files, ACL should be specified using TXT RRs or
+   newly defined RRs.  In each access control entry (ACE), authorized
+   entities (host or user) must be described using domain name (host
+   name, user name, or IP address in in-addr.arpa/ip6.arpa format).
+   There may be other access control attributes such as access time.
+
+   It must be possible to create publicly readable entries, which may be
+   read even by unauthenticated clients.
+
+3.3.3 Zone/ACL Transfer
+
+   As mentioned above, ACL should be transferred from a primary AC-aware
+   server to a secondary AC-aware server with associated zone data.
+   When an AC-aware server receives a zone/ACL transfer request, the
+   server must authenticate the client, and should encrypt the zone
+   data and associated ACL during transfer.
+
+3.4 Backward/co-existence Compatibility
+
+   Any new protocols to be defined for access control in DNS must be
+   backward compatible with existing DNS protocol.  AC-aware servers
+   must be able to process normal DNS query without authentication, and
+   must respond if retrieving RRset is publicly accessible.
+   
+   Modifications to root/gTLD/ccTLD name servers are not allowed.
+
+4. Security Considerations
+
+   This document discusses the requirements for access control
+   mechanisms in DNS.
+
+5. Acknowledgements
+
+   This work is funded by the Telecommunications Advancement
+   Organization of Japan (TAO).
+
+   The author would like to thank the members of the NTT DATA network
+   security team for their important contribution to this work.
+
+
+Baba                     Expires March 11, 2004                 [Page 5]
+
+Internet-Draft       DNS Access Control Requirements      September 2003
+
+
+6. References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
+              Internet Protocol", RFC 2401, November 1998.
+
+   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+              "Secret Key Transaction Authentication for DNS (TSIG)", 
+              RFC 2845, May 2000.
+
+   [RFC2916]  Faltstrom, P., "E.164 number and DNS", RFC 2916,
+              September 2000.
+
+   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
+              RFC 2930, September 2000.
+
+   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures
+              (SIG(0)s)", RFC 2931, September 2000.
+
+   [IPSECAPI] Sommerfeld, W., "Requirements for an IPsec API",
+              draft-ietf-ipsp-ipsec-apireq-00.txt, June 2003, Work in
+              Progress.
+
+
+Author's Address
+
+   Tatsuya Baba
+   NTT Data Corporation
+   Research and Development Headquarters
+   Kayabacho Tower, 1-21-2, Shinkawa, Chuo-ku,
+   Tokyo 104-0033, Japan
+   
+   Tel: +81 3 3523 8081
+   Fax: +81 3 3523 8090
+   Email: babatt@nttdata.co.jp
+
+
+
+
+
+
+
+
+Baba                     Expires March 11, 2004                 [Page 6]

doc/draft/draft-dnsext-opcode-discover-02.txt

@@ -0,0 +1,241 @@
+
+IETF DNSEXT WG                                             Bill Manning
+draft-dnsext-opcode-discover-02.txt                              ep.net
+                                                             Paul Vixie
+                                                                    ISC
+                                                            13 Oct 2003
+
+
+                         The DISCOVER opcode
+
+This document is an Internet-Draft and is subject to all provisions of
+Section 10 of RFC2026.
+
+Comments may be submitted to the group mailing list at "mdns@zocalo.net"
+or the authors.
+
+Distribution of this memo is unlimited.
+
+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 capitalized keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+document are to be interpreted as described in RFC 2119
+
+0. Abstract:
+
+   The QUERY opcode in the DNS is designed for unicast. With the
+   development of multicast capabilities in the DNS, it is desireable
+   to have a more robust opcode for server interactions since a single
+   request may generate replies from multiple responders. So DISCOVER
+   is defined to deal with replies from multiple responders.
+
+   As such, this document extends the core DNS specifications to allow
+   clients to have a method for coping with replies from multiple
+   responders. Use of this new opcode may facilitate DNS operations in
+   modern networking topologies. A prototype of the DISCOVER opcode
+   was developed during the TBDS project (1999-2000), funded under DARPA
+   grant F30602-99-1-0523.
+
+1. Introduction:
+
+   This document describes an experimental extension to the DNS to receive
+   multiple responses which is the likely result when using DNS that has
+   enabled multicast queries.  This approach was developed as part of the
+   TBDS research project, funded under DARPA grant F30602-99-1-0523.  The
+   full processing rules used by TBDS are documented here for possible
+   incorporation in a future revision of the DNS specification."
+
+2. Method:
+
+        DISCOVER works like QUERY except:
+
+        1. it can be sent to a broadcast or multicast destination. QUERY
+           isn't defined for non-unicast, and arguably shouldn't be.
+
+        2. the Question section, if present, has <QNAME=zonename,QTYPE=SOA>
+           tuples. TBDS tried to augment this structure as follows:
+           <QNAME=service,QTYPE=SRV>. While this worked for our purposes in
+           TBDS, it is cleaner to place the SRV question in a separate pass.
+
+        3. if QDCOUNT equals 0 then only servers willing to do recursion should
+           answer. Other servers must silently discard the DISCOVER request.
+
+        4. if QDCOUNT is not equal to 0 then only servers who are authoritative
+           for the zones named by some QNAME should answer.
+
+        5. responses may echo the request's Question section or leave it blank,
+           just like QUERY.
+
+        6. responses have standard Answer, Authority, and Additional sections.
+           e.g. the response is the same as that to a QUERY. It is desireable
+           that zero content answers not be sent to avoid badly formed or
+           unfulfilled requests. Responses should be sent to the unicast
+           address of the requester and the source address should reflect
+           the unicast address of the responder.
+
+   Example usage for gethostby{name,addr}-style requestors:
+
+        Compute the zone name of the enclosing in-addr.arpa, ip6.int, or
+        ip6.arpa domain.
+
+        DISCOVER whether anyone in-scope is authoritative for this zone.
+
+                If so, query these authoritative servers for local
+                in-addr/ip6 names.
+
+        If not, DISCOVER whether there are recursive servers available.
+
+                If so, query these recursive servers for local
+                in-addr/ip6 names.
+
+        So, a node will issue a multicast request with the DISCOVER opcode at
+        some particular multicast scope.  Then determine, from the replies,
+        whether there are any DNS servers which are authoritative (or support
+        recursion) for the zone. Replies to DISCOVER requests MUST set the
+        Recursion Available (RA) flag in the DNS message header.
+
+        It is important to recognize that a requester must be prepared to
+        receive multiple replies from multiple responders. We expect that
+        there will be a single response per responder.
+
+        Once one learns a host's FQDN by the above means, repeat the process
+        for discovering the closest enclosing authoritative server of such
+        local name.
+
+        Cache all NS and A data learned in this process, respecting TTL's.
+
+   TBDS usage for SRV requestors:
+
+        Do the gethostbyaddr() and gethostbyname() on one's own link-local
+        address, using the above process.
+
+        Assume that the closest enclosing zone for which an authority server
+        answers an in-scope DISCOVER packet is "this host's parent domain".
+
+        Compute the SRV name as _service._transport.*.parentdomain.
+
+        This is a change to the definition as defined in RFC 1034.
+        A wildcard label ("*") in the QNAME used in a DNS message with
+        opcode DISCOVER SHOULD be evaluated with special rules.  The
+        wildcard matches any label for which the DNS server data is
+        authoritative.  For example 'x.*.example.com.' would match
+        'x.y.example.com.' and 'x.yy.example.com.' provided that the
+        server was authoritative for 'example.com.'  In this particular
+        case, we suggest the follwing considerations be made:
+
+   getservbyname() can be satisfied by issuing a request with
+   this computed SRV name.  This structure can be
+   populated by values returned from a request as follows:
+
+        s_name    The name of the service, "_service" without the
+                  preceding underscore.
+        s_aliases The names returned in the SRV RRs in replies
+                  to the query.
+        s_port    The port number in the SRV RRs replies to the
+                  query.  If these port numbers disagree - one
+                  of the port numbers is chosen, and only those
+                  names which correspond are returned.
+        s_proto   The transport protocol from named by the
+                  "_transport" label, without the preceding
+                  underscore.
+
+        Send SRV query for this name to discovered local authoritative servers.
+
+     Usage for disconnected networks with no authoritative servers:
+
+        Hosts should run a "stub server" which acts as though its FQDN is a
+        zone name.  Computed SOA gives the host's FQDN as MNAME, "." as the
+        ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE
+        and the other timers.  Compute NS as the host's FQDN.  Compute the
+        glue as the host's link-local address. Or Hosts may run a
+        "DNS stub server" which acts as though its FQDN is a zone name.  The
+        rules governing the behavior of this stub server are given elsewhere
+        [1] [2].
+
+        Such stub servers should answer DISCOVER packets for its zone, and
+        will be found by the iterative "discover closest enclosing authority
+        server" by DISCOVER clients, either in the gethostbyname() or SRV
+        cases described above.  Note that stub servers only answer with
+        zone names which exactly match QNAME's, not with zone names which
+        are owned by QNAME's.
+
+   The main deviation from the DNS[3][4] model is that a host (like, say, a
+   printer offering LPD services) has a DNS server which answers authoritatively
+   for something which hasn't been delegated to it.  However, the only way that
+   such DNS servers can be discovered is with a new opcode, DISCOVER, which
+   is explicitly defined to discover undelegated zones for tightly scoped
+   purposes.  Therefore this isn't officially a violation of DNS's coherency
+   principles. In some cases a responder to DISCOVER may not be traditional
+   DNS software, it could be special purpose software.
+
+3. IANA Considerations
+
+        As a new opcode, the IANA will need to assign a numeric value
+        for the memnonic. The last OPCODE assigned was "5", for UPDATE.
+        Test implementations have used OPCODE "6".
+
+4. Security Considerations
+
+        No new security considerations are known to be introduced with any new
+        opcode, however using multicast for service discovery has the potential
+        for denial of service, primarly from flooding attacks. It may also be
+        possible to enable deliberate misconfiguration of clients simply by
+        running a malicious DNS resolver that claims to be authoritative for
+        things that it is not. One possible way to mitigate this effect is by
+        use of credentials, such as CERT resource records within an RR set.
+        The TBDS project took this approach.
+
+5. Attribution:
+
+        This material was generated in discussions on the mdns mailing list
+hosted by Zocalo in March 2000. Updated by discussion in September/October
+2003.  David Lawrence, Scott Rose, Stuart Cheshire, Bill Woodcock,
+Erik Guttman, Bill Manning and Paul Vixie were active contributors.
+
+6. Author's Address
+
+   Bill Manning
+   PO 12317
+   Marina del Rey, CA. 90295
+   +1.310.322.8102
+   bmanning@karoshi.com
+
+   Paul Vixie
+   Internet Software Consortium
+   950 Charter Street
+   Redwood City, CA 94063
+   +1 650 779 7001
+   <vixie@isc.org>
+
+7. References
+
+Informational References:
+
+[1]  Esibov, L., Aboba, B., Thaler, D., "Multicast DNS",
+        draft-ietf-dnsext-mdns-00.txt, November 2000. Expired
+
+[2] Woodcock, B., Manning, B., "Multicast Domain Name Service",
+        draft-manning-dnsext-mdns-00.txt,  August 2000.  Expired.
+
+Normative References:
+[3]  Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
+        RFC 1034, November 1987.
+[4]  Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
+        RFC 1035, November 1987
+
+        ----------------------------EOL-----------------------
+

doc/draft/draft-dolmatov-dnsext-dnssec-gost-00.txt

@@ -0,0 +1,370 @@
+DNS Extensions working group                               V.Dolmatov, Ed.  
+Internet-Draft                                             Cryptocom Ltd.    
+Intended status: Standards Track                           April 8, 2009
+Expires: December 31, 2009                                 
+
+
+ Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records
+                               for DNSSEC
+                 draft-dolmatov-dnsext-dnssec-gost-00
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on 31 December 2009.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   This document describes how to produce GOST signature and hash algorithms
+   DNSKEY and RRSIG resource records for use in the Domain Name System
+   Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035).
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 
+   2.  DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 
+     2.1.  Using a public key with existing cryptographic libraries. .
+     2.2.  GOST DNSKEY RR Example  . . . . . . . . . . . . . . . . . .
+   3.  RRSIG Resource Records  . . . . . . . . . . . . . . . . . . . . 
+   4.  DS Resource Records . . . . . . . . . . . . . . . . . . . . . .
+   5.  NSEC3 Resource Records  . . . . . . . . . . . . . . . . . . . .
+   6.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 
+     6.1.  Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 
+     6.2.  Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 
+     6.3.  Digest Sizes  . . . . . . . . . . . . . . . . . . . . . . .
+   7.  Implementation Considerations . . . . . . . . . . . . . . . . . 
+     7.1.  Support for GOST signatures . . . . . . . . . . . . . . . . 
+     7.2.  Support for NSEC3 Denial of Existence . . . . . . . . . . . 
+       7.2.1.  NSEC3 in Authoritative servers  . . . . . . . . . . . . 
+       7.2.2.  NSEC3 in Validators . . . . . . . . . . . . . . . . . . 
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 
+   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 
+   10.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 
+     10.1.  Normative References  . . . . . . . . . . . . . . . . . . . 
+     10.2.  Informative References  . . . . . . . . . . . . . . . . . . 
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 
+
+
+1.  Introduction
+
+   The Domain Name System (DNS) is the global hierarchical distributed
+   database for Internet Naming.  The DNS has been extended to use
+   cryptographic keys and digital signatures for the verification of the
+   authenticity and integrity of its data.  RFC 4033 [RFC4033], RFC 4034
+   [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security
+   Extensions, called DNSSEC.
+
+   RFC 4034 describes how to store DNSKEY and RRSIG resource records,
+   and specifies a list of cryptographic algorithms to use.  This
+   document extends that list with the signature and hash algorithms 
+   GOST [GOST3410, GOST3411],
+   and specifies how to store DNSKEY data and how to produce
+   RRSIG resource records with these hash algorithms.
+
+   Familiarity with DNSSEC  and GOST signature and hash
+   algorithms is assumed in this document.
+
+   The term "GOST" is not officially defined, but is usually used to
+   refer to the collection of the Russian cryptographic algorithms
+   GOST R 34.10-2001, GOST R 34.11-94, GOST 28147-89. Since GOST 28147-89
+   is not used in DNSSEC, GOST will only refer to GOST R 34.10-2001 
+   (signatire algorithm) and GOST R 34.11-94 (hash algorithm) in this
+   document.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+2.  DNSKEY Resource Records
+
+   The format of the DNSKEY RR can be found in RFC 4034 [RFC4034].
+
+   GOST R 34.10-2001 public keys are stored with the algorithm number {TBA1}.
+   
+   The public key parameters are those identified by
+   id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357].
+   The digest parameters for signature are those identified by
+   id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].
+   
+   The wire format of the public key is compatible with RFC 4491 [RFC4491]:
+
+   According to [GOSTR341001], a public key is a point on the elliptic
+   curve Q = (x,y).
+
+   The wire representation of a public key MUST contain 64 octets, where the
+   first 32 octets contain the little-endian representation of x and the
+   second 32 octets contain the little-endian representation of y.  This
+   corresponds to the binary representation of (<y>256||<x>256) from
+   [GOSTR341001], ch.  5.3.
+
+2.1.  Using a public key with existing cryptographic libraries
+
+   Existing GOST-aware cryptographic libraries at time of this document
+   writing are capable to read GOST public keys via generic X509 API if the
+   key is encoded according to RFC 4491 [RFC4491], section 2.3.2.
+
+   To make this encoding from the wire format of a GOST public key, prepend
+   a key data with the following 37-byte sequence:
+
+   0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30 0x12
+   0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a 0x85 0x03
+   0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40
+  
+2.2.  GOST DNSKEY RR Example
+
+   The following DNSKEY RR stores a DNS zone key for example.com
+
+   example.com. 86400 IN DNSKEY 256 3 {TBA1} ( RamuUwTG1r4RUqsgXu/xF6B+Y
+                                               tJLzZEykiZ4C2Fa1gV1pI/8GA
+                                               el2Wm69Cz5h1T9eYAQKFAGwzW
+                                               m4Lke0E26aw== )
+
+3.  RRSIG Resource Records
+
+   The value of the signature field in the RRSIG RR follows the RFC 4490
+   [RFC4490] and is calculated as follows.  The values for the RDATA fields
+   that precede the signature data are specified in RFC 4034 [RFC4034].
+
+   hash = GOSTR3411(data)
+
+   where "data" is the wire format data of the resource record set that is
+   signed, as specified in RFC 4034 [RFC4034].  Hash MUST be calculated with
+   GOST R 34.11-94 parameters identified by
+   id-GostR3411-94-CryptoProParamSet [RFC4357].
+
+   Signature is calculated from the hash according to the GOST R 34.10-2001
+   standard and its wire format is compatible with RFC 4490 [RFC4490].
+   Quoting RFC 4490:
+
+   "The signature algorithm GOST R 34.10-2001 generates a digital
+   signature in the form of two 256-bit numbers, r and s.  Its octet
+   string representation consists of 64 octets, where the first 32
+   octets contain the big-endian representation of s and the second 32
+   octets contain the big-endian representation of r."
+
+4.  DS Resource Records
+
+   GOST R 34.11-94 digest algorithm is denoted in DS RR by the digest type
+   {TBA2}.  The wire format of a digest value is compatible with RFC 4490
+   [RFC4490].  Quoting RFC 4490: 
+   
+   "A 32-byte digest in little-endian representation."
+
+   The digest MUST always be calculated with GOST R 34.11-94 parameters
+   identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
+
+5.  NSEC3 Resource Records
+
+   GOST R 34.11-94 digest algorithm is denoted in NSEC3 RR by the digest type
+   {TBA2}.  The wire format of a digest value is compatible with RFC 4490
+   [RFC4490].  Quoting RFC 4490: 
+   
+   "A 32-byte digest in little-endian representation."
+
+   The digest MUST always be calculated with GOST R 34.11-94 parameters
+   identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
+
+6.  Deployment Considerations
+
+6.1.  Key Sizes
+
+   According to RFC4357 [RFC4357] key size of GOST public keys MUST 
+   be 512 bits.
+
+6.2.  Signature Sizes
+
+   According to GOST signature algorithm [GOST3410] size of GOST signature 
+   is 512 bit.
+
+6.3.  Digest Sizes
+
+   According to GOST R 34.11-94 [GOST3411] size of GOST digest is 256 bit.
+
+7.  Implementation Considerations
+
+7.1.  Support for GOST signatures
+
+   DNSSEC aware implementations SHOULD be able to support RRSIG and
+   DNSKEY resource records created with the GOST algorithms as
+   defined in this document.
+
+7.2.  Support for NSEC3 Denial of Existence
+
+   RFC5155 [RFC5155] defines new algorithm identifiers for existing
+   signing algorithms, to indicate that zones signed with these
+   algorithm identifiers use NSEC3 instead of NSEC records to provide
+   denial of existence.  That mechanism was chosen to protect
+   implementations predating RFC5155 from encountering resource records
+   they could not know about.  This document does not define such
+   algorithm aliases, and support for NSEC3 denial of existence is
+   implicitly signaled with support for one of the algorithms defined in
+   this document.
+
+7.2.1.  NSEC3 in Authoritative servers
+
+   An authoritative server that does not implement NSEC3 MAY still serve
+   zones that use GOST with NSEC denial of existence.
+
+7.2.2.  NSEC3 in Validators
+
+   A DNSSEC validator that implements GOST MUST be able to handle
+   both NSEC and NSEC3 [RFC5155] negative answers.  If this is not the
+   case, the validator MUST treat a zone signed with GOST
+   as signed with an unknown algorithm, and thus as insecure.
+
+
+8.  IANA Considerations
+
+   This document updates the IANA registry "DNS SECURITY ALGORITHM
+   NUMBERS -- per [RFC4035] "
+   (http://www.iana.org/assignments/dns-sec-alg-numbers).  The following
+   entries are added to the registry:
+                                        Zone     Trans.
+   Value   Algorithm          Mnemonic  Signing  Sec.   References   Status
+   {TBA1}  GOST R 34.10-2001  GOST      Y        *      (this memo)  OPTIONAL
+
+   This document updates the RFC 4034 [RFC4034] Digest Types assignment
+   (RFC 4034, section A.2):
+
+   Value   Algorithm        Status
+   {TBA2}  GOST R 34.11-94  OPTIONAL
+
+9. Acknowledgments
+
+   This document is a minor extension to RFC 4034 [RFC4034].  Also, we
+   try to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509]
+   and RFC 4357 [RFC4357] for consistency. The authors of and 
+   contributors to these documents are gratefully acknowledged for 
+   their hard work.
+
+   The following people provided additional feedback and text: Dmitry 
+   Burkov, Jaap Akkerhuis, Jelte Jansen and Wouter Wijngaards.
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", RFC 2119, March 1997.
+
+   [RFC3110]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
+              Name System (DNS)", RFC 3110, May 2001.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, March 2005.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+   [GOST3410] "Information technology.  Cryptographic data security.
+              Signature and verification processes of [electronic]
+              digital signature.", GOST R 34.10-2001, Gosudarstvennyi
+              Standard of Russian Federation, Government Committee of
+              the Russia for Standards, 2001.  (In Russian)
+
+   [GOST3411] "Information technology.  Cryptographic Data Security.
+              Hashing function.", GOST R 34.11-94, Gosudarstvennyi
+              Standard of Russian Federation, Government Committee of
+              the Russia for Standards, 1994.  (In Russian)
+
+   [RFC4357] Popov, V., Kurepkin, I., and S. Leontiev, "Additional
+             Cryptographic Algorithms for Use with GOST 28147-89,
+             GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
+             Algorithms", RFC 4357, January 2006.
+
+   [RFC4490] S. Leontiev and G. Chudov, "Using the GOST 28147-89, 
+	     GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 
+             Algorithms with Cryptographic Message Syntax (CMS)",
+             RFC 4490, May 2006.
+
+   [RFC4491] S. Leontiev and D. Shefanovski, "Using the GOST 
+             R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 
+             Algorithms with the Internet X.509 Public Key 
+             Infrastructure Certificate and CRL Profile", RFC 4491,
+             May 2006. 
+
+
+
+10.2.  Informative References
+
+   [NIST800-57]
+              Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
+              "Recommendations for Key Management", NIST SP 800-57,
+              March 2007.
+
+   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+              Standards (PKCS) #1: RSA Cryptography Specifications
+              Version 2.1", RFC 3447, February 2003.
+
+   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
+              (DS) Resource Records (RRs)", RFC 4509, May 2006.
+
+   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+              Security (DNSSEC) Hashed Authenticated Denial of
+              Existence", RFC 5155, March 2008.
+
+Authors' Addresses
+
+
+Vasily Dolmatov, Ed.
+Cryptocom Ltd.
+Bolotnikovskaya, 23
+Moscow, 117303, Russian Federation
+
+EMail: dol@cryptocom.ru
+
+Artem Chuprina
+Cryptocom Ltd.
+Bolotnikovskaya, 23
+Moscow, 117303, Russian Federation
+
+EMail: ran@cryptocom.ru
+
+Igor Ustinov
+Cryptocom Ltd.
+Bolotnikovskaya, 23
+Moscow, 117303, Russian Federation
+
+EMail: igus@cryptocom.ru
+
+                  Expires December 31, 2009                [Page ]
+
+

doc/draft/draft-durand-dnsop-dynreverse-00.txt

@@ -0,0 +1,240 @@
+Internet Engineering Task Force                             Alain Durand
+INTERNET-DRAFT                                          SUN Microsystems
+Feb 21, 2003
+Expires Aug 2, 2003
+
+
+
+                Dynamic reverse DNS for IPv6
+              <draft-durand-dnsop-dynreverse-00.txt>
+
+
+
+Status of this memo
+
+
+   This memo provides information to the Internet community.  It does
+   not specify an Internet standard of any kind.  This memo is in full
+   conformance with all provisions of Section 10 of RFC2026 [RFC2026].
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+
+Abstract
+
+   This document describes a method to dynamically generate PTR records
+   and corresponding A or AAAA records when the reverse path DNS tree is
+   not populated.
+
+   A special domain dynrev.arpa. is reserved for that purpose.
+
+
+1. Introduction
+
+   In IPv4, the reverse path tree of the DNS under in-addr.arpa.
+   although not perfectly maintained, is still mostly usable and its
+   existence is important for a number of applications that relies on
+   its existence and decent status.  Some applications performs some
+   (very) weak security checks based on it. Mail relays relies on it for
+   some anti-spams checks an some FTP server will not let you in unless
+   your IP address resolve properly with a PTR record.
+
+   IPv6 addresses being much longer (and cumbersome) than IPv4
+   addresses, it is to fear that the reverse path tree under ip6.arpa.
+   would not be as well maintained.  Also, tools like 6to4, Isatap and
+   others have made creative use of the 128 bits of an IPv6 address to
+   automatically embed an IPv4 address to enable seamless connection to
+   the IPv6 Internet. However, no provision has been made to make sure
+   the reverse path tree gets automatically updated as well for those
+   new IPv6 addresses.  One step furter, RFC3041 describes a mechanism
+   to basically use random bits in the bottom part of an IPv6 address to
+   preserver anonymity. If those addresses are to resolve in the reverse
+   path tree, it obviously has to be with anonymous data as well.
+   Another point to note is that home customer ISPs in IPv4 have a
+   current practice to pre-populate the reverse path tree with names
+   automatically derived from the IP addresses. This practice is no
+   longer possible in IPv6, where IP address allocation is not dense as
+   it is the case in IPv4. The mere size of typical customer allocation
+   (2^48 according to the recommendation of RFC3177) makes it
+   impossible.
+
+   Applications that check the existence of PTR records usually follow
+   this by checking if the name pointed by the PTR resolve in a A (or
+   AAAA for IPv6) that match the original IP address. Thus the forward
+   path tree must also include the corresponding data.
+
+   One simple approach of this problem is to simply declare the usage of
+   the reverse path DNS as described above obsolete.  The author believe
+   this is too strong an approach for now.
+
+   Similarly, a completely different approach would be to deprecate the
+   usage of DNS for the reverse tree altogether and replace it by
+   something inspired from ICMP name-info messages. The author believes
+   that this approached is an important departure from the current
+   practise and thus not very realistic.  Also, there are some concerns
+   about the the security implications of this method as any node could
+   easily impersonate any name. This approach would fundamentally change
+   the underlying assumption of "I trust what has been put in the DNS by
+   the local administrators" to "I trust what has been configured on
+   each machine I query directly".
+
+
+
+2. Dynamic record generation
+
+   If static pre-population of the tree is not possible anymore and data
+   still need to be returned to applications using getnameinfo(), the
+   alternative is dynamic record generation.  This can be done is two
+   places: in the DNS servers responsible for the allocated space (/64
+   or /48) in the ip6.arpa. domain.  or in the DNS resolvers (either the
+   sub resolver library or the recursive DNS server).
+
+   2.1. On the resolver side.
+
+   The resolver, either in the recursive DNS server or in the stub
+   library could theoretically generate this data.
+
+   In case DNSsec is in place, the recursive DNS server would have to
+   pretend these records are authentic.
+
+   If the synthesis is done in the stub-resolver library, no record
+   needs to be actually generated, only the right information needs to
+   be passed to getnameinfo() and getaddrinfo().  If the synthesis is
+   done in the recursive DNS server, no modification is required to
+   existing stub resolvers.
+
+
+2.2. On the server side.
+
+   PTR records could be generated automatically by the server
+   responsible for the reverse path tree of an IPv6 prefix (a /64 or /48
+   prefixes or basically anything in between) when static data is not
+   available.
+
+   There could be impact on DNSsec as the zone or some parts of the zone
+   may need to be resigned each time a DNS query is made for an
+   unpopulated address. This can be seen as a DOS attack on a DNSsec
+   zone, so server side synthesis is not recommended if DNSsec is
+   deployed.
+
+
+
+3. Synthesis
+
+   The algorithm is simple: Do the normal queries. If the query returns
+   No such domain, replace this answer by the synthetized one if
+   possible.
+
+3.1. PTR synthesis
+
+   The synthetized PTR for a DNS string [X] is simply [X].dynrev.arpa.
+   where [X] is any valid DNS name.
+
+   The fact that the synthetized PTR points to the dynrev.arpa. domain
+   is an indication to the applications that this record has been
+   dynamically generated.
+
+
+3.2. A synthesis
+
+   If [X] is in the form a.b.c.d.in-addr.arpa, one can synthetized an A
+   record for the string [X].dynrev.arpa. which value is d.c.b.a. with
+   a,b,c & d being integer [0..255]
+
+
+3.3. AAAA synthesis
+
+   If [X] is in the form
+   a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.s.t.u.v.w.x.y.z.A.B.C.D.E.F.in-
+   addr.arpa, one can synthetized a AAAA record for the string
+   [X].dynrev.arpa. which value is
+   FEDC:BAzy:xwvu:tsrq:ponm:lkji:hgfe:dcba with
+   a,b,c....x,y,z,A,B,C,D,E,F being hexadecimal digits.
+
+
+3.4. Server side synthesis
+
+   If synthesis is done on the server side, PTR could be set not to use
+   the dynrev.arpa domain but the local domain name instead.  It culd be
+   for instance dynrev.mydomain.com.
+
+   Note also that server side synthesis is not incompatible with
+   resolver side synthesis.
+
+
+
+4. IANA considerations
+
+   The dynrev.arpa. domain is reserved for the purpose of this document.
+
+
+
+5. Security considerations
+
+   Section 2. discusses the the interactions with DNSsec.
+
+
+
+6. Authors addresses
+
+   Alain Durand
+   SUN Microsystems, Inc
+   17, Network Circle
+   UMPK17-202
+   Menlo Park, CA 94025
+   USA
+   Mail: Alain.Durand@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

doc/draft/draft-ietf-dnsext-2929bis-01.txt

@@ -0,0 +1,928 @@
+
+INTERNET-DRAFT                                    Donald E. Eastlake 3rd
+Obsoletes RFC 2929, Updates RFC 1183               Motorola Laboratories
+Expires: February 2006                                       August 2005
+
+
+
+              Domain Name System (DNS) IANA Considerations
+              ------ ---- ------ ----- ---- --------------
+                   <draft-ietf-dnsext-2929bis-01.txt>
+
+
+
+Status of This Document
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Distribution of this draft is unlimited.  It is intended to become
+   the new BCP 42 obsoleting RFC 2929.  Comments should be sent to the
+   DNS Working Group mailing list <namedroppers@ops.ietf.org>.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than a "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+
+
+Abstract
+
+   Internet Assigned Number Authority (IANA) parameter assignment
+   considerations are given for the allocation of Domain Name System
+   (DNS) classes, RR types, operation codes, error codes, RR header
+   bits, and AFSDB subtypes.
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 1]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+Table of Contents
+
+      Status of This Document....................................1
+      Abstract...................................................1
+
+      Table of Contents..........................................2
+
+      1. Introduction............................................3
+      2. DNS Query/Response Headers..............................3
+      2.1 One Spare Bit?.........................................4
+      2.2 Opcode Assignment......................................4
+      2.3 RCODE Assignment.......................................5
+      3. DNS Resource Records....................................6
+      3.1 RR TYPE IANA Considerations............................7
+      3.1.1 DNS TYPE Allocation Policy...........................8
+      3.1.2 Special Note on the OPT RR...........................9
+      3.1.3 The AFSDB RR Subtype Field...........................9
+      3.2 RR CLASS IANA Considerations...........................9
+      3.3 RR NAME Considerations................................11
+      4. Security Considerations................................11
+
+      Appendix: Changes from RFC 2929...........................12
+
+      Copyright and Disclaimer..................................13
+      Normative References......................................13
+      Informative References....................................14
+
+      Authors Addresses.........................................16
+      Expiration and File Name..................................16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 2]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+1. Introduction
+
+   The Domain Name System (DNS) provides replicated distributed secure
+   hierarchical databases which hierarchically store "resource records"
+   (RRs) under domain names.  DNS data is structured into CLASSes and
+   zones which can be independently maintained.  See [RFC 1034, 1035,
+   2136, 2181, 4033] familiarity with which is assumed.
+
+   This document provides, either directly or by reference, general IANA
+   parameter assignment considerations applying across DNS query and
+   response headers and all RRs.  There may be additional IANA
+   considerations that apply to only a particular RR type or
+   query/response opcode.  See the specific RFC defining that RR type or
+   query/response opcode for such considerations if they have been
+   defined, except for AFSDB RR considerations [RFC 1183] which are
+   included herein. This RFC obsoletes [RFC 2929].
+
+   IANA currently maintains a web page of DNS parameters.  See
+   <http://www.iana.org/numbers.htm>.
+
+   "IETF Standards Action", "IETF Consensus", "Specification Required",
+   and "Private Use" are as defined in [RFC 2434].
+
+
+
+2. DNS Query/Response Headers
+
+   The header for DNS queries and responses contains field/bits in the
+   following diagram taken from [RFC 2136, 2929]:
+
+                                              1  1  1  1  1  1
+                0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                      ID                       |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                QDCOUNT/ZOCOUNT                |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                ANCOUNT/PRCOUNT                |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                NSCOUNT/UPCOUNT                |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+               |                    ARCOUNT                    |
+               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   The ID field identifies the query and is echoed in the response so
+   they can be matched.
+
+   The QR bit indicates whether the header is for a query or a response.
+
+
+D. Eastlake 3rd                                                 [Page 3]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+   The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
+   only in queries or only in responses, depending on the bit.  However,
+   many DNS implementations copy the query header as the initial value
+   of the response header without clearing bits.  Thus any attempt to
+   use a "query" bit with a different meaning in a response or to define
+   a query meaning for a "response" bit is dangerous given existing
+   implementation.  Such meanings may only be assigned by an IETF
+   Standards Action.
+
+   The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
+   authority count (NSCOUNT), and additional information count (ARCOUNT)
+   express the number of records in each section for all opcodes except
+   Update.  These fields have the same structure and data type for
+   Update but are instead the counts for the zone (ZOCOUNT),
+   prerequisite (PRCOUNT), update (UPCOUNT), and additional information
+   (ARCOUNT) sections.
+
+
+
+2.1 One Spare Bit?
+
+   There have been ancient DNS implementations for which the Z bit being
+   on in a query meant that only a response from the primary server for
+   a zone is acceptable.  It is believed that current DNS
+   implementations ignore this bit.
+
+   Assigning a meaning to the Z bit requires an IETF Standards Action.
+
+
+
+2.2 Opcode Assignment
+
+   Currently DNS OpCodes are assigned as follows:
+
+          OpCode Name                      Reference
+
+           0     Query                     [RFC 1035]
+           1     IQuery  (Inverse Query, Obsolete) [RFC 3425]
+           2     Status                    [RFC 1035]
+           3     available for assignment
+           4     Notify                    [RFC 1996]
+           5     Update                    [RFC 2136]
+          6-15   available for assignment
+
+   New OpCode assignments require an IETF Standards Action as modified
+   by [RFC 4020].
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 4]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+2.3 RCODE Assignment
+
+   It would appear from the DNS header above that only four bits of
+   RCODE, or response/error code are available.  However, RCODEs can
+   appear not only at the top level of a DNS response but also inside
+   OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
+   The OPT RR provides an eight bit extension resulting in a 12 bit
+   RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
+
+   Error codes appearing in the DNS header and in these three RR types
+   all refer to the same error code space with the single exception of
+   error code 16 which has a different meaning in the OPT RR from its
+   meaning in other contexts.  See table below.
+
+        RCODE   Name    Description                        Reference
+        Decimal
+          Hexadecimal
+         0    NoError   No Error                           [RFC 1035]
+         1    FormErr   Format Error                       [RFC 1035]
+         2    ServFail  Server Failure                     [RFC 1035]
+         3    NXDomain  Non-Existent Domain                [RFC 1035]
+         4    NotImp    Not Implemented                    [RFC 1035]
+         5    Refused   Query Refused                      [RFC 1035]
+         6    YXDomain  Name Exists when it should not     [RFC 2136]
+         7    YXRRSet   RR Set Exists when it should not   [RFC 2136]
+         8    NXRRSet   RR Set that should exist does not  [RFC 2136]
+         9    NotAuth   Server Not Authoritative for zone  [RFC 2136]
+        10    NotZone   Name not contained in zone         [RFC 2136]
+        11 - 15         Available for assignment
+        16    BADVERS   Bad OPT Version                    [RFC 2671]
+        16    BADSIG    TSIG Signature Failure             [RFC 2845]
+        17    BADKEY    Key not recognized                 [RFC 2845]
+        18    BADTIME   Signature out of time window       [RFC 2845]
+        19    BADMODE   Bad TKEY Mode                      [RPC 2930]
+        20    BADNAME   Duplicate key name                 [RPF 2930]
+        21    BADALG    Algorithm not supported            [RPF 2930]
+
+        22 - 3,840
+          0x0016 - 0x0F00   Available for assignment
+
+        3,841 - 4,095
+          0x0F01 - 0x0FFF   Private Use
+
+        4,096 - 65,534
+          0x1000 - 0xFFFE   Available for assignment
+
+        65,535
+          0xFFFF            Reserved, can only be allocated by an IETF
+                            Standards Action.
+
+
+
+D. Eastlake 3rd                                                 [Page 5]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+   Since it is important that RCODEs be understood for interoperability,
+   assignment of new RCODE listed above as "available for assignment"
+   requires an IETF Consensus.
+
+
+
+3. DNS Resource Records
+
+   All RRs have the same top level format shown in the figure below
+   taken from [RFC 1035]:
+
+                                       1  1  1  1  1  1
+         0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+       |                                               |
+       /                                               /
+       /                      NAME                     /
+       |                                               |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+       |                      TYPE                     |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+       |                     CLASS                     |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+       |                      TTL                      |
+       |                                               |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+       |                   RDLENGTH                    |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
+       /                     RDATA                     /
+       /                                               /
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   NAME is an owner name, i.e., the name of the node to which this
+   resource record pertains.  NAMEs are specific to a CLASS as described
+   in section 3.2.  NAMEs consist of an ordered sequence of one or more
+   labels each of which has a label type [RFC 1035, 2671].
+
+   TYPE is a two octet unsigned integer containing one of the RR TYPE
+   codes.  See section 3.1.
+
+   CLASS is a two octet unsigned integer containing one of the RR CLASS
+   codes.  See section 3.2.
+
+   TTL is a four octet (32 bit) bit unsigned integer that specifies the
+   number of seconds that the resource record may be cached before the
+   source of the information should again be consulted.  Zero is
+   interpreted to mean that the RR can only be used for the transaction
+   in progress.
+
+   RDLENGTH is an unsigned 16 bit integer that specifies the length in
+
+
+D. Eastlake 3rd                                                 [Page 6]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+   octets of the RDATA field.
+
+   RDATA is a variable length string of octets that constitutes the
+   resource. The format of this information varies according to the TYPE
+   and in some cases the CLASS of the resource record.
+
+
+
+3.1 RR TYPE IANA Considerations
+
+   There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
+   and MetaTYPEs.
+
+   Data TYPEs are the primary means of storing data.  QTYPES can only be
+   used in queries.  Meta-TYPEs designate transient data associated with
+   an particular DNS message and in some cases can also be used in
+   queries.  Thus far, data TYPEs have been assigned from 1 upwards plus
+   the block from 100 through 103 while Q and Meta Types have been
+   assigned from 255 downwards except for the OPT Meta-RR which is
+   assigned TYPE 41.  There have been DNS implementations which made
+   caching decisions based on the top bit of the bottom byte of the RR
+   TYPE.
+
+   There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
+   [RFC 2845], and TKEY [RFC 2930].
+
+   There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
+   AXFR, and IXFR.
+
+   Considerations for the allocation of new RR TYPEs are as follows:
+
+     Decimal
+   Hexadecimal
+
+     0
+   0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
+          2535] and in other circumstances and must never be allocated
+          for ordinary use.
+
+     1 - 127
+   0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
+          TYPEs by the DNS TYPE Allocation Policy as specified in
+          section 3.1.1.
+
+     128 - 255
+   0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
+          Meta TYPEs by the DNS TYPE Allocation Policy as specified in
+          section 3.1.1.
+
+
+
+
+D. Eastlake 3rd                                                 [Page 7]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+     256 - 32,767
+   0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS
+          TYPE Allocation Policy as specified in section 3.1.1.
+
+     32,768 - 65,279
+   0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
+
+     65,280 - 65534
+   0xFF00 - 0xFFFE - Private Use.
+
+     65,535
+   0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
+
+
+
+3.1.1 DNS TYPE Allocation Policy
+
+   Parameter values specified above as assigned based on DNS TYPE
+   Allocation Policy. That is, Expert Review with the additional
+   requirement that the review be based on a complete template as
+   specified below which has been posted for three weeks to the
+   namedroppers@ops.ietf.org mailing list.
+
+   Partial or draft templates may be posted with the intend of
+   soliciting feedback.
+
+
+                 DNS RR TYPE PARAMETER ALLOCATION TEMPLATE
+
+        Date:
+
+        Name and email of originator:
+
+        Pointer to internet-draft or other document giving a detailed
+        description of the protocol use of the new RR Type:
+
+        What need is the new RR TYPE intended to fix?
+
+        What existing RR TYPE(s) come closest to filling that need and why are
+        they unsatisfactory?
+
+        Does the proposed RR TYPR require special handling within the DNS
+        different from an Unknown RR TYPE?
+
+        Comments:
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 8]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+3.1.2 Special Note on the OPT RR
+
+   The OPT (OPTion) RR, number 41, is specified in [RFC 2671].  Its
+   primary purpose is to extend the effective field size of various DNS
+   fields including RCODE, label type, OpCode, flag bits, and RDATA
+   size.  In particular, for resolvers and servers that recognize it, it
+   extends the RCODE field from 4 to 12 bits.
+
+
+
+3.1.3 The AFSDB RR Subtype Field
+
+   The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same
+   RDATA field structure as the MX RR but the 16 bit unsigned integer
+   field at the beginning of the RDATA is interpreted as a subtype as
+   follows:
+
+     Decimal
+   Hexadecimal
+
+     0
+   0x0000 -  Allocation requires IETF Standards Action.
+
+     1
+   0x0001 - Andrews File Service v3.0 Location Service [RFC 1183].
+
+     2
+   0x0002 - DCE/NCA root cell directory node [RFC 1183].
+
+     3 - 65,279
+   0x0003 - 0xFEFF - Allocation by IETF Consensus.
+
+     65,280 - 65,534
+   0xFF00 - 0xFFFE - Private Use.
+
+     65,535
+   0xFFFF - Reserved, allocation requires IETF Standards Action.
+
+
+
+3.2 RR CLASS IANA Considerations
+
+   DNS CLASSes have been little used but constitute another dimension of
+   the DNS distributed database.  In particular, there is no necessary
+   relationship between the name space or root servers for one CLASS and
+   those for another CLASS.  The same name can have completely different
+   meanings in different CLASSes; however, the label types are the same
+   and the null label is usable only as root in every CLASS.  However,
+   as global networking and DNS have evolved, the IN, or Internet, CLASS
+   has dominated DNS use.
+
+
+D. Eastlake 3rd                                                 [Page 9]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+   There are two subcategories of DNS CLASSes: normal data containing
+   classes and QCLASSes that are only meaningful in queries or updates.
+
+   The current CLASS assignments and considerations for future
+   assignments are as follows:
+
+     Decimal
+   Hexadecimal
+
+     0
+   0x0000 - Reserved, assignment requires an IETF Standards Action.
+
+     1
+   0x0001 - Internet (IN).
+
+     2
+   0x0002 - Available for assignment by IETF Consensus as a data CLASS.
+
+     3
+   0x0003 - Chaos (CH) [Moon 1981].
+
+     4
+   0x0004 - Hesiod (HS) [Dyer 1987].
+
+     5 - 127
+   0x0005 - 0x007F - available for assignment by IETF Consensus for data
+          CLASSes only.
+
+     128 - 253
+   0x0080 - 0x00FD - available for assignment by IETF Consensus for
+          QCLASSes only.
+
+     254
+   0x00FE - QCLASS None [RFC 2136].
+
+     255
+   0x00FF - QCLASS Any [RFC 1035].
+
+     256 - 32,767
+   0x0100 - 0x7FFF - Assigned by IETF Consensus.
+
+     32,768 - 65,279
+   0x8000 - 0xFEFF - Assigned based on Specification Required as defined
+          in [RFC 2434].
+
+     65,280 - 65,534
+   0xFF00 - 0xFFFE - Private Use.
+
+     65,535
+   0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
+
+
+D. Eastlake 3rd                                                [Page 10]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+3.3 RR NAME Considerations
+
+   DNS NAMEs are sequences of labels [RFC 1035].  The last label in each
+   NAME is "ROOT" which is the zero length label.  By definition, the
+   null or ROOT label can not be used for any other NAME purpose.
+
+   At the present time, there are two categories of label types, data
+   labels and compression labels.  Compression labels are pointers to
+   data labels elsewhere within an RR or DNS message and are intended to
+   shorten the wire encoding of NAMEs.  The two existing data label
+   types are sometimes referred to as Text and Binary.  Text labels can,
+   in fact, include any octet value including zero value octets but most
+   current uses involve only [US-ASCII].  For retrieval, Text labels are
+   defined to treat ASCII upper and lower case letter codes as matching
+   [insensitive].  Binary labels are bit sequences [RFC 2673]. The
+   Binary label type is Experimental [RFC 3363].
+
+   IANA considerations for label types are given in [RFC 2671].
+
+   NAMEs are local to a CLASS.  The Hesiod [Dyer 1987] and Chaos [Moon
+   1981] CLASSes are essentially for local use.  The IN or Internet
+   CLASS is thus the only DNS CLASS in global use on the Internet at
+   this time.
+
+   A somewhat out-of-date description of name allocation in the IN Class
+   is given in [RFC 1591].  Some information on reserved top level
+   domain names is in BCP 32 [RFC 2606].
+
+
+
+4. Security Considerations
+
+   This document addresses IANA considerations in the allocation of
+   general DNS parameters, not security.  See [RFC 4033, 4034, 4035] for
+   secure DNS considerations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                [Page 11]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+Appendix: Changes from RFC 2929
+
+   RFC Editor: This Appendix should be deleted for publication.
+
+   Changes from RFC 2929 to this draft:
+
+   1. Changed many "IETF Consensus" for RR TYPEs to be "DNS TYPE
+   Allocation Policy" and add the specification of that policy. Change
+   some remaining "IETF Standards Action" allocation requirements to say
+   "as modified by [RFC 4020]".
+
+   2. Updated various RFC references.
+
+   3. Mentioned that the Binary label type is now Experimental and
+   IQuery is Obsolete.
+
+   4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be
+   IETF Standards Action required.
+
+   5. Add an IANA allocation policy for the AFSDB RR Subtype field.
+
+   6. Addition of reference to case insensitive draft.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                [Page 12]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+Copyright and Disclaimer
+
+   Copyright (C) The Internet Society (2005).  This document is subject to
+   the rights, licenses and restrictions contained in BCP 78, and except
+   as set forth therein, the authors retain all their rights.
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+Normative References
+
+   [RFC 1034] - Mockapetris, P., "Domain Names - Concepts and
+   Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC 1035] - Mockapetris, P., "Domain Names - Implementation and
+   Specifications", STD 13, RFC 1035, November 1987.
+
+   [RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P.
+   Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.
+
+   [RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone
+   Changes (DNS NOTIFY)", RFC 1996, August 1996.
+
+   [RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
+   "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+   April 1997.
+
+   [RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS
+   Specification", RFC 2181, July 1997.
+
+   [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
+   IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+   [RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
+   2671, August 1999.
+
+   [RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System",
+   RFC 2673, August 1999.
+
+   [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B.
+   Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
+   RFC 2845, May 2000.
+
+
+D. Eastlake 3rd                                                [Page 13]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+   [RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY
+   RR)", September 2000.
+
+   [RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
+   Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
+   the Domain Name System (DNS)", RFC 3363, August 2002.
+
+   [RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
+   2002.
+
+   [RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of
+   Standards Track Code Points", BCP 100, RFC 4020, February 2005.
+
+   [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "DNS Security Introduction and Requirements", RFC 4033, March
+   2005.
+
+   [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
+   March 2005.
+
+   [RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "Protocol Modifications for the DNS Security Extensions", RFC
+   4035, March 2005.
+
+   [US-ASCII] - ANSI, "USA Standard Code for Information Interchange",
+   X3.4, American National Standards Institute: New York, 1968.
+
+
+
+Informative References
+
+   [Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena
+   Technical Plan - Name Service, April 1987,
+
+   [Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
+   Institute of Technology Artificial Intelligence Laboratory, June
+   1981.
+
+   [RFC 1591] - Postel, J., "Domain Name System Structure and
+   Delegation", RFC 1591, March 1994.
+
+   [RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
+   "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
+   September 2000.
+
+   [RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS
+   Names", RFC 2606, June 1999.
+
+   [insensitive] - Eastlake, D., "Domain Name System (DNS) Case
+
+
+D. Eastlake 3rd                                                [Page 14]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+   Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt,
+   work in progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                [Page 15]
+
+
+INTERNET-DRAFT           DNS IANA Considerations             August 2005
+
+
+Authors Addresses
+
+   Donald E. Eastlake 3rd
+   Motorola Laboratories
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Telephone:   +1-508-786-7554 (w)
+   email:       Donald.Eastlake@motorola.com
+
+
+
+Expiration and File Name
+
+   This draft expires February 2006.
+
+   Its file name is draft-ietf-dnsext-2929bis-01.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                [Page 16]
+

doc/draft/draft-ietf-dnsext-dnsproxy-05.txt

@@ -0,0 +1,728 @@
+
+
+
+DNSEXT                                                         R. Bellis
+Internet-Draft                                                Nominet UK
+Intended status: BCP                                      April 23, 2009
+Expires: October 25, 2009
+
+
+                  DNS Proxy Implementation Guidelines
+                     draft-ietf-dnsext-dnsproxy-05
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on October 25, 2009.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   This document provides guidelines for the implementation of DNS
+   proxies, as found in broadband gateways and other similar network
+   devices.
+
+
+
+Bellis                  Expires October 25, 2009                [Page 1]
+
+Internet-Draft     DNS Proxy Implementation Guidelines        April 2009
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+
+   3.  The Transparency Principle . . . . . . . . . . . . . . . . . .  3
+
+   4.  Protocol Conformance . . . . . . . . . . . . . . . . . . . . .  4
+     4.1.  Unexpected Flags and Data  . . . . . . . . . . . . . . . .  4
+     4.2.  Label Compression  . . . . . . . . . . . . . . . . . . . .  4
+     4.3.  Unknown Resource Record Types  . . . . . . . . . . . . . .  5
+     4.4.  Packet Size Limits . . . . . . . . . . . . . . . . . . . .  5
+       4.4.1.  TCP Transport  . . . . . . . . . . . . . . . . . . . .  6
+       4.4.2.  Extension Mechanisms for DNS (EDNS0) . . . . . . . . .  6
+       4.4.3.  IP Fragmentation . . . . . . . . . . . . . . . . . . .  6
+     4.5.  Secret Key Transaction Authentication for DNS (TSIG) . . .  7
+
+   5.  DHCP's Interaction with DNS  . . . . . . . . . . . . . . . . .  7
+     5.1.  Domain Name Server (DHCP Option 6) . . . . . . . . . . . .  8
+     5.2.  Domain Name (DHCP Option 15) . . . . . . . . . . . . . . .  8
+     5.3.  DHCP Leases  . . . . . . . . . . . . . . . . . . . . . . .  8
+
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+     6.1.  Forgery Resilience . . . . . . . . . . . . . . . . . . . .  9
+     6.2.  Interface Binding  . . . . . . . . . . . . . . . . . . . . 10
+     6.3.  Packet Filtering . . . . . . . . . . . . . . . . . . . . . 10
+
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
+
+   8.  Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
+
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
+
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis                  Expires October 25, 2009                [Page 2]
+
+Internet-Draft     DNS Proxy Implementation Guidelines        April 2009
+
+
+1.  Introduction
+
+   Research has found ([SAC035], [DOTSE]) that many commonly-used
+   broadband gateways (and similar devices) contain DNS proxies which
+   are incompatible in various ways with current DNS standards.
+
+   These proxies are usually simple DNS forwarders, but typically do not
+   have any caching capabilities.  The proxy serves as a convenient
+   default DNS resolver for clients on the LAN, but relies on an
+   upstream resolver (e.g. at an ISP) to perform recursive DNS lookups.
+
+   Note that to ensure full DNS protocol interoperability it is
+   preferred that client stub resolvers should communicate directly with
+   full-feature upstream recursive resolvers wherever possible.
+
+   That notwithstanding, this document describes the incompatibilities
+   that have been discovered and offers guidelines to implementors on
+   how to provide better interoperability in those cases where the
+   client must use the broadband gateway's DNS proxy.
+
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+3.  The Transparency Principle
+
+   It is not considered practical for a simple DNS proxy to implement
+   all current and future DNS features.
+
+   There are several reasons why this is the case:
+
+   o  broadband gateways usually have limited hardware resources
+   o  firmware upgrade cycles are long, and many users do not routinely
+      apply upgrades when they become available
+   o  no-one knows what those future DNS features will be, nor how they
+      might be implemented
+   o  it would substantially complicate the configuration UI of the
+      device
+
+   Furthermore some modern DNS protocol extensions (see e.g.  EDNS0,
+   below) are intended to be used as "hop-by-hop" mechanisms.  If the
+   DNS proxy is considered to be such a "hop" in the resolution chain,
+   then for it to function correctly, it would need to be fully
+   compliant with all such mechanisms.
+
+
+
+Bellis                  Expires October 25, 2009                [Page 3]
+
+Internet-Draft     DNS Proxy Implementation Guidelines        April 2009
+
+
+   [SAC035] shows that the more actively a proxy participates in the DNS
+   protocol then the more likely it is that it will somehow interfere
+   with the flow of messages between the DNS client and the upstream
+   recursive resolvers.
+
+   The role of the proxy should therefore be no more and no less than to
+   receive DNS requests from clients on the LAN side, forward those
+   verbatim to one of the known upstream recursive resolvers on the WAN
+   side, and ensure that the whole response is returned verbatim to the
+   original client.
+
+   It is RECOMMENDED that proxies should be as transparent as possible,
+   such that any "hop-by-hop" mechanisms or newly introduced protocol
+   extensions operate as if the proxy were not there.
+
+   Except when required to enforce an active security or network policy
+   (such as maintaining a pre-authentication "walled garden"), end-users
+   SHOULD be able to send their DNS queries to specified upstream
+   resolvers, thereby bypassing the proxy altogether.  In this case, the
+   gateway SHOULD NOT modify the DNS request or response packets in any
+   way.
+
+
+4.  Protocol Conformance
+
+4.1.  Unexpected Flags and Data
+
+   The Transparency Principle above, when combined with Postel's
+   Robustness Principle [RFC0793], suggests that DNS proxies should not
+   arbitrarily reject or otherwise drop requests or responses based on
+   perceived non-compliance with standards.
+
+   For example, some proxies have been observed to drop any packet
+   containing either the "Authentic Data" (AD) or "Checking Disabled"
+   (CD) bits from DNSSEC [RFC4035].  This may be because [RFC1035]
+   originally specified that these unused "Z" flag bits "MUST" be zero.
+   However these flag bits were always intended to be reserved for
+   future use, so refusing to proxy any packet containing these flags
+   (now that uses for those flags have indeed been defined) is not
+   appropriate.
+
+   Therefore it is RECOMMENDED that proxies SHOULD ignore any unknown
+   DNS flags and proxy those packets as usual.
+
+4.2.  Label Compression
+
+   Compression of labels as per Section 4.1.4 of [RFC1035] is optional.
+
+
+
+
+Bellis                  Expires October 25, 2009                [Page 4]
+
+Internet-Draft     DNS Proxy Implementation Guidelines        April 2009
+
+
+   Proxies MUST forward packets regardless of the presence or absence of
+   compressed labels therein.
+
+4.3.  Unknown Resource Record Types
+
+   [RFC3597] requires that resolvers MUST handle Resource Records (RRs)
+   of unknown type transparently.
+
+   All requests and responses MUST be proxied regardless of the values
+   of the QTYPE and QCLASS fields.
+
+   Similarly all responses MUST be proxied regardless of the values of
+   the TYPE and CLASS fields of any Resource Record therein.
+
+4.4.  Packet Size Limits
+
+   [RFC1035] specifies that the maximum size of the DNS payload in a UDP
+   packet is 512 octets.  Where the required portions of a response
+   would not fit inside that limit the DNS server MUST set the
+   "TrunCation" (TC) bit in the DNS response header to indicate that
+   truncation has occurred.  There are however two standard mechanisms
+   (described in Section 4.4.1 and Section 4.4.2) for transporting
+   responses larger than 512 octets.
+
+   Many proxies have been observed to truncate all responses at 512
+   octets, and others at a packet size related to the WAN MTU, in either
+   case doing so without correctly setting the TC bit.
+
+   Other proxies have been observed to remove the TC bit in server
+   responses which correctly had the TC bit set by the server.
+
+   If a DNS response is truncated but the TC bit is not set then client
+   failures may result.  In particular a naive DNS client library might
+   suffer crashes due to reading beyond the end of the data actually
+   received.
+
+   Since UDP packets larger than 512 octets are now expected in normal
+   operation, proxies SHOULD NOT truncate UDP packets that exceed that
+   size.  See Section 4.4.3 for recommendations for packet sizes
+   exceeding the WAN MTU.
+
+   If a proxy must unilaterally truncate a response then the proxy MUST
+   set the TC bit.  Similarly, proxies MUST NOT remove the TC bit from
+   responses.
+
+
+
+
+
+
+
+Bellis                  Expires October 25, 2009                [Page 5]
+
+Internet-Draft     DNS Proxy Implementation Guidelines        April 2009
+
+
+4.4.1.  TCP Transport
+
+   Should a UDP query fail because of truncation, the standard fail-over
+   mechanism is to retry the query using TCP, as described in section
+   6.1.3.2 of [RFC1123].
+
+   DNS proxies SHOULD therefore be prepared to receive and forward
+   queries over TCP.
+
+   Note that it is unlikely that a client would send a request over TCP
+   unless it had already received a truncated UDP response.  Some
+   "smart" proxies have been observed to first forward any request
+   received over TCP to an upstream resolver over UDP, only for the
+   response to be truncated, causing the proxy to retry over TCP.  Such
+   behaviour increases network traffic and causes delay in DNS
+   resolution since the initial UDP request is doomed to fail.
+
+   Therefore whenever a proxy receives a request over TCP, the proxy
+   SHOULD forward the query over TCP and SHOULD NOT attempt the same
+   query over UDP first.
+
+4.4.2.  Extension Mechanisms for DNS (EDNS0)
+
+   The Extension Mechanism for DNS [RFC2671] was introduced to allow the
+   transport of larger DNS packets over UDP and also to allow for
+   additional request and response flags.
+
+   A client may send an OPT Resource Record (OPT RR) in the Additional
+   Section of a request to indicate that it supports a specific receive
+   buffer size.  The OPT RR also includes the "DNSSEC OK" (DO) flag used
+   by DNSSEC to indicate that DNSSEC-related RRs should be returned to
+   the client.
+
+   However some proxies have been observed to either reject (with a
+   FORMERR response code) or black-hole any packet containing an OPT RR.
+   As per Section 4.1 proxies SHOULD NOT refuse to proxy such packets.
+
+4.4.3.  IP Fragmentation
+
+   Support for UDP packet sizes exceeding the WAN MTU depends on the
+   gateway's algorithm for handling fragmented IP packets.  Several
+   methods are possible:
+
+   1.  fragments are dropped
+   2.  fragments are forwarded individually as they're received
+   3.  complete packets are reassembled on the gateway, and then re-
+       fragmented (if necessary) as they're forwarded to the client
+
+
+
+
+Bellis                  Expires October 25, 2009                [Page 6]
+
+Internet-Draft     DNS Proxy Implementation Guidelines        April 2009
+
+
+   Method 1 above will cause compatibility problems with EDNS0 unless
+   the DNS client is configured to advertise an EDNS0 buffer size
+   limited to the WAN MTU less the size of the IP header.  Note that RFC
+   2671 does recommend that the path MTU should be taken into account
+   when using EDNS0.
+
+   Also, whilst the EDNS0 specification allows for a buffer size of up
+   to 65535 octets, most common DNS server implementations do not
+   support a buffer size above 4096 octets.
+
+   Therefore (irrespective of which of the methods above is in use)
+   proxies SHOULD be capable of forwarding UDP packets up to a payload
+   size of at least 4096 octets.
+
+   NB: in theory IP fragmentation may also occur if the LAN MTU is
+   smaller than the WAN MTU, although the author has not observed such a
+   configuration in use on any residential broadband service.
+
+4.5.  Secret Key Transaction Authentication for DNS (TSIG)
+
+   [RFC2845] defines TSIG, which is a mechanism for authenticating DNS
+   requests and responses at the packet level.
+
+   Any modifications made to the DNS portions of a TSIG-signed query or
+   response packet (with the exception of the Query ID) will cause a
+   TSIG authentication failure.
+
+   DNS proxies MUST implement Section 4.7 of [RFC2845] and either
+   forward packets unchanged (as recommended above) or fully implement
+   TSIG.
+
+   As per Section 4.3, DNS proxies MUST be capable of proxying packets
+   containing TKEY [RFC2930] Resource Records.
+
+   NB: any DNS proxy (such as those commonly found in WiFi hotspot
+   "walled gardens") which transparently intercepts all DNS queries, and
+   which returns unsigned responses to signed queries, will also cause
+   TSIG authentication failures.
+
+
+5.  DHCP's Interaction with DNS
+
+   Whilst this document is primarily about DNS proxies, most consumers
+   rely on DHCP [RFC2131] to obtain network configuration settings.
+   Such settings include the client machine's IP address, subnet mask
+   and default gateway, but also include DNS related settings.
+
+   It is therefore appropriate to examine how DHCP affects client DNS
+
+
+
+Bellis                  Expires October 25, 2009                [Page 7]
+
+Internet-Draft     DNS Proxy Implementation Guidelines        April 2009
+
+
+   configuration.
+
+5.1.  Domain Name Server (DHCP Option 6)
+
+   Most gateways default to supplying their own IP address in the DHCP
+   "Domain Name Server" option [RFC2132].  The net result is that
+   without explicit re-configuration many DNS clients will by default
+   send queries to the gateway's DNS proxy.  This is understandable
+   behaviour given that the correct upstream settings are not usually
+   known at boot time.
+
+   Most gateways learn their own DNS settings via values supplied by an
+   ISP via DHCP or PPP over the WAN interface.  However whilst many
+   gateways do allow the device administrator to override those values,
+   some gateways only use those supplied values to affect the proxy's
+   own forwarding function, and do not offer these values via DHCP.
+
+   When using such a device the only way to avoid using the DNS proxy is
+   to hard-code the required values in the client operating system.
+   This may be acceptable for a desktop system but it is inappropriate
+   for mobile devices which are regularly used on many different
+   networks.
+
+   As per Section 3, end-users SHOULD be able to send their DNS queries
+   directly to specified upstream resolvers, ideally without hard-coding
+   those settings in their stub resolver.
+
+   It is therefore RECOMMENDED that gateways SHOULD support device
+   administrator configuration of values for the "Domain Name Server"
+   DHCP option.
+
+5.2.  Domain Name (DHCP Option 15)
+
+   A significant amount of traffic to the DNS Root Name Servers is for
+   invalid top-level domain names, and some of that traffic can be
+   attributed to particular equipment vendors whose firmware defaults
+   this DHCP option to specific values.
+
+   Since no standard exists for a "local" scoped domain name suffix it
+   is RECOMMENDED that the default value for this option SHOULD be
+   empty, and that this option MUST NOT be sent to clients when no value
+   is configured.
+
+5.3.  DHCP Leases
+
+   It is noted that some DHCP servers in broadband gateways by default
+   offer their own IP address for the "Domain Name Server" option (as
+   described above) but then automatically start offering the upstream
+
+
+
+Bellis                  Expires October 25, 2009                [Page 8]
+
+Internet-Draft     DNS Proxy Implementation Guidelines        April 2009
+
+
+   servers' addresses once they've been learnt over the WAN interface.
+
+   In general this behaviour is highly desirable, but the effect for the
+   end-user is that the settings used depend on whether the DHCP lease
+   was obtained before or after the WAN link was established.
+
+   If the DHCP lease is obtained whilst the WAN link is down then the
+   DHCP client (and hence the DNS client) will not receive the correct
+   values until the DHCP lease is renewed.
+
+   Whilst no specific recommendations are given here, vendors may wish
+   to give consideration to the length of DHCP leases, and whether some
+   mechanism for forcing a DHCP lease renewal might be appropriate.
+
+   Another possibility is that the learnt upstream values might be
+   persisted in non-volatile memory such that on reboot the same values
+   can be automatically offered via DHCP.  However this does run the
+   risk that incorrect values are initially offered if the device is
+   moved or connected to another ISP.
+
+   Alternatively, the DHCP server might only issue very short (i.e. 60
+   second) leases while the WAN link is down, only reverting to more
+   typical lease lengths once the WAN link is up and the upstream DNS
+   servers are known.  Indeed with such a configuration it may be
+   possible to avoid the need to implement a DNS proxy function in the
+   broadband gateway at all.
+
+
+6.  Security Considerations
+
+   This document introduces no new protocols.  However there are some
+   security related recommendations for vendors that are listed here.
+
+6.1.  Forgery Resilience
+
+   Whilst DNS proxies are not usually full-feature resolvers they
+   nevertheless share some characteristics with them.
+
+   Notwithstanding the recommendations above about transparency many DNS
+   proxies are observed to pick a new Query ID for outbound requests to
+   ensure that responses are directed to the correct client.
+
+   NB: Changing the Query ID is acceptable and compatible with proxying
+   TSIG-signed packets since the TSIG signature calculation is based on
+   the original message ID which is carried in the TSIG RR.
+
+   It has been standard guidance for many years that each DNS query
+   should use a randomly generated Query ID.  However many proxies have
+
+
+
+Bellis                  Expires October 25, 2009                [Page 9]
+
+Internet-Draft     DNS Proxy Implementation Guidelines        April 2009
+
+
+   been observed picking sequential Query IDs for successive requests.
+
+   It is strongly RECOMMENDED that DNS proxies follow the relevant
+   recommendations in [RFC5452], particularly those in Section 9.2
+   relating to randomisation of Query IDs and source ports.  This also
+   applies to source port selection within any NAT function.
+
+   If a DNS proxy is running on a broadband gateway with NAT that is
+   compliant with [RFC4787] then it SHOULD also follow the
+   recommendations in Section 10 of [RFC5452] concerning how long DNS
+   state is kept.
+
+6.2.  Interface Binding
+
+   Some gateways have been observed to have their DNS proxy listening on
+   both internal (LAN) and external (WAN) interfaces.  In this
+   configuration it is possible for the proxy to be used to mount
+   reflector attacks as described in [RFC5358].
+
+   The DNS proxy in a gateway SHOULD NOT by default be accessible from
+   the WAN interfaces of the device.
+
+6.3.  Packet Filtering
+
+   The Transparency and Robustness Principles are not entirely
+   compatible with the deep packet inspection features of security
+   appliances such as firewalls which are intended to protect systems on
+   the inside of a network from rogue traffic.
+
+   However a clear distinction may be made between traffic that is
+   intrinsically malformed and that which merely contains unexpected
+   data.
+
+   Examples of malformed packets which MAY be dropped include:
+
+   o  invalid compression pointers (i.e. those that point outside of the
+      current packet, or which might cause a parsing loop).
+   o  incorrect counts for the Question, Answer, Authority and
+      Additional Sections (although care should be taken where
+      truncation is a possibility).
+
+   Since dropped packets will cause the client to repeatedly retransmit
+   the original request, it is RECOMMENDED that proxies SHOULD instead
+   return a suitable DNS error response to the client (i.e.  SERVFAIL)
+   instead of dropping the packet completely.
+
+
+
+
+
+
+Bellis                  Expires October 25, 2009               [Page 10]
+
+Internet-Draft     DNS Proxy Implementation Guidelines        April 2009
+
+
+7.  IANA Considerations
+
+   This document requests no IANA actions.
+
+
+8.  Change Log
+
+   NB: to be removed by the RFC Editor before publication.
+
+   draft-ietf-dnsproxy-05
+      Removed specific reference to 28 byte IP headers (from Mark
+      Andrews)
+
+   draft-ietf-dnsproxy-04 - post WGLC
+      Introduction expanded
+      Section 5.2 - changed SHOULD to MUST
+      Section 4.5 - changed SHOULD to MUST (Alex Bligh)
+      Editorial nits (from Andrew Sullivan, Alfred Hones)
+      Clarificaton on end-user vs device administrator (Alan Barrett,
+      Paul Selkirk)
+
+   draft-ietf-dnsproxy-03
+      Editorial nits and mention of LAN MTU (from Alex Bligh)
+
+   draft-ietf-dnsproxy-02
+      Changed "router" to "gateway" throughout (David Oran)
+      Updated forgery resilience reference
+      Elaboration on bypassability (from Nicholas W.)
+      Elaboration on NAT source port randomisation (from Nicholas W.)
+      Mention of using short DHCP leases while the WAN link is down
+      (from Ralph Droms)
+      Further clarification on permissibility of altering QID when using
+      TSIG
+
+   draft-ietf-dnsproxy-01
+      Strengthened recommendations about truncation (from Shane Kerr)
+      New TSIG text (with help from Olafur)
+      Additional forgery resilience text (from Olafur)
+      Compression support (from Olafur)
+      Correction of text re: QID changes and compatibility with TSIG
+
+   draft-ietf-dnsproxy-00
+      Changed recommended DPI error to SERVFAIL (from Jelte)
+      Changed example for invalid compression pointers (from Wouter).
+      Note about TSIG implications of changing Query ID (from Wouter).
+      Clarified TC-bit text (from Wouter)
+
+
+
+
+
+Bellis                  Expires October 25, 2009               [Page 11]
+
+Internet-Draft     DNS Proxy Implementation Guidelines        April 2009
+
+
+      Extra text about proxy bypass (Nicholas W.)
+
+   draft-bellis-dnsproxy-00
+      Initial draft
+
+
+9.  Acknowledgements
+
+   The author would particularly like to acknowledge the assistance of
+   Lisa Phifer of Core Competence.  In addition the author is grateful
+   for the feedback from the members of the DNSEXT Working Group.
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
+              RFC 793, September 1981.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
+              and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
+              RFC 2131, March 1997.
+
+   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+              Extensions", RFC 2132, March 1997.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
+              RR)", RFC 2930, September 2000.
+
+   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
+              (RR) Types", RFC 3597, September 2003.
+
+
+
+
+Bellis                  Expires October 25, 2009               [Page 12]
+
+Internet-Draft     DNS Proxy Implementation Guidelines        April 2009
+
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
+              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
+              RFC 4787, January 2007.
+
+   [RFC5358]  Damas, J. and F. Neves, "Preventing Use of Recursive
+              Nameservers in Reflector Attacks", BCP 140, RFC 5358,
+              October 2008.
+
+   [RFC5452]  Hubert, A. and R. van Mook, "Measures for Making DNS More
+              Resilient against Forged Answers", RFC 5452, January 2009.
+
+10.2.  Informative References
+
+   [DOTSE]    Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband
+              Routers", February 2008,
+              <http://www.iis.se/docs/Routertester_en.pdf>.
+
+   [SAC035]   Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on
+              Broadband Routers and Firewalls", September 2008,
+              <http://www.icann.org/committees/security/sac035.pdf>.
+
+
+Author's Address
+
+   Ray Bellis
+   Nominet UK
+   Edmund Halley Road
+   Oxford  OX4 4DQ
+   United Kingdom
+
+   Phone: +44 1865 332211
+   Email: ray.bellis@nominet.org.uk
+   URI:   http://www.nominet.org.uk/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis                  Expires October 25, 2009               [Page 13]
+

doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt

@@ -0,0 +1,442 @@
+
+
+INTERNET-DRAFT                                             Samuel Weiler
+Expires: June 2004                                     December 15, 2003
+Updates: RFC 2535, [DS]
+
+	 Legacy Resolver Compatibility for Delegation Signer
+	 draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to 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/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+   Comments should be sent to the author or to the DNSEXT WG mailing
+   list: namedroppers@ops.ietf.org
+
+Abstract
+
+   As the DNS Security (DNSSEC) specifications have evolved, the
+   syntax and semantics of the DNSSEC resource records (RRs) have
+   changed.  Many deployed nameservers understand variants of these
+   semantics.  Dangerous interactions can occur when a resolver that
+   understands an earlier version of these semantics queries an
+   authoritative server that understands the new delegation signer
+   semantics, including at least one failure scenario that will cause
+   an unsecured zone to be unresolvable.  This document changes the
+   type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to
+   avoid those interactions.
+
+Changes between 05 and 06:
+
+   Signifigantly reworked the IANA section -- went back to one
+   algorithm registry.
+
+   Removed Diffie-Hellman from the list of zone-signing algorithms
+   (leaving only DSA, RSA/SHA-1, and private algorithms).
+
+   Added a DNSKEY flags field registry.
+
+Changes between 04 and 05:
+
+   IESG approved publication.
+
+   Cleaned up an internal reference in the acknowledgements section.
+
+   Retained KEY and SIG for TKEY, too.  Added TKEY (2930) reference.
+
+   Changed the names of both new registries.  Added algorithm
+   mnemonics to the new zone signing algorithm registry.  Minor
+   rewording in the IANA section for clarity.
+
+   Cleaned up formatting of references.  Replaced unknown-rr draft
+   references with RFC3597.  Bumped DS version number.
+
+Changes between 03 and 04:
+
+   Clarified that RRSIG(0) may be defined by standards action.
+
+   Created a new algorithm registry and renamed the old algorithm
+   registry for SIG(0) only.  Added references to the appropriate
+   crypto algorithm and format specifications.
+
+   Several minor rephrasings.
+
+Changes between 02 and 03:
+
+   KEY (as well as SIG) retained for SIG(0) use only.
+
+Changes between 01 and 02:
+
+   SIG(0) still uses SIG, not RRSIG.  Added 2931 reference.
+
+   Domain names embedded in NSECs and RRSIGs are not compressible and
+   are not downcased.  Added unknown-rrs reference (as informative).
+
+   Simplified the last paragraph of section 3 (NSEC doesn't always
+   signal a negative answer).
+
+   Changed the suggested type code assignments.
+
+   Added 2119 reference.
+
+   Added definitions of "unsecure delegation" and "unsecure referral",
+   since they're not clearly defined elsewhere.
+
+   Moved 2065 to informative references, not normative.
+
+1. Introduction
+
+   The DNSSEC protocol has been through many iterations whose syntax
+   and semantics are not completely compatible.  This has occurred as
+   part of the ordinary process of proposing a protocol, implementing
+   it, testing it in the increasingly complex and diverse environment
+   of the Internet, and refining the definitions of the initial
+   Proposed Standard.  In the case of DNSSEC, the process has been
+   complicated by DNS's criticality and wide deployment and the need
+   to add security while minimizing daily operational complexity.
+
+   A weak area for previous DNS specifications has been lack of detail
+   in specifying resolver behavior, leaving implementors largely on
+   their own to determine many details of resolver function.  This,
+   combined with the number of iterations the DNSSEC spec has been
+   through, has resulted in fielded code with a wide variety of
+   behaviors.  This variety makes it difficult to predict how a
+   protocol change will be handled by all deployed resolvers.  The
+   risk that a change will cause unacceptable or even catastrophic
+   failures makes it difficult to design and deploy a protocol change.
+   One strategy for managing that risk is to structure protocol
+   changes so that existing resolvers can completely ignore input that
+   might confuse them or trigger undesirable failure modes.
+
+   This document addresses a specific problem caused by Delegation
+   Signer's [DS] introduction of new semantics for the NXT RR that are
+   incompatible with the semantics in RFC 2535 [RFC2535].  Answers
+   provided by DS-aware servers can trigger an unacceptable failure
+   mode in some resolvers that implement RFC 2535, which provides a
+   great disincentive to sign zones with DS.  The changes defined in
+   this document allow for the incremental deployment of DS.
+
+1.1 Terminology
+
+   In this document, the term "unsecure delegation" means any
+   delegation for which no DS record appears at the parent.  An
+   "unsecure referral" is an answer from the parent containing an NS
+   RRset and a proof that no DS record exists for that name.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+1.2 The Problem
+
+   Delegation Signer introduces new semantics for the NXT RR that are
+   incompatible with the semantics in RFC 2535.  In RFC 2535, NXT
+   records were only required to be returned as part of a
+   non-existence proof.  With DS, an unsecure referral returns, in
+   addition to the NS, a proof of non-existence of a DS RR in the form
+   of an NXT and SIG(NXT).  RFC 2535 didn't specify how a resolver was
+   to interpret a response with both an NS and an NXT in the authority
+   section, RCODE=0, and AA=0.  Some widely deployed 2535-aware
+   resolvers interpret any answer with an NXT as a proof of
+   non-existence of the requested record.  This results in unsecure
+   delegations being invisible to 2535-aware resolvers and violates
+   the basic architectural principle that DNSSEC must do no harm --
+   the signing of zones must not prevent the resolution of unsecured
+   delegations.
+
+2. Possible Solutions
+
+   This section presents several solutions that were considered.
+   Section 3 describes the one selected.
+
+2.1. Change SIG, KEY, and NXT type codes
+
+   To avoid the problem described above, legacy (RFC2535-aware)
+   resolvers need to be kept from seeing unsecure referrals that
+   include NXT records in the authority section.  The simplest way to
+   do that is to change the type codes for SIG, KEY, and NXT.
+
+   The obvious drawback to this is that new resolvers will not be able
+   to validate zones signed with the old RRs.  This problem already
+   exists, however, because of the changes made by DS, and resolvers
+   that understand the old RRs (and have compatibility issues with DS)
+   are far more prevalent than 2535-signed zones.
+
+2.2. Change a subset of type codes
+
+   The observed problem with unsecure referrals could be addressed by
+   changing only the NXT type code or another subset of the type codes
+   that includes NXT.  This has the virtue of apparent simplicity, but
+   it risks introducing new problems or not going far enough.  It's
+   quite possible that more incompatibilities exist between DS and
+   earlier semantics.  Legacy resolvers may also be confused by seeing
+   records they recognize (SIG and KEY) while being unable to find
+   NXTs.  Although it may seem unnecessary to fix that which is not
+   obviously broken, it's far cleaner to change all of the type codes
+   at once.  This will leave legacy resolvers and tools completely
+   blinded to DNSSEC -- they will see only unknown RRs.
+
+2.3. Replace the DO bit
+
+   Another way to keep legacy resolvers from ever seeing DNSSEC
+   records with DS semantics is to have authoritative servers only
+   send that data to DS-aware resolvers.  It's been proposed that
+   assigning a new EDNS0 flag bit to signal DS-awareness (tentatively
+   called "DA"), and having authoritative servers send DNSSEC data
+   only in response to queries with the DA bit set, would accomplish
+   this.  This bit would presumably supplant the DO bit described in
+   RFC 3225.
+
+   This solution is sufficient only if all 2535-aware resolvers zero
+   out EDNS0 flags that they don't understand.  If one passed through
+   the DA bit unchanged, it would still see the new semantics, and it
+   would probably fail to see unsecure delegations.  Since it's
+   impractical to know how every DNS implementation handles unknown
+   EDNS0 flags, this is not a universal solution.  It could, though,
+   be considered in addition to changing the RR type codes.
+
+2.4. Increment the EDNS version
+
+   Another possible solution is to increment the EDNS version number
+   as defined in RFC 2671 [RFC2671], on the assumption that all
+   existing implementations will reject higher versions than they
+   support, and retain the DO bit as the signal for DNSSEC awareness.
+   This approach has not been tested.
+
+2.5. Do nothing
+
+   There is a large deployed base of DNS resolvers that understand
+   DNSSEC as defined by the standards track RFC 2535 and RFC 2065
+   and, due to under specification in those documents, interpret any
+   answer with an NXT as a non-existence proof.  So long as that is
+   the case, zone owners will have a strong incentive to not sign any
+   zones that contain unsecure delegations, lest those delegations be
+   invisible to such a large installed base.  This will dramatically
+   slow DNSSEC adoption.
+
+   Unfortunately, without signed zones there's no clear incentive for
+   operators of resolvers to upgrade their software to support the new
+   version of DNSSEC, as defined in [DS].  Historical data suggests
+   that resolvers are rarely upgraded, and that old nameserver code
+   never dies.
+
+   Rather than wait years for resolvers to be upgraded through natural
+   processes before signing zones with unsecure delegations,
+   addressing this problem with a protocol change will immediately
+   remove the disincentive for signing zones and allow widespread
+   deployment of DNSSEC.
+
+3. Protocol changes
+
+   This document changes the type codes of SIG, KEY, and NXT.  This
+   approach is the cleanest and safest of those discussed above,
+   largely because the behavior of resolvers that receive unknown type
+   codes is well understood.  This approach has also received the most
+   testing.
+
+   To avoid operational confusion, it's also necessary to change the
+   mnemonics for these RRs.  DNSKEY will be the replacement for KEY,
+   with the mnemonic indicating that these keys are not for
+   application use, per [RFC3445].  RRSIG (Resource Record SIGnature)
+   will replace SIG, and NSEC (Next SECure) will replace NXT.  These
+   new types completely replace the old types, except that SIG(0)
+   [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY.
+
+   The new types will have exactly the same syntax and semantics as
+   specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for
+   the following:
+
+      1) Consistent with [RFC3597], domain names embedded in
+      RRSIG and NSEC RRs MUST NOT be compressed,
+
+      2) Embedded domain names in RRSIG and NSEC RRs are not downcased
+      for purposes of DNSSEC canonical form and ordering nor for
+      equality comparison, and
+
+      3) An RRSIG with a type-covered field of zero has undefined
+      semantics.  The meaning of such a resource record may only be
+      defined by IETF Standards Action.
+
+   If a resolver receives the old types, it SHOULD treat them as
+   unknown RRs and SHOULD NOT assign any special meaning to them or
+   give them any special treatment.  It MUST NOT use them for DNSSEC
+   validations or other DNS operational decision making.  For example,
+   a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to
+   validate RRSIGs.  If SIG, KEY, or NXT RRs are included in a zone,
+   they MUST NOT receive special treatment.  As an example, if a SIG
+   is included in a signed zone, there MUST be an RRSIG for it.
+   Authoritative servers may wish to give error messages when loading
+   zones containing SIG or NXT records (KEY records may be included
+   for SIG(0) or TKEY).
+
+   As a clarification to previous documents, some positive responses,
+   particularly wildcard proofs and unsecure referrals, will contain
+   NSEC RRs.  Resolvers MUST NOT treat answers with NSEC RRs as
+   negative answers merely because they contain an NSEC.
+
+4. IANA Considerations
+
+4.1 DNS Resource Record Types
+
+   This document updates the IANA registry for DNS Resource Record
+   Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and
+   DNSKEY RRs, respectively.
+
+   Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
+   TKEY [RFC2930] use only.
+
+   Type 30 (NXT) should be marked as Obsolete.
+
+4.2 DNS Security Algorithm Numbers
+
+   To allow zone signing (DNSSEC) and transaction security mechanisms
+   (SIG(0) and TKEY) to use different sets of algorithms, the existing
+   "DNS Security Algorithm Numbers" registry is modified to include
+   the applicability of each algorithm.  Specifically, two new columns
+   are added to the registry, showing whether each algorithm may be
+   used for zone signing, transaction security mechanisms, or both.
+   Only algorithms usable for zone signing may be used in DNSKEY,
+   RRSIG, and DS RRs.  Only algorithms usable for SIG(0) and/or TSIG
+   may be used in SIG and KEY RRs.
+
+   All currently defined algorithms remain usable for transaction
+   security mechanisms.  Only RSA/SHA-1, DSA/SHA-1, and private
+   algorithms (types 253 and 254) may be used for zone signing.  Note
+   that the registry does not contain the requirement level of each
+   algorithm, only whether or not an algorithm may be used for the
+   given purposes.  For example, RSA/MD5, while allowed for
+   transaction security mechanisms, is NOT RECOMMENDED, per RFC3110.
+
+   Additionally, the presentation format algorithm mnemonics from
+   RFC2535 Section 7 are added to the registry.  This document assigns
+   RSA/SHA-1 the mnemonic RSASHA1.
+
+   As before, assignment of new algorithms in this registry requires
+   IETF Standards Action.  Additionally, modification of algorithm
+   mnemonics or applicability requires IETF Standards Action.
+   Documents defining a new algorithm must address the applicability
+   of the algorithm and should assign a presentation mnemonic to the
+   algorithm.
+
+4.3 DNSKEY Flags
+
+   Like the KEY resource record, DNSKEY contains a 16-bit flags field.
+   This document creates a new registry for the DNSKEY flags field.
+
+   Initially, this registry only contains an assignment for bit 7 (the
+   ZONE bit).  Bits 0-6 and 8-15 are available for assignment by IETF
+   Standards Action.
+
+4.4 DNSKEY Protocol Octet
+
+   Like the KEY resource record, DNSKEY contains an eight bit protocol
+   field.  The only defined value for this field is 3 (DNSSEC).  No
+   other values are allowed, hence no IANA registry is needed for this
+   field.
+
+5. Security Considerations
+
+   The changes introduced here do not materially affect security.
+   The implications of trying to use both new and legacy types
+   together are not well understood, and attempts to do so would
+   probably lead to unintended and dangerous results.
+
+   Changing type codes will leave code paths in legacy resolvers that
+   are never exercised.  Unexercised code paths are a frequent source
+   of security holes, largely because those code paths do not get
+   frequent scrutiny.
+
+   Doing nothing, as described in section 2.5, will slow DNSSEC
+   deployment.  While this does not decrease security, it also fails
+   to increase it.
+
+6. Normative references
+
+   [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
+             RFC 2535, March 1999.
+
+   [DS]      Gudmundsson, O., "Delegation Signer Resource Record",
+             draft-ietf-dnsext-delegation-signer-15.txt, work in
+             progress, June 2003.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
+             (SIG(0)s)", RFC 2931, September 2000.
+
+   [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
+             RR)", RFC 2930, September 2000.
+
+   [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name
+             System (DNS)", RFC 2436, March 1999.
+
+   [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
+             Domain Name System (DNS)", RFC 2539, March 1999.
+
+   [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the
+             Domain Name System (DNS)", RFC 3110, May 2001.
+
+7. Informative References
+
+   [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
+             Extensions", RFC 2065, January 1997.
+
+   [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+	     2671, August 1999.
+
+   [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+             3225, December 2001.
+
+   [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning,
+	     "Domain Name System (DNS) IANA Considerations", BCP 42,
+	     RFC 2929, September 2000.
+
+   [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY
+	     Resource Record (RR)", RFC 3445, December 2002.
+
+   [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
+             Record (RR) Types", RFC 3597, September 2003.
+
+8. Acknowledgments
+
+   The changes introduced here and the analysis of alternatives had
+   many contributors.  With apologies to anyone overlooked, those
+   include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed
+   Lewis, Bill Manning, and Suzanne Woolf.
+
+   Thanks to Jakob Schlyter and Mark Andrews for identifying the
+   incompatibility described in section 1.2.
+
+   In addition to the above, the author would like to thank Scott
+   Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive
+   comments.
+
+9. Author's Address
+
+   Samuel Weiler
+   SPARTA, Inc.
+   7075 Samuel Morse Drive
+   Columbia, MD 21046
+   USA
+   weiler@tislabs.com
+

doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt

@@ -0,0 +1,840 @@
+
+
+
+DNSEXT                                                         D. Blacka
+Internet-Draft                                            VeriSign, Inc.
+Intended status: Standards Track                           April 7, 2006
+Expires: October 9, 2006
+
+
+                           DNSSEC Experiments
+                draft-ietf-dnsext-dnssec-experiments-03
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on October 9, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                   Expires October 9, 2006                [Page 1]
+
+Internet-Draft             DNSSEC Experiments                 April 2006
+
+
+Abstract
+
+   This document describes a methodology for deploying alternate, non-
+   backwards-compatible, DNSSEC methodologies in an experimental fashion
+   without disrupting the deployment of standard DNSSEC.
+
+
+Table of Contents
+
+   1.  Definitions and Terminology  . . . . . . . . . . . . . . . . .  3
+   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  Experiments  . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   4.  Method . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+   5.  Defining an Experiment . . . . . . . . . . . . . . . . . . . .  8
+   6.  Considerations . . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 10
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     10.1.  Normative References  . . . . . . . . . . . . . . . . . . 13
+     10.2.  Informative References  . . . . . . . . . . . . . . . . . 13
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
+   Intellectual Property and Copyright Statements . . . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                   Expires October 9, 2006                [Page 2]
+
+Internet-Draft             DNSSEC Experiments                 April 2006
+
+
+1.  Definitions and Terminology
+
+   Throughout this document, familiarity with the DNS system (RFC 1035
+   [5]) and the DNS security extensions ([2], [3], and [4] is assumed.
+
+   The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [1].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                   Expires October 9, 2006                [Page 3]
+
+Internet-Draft             DNSSEC Experiments                 April 2006
+
+
+2.  Overview
+
+   Historically, experimentation with DNSSEC alternatives has been a
+   problematic endeavor.  There has typically been a desire to both
+   introduce non-backwards-compatible changes to DNSSEC and to try these
+   changes on real zones in the public DNS.  This creates a problem when
+   the change to DNSSEC would make all or part of the zone using those
+   changes appear bogus (bad) or otherwise broken to existing security-
+   aware resolvers.
+
+   This document describes a standard methodology for setting up DNSSEC
+   experiments.  This methodology addresses the issue of co-existence
+   with standard DNSSEC and DNS by using unknown algorithm identifiers
+   to hide the experimental DNSSEC protocol modifications from standard
+   security-aware resolvers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                   Expires October 9, 2006                [Page 4]
+
+Internet-Draft             DNSSEC Experiments                 April 2006
+
+
+3.  Experiments
+
+   When discussing DNSSEC experiments, it is necessary to classify these
+   experiments into two broad categories:
+
+   Backwards-Compatible:  describes experimental changes that, while not
+      strictly adhering to the DNSSEC standard, are nonetheless
+      interoperable with clients and servers that do implement the
+      DNSSEC standard.
+
+   Non-Backwards-Compatible:  describes experiments that would cause a
+      standard security-aware resolver to (incorrectly) determine that
+      all or part of a zone is bogus, or to otherwise not interoperate
+      with standard DNSSEC clients and servers.
+
+   Not included in these terms are experiments with the core DNS
+   protocol itself.
+
+   The methodology described in this document is not necessary for
+   backwards-compatible experiments, although it certainly may be used
+   if desired.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                   Expires October 9, 2006                [Page 5]
+
+Internet-Draft             DNSSEC Experiments                 April 2006
+
+
+4.  Method
+
+   The core of the methodology is the use of strictly unknown algorithm
+   identifiers when signing the experimental zone, and more importantly,
+   having only unknown algorithm identifiers in the DS records for the
+   delegation to the zone at the parent.
+
+   This technique works because of the way DNSSEC-compliant validators
+   are expected to work in the presence of a DS set with only unknown
+   algorithm identifiers.  From [4], Section 5.2:
+
+      If the validator does not support any of the algorithms listed in
+      an authenticated DS RRset, then the resolver has no supported
+      authentication path leading from the parent to the child.  The
+      resolver should treat this case as it would the case of an
+      authenticated NSEC RRset proving that no DS RRset exists, as
+      described above.
+
+   And further:
+
+      If the resolver does not support any of the algorithms listed in
+      an authenticated DS RRset, then the resolver will not be able to
+      verify the authentication path to the child zone.  In this case,
+      the resolver SHOULD treat the child zone as if it were unsigned.
+
+   While this behavior isn't strictly mandatory (as marked by MUST), it
+   is likely that a validator would implement this behavior, or, more to
+   the point, it would handle this situation in a safe way (see below
+   (Section 6).)
+
+   Because we are talking about experiments, it is RECOMMENDED that
+   private algorithm numbers be used (see [3], appendix A.1.1.  Note
+   that secure handling of private algorithms requires special handing
+   by the validator logic.  See [6] for further details.)  Normally,
+   instead of actually inventing new signing algorithms, the recommended
+   path is to create alternate algorithm identifiers that are aliases
+   for the existing, known algorithms.  While, strictly speaking, it is
+   only necessary to create an alternate identifier for the mandatory
+   algorithms, it is suggested that all optional defined algorithms be
+   aliased as well.
+
+   It is RECOMMENDED that for a particular DNSSEC experiment, a
+   particular domain name base is chosen for all new algorithms, then
+   the algorithm number (or name) is prepended to it.  For example, for
+   experiment A, the base name of "dnssec-experiment-a.example.com" is
+   chosen.  Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
+   defined to be "3.dnssec-experiment-a.example.com" and
+   "5.dnssec-experiment-a.example.com".  However, any unique identifier
+
+
+
+Blacka                   Expires October 9, 2006                [Page 6]
+
+Internet-Draft             DNSSEC Experiments                 April 2006
+
+
+   will suffice.
+
+   Using this method, resolvers (or, more specifically, DNSSEC
+   validators) essentially indicate their ability to understand the
+   DNSSEC experiment's semantics by understanding what the new algorithm
+   identifiers signify.
+
+   This method creates two classes of security-aware servers and
+   resolvers: servers and resolvers that are aware of the experiment
+   (and thus recognize the experiment's algorithm identifiers and
+   experimental semantics), and servers and resolvers that are unaware
+   of the experiment.
+
+   This method also precludes any zone from being both in an experiment
+   and in a classic DNSSEC island of security.  That is, a zone is
+   either in an experiment and only experimentally validatable, or it is
+   not.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                   Expires October 9, 2006                [Page 7]
+
+Internet-Draft             DNSSEC Experiments                 April 2006
+
+
+5.  Defining an Experiment
+
+   The DNSSEC experiment MUST define the particular set of (previously
+   unknown) algorithm identifiers that identify the experiment, and
+   define what each unknown algorithm identifier means.  Typically,
+   unless the experiment is actually experimenting with a new DNSSEC
+   algorithm, this will be a mapping of private algorithm identifiers to
+   existing, known algorithms.
+
+   Normally the experiment will choose a DNS name as the algorithm
+   identifier base.  This DNS name SHOULD be under the control of the
+   authors of the experiment.  Then the experiment will define a mapping
+   between known mandatory and optional algorithms into this private
+   algorithm identifier space.  Alternately, the experiment MAY use the
+   OID private algorithm space instead (using algorithm number 254), or
+   MAY choose non-private algorithm numbers, although this would require
+   an IANA allocation.
+
+   For example, an experiment might specify in its description the DNS
+   name "dnssec-experiment-a.example.com" as the base name, and declare
+   that "3.dnssec-experiment-a.example.com" is an alias of DNSSEC
+   algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an
+   alias of DNSSEC algorithm 5 (RSASHA1).
+
+   Resolvers MUST only recognize the experiment's semantics when present
+   in a zone signed by one or more of these algorithm identifiers.  This
+   is necessary to isolate the semantics of one experiment from any
+   others that the resolver might understand.
+
+   In general, resolvers involved in the experiment are expected to
+   understand both standard DNSSEC and the defined experimental DNSSEC
+   protocol, although this isn't required.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                   Expires October 9, 2006                [Page 8]
+
+Internet-Draft             DNSSEC Experiments                 April 2006
+
+
+6.  Considerations
+
+   There are a number of considerations with using this methodology.
+
+   1.  Under some circumstances, it may be that the experiment will not
+       be sufficiently masked by this technique and may cause resolution
+       problem for resolvers not aware of the experiment.  For instance,
+       the resolver may look at a non-validatable response and conclude
+       that the response is bogus, either due to local policy or
+       implementation details.  This is not expected to be a common
+       case, however.
+
+   2.  It will not be possible for security-aware resolvers unaware of
+       the experiment to build a chain of trust through an experimental
+       zone.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                   Expires October 9, 2006                [Page 9]
+
+Internet-Draft             DNSSEC Experiments                 April 2006
+
+
+7.  Use in Non-Experiments
+
+   This general methodology MAY be used for non-backwards compatible
+   DNSSEC protocol changes that start out as or become standards.  In
+   this case:
+
+   o  The protocol change SHOULD use public IANA allocated algorithm
+      identifiers instead of private algorithm identifiers.  This will
+      help identify the protocol change as a standard, rather than an
+      experiment.
+
+   o  Resolvers MAY recognize the protocol change in zones not signed
+      (or not solely signed) using the new algorithm identifiers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                   Expires October 9, 2006               [Page 10]
+
+Internet-Draft             DNSSEC Experiments                 April 2006
+
+
+8.  Security Considerations
+
+   Zones using this methodology will be considered insecure by all
+   resolvers except those aware of the experiment.  It is not generally
+   possible to create a secure delegation from an experimental zone that
+   will be followed by resolvers unaware of the experiment.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                   Expires October 9, 2006               [Page 11]
+
+Internet-Draft             DNSSEC Experiments                 April 2006
+
+
+9.  IANA Considerations
+
+   This document has no IANA actions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                   Expires October 9, 2006               [Page 12]
+
+Internet-Draft             DNSSEC Experiments                 April 2006
+
+
+10.  References
+
+10.1.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033,
+        March 2005.
+
+   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+   [4]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions",
+        RFC 4035, March 2005.
+
+10.2.  Informative References
+
+   [5]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [6]  Austein, R. and S. Weiler, "Clarifications and Implementation
+        Notes for DNSSECbis", draft-ietf-dnsext-dnssec-bis-updates-02
+        (work in progress), January 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                   Expires October 9, 2006               [Page 13]
+
+Internet-Draft             DNSSEC Experiments                 April 2006
+
+
+Author's Address
+
+   David Blacka
+   VeriSign, Inc.
+   21355 Ridgetop Circle
+   Dulles, VA  20166
+   US
+
+   Phone: +1 703 948 3200
+   Email: davidb@verisign.com
+   URI:   http://www.verisignlabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka                   Expires October 9, 2006               [Page 14]
+
+Internet-Draft             DNSSEC Experiments                 April 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Blacka                   Expires October 9, 2006               [Page 15]
+

doc/draft/draft-ietf-dnsext-dnssec-gost-03.txt

@@ -0,0 +1,455 @@
+DNS Extensions working group                             V.Dolmatov, Ed.  
+Internet-Draft                                            Cryptocom Ltd.    
+Intended status: Standards Track                      November 10, 2009
+Expires: May 10, 2010                                 
+
+
+ Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records
+                               for DNSSEC
+                 draft-ietf-dnsext-dnssec-gost-03
+
+Status of this Memo
+
+   This Internet-Draft is submitted to IETF in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on May  10 2010.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   This document describes how to produce signature and hash using 
+   GOST algorithms for DNSKEY, RRSIG and DS resource records for use in
+   the Domain Name System Security Extensions (DNSSEC, RFC 4033, 
+   RFC 4034, and RFC 4035).
+
+V.Dolmatov              Expires May  10, 2010               [Page 1]
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3
+     2.1.  Using a public key with existing cryptographic libraries. . 3
+     2.2.  GOST DNSKEY RR Example  . . . . . . . . . . . . . . . . . . 3
+   3.  RRSIG Resource Records  . . . . . . . . . . . . . . . . . . . . 4
+     3.1 RRSIG RR Example  . . . . . . . . . . . . . . . . . . . . . . 4
+   4.  DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 4
+     4.1 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . . 5
+   5.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 5
+     5.1.  Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 5
+     5.2.  Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 5
+     5.3.  Digest Sizes  . . . . . . . . . . . . . . . . . . . . . . . 5
+   6.  Implementation Considerations . . . . . . . . . . . . . . . . . 5
+     6.1.  Support for GOST signatures . . . . . . . . . . . . . . . . 5
+     6.2.  Support for NSEC3 Denial of Existence . . . . . . . . . . . 5
+     6.3.  Byte order  . . . . . . . . . . . . . . . . . . . . . . . . 5
+   7. Security consideration . . . . . . . . . . . . . . . . . . . . . 5
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
+   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
+   10.  References   . . . . . . . . . . . . . . . . . . . . . . . . . 6
+     10.1.  Normative References . . . . . . . . . . . . . . . . . . . 6
+     10.2.  Informative References . . . . . . . . . . . . . . . . . . 7
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
+
+1.  Introduction
+
+   The Domain Name System (DNS) is the global hierarchical distributed
+   database for Internet Naming.  The DNS has been extended to use
+   cryptographic keys and digital signatures for the verification of the
+   authenticity and integrity of its data.  RFC 4033 [RFC4033], RFC 4034
+   [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security
+   Extensions, called DNSSEC.
+
+   RFC 4034 describes how to store DNSKEY and RRSIG resource records,
+   and specifies a list of cryptographic algorithms to use.  This
+   document extends that list with the signature and hash algorithms 
+   GOST [GOST3410, GOST3411],
+   and specifies how to store DNSKEY data and how to produce
+   RRSIG resource records with these hash algorithms.
+
+   Familiarity with DNSSEC  and GOST signature and hash
+   algorithms is assumed in this document.
+
+   The term "GOST" is not officially defined, but is usually used to
+   refer to the collection of the Russian cryptographic algorithms
+   GOST R 34.10-2001, GOST R 34.11-94, GOST 28147-89. 
+   Since GOST 28147-89 is not used in DNSSEC, "GOST" will only refer to
+   the GOST R 34.10-2001 and GOST R 34.11-94 in this document.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+V.Dolmatov              Expires May  10, 2010                [Page 2]
+
+2.  DNSKEY Resource Records
+
+   The format of the DNSKEY RR can be found in RFC 4034 [RFC4034].
+
+   GOST R 34.10-2001 public keys are stored with the algorithm number 
+   {TBA1}.
+      
+   The wire format of the public key is compatible with 
+   RFC 4491 [RFC4491]:
+
+   According to [GOSTR341001], a public key is a point on the elliptic
+   curve Q = (x,y).
+
+   The wire representation of a public key MUST contain 66 octets, 
+   where the first octet designates public key parameters, the second
+   octet designates digest parameters next 32 octets contain the 
+   little-endian representation of x and the second 32 octets contain
+   the little-endian representation of y. 
+   This corresponds to the binary representation of (<y>256||<x>256) 
+   from [GOSTR341001], ch.  5.3.
+
+   The only valid value for both parameters octets is 0.
+   Other parameters octets values are reserved for future use.
+   
+   Corresponding public key parameters are those identified by
+   id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357],
+   and the digest parameters are those identified by
+   id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].
+
+2.1.  Using a public key with existing cryptographic libraries
+
+   Existing GOST-aware cryptographic libraries at the time of this 
+   document writing are capable to read GOST public keys via a generic
+   X509 API if the key is encoded according to RFC 4491 [RFC4491],
+   section 2.3.2.
+
+   To make this encoding from the wire format of a GOST public key 
+   with the parameters used in this document, prepend the last 64 octets
+   of key data (in other words, substitute first two parameter octets)
+   with the following 37-byte sequence:
+
+   0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30 
+   0x12 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a
+   0x85 0x03 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40
+  
+2.2.  GOST DNSKEY RR Example
+
+   Given a private key with the following value (the value of GostAsn1
+   field is split here into two lines to simplify reading; in the 
+   private key file it must be in one line):
+
+   Private-key-format: v1.2
+   Algorithm: {TBA1} (GOST)
+   GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQgV/S
+	     2FXdMtzKJBehZvjF4lVSx6m66TwqSe/MFwKSH/3E=
+
+V.Dolmatov              Expires May  10, 2010                [Page 3]
+
+   The following DNSKEY RR stores a DNS zone key for example.net
+ 
+   example.net. 86400 IN DNSKEY 256 3 {TBA1} (
+                                AADMrbi2vAs4hklTmmzGE3WWNtJ8Dll0u0jq
+				tGRbNKeJguZQj/9EpGWmQK9hekPiPlzH2Ph6
+				yB7i836EfzmJo5LP
+				) ; key id = 15820
+
+3.  RRSIG Resource Records
+
+   The value of the signature field in the RRSIG RR follows RFC 4490
+   [RFC4490] and is calculated as follows.  The values for the RDATA 
+   fields that precede the signature data are specified 
+   in RFC 4034 [RFC4034].
+
+   hash = GOSTR3411(data)
+
+   where "data" is the wire format data of the resource record set 
+   that is signed, as specified in RFC 4034 [RFC4034].
+   
+   Hash MUST be calculated with GOST R 34.11-94 parameters identified
+   by id-GostR3411-94-CryptoProParamSet [RFC4357].
+
+   Signature is calculated from the hash according to the 
+   GOST R 34.10-2001 standard and its wire format is compatible with 
+   RFC 4490 [RFC4490].
+
+   Quoting RFC 4490:
+
+   "The signature algorithm GOST R 34.10-2001 generates a digital
+   signature in the form of two 256-bit numbers, r and s.  Its octet
+   string representation consists of 64 octets, where the first 32
+   octets contain the big-endian representation of s and the second 32
+   octets contain the big-endian representation of r."
+
+3.1. RRSIG RR Example
+
+   With the private key from section 2.2 sign the following RRSet, 
+   consisting of one A record:
+
+   www.example.net. 3600 IN A 192.0.32.10
+
+   Setting the inception date to 2000-01-01 00:00:00 UTC and the 
+   expiration date to 2030-01-01 00:00:00 UTC, the following signature
+   should be created (assuming {TBA1}==249 until proper code is 
+   assigned by IANA)
+
+   www.example.net. 3600 IN RRSIG A {TBA1} 3 3600 20300101000000 (
+                                  20000101000000 15820 example.net.
+                                  K4sw+TOJz47xqP6685ItDfPhkktyvgxXrLdX
+                                  aQLX01mMZbJUp6tzetBYGpdHciAW5RLvHLVB
+                                  P8RtFK8Qv5DRsA== )
+
+  Note: Several GOST signatures calculated for the same message text 
+   differ because of using of a random element is used in signature 
+   generation process.
+
+4.  DS Resource Records
+
+   GOST R 34.11-94 digest algorithm is denoted in DS RRs by the digest
+   type {TBA2}.  The wire format of a digest value is compatible with 
+   RFC 4490 [RFC4490], that is digest is in little-endian representation. 
+
+V.Dolmatov              Expires May  10, 2010                [Page 4]
+
+      The digest MUST always be calculated with GOST R 34.11-94 parameters
+   identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
+
+4.1. DS RR Example
+
+   For key signing key (assuming {TBA1}==249 until proper code is 
+   assigned by IANA)
+
+   example.net. 86400   DNSKEY  257 3 {TBA1} (
+                                AAADr5vmKVdXo780hSRU1YZYWuMZUbEe9R7C
+                                RRLc7Wj2osDXv2XbCnIpTUx8dVLnLKmDBquu
+                                9tCz5oSsZl0cL0R2
+                                ) ; key id = 21649
+
+   The DS RR will be
+
+   example.net. 3600 IN DS 21649 {TBA1} {TBA2} (
+             A8146F448569F30B91255BA8E98DE14B18569A524C49593ADCA4103A
+	     A44649C6 )
+
+
+5.  Deployment Considerations
+
+5.1.  Key Sizes
+
+   According to RFC4357 [RFC4357], the key size of GOST public keys
+   MUST be 512 bits.
+
+5.2.  Signature Sizes
+
+   According to the GOST signature algorithm specification [GOST3410],
+   the size of a GOST signature is 512 bits.
+
+5.3.  Digest Sizes
+
+   According to the GOST R 34.11-94 [GOST3411], the size of a GOST digest
+   is 256 bits.
+
+6.  Implementation Considerations
+
+6.1.  Support for GOST signatures
+
+   DNSSEC aware implementations SHOULD be able to support RRSIG and
+   DNSKEY resource records created with the GOST algorithms as
+   defined in this document.
+
+6.2.  Support for NSEC3 Denial of Existence
+
+    Any DNSSEC-GOST implementation is required to have either NSEC or
+    NSEC3 support.
+
+6.3  Byte order
+
+    Due to the fact that all existing industry implementations of GOST
+    cryptographic libraries are returning GOST blobs in little-endian 
+    format and in order to avoid the necessity for DNSSEC developers 
+    to handle different cryptographic algorithms differently, it was
+    chosen to send these blobs on the wire "as is" without 
+    transformation of endianness.
+
+7.  Security considerations
+
+    Currently, the cryptographic resistance of the GOST 34.10-2001 
+    digital signature algorithm is estimated as 2**128 operations
+    of multiple elliptic curve point computations on prime modulus
+    2**256.
+
+V.Dolmatov              Expires May  10, 2010                [Page 5]
+
+    Currently, the cryptographic resistance of GOST 34.11-94 hash
+    algorithm is estimated as 2**128 operations of computations of a
+    step hash function. (There is known method to reduce this 
+    estimate to 2**105 operations, but it demands padding the 
+    colliding message with 1024 random bit blocks each of 256 bit
+    length, thus it cannot be used in any practical implementation).
+
+8.  IANA Considerations
+
+   This document updates the IANA registry "DNS Security Algorithm 
+   Numbers [RFC4034]"
+   (http://www.iana.org/assignments/dns-sec-alg-numbers).  The 
+   following entries are added to the registry:
+                                     Zone    Trans.
+   Value  Algorithm         Mnemonic Signing Sec.  References   Status
+   {TBA1} GOST R 34.10-2001 GOST     Y       *     (this memo)  OPTIONAL
+
+   This document updates the RFC 4034 Digest Types assignment
+   (section A.2)by adding the value and status for the GOST R 34.11-94
+   algorithm:
+
+   Value   Algorithm        Status
+   {TBA2}  GOST R 34.11-94  OPTIONAL
+
+9. Acknowledgments
+
+   This document is a minor extension to RFC 4034 [RFC4034].  Also, we
+   tried to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509],
+   and RFC 4357 [RFC4357] for consistency. The authors of and 
+   contributors to these documents are gratefully acknowledged for 
+   their hard work.
+
+   The following people provided additional feedback and text: Dmitry 
+   Burkov, Jaap Akkerhuis, Olafur Gundmundsson, Jelte Jansen 
+   and Wouter Wijngaards.
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", RFC 2119, March 1997.
+
+   [RFC3110]  Eastlake D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
+              Name System (DNS)", RFC 3110, May 2001.
+
+   [RFC4033]  Arends R., Austein R., Larson M., Massey D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC4034]  Arends R., Austein R., Larson M., Massey D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, March 2005.
+
+V.Dolmatov              Expires May  10, 2010                [Page 6]
+
+   [RFC4035]  Arends R., Austein R., Larson M., Massey D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+   [GOST3410] "Information technology.  Cryptographic data security.
+              Signature and verification processes of [electronic]
+              digital signature.", GOST R 34.10-2001, Gosudarstvennyi
+              Standard of Russian Federation, Government Committee of
+              the Russia for Standards, 2001.  (In Russian)
+
+   [GOST3411] "Information technology.  Cryptographic Data Security.
+              Hashing function.", GOST R 34.11-94, Gosudarstvennyi
+              Standard of Russian Federation, Government Committee of
+              the Russia for Standards, 1994.  (In Russian)
+
+   [RFC4357] Popov V., Kurepkin I., and S. Leontiev, "Additional
+             Cryptographic Algorithms for Use with GOST 28147-89,
+             GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
+             Algorithms", RFC 4357, January 2006.
+
+   [RFC4490] S. Leontiev and G. Chudov, "Using the GOST 28147-89, 
+	     GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 
+             Algorithms with Cryptographic Message Syntax (CMS)",
+             RFC 4490, May 2006.
+
+   [RFC4491] S. Leontiev and D. Shefanovski, "Using the GOST 
+             R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 
+             Algorithms with the Internet X.509 Public Key 
+             Infrastructure Certificate and CRL Profile", RFC 4491,
+             May 2006. 
+
+
+
+10.2.  Informative References
+
+   [NIST800-57]
+              Barker E., Barker W., Burr W., Polk W., and M. Smid,
+              "Recommendations for Key Management", NIST SP 800-57,
+              March 2007.
+
+   [RFC3447]  Jonsson J. and B. Kaliski, "Public-Key Cryptography
+              Standards (PKCS) #1: RSA Cryptography Specifications
+              Version 2.1", RFC 3447, February 2003.
+
+   [RFC4509]  Hardaker W., "Use of SHA-256 in DNSSEC Delegation Signer
+              (DS) Resource Records (RRs)", RFC 4509, May 2006.
+
+   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+              Security (DNSSEC) Hashed Authenticated Denial of
+              Existence", RFC 5155, March 2008.
+
+   [DRAFT1]   Dolmatov V., Kabelev D., Ustinov I., Vyshensky S.,
+              "GOST R 34.10-2001 digital signature algorithm"
+              draft-dolmatov-cryptocom-gost3410-2001-06, 11.10.09
+              work in progress.
+V.Dolmatov              Expires May  10, 2010               [Page 7]
+
+   [DRAFT2]   Dolmatov V., Kabelev D., Ustinov I., Vyshensky S.,
+              "GOST R 34.11-94 Hash function algorithm"
+              draft-dolmatov-cryptocom-gost341194-04, 11.10.09
+              work in progress.
+
+   [DRAFT3]   Dolmatov V., Kabelev D., Ustinov I., Emelyanova I.,
+              "GOST 28147-89 encryption, decryption and MAC algorithms"
+              draft-dolmatov-cryptocom-gost2814789-04, 11.10.09
+              work in progress.
+
+Authors' Addresses
+
+
+Vasily Dolmatov, Ed.
+Cryptocom Ltd.
+Bolotnikovskaya, 23
+Moscow, 117303, Russian Federation
+
+EMail: dol@cryptocom.ru
+
+Artem Chuprina
+Cryptocom Ltd.
+Bolotnikovskaya, 23
+Moscow, 117303, Russian Federation
+
+EMail: ran@cryptocom.ru
+
+Igor Ustinov
+Cryptocom Ltd.
+Bolotnikovskaya, 23
+Moscow, 117303, Russian Federation
+
+EMail: igus@cryptocom.ru
+
+V.Dolmatov              Expires May  10, 2010                [Page 8]
+
+
+
+

doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt

@@ -0,0 +1,616 @@
+
+
+
+Network Working Group                                          S. Weiler
+Internet-Draft                                               SPARTA, Inc
+Updates: 4034, 4035 (if approved)                               J. Ihren
+Expires: July 24, 2006                                     Autonomica AB
+                                                        January 20, 2006
+
+
+       Minimally Covering NSEC Records and DNSSEC On-line Signing
+               draft-ietf-dnsext-dnssec-online-signing-02
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on July 24, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes how to construct DNSSEC NSEC resource records
+   that cover a smaller range of names than called for by RFC4034.  By
+   generating and signing these records on demand, authoritative name
+   servers can effectively stop the disclosure of zone contents
+   otherwise made possible by walking the chain of NSEC records in a
+   signed zone.
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 1]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+Changes from ietf-01 to ietf-02
+
+   Clarified that a generated NSEC RR's type bitmap MUST have the RRSIG
+   and NSEC bits set, to be consistent with DNSSECbis -- previous text
+   said SHOULD.
+
+   Made the applicability statement a little less oppressive.
+
+Changes from ietf-00 to ietf-01
+
+   Added an applicability statement, making reference to ongoing work on
+   NSEC3.
+
+   Added the phrase "epsilon functions", which has been commonly used to
+   describe the technique and already appeared in the header of each
+   page, in place of "increment and decrement functions".  Also added an
+   explanatory sentence.
+
+   Corrected references from 4034 section 6.2 to section 6.1.
+
+   Fixed an out-of-date reference to [-bis] and other typos.
+
+   Replaced IANA Considerations text.
+
+   Escaped close parentheses in examples.
+
+   Added some more acknowledgements.
+
+Changes from weiler-01 to ietf-00
+
+   Inserted RFC numbers for 4033, 4034, and 4035.
+
+   Specified contents of bitmap field in synthesized NSEC RR's, pointing
+   out that this relaxes a constraint in 4035.  Added 4035 to the
+   Updates header.
+
+Changes from weiler-00 to weiler-01
+
+   Clarified that this updates RFC4034 by relaxing requirements on the
+   next name field.
+
+   Added examples covering wildcard names.
+
+   In the 'better functions' section, reiterated that perfect functions
+   aren't needed.
+
+   Added a reference to RFC 2119.
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 2]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+Table of Contents
+
+   1.  Introduction and Terminology . . . . . . . . . . . . . . . . .  4
+   2.  Applicability of This Technique  . . . . . . . . . . . . . . .  4
+   3.  Minimally Covering NSEC Records  . . . . . . . . . . . . . . .  5
+   4.  Better Epsilon Functions . . . . . . . . . . . . . . . . . . .  6
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
+   7.  Normative References . . . . . . . . . . . . . . . . . . . . .  8
+   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . .  8
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
+   Intellectual Property and Copyright Statements . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 3]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+1.  Introduction and Terminology
+
+   With DNSSEC [1], an NSEC record lists the next instantiated name in
+   its zone, proving that no names exist in the "span" between the
+   NSEC's owner name and the name in the "next name" field.  In this
+   document, an NSEC record is said to "cover" the names between its
+   owner name and next name.
+
+   Through repeated queries that return NSEC records, it is possible to
+   retrieve all of the names in the zone, a process commonly called
+   "walking" the zone.  Some zone owners have policies forbidding zone
+   transfers by arbitrary clients; this side-effect of the NSEC
+   architecture subverts those policies.
+
+   This document presents a way to prevent zone walking by constructing
+   NSEC records that cover fewer names.  These records can make zone
+   walking take approximately as many queries as simply asking for all
+   possible names in a zone, making zone walking impractical.  Some of
+   these records must be created and signed on demand, which requires
+   on-line private keys.  Anyone contemplating use of this technique is
+   strongly encouraged to review the discussion of the risks of on-line
+   signing in Section 6.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [4].
+
+
+2.  Applicability of This Technique
+
+   The technique presented here may be useful to a zone owner that wants
+   to use DNSSEC, is concerned about exposure of its zone contents via
+   zone walking, and is willing to bear the costs of on-line signing.
+
+   As discussed in Section 6, on-line signing has several security
+   risks, including an increased likelihood of private keys being
+   disclosed and an increased risk of denial of service attack.  Anyone
+   contemplating use of this technique is strongly encouraged to review
+   the discussion of the risks of on-line signing in Section 6.
+
+   Furthermore, at the time this document was published, the DNSEXT
+   working group was actively working on a mechanism to prevent zone
+   walking that does not require on-line signing (tentatively called
+   NSEC3).  The new mechanism is likely to expose slightly more
+   information about the zone than this technique (e.g. the number of
+   instantiated names), but it may be preferable to this technique.
+
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 4]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+3.  Minimally Covering NSEC Records
+
+   This mechanism involves changes to NSEC records for instantiated
+   names, which can still be generated and signed in advance, as well as
+   the on-demand generation and signing of new NSEC records whenever a
+   name must be proven not to exist.
+
+   In the 'next name' field of instantiated names' NSEC records, rather
+   than list the next instantiated name in the zone, list any name that
+   falls lexically after the NSEC's owner name and before the next
+   instantiated name in the zone, according to the ordering function in
+   RFC4034 [2] section 6.1.  This relaxes the requirement in section
+   4.1.1 of RFC4034 that the 'next name' field contains the next owner
+   name in the zone.  This change is expected to be fully compatible
+   with all existing DNSSEC validators.  These NSEC records are returned
+   whenever proving something specifically about the owner name (e.g.
+   that no resource records of a given type appear at that name).
+
+   Whenever an NSEC record is needed to prove the non-existence of a
+   name, a new NSEC record is dynamically produced and signed.  The new
+   NSEC record has an owner name lexically before the QNAME but
+   lexically following any existing name and a 'next name' lexically
+   following the QNAME but before any existing name.
+
+   The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
+   bits set and SHOULD NOT have any other bits set.  This relaxes the
+   requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
+   names that did not exist before the zone was signed.
+
+   The functions to generate the lexically following and proceeding
+   names need not be perfect nor consistent, but the generated NSEC
+   records must not cover any existing names.  Furthermore, this
+   technique works best when the generated NSEC records cover as few
+   names as possible.  In this document, the functions that generate the
+   nearby names are called 'epsilon' functions, a reference to the
+   mathematical convention of using the greek letter epsilon to
+   represent small deviations.
+
+   An NSEC record denying the existence of a wildcard may be generated
+   in the same way.  Since the NSEC record covering a non-existent
+   wildcard is likely to be used in response to many queries,
+   authoritative name servers using the techniques described here may
+   want to pregenerate or cache that record and its corresponding RRSIG.
+
+   For example, a query for an A record at the non-instantiated name
+   example.com might produce the following two NSEC records, the first
+   denying the existence of the name example.com and the second denying
+   the existence of a wildcard:
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 5]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+             exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
+
+             \).com 3600 IN NSEC +.com ( RRSIG NSEC )
+
+   Before answering a query with these records, an authoritative server
+   must test for the existence of names between these endpoints.  If the
+   generated NSEC would cover existing names (e.g. exampldd.com or
+   *bizarre.example.com), a better epsilon function may be used or the
+   covered name closest to the QNAME could be used as the NSEC owner
+   name or next name, as appropriate.  If an existing name is used as
+   the NSEC owner name, that name's real NSEC record MUST be returned.
+   Using the same example, assuming an exampldd.com delegation exists,
+   this record might be returned from the parent:
+
+             exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
+
+   Like every authoritative record in the zone, each generated NSEC
+   record MUST have corresponding RRSIGs generated using each algorithm
+   (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
+   described in RFC4035 [3] section 2.2.  To minimize the number of
+   signatures that must be generated, a zone may wish to limit the
+   number of algorithms in its DNSKEY RRset.
+
+
+4.  Better Epsilon Functions
+
+   Section 6.1 of RFC4034 defines a strict ordering of DNS names.
+   Working backwards from that definition, it should be possible to
+   define epsilon functions that generate the immediately following and
+   preceding names, respectively.  This document does not define such
+   functions.  Instead, this section presents functions that come
+   reasonably close to the perfect ones.  As described above, an
+   authoritative server should still ensure than no generated NSEC
+   covers any existing name.
+
+   To increment a name, add a leading label with a single null (zero-
+   value) octet.
+
+   To decrement a name, decrement the last character of the leftmost
+   label, then fill that label to a length of 63 octets with octets of
+   value 255.  To decrement a null (zero-value) octet, remove the octet
+   -- if an empty label is left, remove the label.  Defining this
+   function numerically: fill the left-most label to its maximum length
+   with zeros (numeric, not ASCII zeros) and subtract one.
+
+   In response to a query for the non-existent name foo.example.com,
+   these functions produce NSEC records of:
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 6]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+     fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
+
+     \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
+
+   The first of these NSEC RRs proves that no exact match for
+   foo.example.com exists, and the second proves that there is no
+   wildcard in example.com.
+
+   Both of these functions are imperfect: they don't take into account
+   constraints on number of labels in a name nor total length of a name.
+   As noted in the previous section, though, this technique does not
+   depend on the use of perfect epsilon functions: it is sufficient to
+   test whether any instantiated names fall into the span covered by the
+   generated NSEC and, if so, substitute those instantiated owner names
+   for the NSEC owner name or next name, as appropriate.
+
+
+5.  IANA Considerations
+
+   This document specifies no IANA Actions.
+
+
+6.  Security Considerations
+
+   This approach requires on-demand generation of RRSIG records.  This
+   creates several new vulnerabilities.
+
+   First, on-demand signing requires that a zone's authoritative servers
+   have access to its private keys.  Storing private keys on well-known
+   internet-accessible servers may make them more vulnerable to
+   unintended disclosure.
+
+   Second, since generation of digital signatures tends to be
+   computationally demanding, the requirement for on-demand signing
+   makes authoritative servers vulnerable to a denial of service attack.
+
+   Lastly, if the epsilon functions are predictable, on-demand signing
+   may enable a chosen-plaintext attack on a zone's private keys.  Zones
+   using this approach should attempt to use cryptographic algorithms
+   that are resistant to chosen-plaintext attacks.  It's worth noting
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 7]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+   that while DNSSEC has a "mandatory to implement" algorithm, that is a
+   requirement on resolvers and validators -- there is no requirement
+   that a zone be signed with any given algorithm.
+
+   The success of using minimally covering NSEC record to prevent zone
+   walking depends greatly on the quality of the epsilon functions
+   chosen.  An increment function that chooses a name obviously derived
+   from the next instantiated name may be easily reverse engineered,
+   destroying the value of this technique.  An increment function that
+   always returns a name close to the next instantiated name is likewise
+   a poor choice.  Good choices of epsilon functions are the ones that
+   produce the immediately following and preceding names, respectively,
+   though zone administrators may wish to use less perfect functions
+   that return more human-friendly names than the functions described in
+   Section 4 above.
+
+   Another obvious but misguided concern is the danger from synthesized
+   NSEC records being replayed.  It's possible for an attacker to replay
+   an old but still validly signed NSEC record after a new name has been
+   added in the span covered by that NSEC, incorrectly proving that
+   there is no record at that name.  This danger exists with DNSSEC as
+   defined in [3].  The techniques described here actually decrease the
+   danger, since the span covered by any NSEC record is smaller than
+   before.  Choosing better epsilon functions will further reduce this
+   danger.
+
+7.  Normative References
+
+   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033,
+        March 2005.
+
+   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions",
+        RFC 4035, March 2005.
+
+   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+
+Appendix A.  Acknowledgments
+
+   Many individuals contributed to this design.  They include, in
+   addition to the authors of this document, Olaf Kolkman, Ed Lewis,
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 8]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+   Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
+   Jakob Schlyter, Bill Manning, and Joao Damas.
+
+   In addition, the editors would like to thank Ed Lewis, Scott Rose,
+   and David Blacka for their careful review of the document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                 [Page 9]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+Authors' Addresses
+
+   Samuel Weiler
+   SPARTA, Inc
+   7075 Samuel Morse Drive
+   Columbia, Maryland  21046
+   US
+
+   Email: weiler@tislabs.com
+
+
+   Johan Ihren
+   Autonomica AB
+   Bellmansgatan 30
+   Stockholm  SE-118 47
+   Sweden
+
+   Email: johani@autonomica.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                [Page 10]
+
+Internet-Draft                NSEC Epsilon                  January 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Weiler & Ihren            Expires July 24, 2006                [Page 11]
+

doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt

@@ -0,0 +1,896 @@
+
+
+
+DNSEXT                                                         R. Arends
+Internet-Draft                                      Telematica Instituut
+Expires: January 19, 2006                                     M. Kosters
+                                                               D. Blacka
+                                                          Verisign, Inc.
+                                                           July 18, 2005
+
+
+                             DNSSEC Opt-In
+                   draft-ietf-dnsext-dnssec-opt-in-07
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on January 19, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   In the DNS security extensions (DNSSEC, defined in RFC 4033 [3], RFC
+   4034 [4], and RFC 4035 [5]), delegations to unsigned subzones are
+   cryptographically secured.  Maintaining this cryptography is not
+   practical or necessary.  This document describes an experimental
+   "Opt-In" model that allows administrators to omit this cryptography
+   and manage the cost of adopting DNSSEC with large zones.
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 1]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+Table of Contents
+
+   1.  Definitions and Terminology  . . . . . . . . . . . . . . . . .  3
+   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  Experimental Status  . . . . . . . . . . . . . . . . . . . . .  4
+   4.  Protocol Additions . . . . . . . . . . . . . . . . . . . . . .  4
+     4.1   Server Considerations  . . . . . . . . . . . . . . . . . .  5
+       4.1.1   Delegations Only . . . . . . . . . . . . . . . . . . .  5
+       4.1.2   Insecure Delegation Responses  . . . . . . . . . . . .  6
+       4.1.3   Wildcards and Opt-In . . . . . . . . . . . . . . . . .  6
+       4.1.4   Dynamic Update . . . . . . . . . . . . . . . . . . . .  7
+     4.2   Client Considerations  . . . . . . . . . . . . . . . . . .  7
+       4.2.1   Delegations Only . . . . . . . . . . . . . . . . . . .  7
+       4.2.2   Validation Process Changes . . . . . . . . . . . . . .  7
+       4.2.3   NSEC Record Caching  . . . . . . . . . . . . . . . . .  8
+       4.2.4   Use of the AD bit  . . . . . . . . . . . . . . . . . .  8
+   5.  Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  Transition Issues  . . . . . . . . . . . . . . . . . . . . . . 10
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
+   10.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 12
+   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     11.1  Normative References . . . . . . . . . . . . . . . . . . . 13
+     11.2  Informative References . . . . . . . . . . . . . . . . . . 13
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
+   A.  Implementing Opt-In using "Views"  . . . . . . . . . . . . . . 14
+       Intellectual Property and Copyright Statements . . . . . . . . 16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 2]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+1.  Definitions and Terminology
+
+   Throughout this document, familiarity with the DNS system (RFC 1035
+   [1]), DNS security extensions ([3], [4], and [5], referred to in this
+   document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090
+   [10]) is assumed.
+
+   The following abbreviations and terms are used in this document:
+
+   RR: is used to refer to a DNS resource record.
+   RRset: refers to a Resource Record Set, as defined by [8].  In this
+      document, the RRset is also defined to include the covering RRSIG
+      records, if any exist.
+   signed name: refers to a DNS name that has, at minimum, a (signed)
+      NSEC record.
+   unsigned name: refers to a DNS name that does not (at least) have a
+      NSEC record.
+   covering NSEC record/RRset: is the NSEC record used to prove
+      (non)existence of a particular name or RRset.  This means that for
+      a RRset or name 'N', the covering NSEC 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.
+   secure delegation: refers to a signed name containing a delegation
+      (NS RRset), and a signed DS RRset, signifying a delegation to a
+      signed subzone.
+   insecure delegation: refers to a signed name containing a delegation
+      (NS RRset), but lacking a DS RRset, signifying a delegation to an
+      unsigned subzone.
+   Opt-In insecure delegation: refers to an unsigned name containing
+      only a delegation NS RRset.  The covering NSEC record uses the
+      Opt-In methodology described in this document.
+
+   The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [7].
+
+2.  Overview
+
+   The cost to cryptographically secure delegations to unsigned zones is
+   high for large delegation-centric zones and zones where insecure
+   delegations will be updated rapidly.  For these zones, the costs of
+   maintaining the NSEC record chain may be extremely high relative to
+   the gain of cryptographically authenticating existence of unsecured
+   zones.
+
+   This document describes an experimental method of eliminating the
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 3]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   superfluous cryptography present in secure delegations to unsigned
+   zones.  Using "Opt-In", a zone administrator can choose to remove
+   insecure delegations from the NSEC chain.  This is accomplished by
+   extending the semantics of the NSEC record by using a redundant bit
+   in the type map.
+
+3.  Experimental Status
+
+   This document describes an EXPERIMENTAL extension to DNSSEC.  It
+   interoperates with non-experimental DNSSEC using the technique
+   described in [6].  This experiment is identified with the following
+   private algorithms (using algorithm 253):
+
+   "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA,
+      and
+   "5.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5,
+      RSASHA1.
+
+   Servers wishing to sign and serve zones that utilize Opt-In MUST sign
+   the zone with only one or more of these private algorithms.  This
+   requires the signing tools and servers to support private algorithms,
+   as well as Opt-In.
+
+   Resolvers wishing to validate Opt-In zones MUST only do so when the
+   zone is only signed using one or more of these private algorithms.
+
+   The remainder of this document assumes that the servers and resolvers
+   involved are aware of and are involved in this experiment.
+
+4.  Protocol Additions
+
+   In DNSSEC, delegation NS RRsets are not signed, but are instead
+   accompanied by a NSEC RRset of the same name and (possibly) a DS
+   record.  The security status of the subzone is determined by the
+   presence or absence of the DS RRset, cryptographically proven by the
+   NSEC record.  Opt-In expands this definition by allowing insecure
+   delegations to exist within an otherwise signed zone without the
+   corresponding NSEC record at the delegation's owner name.  These
+   insecure delegations are proven insecure by using a covering NSEC
+   record.
+
+   Since this represents a change of the interpretation of NSEC records,
+   resolvers must be able to distinguish between RFC standard DNSSEC
+   NSEC records and Opt-In NSEC records.  This is accomplished by
+   "tagging" the NSEC records that cover (or potentially cover) insecure
+   delegation nodes.  This tag is indicated by the absence of the NSEC
+   bit in the type map.  Since the NSEC bit in the type map merely
+   indicates the existence of the record itself, this bit is redundant
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 4]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   and safe for use as a tag.
+
+   An Opt-In tagged NSEC record does not assert the (non)existence of
+   the delegations that it covers (except for a delegation with the same
+   name).  This allows for the addition or removal of these delegations
+   without recalculating or resigning records in the NSEC chain.
+   However, Opt-In tagged NSEC records do assert the (non)existence of
+   other RRsets.
+
+   An Opt-In NSEC record MAY have the same name as an insecure
+   delegation.  In this case, the delegation is proven insecure by the
+   lack of a DS bit in type map and the signed NSEC record does assert
+   the existence of the delegation.
+
+   Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC
+   records and standard DNSSEC NSEC records.  If a NSEC record is not
+   Opt-In, there MUST NOT be any insecure delegations (or any other
+   records) between it and the RRsets indicated by the 'next domain
+   name' in the NSEC RDATA.  If it is Opt-In, there MUST only be
+   insecure delegations between it and the next node indicated by the
+   'next domain name' in the NSEC RDATA.
+
+   In summary,
+
+   o  An Opt-In NSEC type is identified by a zero-valued (or not-
+      specified) NSEC bit in the type bit map of the NSEC record.
+   o  A RFC2535bis NSEC type is identified by a one-valued NSEC bit in
+      the type bit map of the NSEC record.
+
+   and,
+
+   o  An Opt-In NSEC 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 NSEC record does assert the (non)existence of RRsets
+      with the same owner name.
+
+4.1  Server Considerations
+
+   Opt-In imposes some new requirements on authoritative DNS servers.
+
+4.1.1  Delegations Only
+
+   This specification dictates that only insecure delegations may exist
+   between the owner and "next" names of an Opt-In tagged NSEC record.
+   Signing tools SHOULD NOT generate signed zones that violate this
+   restriction.  Servers SHOULD refuse to load and/or serve zones that
+   violate this restriction.  Servers also SHOULD reject AXFR or IXFR
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 5]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   responses that violate this restriction.
+
+4.1.2  Insecure Delegation Responses
+
+   When returning an Opt-In insecure delegation, the server MUST return
+   the covering NSEC RRset in the Authority section.
+
+   In standard DNSSEC, NSEC records already must be returned along with
+   the insecure delegation.  The primary difference that this proposal
+   introduces is that the Opt-In tagged NSEC record will have a
+   different owner name from the delegation RRset.  This may require
+   implementations to search for the covering NSEC RRset.
+
+4.1.3  Wildcards and Opt-In
+
+   Standard DNSSEC describes the practice of returning NSEC records to
+   prove the non-existence of an applicable wildcard in non-existent
+   name responses.  This NSEC record can be described as a "negative
+   wildcard proof".  The use of Opt-In NSEC records changes the
+   necessity for this practice.  For non-existent name responses when
+   the query name (qname) is covered by an Opt-In tagged NSEC record,
+   servers MAY choose to omit the wildcard proof record, and clients
+   MUST NOT treat the absence of this NSEC record as a validation error.
+
+   The intent of the standard DNSSEC 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"
+       NSEC record.
+   2.  No applicable wildcard exists.  This is done by returning a NSEC
+       record proving that the wildcard does not exist (this is the
+       negative wildcard proof).
+
+   However, if the NSEC record covering the exact qname is an Opt-In
+   NSEC 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 NSEC record is not useful.
+
+   The negative wildcard proof is 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.
+
+   The presence of an Opt-In tagged NSEC record does not change the
+   practice of returning a NSEC along with a wildcard expansion.  Even
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 6]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   though the Opt-In NSEC 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.
+
+4.1.4  Dynamic Update
+
+   Opt-In changes the semantics of Secure DNS Dynamic Update [9].  In
+   particular, it introduces the need for rules that describe when to
+   add or remove a delegation name from the NSEC chain.  This document
+   does not attempt to define these rules.  Until these rules are
+   defined, servers MUST NOT process DNS Dynamic Update requests against
+   zones that use Opt-In NSEC records.  Servers SHOULD return responses
+   to update requests with RCODE=REFUSED.
+
+4.2  Client Considerations
+
+   Opt-In imposes some new requirements on security-aware resolvers
+   (caching or otherwise).
+
+4.2.1  Delegations Only
+
+   As stated in the "Server Considerations" section above, this
+   specification restricts the namespace covered by Opt-In tagged NSEC
+   records to insecure delegations only.  Thus, resolvers MUST reject as
+   invalid any records that fall within an Opt-In NSEC record's span
+   that are not NS records or corresponding glue records.
+
+4.2.2  Validation Process Changes
+
+   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 NSEC 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:
+
+   o  In standard DNSSEC, the security status is proven by the existence
+      or absence of a DS RRset at the same name as the delegation.  The
+      existence of the DS RRset indicates that the referred-to zone is
+      signed.  The absence of the DS RRset is proven using a verified
+      NSEC record of the same name that does not have the DS bit set in
+      the type map.  This NSEC record MAY also be tagged as Opt-In.
+   o  Using Opt-In, the security status is proven by the existence of a
+      DS record (for signed) or the presence of a verified Opt-In tagged
+      NSEC record that covers the delegation name.  That is, the NSEC
+      record does not have the NSEC bit set in the type map, and the
+      delegation name falls between the NSEC's owner and "next" name.
+
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 7]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   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 referred-to subzone is signed
+   or unsigned.
+
+   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 NSEC record, the resolver MUST NOT require proof (in the form
+   of a NSEC record) that a wildcard did not exist.
+
+4.2.3  NSEC Record Caching
+
+   Caching resolvers MUST be able to retrieve the appropriate covering
+   Opt-In NSEC record when returning referrals that need them.  This
+   requirement differs from standard DNSSEC in that the covering NSEC
+   will not have the same owner name as the delegation.  Some
+   implementations may have to use new methods for finding these NSEC
+   records.
+
+4.2.4  Use of the AD bit
+
+   The AD bit, as defined by [2] and [5], MUST NOT be set when:
+
+   o  sending a Name Error (RCODE=3) response where the covering NSEC is
+      tagged as Opt-In.
+   o  sending an Opt-In insecure delegation response, unless the
+      covering (Opt-In) NSEC record's owner name equals the delegation
+      name.
+
+   This rule is based on what the Opt-In NSEC record actually proves:
+   for names that exist between the Opt-In NSEC record's owner and
+   "next" names, the Opt-In NSEC 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.
+
+5.  Benefits
+
+   Using Opt-In allows administrators of large and/or changing
+   delegation-centric zones to minimize the overhead involved in
+   maintaining the security of the zone.
+
+   Opt-In accomplishes this by eliminating the need for NSEC records for
+   insecure delegations.  This, in a zone with a large number of
+   delegations to unsigned subzones, can lead to substantial space
+   savings (both in memory and on disk).  Additionally, Opt-In allows
+   for the addition or removal of insecure delegations without modifying
+   the NSEC record chain.  Zones that are frequently updating insecure
+   delegations (e.g., TLDs) can avoid the substantial overhead of
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 8]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   modifying and resigning the affected NSEC records.
+
+6.  Example
+
+   Consider the zone EXAMPLE, shown below.  This is a zone where all of
+   the NSEC records are tagged as Opt-In.
+
+   Example A: Fully Opt-In Zone.
+
+         EXAMPLE.               SOA    ...
+         EXAMPLE.               RRSIG  SOA ...
+         EXAMPLE.               NS     FIRST-SECURE.EXAMPLE.
+         EXAMPLE.               RRSIG  NS ...
+         EXAMPLE.               DNSKEY ...
+         EXAMPLE.               RRSIG  DNSKEY ...
+         EXAMPLE.               NSEC   FIRST-SECURE.EXAMPLE. (
+                                       SOA NS RRSIG DNSKEY )
+         EXAMPLE.               RRSIG  NSEC ...
+
+         FIRST-SECURE.EXAMPLE.  A      ...
+         FIRST-SECURE.EXAMPLE.  RRSIG  A ...
+         FIRST-SECURE.EXAMPLE.  NSEC   NOT-SECURE-2.EXAMPLE. A RRSIG
+         FIRST-SECURE.EXAMPLE.  RRSIG  NSEC ...
+
+         NOT-SECURE.EXAMPLE.    NS     NS.NOT-SECURE.EXAMPLE.
+         NS.NOT-SECURE.EXAMPLE. A      ...
+
+         NOT-SECURE-2.EXAMPLE.  NS     NS.NOT-SECURE.EXAMPLE.
+         NOT-SECURE-2.EXAMPLE   NSEC   SECOND-SECURE.EXAMPLE NS RRSIG
+         NOT-SECURE-2.EXAMPLE   RRSIG  NSEC ...
+
+         SECOND-SECURE.EXAMPLE. NS     NS.ELSEWHERE.
+         SECOND-SECURE.EXAMPLE. DS     ...
+         SECOND-SECURE.EXAMPLE. RRSIG  DS ...
+         SECOND-SECURE.EXAMPLE. NSEC   EXAMPLE. NS RRSIG DNSKEY
+         SECOND-SECURE.EXAMPLE. RRSIG  NSEC ...
+
+         UNSIGNED.EXAMPLE.      NS     NS.UNSIGNED.EXAMPLE.
+         NS.UNSIGNED.EXAMPLE.   A      ...
+
+
+   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 DNSSEC response.
+
+   A query for a nonexistent RRset will result in a response that
+   differs from standard DNSSEC by: the NSEC record will be tagged as
+   Opt-In, there may be no NSEC record proving the non-existence of a
+
+
+
+Arends, et al.          Expires January 19, 2006                [Page 9]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   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-In NSEC record to prove that it is not secure.
+
+   Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE.  A
+
+
+         RCODE=NOERROR, AD=0
+
+         Answer Section:
+
+         Authority Section:
+         UNSIGNED.EXAMPLE.      NS     NS.UNSIGNED.EXAMPLE
+         SECOND-SECURE.EXAMPLE. NSEC   EXAMPLE. NS RRSIG DS
+         SECOND-SECURE.EXAMPLE. RRSIG  NSEC ...
+
+         Additional Section:
+         NS.UNSIGNED.EXAMPLE.   A      ...
+
+   In the Example A.1 zone, the EXAMPLE. node MAY use either style of
+   NSEC record, because there are no insecure delegations that occur
+   between it and the next node, FIRST-SECURE.EXAMPLE.  In other words,
+   Example A would still be a valid zone if the NSEC record for EXAMPLE.
+   was changed to the following RR:
+
+         EXAMPLE.               NSEC   FIRST-SECURE.EXAMPLE. (SOA NS
+                                       RRSIG DNSKEY NSEC )
+
+   However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND-
+   SECURE.EXAMPLE.)  MUST be tagged as Opt-In because there are insecure
+   delegations in the range they define.  (NOT-SECURE.EXAMPLE. and
+   UNSIGNED.EXAMPLE., respectively).
+
+   NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is
+   part of the NSEC chain and also covered by an Opt-In tagged NSEC
+   record.  Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be
+   removed from the zone without modifying and resigning the prior NSEC
+   record.  Delegations with names that fall between NOT-SECURE-
+   2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without
+   resigning any NSEC records.
+
+7.  Transition Issues
+
+   Opt-In is not backwards compatible with standard DNSSEC and is
+   considered experimental.  Standard DNSSEC compliant implementations
+   would not recognize Opt-In tagged NSEC records as different from
+
+
+
+Arends, et al.          Expires January 19, 2006               [Page 10]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   standard NSEC records.  Because of this, standard DNSSEC
+   implementations, if they were to validate Opt-In style responses,
+   would reject all Opt-In insecure delegations within a zone as
+   invalid.  However, by only signing with private algorithms, standard
+   DNSSEC implementations will treat Opt-In responses as unsigned.
+
+   It should be noted that all elements in the resolution path between
+   (and including) the validator and the authoritative name server must
+   be aware of the Opt-In experiment and implement the Opt-In semantics
+   for successful validation to be possible.  In particular, this
+   includes any caching middleboxes between the validator and
+   authoritative name server.
+
+8.  Security Considerations
+
+   Opt-In allows for unsigned names, in the form of delegations to
+   unsigned subzones, to exist within an otherwise signed zone.  All
+   unsigned names are, by definition, insecure, and their validity or
+   existence cannot by cryptographically proven.
+
+   In general:
+
+   o  Records with unsigned names (whether existing or not) suffer from
+      the same vulnerabilities as records in an unsigned zone.  These
+      vulnerabilities are described in more detail in [12] (note in
+      particular sections 2.3, "Name Games" and 2.6, "Authenticated
+      Denial").
+   o  Records with signed names have the same security whether or not
+      Opt-In is used.
+
+   Note that with or without Opt-In, an insecure delegation may have its
+   contents undetectably altered by an attacker.  Because of this, the
+   primary difference in security that Opt-In introduces is the loss of
+   the ability to prove the existence or nonexistence of an insecure
+   delegation within the span of an Opt-In NSEC record.
+
+   In particular, this means that a malicious entity may be able to
+   insert or delete records with unsigned names.  These records are
+   normally NS records, but this also includes signed wildcard
+   expansions (while the wildcard record itself is signed, its expanded
+   name is an unsigned name).
+
+   For example, if a resolver received the following response from the
+   example zone above:
+
+
+
+
+
+
+
+Arends, et al.          Expires January 19, 2006               [Page 11]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE.  A
+
+         RCODE=NOERROR
+
+         Answer Section:
+
+         Authority Section:
+         DOES-NOT-EXIST.EXAMPLE. NS     NS.FORGED.
+         EXAMPLE.                NSEC   FIRST-SECURE.EXAMPLE. SOA NS \
+                                        RRSIG DNSKEY
+         EXAMPLE.                RRSIG  NSEC ...
+
+         Additional Section:
+
+
+   The resolver would have no choice but to believe that the referral to
+   NS.FORGED. is valid.  If a wildcard existed that would have been
+   expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
+   have undetectably removed it and replaced it with the forged
+   delegation.
+
+   Note that being able to add a delegation is functionally equivalent
+   to being able to add any record type: an attacker merely has to forge
+   a delegation to nameserver under his/her control and place whatever
+   records needed at the subzone apex.
+
+   While in particular cases, this issue may not present a significant
+   security problem, in general it should not be lightly dismissed.
+   Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
+   In particular, zone signing tools SHOULD NOT default to Opt-In, and
+   MAY choose to not support Opt-In at all.
+
+9.  IANA Considerations
+
+   None.
+
+10.  Acknowledgments
+
+   The contributions, suggestions and remarks of the following persons
+   (in alphabetic order) to this draft are acknowledged:
+
+      Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf
+      Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning,
+      Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian
+      Wellington.
+
+11.  References
+
+
+
+
+Arends, et al.          Expires January 19, 2006               [Page 12]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+11.1  Normative References
+
+   [1]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [2]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
+        Authenticated Data (AD) bit", RFC 3655, November 2003.
+
+   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033,
+        March 2005.
+
+   [4]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+   [5]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions",
+        RFC 4035, March 2005.
+
+   [6]  Blacka, D., "DNSSEC Experiments",
+        draft-ietf-dnsext-dnssec-experiments-01 (work in progress),
+        July 2005.
+
+11.2  Informative References
+
+   [7]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [8]   Elz, R. and R. Bush, "Clarifications to the DNS Specification",
+         RFC 2181, July 1997.
+
+   [9]   Eastlake, D., "Secure Domain Name System Dynamic Update",
+         RFC 2137, April 1997.
+
+   [10]  Lewis, E., "DNS Security Extension Clarification on Zone
+         Status", RFC 3090, March 2001.
+
+   [11]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
+         December 2001.
+
+   [12]  Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
+         System (DNS)", RFC 3833, August 2004.
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 19, 2006               [Page 13]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+Authors' Addresses
+
+   Roy Arends
+   Telematica Instituut
+   Drienerlolaan 5
+   7522 NB  Enschede
+   NL
+
+   Email: roy.arends@telin.nl
+
+
+   Mark Kosters
+   Verisign, Inc.
+   21355 Ridgetop Circle
+   Dulles, VA  20166
+   US
+
+   Phone: +1 703 948 3200
+   Email: markk@verisign.com
+   URI:   http://www.verisignlabs.com
+
+
+   David Blacka
+   Verisign, Inc.
+   21355 Ridgetop Circle
+   Dulles, VA  20166
+   US
+
+   Phone: +1 703 948 3200
+   Email: davidb@verisign.com
+   URI:   http://www.verisignlabs.com
+
+Appendix A.  Implementing Opt-In using "Views"
+
+   In many cases, it may be convenient to implement an Opt-In zone by
+   combining two separately maintained "views" of a zone at request
+   time.  In this context, "view" refers to a particular version of a
+   zone, not to any specific DNS implementation feature.
+
+   In this scenario, one view is the secure view, the other is the
+   insecure (or legacy) view.  The secure view consists of an entirely
+   signed zone using Opt-In tagged NSEC records.  The insecure view
+   contains no DNSSEC information.  It is helpful, although not
+   necessary, for the secure view to be a subset (minus DNSSEC records)
+   of the insecure view.
+
+   In addition, the only RRsets that may solely exist in the insecure
+   view are non-zone-apex NS RRsets.  That is, all non-NS RRsets (and
+
+
+
+Arends, et al.          Expires January 19, 2006               [Page 14]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+   the zone apex NS RRset) MUST be signed and in the secure view.
+
+   These two views may be combined at request time to provide a virtual,
+   single Opt-In zone.  The following algorithm is used when responding
+   to each query:
+      V_A is the secure view as described above.
+      V_B is the insecure view as described above.
+      R_A is a response generated from V_A, following RFC 2535bis.
+      R_B is a response generated from V_B, following DNS resolution as
+      per RFC 1035 [1].
+      R_C is the response generated by combining R_A with R_B, as
+      described below.
+      A query is DNSSEC-aware if it either has the DO bit [11] turned
+      on, or is for a DNSSEC-specific record type.
+
+
+
+   1.  If V_A is a subset of V_B and the query is not DNSSEC-aware,
+       generate and return R_B, otherwise
+   2.  Generate R_A.
+   3.  If R_A's RCODE != NXDOMAIN, return R_A, otherwise
+   4.  Generate R_B and combine it with R_A to form R_C:
+          For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
+          records from R_A into R_B, EXCEPT the AUTHORITY section SOA
+          record, if R_B's RCODE = NOERROR.
+   5.  Return R_C.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.          Expires January 19, 2006               [Page 15]
+
+Internet-Draft                DNSSEC Opt-In                    July 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Arends, et al.          Expires January 19, 2006               [Page 16]
+

doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt

@@ -0,0 +1,839 @@
+
+DNS Extensions Working Group                                   R. Arends
+Internet-Draft                                      Telematica Instituut
+Expires: August 25, 2005                                         P. Koch
+                                                                DENIC eG
+                                                             J. Schlyter
+                                                                  NIC-SE
+                                                       February 21, 2005
+
+
+                Evaluating DNSSEC Transition Mechanisms
+                 draft-ietf-dnsext-dnssec-trans-02.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is subject to all provisions
+   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 25, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document collects and summarizes different proposals for
+   alternative and additional strategies for authenticated denial in DNS
+   responses, evaluates these proposals and gives a recommendation for a
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 1]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+   way forward.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Transition Mechanisms  . . . . . . . . . . . . . . . . . . . .  3
+     2.1   Mechanisms With Need of Updating DNSSEC-bis  . . . . . . .  4
+       2.1.1   Dynamic NSEC Synthesis . . . . . . . . . . . . . . . .  4
+       2.1.2   Add Versioning/Subtyping to Current NSEC . . . . . . .  5
+       2.1.3   Type Bit Map NSEC Indicator  . . . . . . . . . . . . .  6
+       2.1.4   New Apex Type  . . . . . . . . . . . . . . . . . . . .  6
+       2.1.5   NSEC White Lies  . . . . . . . . . . . . . . . . . . .  7
+       2.1.6   NSEC Optional via DNSSKEY Flag . . . . . . . . . . . .  8
+       2.1.7   New Answer Pseudo RR Type  . . . . . . . . . . . . . .  9
+       2.1.8   SIG(0) Based Authenticated Denial  . . . . . . . . . .  9
+     2.2   Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10
+       2.2.1   Partial Type-code and Signal Rollover  . . . . . . . . 10
+       2.2.2   A Complete Type-code and Signal Rollover . . . . . . . 11
+       2.2.3   Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11
+   3.  Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12
+   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
+   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     5.1   Normative References . . . . . . . . . . . . . . . . . . . 13
+     5.2   Informative References . . . . . . . . . . . . . . . . . . 13
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
+       Intellectual Property and Copyright Statements . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 2]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+1.  Introduction
+
+   This report shall document the process of dealing with the NSEC
+   walking problem late in the Last Call for
+   [I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol,
+   I-D.ietf-dnsext-dnssec-records].  It preserves some of the discussion
+   that took place in the DNSEXT WG during the first half of June 2004
+   as well as some additional ideas that came up subsequently.
+
+   This is an edited excerpt of the chairs' mail to the WG:
+      The working group consents on not including NSEC-alt in the
+      DNSSEC-bis documents.  The working group considers to take up
+      "prevention of zone enumeration" as a work item.
+      There may be multiple mechanisms to allow for co-existence with
+      DNSSEC-bis.  The chairs allow the working group a little over a
+      week (up to June 12, 2004) to come to consensus on a possible
+      modification to the document to enable gentle rollover.  If that
+      consensus cannot be reached the DNSSEC-bis documents will go out
+      as-is.
+
+   To ease the process of getting consensus, a summary of the proposed
+   solutions and analysis of the pros and cons were written during the
+   weekend.
+
+   This summary includes:
+
+      An inventory of the proposed mechanisms to make a transition to
+      future work on authenticated denial of existence.
+      List the known Pros and Cons, possibly provide new arguments, and
+      possible security considerations of these mechanisms.
+      Provide a recommendation on a way forward that is least disruptive
+      to the DNSSEC-bis specifications as they stand and keep an open
+      path to other methods for authenticated denial of existence.
+
+   The descriptions of the proposals in this document are coarse and do
+   not cover every detail necessary for implementation.  In any case,
+   documentation and further study is needed before implementaion and/or
+   deployment, including those which seem to be solely operational in
+   nature.
+
+2.  Transition Mechanisms
+
+   In the light of recent discussions and past proposals, we have found
+   several ways to allow for transition to future expansion of
+   authenticated denial.  We tried to illuminate the paths and pitfalls
+   in these ways forward.  Some proposals lead to a versioning of
+   DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other
+   proposals are 'clean' but may cause delay, while again others may be
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 3]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+   plain hacks.
+
+   Some paths do not introduce versioning, and might require the current
+   DNSSEC-bis documents to be fully updated to allow for extensions to
+   authenticated denial mechanisms.  Other paths introduce versioning
+   and do not (or minimally) require DNSSEC-bis documents to be updated,
+   allowing DNSSEC-bis to be deployed, while future versions can be
+   drafted independent from or partially depending on DNSSEC-bis.
+
+2.1  Mechanisms With Need of Updating DNSSEC-bis
+
+   Mechanisms in this category demand updates to the DNSSEC-bis document
+   set.
+
+2.1.1  Dynamic NSEC Synthesis
+
+   This proposal assumes that NSEC RRs and the authenticating RRSIG will
+   be generated dynamically to just cover the (non existent) query name.
+   The owner name is (the) one preceding the name queried for, the Next
+   Owner Name Field has the value of the Query Name Field + 1 (first
+   successor in canonical ordering).  A separate key (the normal ZSK or
+   a separate ZSK per authoritative server) would be used for RRSIGs on
+   NSEC RRs.  This is a defense against enumeration, though it has the
+   presumption of online signing.
+
+2.1.1.1  Coexistence and Migration
+
+   There is no change in interpretation other then that the next owner
+   name might or might not exist.
+
+2.1.1.2  Limitations
+
+   This introduces an unbalanced cost between query and response
+   generation due to dynamic generation of signatures.
+
+2.1.1.3  Amendments to DNSSEC-bis
+
+   The current DNSSEC-bis documents might need to be updated to indicate
+   that the next owner name might not be an existing name in the zone.
+   This is not a real change to the spec since implementers have been
+   warned not to synthesize with previously cached NSEC records.  A
+   specific bit to identify the dynamic signature generating key might
+   be useful as well, to prevent it from being used to fake positive
+   data.
+
+2.1.1.4  Cons
+
+   Unbalanced cost is a ground for DDoS.  Though this protects against
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 4]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+   enumeration, it is not really a path for versioning.
+
+2.1.1.5  Pros
+
+   Hardly any amendments to DNSSEC-bis.
+
+2.1.2  Add Versioning/Subtyping to Current NSEC
+
+   This proposal introduces versioning for the NSEC RR type (a.k.a.
+   subtyping) by adding a (one octet) version field to the NSEC RDATA.
+   Version number 0 is assigned to the current (DNSSEC-bis) meaning,
+   making this an 'Must Be Zero' (MBZ) for the to be published docset.
+
+2.1.2.1  Coexistence and Migration
+
+   Since the versioning is done inside the NSEC RR, different versions
+   may coexist.  However, depending on future methods, that may or may
+   not be useful inside a single zone.  Resolvers cannot ask for
+   specific NSEC versions but may be able to indicate version support by
+   means of a to be defined EDNS option bit.
+
+2.1.2.2  Limitations
+
+   There are no technical limitations, though it will cause delay to
+   allow testing of the (currently unknown) new NSEC interpretation.
+
+   Since the versioning and signaling is done inside the NSEC RR, future
+   methods will likely be restricted to a single RR type authenticated
+   denial (as opposed to e.g.  NSEC-alt, which currently proposes three
+   RR types).
+
+2.1.2.3  Amendments to DNSSEC-bis
+
+   Full Update of the current DNSSEC-bis documents to provide for new
+   fields in NSEC, while specifying behavior in case of unknown field
+   values.
+
+2.1.2.4  Cons
+
+   Though this is a clean and clear path without versioning DNSSEC, it
+   takes some time to design, gain consensus, update the current
+   dnssec-bis document, test and implement a new authenticated denial
+   record.
+
+2.1.2.5  Pros
+
+   Does not introduce an iteration to DNSSEC while providing a clear and
+   clean migration strategy.
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 5]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+2.1.3  Type Bit Map NSEC Indicator
+
+   Bits in the type-bit-map are reused or allocated to signify the
+   interpretation of NSEC.
+
+   This proposal assumes that future extensions make use of the existing
+   NSEC RDATA syntax, while it may need to change the interpretation of
+   the RDATA or introduce an alternative denial mechanism, invoked by
+   the specific type-bit-map-bits.
+
+2.1.3.1  Coexistence and migration
+
+   Old and new NSEC meaning could coexist, depending how the signaling
+   would be defined.  The bits for NXT, NSEC, RRSIG or other outdated RR
+   types are available  as well as those covering meta/query types or
+   types to be specifically allocated.
+
+2.1.3.2  Limitations
+
+   This mechanism uses an NSEC field that was not designed for that
+   purpose.  Similar methods were discussed during the Opt-In discussion
+   and the Silly-State discussion.
+
+2.1.3.3  Amendments to DNSSEC-bis
+
+   The specific type-bit-map-bits must be allocated and they need to be
+   specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis)
+   interpretation.  Also, behaviour of the resolver and validator must
+   be documented in case unknown values are encountered for the MBZ
+   field.  Currently the protocol document specifies that the validator
+   MUST ignore the setting of the NSEC and the RRSIG bits, while other
+   bits are only used for the specific purpose of the type-bit-map field
+
+2.1.3.4  Cons
+
+   The type-bit-map was not designed for this purpose.  It is a
+   straightforward hack.  Text in protocol section 5.4 was put in
+   specially to defend against this usage.
+
+2.1.3.5  Pros
+
+   No change needed to the on-the-wire protocol as specified in the
+   current docset.
+
+2.1.4  New Apex Type
+
+   This introduces a new Apex type (parallel to the zone's SOA)
+   indicating the DNSSEC version (or authenticated denial) used in or
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 6]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+   for this zone.
+
+2.1.4.1  Coexistence and Migration
+
+   Depending on the design of this new RR type multiple denial
+   mechanisms may coexist in a zone.  Old validators will not understand
+   and thus ignore the new type, so interpretation of the new NSEC
+   scheme may fail, negative responses may appear 'bogus'.
+
+2.1.4.2  Limitations
+
+   A record of this kind is likely to carry additional
+   feature/versioning indications unrelated to the current question of
+   authenticated denial.
+
+2.1.4.3  Amendments to DNSSEC-bis
+
+   The current DNSSEC-bis documents need to be updated to indicate that
+   the absence of this type indicates dnssec-bis, and that the (mere)
+   presence of this type indicated unknown versions.
+
+2.1.4.4  Cons
+
+   The only other 'zone' or 'apex' record is the SOA record.  Though
+   this proposal is not new, it is yet unknown how it might fulfill
+   authenticated denial extensions.  This new RR type would only provide
+   for a generalized signaling mechanism, not the new authenticated
+   denial scheme.  Since it is likely to be general in nature, due to
+   this generality consensus is not to be reached soon.
+
+2.1.4.5  Pros
+
+   This approach would allow for a lot of other per zone information to
+   be transported or signaled to both (slave) servers and resolvers.
+
+2.1.5  NSEC White Lies
+
+   This proposal disables one part of NSEC (the pointer part) by means
+   of a special target (root, apex, owner, ...), leaving intact only the
+   ability to authenticate denial of existence of RR sets, not denial of
+   existence of domain names (NXDOMAIN).  It may be necessary to have
+   one working NSEC to prove the absence of a wildcard.
+
+2.1.5.1  Coexistence and Migration
+
+   The NSEC target can be specified per RR, so standard NSEC and 'white
+   lie' NSEC can coexist in a zone.  There is no need for migration
+   because no versioning is introduced or intended.
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 7]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+2.1.5.2  Limitations
+
+   This proposal breaks the protocol and is applicable to certain types
+   of zones only (no wildcard, no deep names, delegation only).  Most of
+   the burden is put on the resolver side and operational consequences
+   are yet to be studied.
+
+2.1.5.3  Amendments to DNSSEC-bis
+
+   The current DNSSEC-bis documents need to be updated to indicate that
+   the NXDOMAIN responses may be insecure.
+
+2.1.5.4  Cons
+
+   Strictly speaking this breaks the protocol and doesn't fully fulfill
+   the requirements for authenticated denial of existence.  Security
+   implications need to be carefully documented: search path problems
+   (forged denial of existence may lead to wrong expansion of non-FQDNs
+   [RFC1535]) and replay attacks to deny existence of records.
+
+2.1.5.5  Pros
+
+   Hardly any amendments to DNSSEC-bis.  Operational "trick" that is
+   available anyway.
+
+2.1.6  NSEC Optional via DNSSKEY Flag
+
+   A new DNSKEY may be defined to declare NSEC optional per zone.
+
+2.1.6.1  Coexistence and Migration
+
+   Current resolvers/validators will not understand the Flag bit and
+   will have to treat negative responses as bogus.  Otherwise, no
+   migration path is needed since NSEC is simply turned off.
+
+2.1.6.2  Limitations
+
+   NSEC can only be made completely optional at the cost of being unable
+   to prove unsecure delegations (absence of a DS RR [RFC3658]).  A next
+   to this approach would just disable authenticated denial for
+   non-existence of nodes.
+
+2.1.6.3  Amendments to DNSSEC-bis
+
+   New DNSKEY Flag to be defined.  Resolver/Validator behaviour needs to
+   be specified in the light of absence of authenticated denial.
+
+
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 8]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+2.1.6.4  Cons
+
+   Doesn't fully meet requirements.  Operational consequences to be
+   studied.
+
+2.1.6.5  Pros
+
+   Official version of the "trick" presented in (8).  Operational
+   problems can be addressed during future work on validators.
+
+2.1.7  New Answer Pseudo RR Type
+
+   A new pseudo RR type may be defined that will be dynamically created
+   (and signed) by the responding authoritative server.  The RR in the
+   response will cover the QNAME, QCLASS and QTYPE and will authenticate
+   both denial of existence of name (NXDOMAIN) or RRset.
+
+2.1.7.1  Coexistence and Migration
+
+   Current resolvers/validators will not understand the pseudo RR and
+   will thus not be able to process negative responses so testified.  A
+   signaling or solicitation method would have to be specified.
+
+2.1.7.2  Limitations
+
+   This method can only be used with online keys and online signing
+   capacity.
+
+2.1.7.3  Amendments to DNSSEC-bis
+
+   Signaling method needs to be defined.
+
+2.1.7.4  Cons
+
+   Keys have to be held and processed online with all security
+   implications.  An additional flag for those keys identifying them as
+   online or negative answer only keys should be considered.
+
+2.1.7.5  Pros
+
+   Expands DNSSEC authentication to the RCODE.
+
+2.1.8  SIG(0) Based Authenticated Denial
+
+
+2.1.8.1  Coexistence and Migration
+
+
+
+
+
+Arends, et al.           Expires August 25, 2005                [Page 9]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+2.1.8.2  Limitations
+
+
+2.1.8.3  Amendments to DNSSEC-bis
+
+
+2.1.8.4  Cons
+
+
+2.1.8.5  Pros
+
+
+2.2  Mechanisms Without Need of Updating DNSSEC-bis
+
+2.2.1  Partial Type-code and Signal Rollover
+
+   Carefully crafted type code/signal rollover to define a new
+   authenticated denial space that extends/replaces DNSSEC-bis
+   authenticated denial space.  This particular path is illuminated by
+   Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com>
+   posted to <namedroppers@ops.ietf.org> 2004-06-02.
+
+2.2.1.1  Coexistence and Migration
+
+   To protect the current resolver for future versions, a new DNSSEC-OK
+   bit must be allocated to make clear it does or does not understand
+   the future version.  Also, a new DS type needs to be allocated to
+   allow differentiation between a current signed delegation and a
+   'future' signed delegation.  Also, current NSEC needs to be rolled
+   into a new authenticated denial type.
+
+2.2.1.2  Limitations
+
+   None.
+
+2.2.1.3  Amendments to DNSSEC-bis
+
+   None.
+
+2.2.1.4  Cons
+
+   It is cumbersome to carefully craft an TCR that 'just fits'.  The
+   DNSSEC-bis protocol has many 'borderline' cases that needs special
+   consideration.  It might be easier to do a full TCR, since a few of
+   the types and signals need upgrading anyway.
+
+
+
+
+
+
+Arends, et al.           Expires August 25, 2005               [Page 10]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+2.2.1.5  Pros
+
+   Graceful adoption of future versions of NSEC, while there are no
+   amendments to DNSSEC-bis.
+
+2.2.2  A Complete Type-code and Signal Rollover
+
+   A new DNSSEC space is defined which can exist independent of current
+   DNSSEC-bis space.
+
+   This proposal assumes that all current DNSSEC type-codes
+   (RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any
+   future versions of DNSSEC.  Any future version of DNSSEC has its own
+   types to allow for keys, signatures, authenticated denial, etcetera.
+
+2.2.2.1  Coexistence and Migration
+
+   Both spaces can co-exist.  They can be made completely orthogonal.
+
+2.2.2.2  Limitations
+
+   None.
+
+2.2.2.3  Amendments to DNSSEC-bis
+
+   None.
+
+2.2.2.4  Cons
+
+   With this path we abandon the current DNSSEC-bis.  Though it is easy
+   to role specific well-known and well-tested parts into the re-write,
+   once deployment has started this path is very expensive for
+   implementers, registries, registrars and registrants as well as
+   resolvers/users.  A TCR is not to be expected to occur frequently, so
+   while a next generation authenticated denial may be enabled by a TCR,
+   it is likely that that TCR will only be agreed upon if it serves a
+   whole basket of changes or additions.  A quick introduction of
+   NSEC-ng should not be expected from this path.
+
+2.2.2.5  Pros
+
+   No amendments/changes to current DNSSEC-bis docset needed.  It is
+   always there as last resort.
+
+2.2.3  Unknown Algorithm in RRSIG
+
+   This proposal assumes that future extensions make use of the existing
+   NSEC RDATA syntax, while it may need to change the interpretation of
+
+
+
+Arends, et al.           Expires August 25, 2005               [Page 11]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+   the RDATA or introduce an alternative denial mechanism, invoked by
+   the specific unknown signing algorithm.  The different interpretation
+   would be signaled by use of different signature algorithms in the
+   RRSIG records covering the NSEC RRs.
+
+   When an entire zone is signed with a single unknown algorithm, it
+   will cause implementations that follow current dnssec-bis documents
+   to treat individual RRsets as unsigned.
+
+2.2.3.1  Coexistence and migration
+
+   Old and new NSEC RDATA interpretation or known and unknown Signatures
+   can NOT coexist in a zone since signatures cover complete (NSEC)
+   RRSets.
+
+2.2.3.2  Limitations
+
+   Validating resolvers agnostic of new interpretation will treat the
+   NSEC RRset as "not signed".  This affects wildcard and non-existence
+   proof, as well as proof for (un)secured delegations.  Also, all
+   positive signatures (RRSIGs on RRSets other than DS, NSEC) appear
+   insecure/bogus to an old validator.
+
+   The algorithm version space is split for each future version of
+   DNSSEC.  Violation of the 'modular components' concept.  We use the
+   'validator' to protect the 'resolver' from unknown interpretations.
+
+2.2.3.3  Amendments to DNSSEC-bis
+
+   None.
+
+2.2.3.4  Cons
+
+   The algorithm field was not designed for this purpose.  This is a
+   straightforward hack.
+
+2.2.3.5  Pros
+
+   No amendments/changes to current DNSSEC-bis docset needed.
+
+3.  Recommendation
+
+   The authors recommend that the working group commits to and starts
+   work on a partial TCR, allowing graceful transition towards a future
+   version of NSEC.  Meanwhile, to accomodate the need for an
+   immediately, temporary, solution against zone-traversal, we recommend
+   On-Demand NSEC synthesis.
+
+
+
+
+Arends, et al.           Expires August 25, 2005               [Page 12]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+   This approach does not require any mandatory changes to DNSSEC-bis,
+   does not violate the protocol and fulfills the requirements.  As a
+   side effect, it moves the cost of implementation and deployment to
+   the users (zone owners) of this mechanism.
+
+4.  Acknowledgements
+
+   The authors would like to thank Sam Weiler and Mark Andrews for their
+   input and constructive comments.
+
+5.  References
+
+5.1  Normative References
+
+   [I-D.ietf-dnsext-dnssec-intro]
+              Arends, R., Austein, R., Massey, D., Larson, M. and S.
+              Rose, "DNS Security Introduction and Requirements",
+              Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October
+              2004.
+
+   [I-D.ietf-dnsext-dnssec-protocol]
+              Arends, R., "Protocol Modifications for the DNS Security
+              Extensions",
+              Internet-Draft draft-ietf-dnsext-dnssec-protocol-09,
+              October 2004.
+
+   [I-D.ietf-dnsext-dnssec-records]
+              Arends, R., "Resource Records for the DNS Security
+              Extensions",
+              Internet-Draft draft-ietf-dnsext-dnssec-records-11,
+              October 2004.
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (
+              SIG(0)s)", RFC 2931, September 2000.
+
+5.2  Informative References
+
+   [RFC1535]  Gavron, E., "A Security Problem and Proposed Correction
+              With Widely Deployed DNS Software", RFC 1535, October
+              1993.
+
+   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
+
+
+
+Arends, et al.           Expires August 25, 2005               [Page 13]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+              RFC 2535, March 1999.
+
+   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
+              June 1999.
+
+   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
+              (RR)", RFC 3658, December 2003.
+
+
+Authors' Addresses
+
+   Roy Arends
+   Telematica Instituut
+   Brouwerijstraat 1
+   Enschede  7523 XC
+   The Netherlands
+
+   Phone: +31 53 4850485
+   Email: roy.arends@telin.nl
+
+
+   Peter Koch
+   DENIC eG
+   Wiesenh"uttenplatz 26
+   Frankfurt  60329
+   Germany
+
+   Phone: +49 69 27235 0
+   Email: pk@DENIC.DE
+
+
+   Jakob Schlyter
+   NIC-SE
+   Box 5774
+   Stockholm  SE-114 87
+   Sweden
+
+   Email: jakob@nic.se
+   URI:   http://www.nic.se/
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.           Expires August 25, 2005               [Page 14]
+
+Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Arends, et al.           Expires August 25, 2005               [Page 15]
+
+

doc/draft/draft-ietf-dnsext-ds-sha256-05.txt

@@ -0,0 +1,504 @@
+
+
+
+Network Working Group                                        W. Hardaker
+Internet-Draft                                                    Sparta
+Expires: August 25, 2006                               February 21, 2006
+
+
+ Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
+                   draft-ietf-dnsext-ds-sha256-05.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on August 25, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document specifies how to use the SHA-256 digest type in DNS
+   Delegation Signer (DS) Resource Records (RRs).  DS records, when
+   stored in a parent zone, point to key signing DNSKEY key(s) in a
+   child zone.
+
+
+
+
+
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 1]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.  Implementing the SHA-256 algorithm for DS record support  . . . 3
+     2.1.  DS record field values  . . . . . . . . . . . . . . . . . . 3
+     2.2.  DS Record with SHA-256 Wire Format  . . . . . . . . . . . . 3
+     2.3.  Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4
+   3.  Implementation Requirements . . . . . . . . . . . . . . . . . . 4
+   4.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 4
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+     6.1.  Potential Digest Type Downgrade Attacks . . . . . . . . . . 5
+     6.2.  SHA-1 vs SHA-256 Considerations for DS Records  . . . . . . 6
+   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
+     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
+   Intellectual Property and Copyright Statements  . . . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 2]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+1.  Introduction
+
+   The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
+   zones to distribute a cryptographic digest of a child's Key Signing
+   Key (KSK) DNSKEY RR.  The DS RRset is signed by at least one of the
+   parent zone's private zone data signing keys for each algorithm in
+   use by the parent.  Each signature is published in an RRSIG resource
+   record, owned by the same domain as the DS RRset and with a type
+   covered of DS.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+2.  Implementing the SHA-256 algorithm for DS record support
+
+   This document specifies that the digest type code [XXX: To be
+   assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256]
+   [SHA256CODE] for use within DS records.  The results of the digest
+   algorithm MUST NOT be truncated and the entire 32 byte digest result
+   is to be published in the DS record.
+
+2.1.  DS record field values
+
+   Using the SHA-256 digest algorithm within a DS record will make use
+   of the following DS-record fields:
+
+   Digest type: [XXX: To be assigned by IANA; likely 2]
+
+   Digest: A SHA-256 bit digest value calculated by using the following
+      formula ("|" denotes concatenation).  The resulting value is not
+      truncated and the entire 32 byte result is to used in the
+      resulting DS record and related calculations.
+
+        digest = SHA_256(DNSKEY owner name | DNSKEY RDATA)
+
+      where DNSKEY RDATA is defined by [RFC4034] as:
+
+        DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key
+
+   The Key Tag field and Algorithm fields remain unchanged by this
+   document and are specified in the [RFC4034] specification.
+
+2.2.  DS Record with SHA-256 Wire Format
+
+   The resulting on-the-wire format for the resulting DS record will be
+   [XXX: IANA assignment should replace the 2 below]:
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 3]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+                           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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           Key Tag             |  Algorithm    | DigestType=2  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      /                                                               /
+      /            Digest  (length for SHA-256 is 32 bytes)           /
+      /                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
+2.3.  Example DS Record Using SHA-256
+
+   The following is an example DNSKEY and matching DS record.  This
+   DNSKEY record comes from the example DNSKEY/DS records found in
+   section 5.4 of [RFC4034].
+
+   The DNSKEY record:
+
+   dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
+                                                fwJr1AYtsmx3TGkJaNXVbfi/
+                                                2pHm822aJ5iI9BMzNXxeYCmZ
+                                                DRD99WYwYqUSdjMmmAphXdvx
+                                                egXd/M5+X7OrzKBaMbCVdFLU
+                                                Uh6DhweJBjEVv5f2wwjM9Xzc
+                                                nOf+EPbtG9DMBmADjFDc2w/r
+                                                ljwvFw==
+                                                ) ;  key id = 60485
+
+   The resulting DS record covering the above DNSKEY record using a SHA-
+   256 digest: [RFC Editor: please replace XXX with the assigned digest
+   type (likely 2):]
+
+   dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C
+                                                CEB1E3E0614B93C4F9E99B83
+                                                83F6A1E4469DA50A )
+
+
+3.  Implementation Requirements
+
+   Implementations MUST support the use of the SHA-256 algorithm in DS
+   RRs.  Validator implementations SHOULD ignore DS RRs containing SHA-1
+   digests if DS RRs with SHA-256 digests are present in the DS RRset.
+
+
+4.  Deployment Considerations
+
+   If a validator does not support the SHA-256 digest type and no other
+   DS RR exists in a zone's DS RRset with a supported digest type, then
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 4]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+   the validator has no supported authentication path leading from the
+   parent to the child.  The resolver should treat this case as it would
+   the case of an authenticated NSEC RRset proving that no DS RRset
+   exists, as described in [RFC4035], section 5.2.
+
+   Because zone administrators can not control the deployment speed of
+   support for SHA-256 in validators that may be referencing any of
+   their zones, zone operators should consider deploying both SHA-1 and
+   SHA-256 based DS records.  This should be done for every DNSKEY for
+   which DS records are being generated.  Whether to make use of both
+   digest types and for how long is a policy decision that extends
+   beyond the scope of this document.
+
+
+5.  IANA Considerations
+
+   Only one IANA action is required by this document:
+
+   The Digest Type to be used for supporting SHA-256 within DS records
+   needs to be assigned by IANA.  This document requests that the Digest
+   Type value of 2 be assigned to the SHA-256 digest algorithm.
+
+   At the time of this writing, the current digest types assigned for
+   use in DS records are as follows:
+
+      VALUE     Digest Type          Status
+        0       Reserved                -
+        1       SHA-1                MANDATORY
+        2       SHA-256              MANDATORY
+      3-255    Unassigned               -
+
+
+6.  Security Considerations
+
+6.1.  Potential Digest Type Downgrade Attacks
+
+   A downgrade attack from a stronger digest type to a weaker one is
+   possible if all of the following are true:
+
+   o  A zone includes multiple DS records for a given child's DNSKEY,
+      each of which use a different digest type.
+
+   o  A validator accepts a weaker digest even if a stronger one is
+      present but invalid.
+
+   For example, if the following conditions are all true:
+
+
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 5]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+   o  Both SHA-1 and SHA-256 based digests are published in DS records
+      within a parent zone for a given child zone's DNSKEY.
+
+   o  The DS record with the SHA-1 digest matches the digest computed
+      using the child zone's DNSKEY.
+
+   o  The DS record with the SHA-256 digest fails to match the digest
+      computed using the child zone's DNSKEY.
+
+   Then if the validator accepts the above situation as secure then this
+   can be used as a downgrade attack since the stronger SHA-256 digest
+   is ignored.
+
+6.2.  SHA-1 vs SHA-256 Considerations for DS Records
+
+   Users of DNSSEC are encouraged to deploy SHA-256 as soon as software
+   implementations allow for it.  SHA-256 is widely believed to be more
+   resilient to attack than SHA-1, and confidence in SHA-1's strength is
+   being eroded by recently-announced attacks.  Regardless of whether or
+   not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
+   time of this writing) that SHA-256 is the better choice for use in DS
+   records.
+
+   At the time of this publication, the SHA-256 digest algorithm is
+   considered sufficiently strong for the immediate future.  It is also
+   considered sufficient for use in DNSSEC DS RRs for the immediate
+   future.  However, future published attacks may weaken the usability
+   of this algorithm within the DS RRs.  It is beyond the scope of this
+   document to speculate extensively on the cryptographic strength of
+   the SHA-256 digest algorithm.
+
+   Likewise, it is also beyond the scope of this document to specify
+   whether or for how long SHA-1 based DS records should be
+   simultaneously published alongside SHA-256 based DS records.
+
+
+7.  Acknowledgments
+
+   This document is a minor extension to the existing DNSSEC documents
+   and those authors are gratefully appreciated for the hard work that
+   went into the base documents.
+
+   The following people contributed to portions of this document in some
+   fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman,
+   Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam
+   Weiler.
+
+
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 6]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, March 2005.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+   [SHA256]   National Institute of Standards and Technology, "Secure
+              Hash Algorithm. NIST FIPS 180-2", August 2002.
+
+8.2.  Informative References
+
+   [SHA256CODE]
+              Eastlake, D., "US Secure Hash Algorithms (SHA)",
+              June 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 7]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+Author's Address
+
+   Wes Hardaker
+   Sparta
+   P.O. Box 382
+   Davis, CA  95617
+   US
+
+   Email: hardaker@tislabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 8]
+
+Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Hardaker                 Expires August 25, 2006                [Page 9]
+

doc/draft/draft-ietf-dnsext-forgery-resilience-02.txt

@@ -0,0 +1,17 @@
+
+This Internet-Draft, draft-ietf-dnsext-forgery-resilience-01.txt, has expired, and has been deleted 
+from the Internet-Drafts directory.  An Internet-Draft expires 185 days from 
+the date that it is posted unless it is replaced by an updated version, or the
+Secretariat has been notified that the document is under official review by the
+IESG or has been passed to the RFC Editor for review and/or publication as an 
+RFC.  This Internet-Draft was not published as an RFC.
+
+Internet-Drafts are not archival documents, and copies of Internet-Drafts that have 
+been deleted from the directory are not available.  The Secretariat does not have 
+any information regarding the future plans of the author(s) or working group, if 
+applicable, with respect to this deleted Internet-Draft.  For more information, or 
+to request a copy of the document, please contact the author(s) directly.
+
+Draft Author(s):
+Remco van Mook <remco@virtu.nl>,
+Bert Hubert <bert.hubert@netherlabs.nl>

doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt

@@ -0,0 +1,560 @@
+
+DNS Extensions                                                O. Kolkman
+Internet-Draft                                                  RIPE NCC
+Expires: June 17, 2004                                       J. Schlyter
+
+                                                                E. Lewis
+                                                                    ARIN
+                                                       December 18, 2003
+
+
+                   DNSKEY RR Secure Entry Point Flag
+              draft-ietf-dnsext-keyrr-key-signing-flag-12
+
+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 June 17, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+   With the Delegation Signer (DS) resource record the concept of a
+   public key acting as a secure entry point has been introduced. During
+   exchanges of public keys with the parent there is a need to
+   differentiate secure entry point keys from other public keys in the
+   DNSKEY resource record (RR) set.  A flag bit in the DNSKEY RR is
+   defined to indicate that DNSKEY is to be used as a secure entry
+   point. The flag bit is intended to assist in operational procedures
+   to correctly generate DS resource records, or to indicate what
+   DNSKEYs are intended for static configuration. The flag bit is not to
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 1]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+   be used in the DNS verification protocol. This document updates RFC
+   2535 and RFC 3445.
+
+Table of Contents
+
+   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2. The Secure Entry Point (SEP) Flag  . . . . . . . . . . . . . . . 4
+   3. DNSSEC Protocol Changes  . . . . . . . . . . . . . . . . . . . . 5
+   4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 5
+   5. Security Considerations  . . . . . . . . . . . . . . . . . . . . 6
+   6. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 6
+   7. Internationalization Considerations  . . . . . . . . . . . . . . 6
+   8. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . 6
+      Normative References . . . . . . . . . . . . . . . . . . . . . . 7
+      Informative References . . . . . . . . . . . . . . . . . . . . . 7
+      Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
+      Intellectual Property and Copyright Statements . . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 2]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+1. Introduction
+
+   "All keys are equal but some keys are more equal than others" [6]
+
+   With the definition of the Delegation Signer Resource Record (DS RR)
+   [5] it has become important to differentiate between the keys in the
+   DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
+   other keys in the DNSKEY RR set.  We refer to these public keys as
+   Secure Entry Point (SEP) keys.  A SEP key either used to generate a
+   DS RR or is distributed to resolvers that use the key as the root of
+   a trusted subtree[3].
+
+   In early deployment tests, the use of two (kinds of) key pairs for
+   each zone has been prevalent.  For one kind of key pair the private
+   key is used to sign just the zone's DNSKEY resource record (RR) set.
+   Its public key is intended to be referenced by a DS RR at the parent
+   or configured statically in a resolver.  The private key of the other
+   kind of key pair is used to sign the rest of the zone's data sets.
+   The former key pair is called a key-signing key (KSK) and the latter
+   is called a zone-signing key (ZSK).  In practice there have been
+   usually one of each kind of key pair, but there will be multiples of
+   each at times.
+
+   It should be noted that division of keys pairs into KSK's and ZSK's
+   is not mandatory in any definition of DNSSEC, not even with the
+   introduction of the DS RR.  But, in testing, this distinction has
+   been helpful when designing key roll over (key super-cession)
+   schemes.  Given that the distinction has proven helpful, the labels
+   KSK and ZSK have begun to stick.
+
+   There is a need to differentiate the public keys for the key pairs
+   that are used for key signing from keys that are not used key signing
+   (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to
+   be sent for generating DS RRs, which DNSKEYs are to be distributed to
+   resolvers, and which keys are fed to the signer application at the
+   appropriate time.
+
+   In other words, the SEP bit provides an in-band method to communicate
+   a DNSKEY RR's intended use to third parties. As an example we present
+   3 use cases in which the bit is useful:
+
+      The parent is a registry, the parent and the child use secured DNS
+      queries and responses, with a preexisting trust-relation, or plain
+      DNS over a secured channel to exchange the child's  DNSKEY RR
+      sets. Since a DNSKEY RR set will contain a complete DNSKEY RRset
+      the SEP bit can be used to isolate the DNSKEYs for which a DS RR
+      needs to be created.
+
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 3]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+      An administrator has configured a DNSKEY as root for a trusted
+      subtree into security aware resolver. Using a special purpose tool
+      that queries for the KEY RRs from that domain's apex, the
+      administrator will be able to notice the roll over of the trusted
+      anchor by a change of the subset of KEY RRs with the DS flag set.
+
+      A signer might use the SEP bit on the public key to determine
+      which private key to use to exclusively sign the DNSKEY RRset and
+      which private key to use to sign the other RRsets in the zone.
+
+   As demonstrated in the above examples it is important to be able to
+   differentiate the SEP keys from the other keys in a DNSKEY RR set in
+   the flow between signer and (parental) key-collector and in the flow
+   between the signer and the resolver configuration. The SEP flag is to
+   be of no interest to the flow between the verifier and the
+   authoritative data store.
+
+   The reason for the term "SEP" is a result of the observation that the
+   distinction between KSK and ZSK key pairs is made by the signer, a
+   key pair could be used as both a KSK and a ZSK at the same time. To
+   be clear, the term SEP was coined to lessen the confusion caused by
+   the overlap. ( Once this label was applied, it had the side effect of
+   removing the temptation to have both a KSK flag bit and a ZSK flag
+   bit.)
+
+   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 [1].
+
+2. The Secure Entry Point (SEP) 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          |S|   protocol    |   algorithm   |
+      |                             |E|               |               |
+      |                             |P|               |               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               /
+      /                        public key                             /
+      /                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                                DNSKEY RR Format
+
+
+
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 4]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+   This document assigns the 15'th bit in the flags field as the secure
+   entry point (SEP) bit.  If the the bit is set to 1 the key is
+   intended to be used as secure entry point key.  One SHOULD NOT assign
+   special meaning to the key if the bit is set to 0.  Operators can
+   recognize the secure entry point key by the even or odd-ness of the
+   decimal representation of the flag field.
+
+3. DNSSEC Protocol Changes
+
+   The bit MUST NOT be used during the resolving and verification
+   process. The SEP flag is only used to provide a hint about the
+   different administrative properties of the key and therefore the use
+   of the SEP flag does not change the DNS resolution protocol or the
+   resolution process.
+
+4. Operational Guidelines
+
+   The SEP bit is set by the key-pair-generator and MAY be used by the
+   zone signer to decide whether the public part of the key pair is to
+   be prepared for input to a DS RR generation function.  The SEP bit is
+   recommended to be set (to 1) whenever the public key of the key pair
+   will be distributed to the parent zone to build the authentication
+   chain or if the public key is to be distributed for static
+   configuration in verifiers.
+
+   When a key pair is created, the operator needs to indicate whether
+   the SEP bit is to be set in the DNSKEY RR.  As the SEP bit is within
+   the data that is used to compute the 'key tag field' in the SIG RR,
+   changing the SEP bit will change the identity of the key within DNS.
+   In other words, once a key is used to generate signatures, the
+   setting of the SEP bit is to remain constant. If not, a verifier will
+   not be able to find the relevant KEY RR.
+
+   When signing a zone, it is intended that the key(s) with the SEP bit
+   set (if such keys exist) are used to sign the KEY RR set of the zone.
+   The same key can be used to sign the rest of the zone data too.  It
+   is conceivable that not all keys with a SEP bit set will sign the
+   DNSKEY RR set, such keys might be pending retirement or not yet in
+   use.
+
+   When verifying a RR set, the SEP bit is not intended to play a role.
+   How the key is used by the verifier is not intended to be a
+   consideration at key creation time.
+
+   Although the SEP flag provides a hint on which public key is to be
+   used as trusted root, administrators can choose to ignore the fact
+   that a DNSKEY has its SEP bit set or not when configuring a trusted
+   root for their resolvers.
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 5]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+   Using the SEP flag a key roll over can be automated. The parent can
+   use an existing trust relation to verify DNSKEY RR sets in which a
+   new DNSKEY RR with the SEP flag appears.
+
+5. Security Considerations
+
+   As stated in Section 3 the flag is not to 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 might be used for automating public key exchanges, we
+   think the following consideration is in place.
+
+   Automated mechanisms for roll over of the DS RR might be vulnerable
+   to a class of replay attacks.  This might happen after a public key
+   exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
+   SEP flag set, is sent to the parent.  The parent verifies the DNSKEY
+   RR set with the existing trust relation and creates the new DS RR
+   from the DNSKEY RR that the current DS RR is not pointing to.  This
+   key exchange might be replayed. Parents are encouraged to implement a
+   replay defense. A simple defense can be based on a registry of keys
+   that have been used to generate DS RRs during the most recent roll
+   over. These same considerations apply to entities that configure keys
+   in resolvers.
+
+6. IANA Considerations
+
+   The flag bits  in the DNSKEY RR are assigned by IETF consensus and
+   registered in the DNSKEY Flags registry (created by [4]). This
+   document assigns the 15th bit in the DNSKEY RR as the Secure Entry
+   Point (SEP) bit.
+
+7. Internationalization Considerations
+
+   Although SEP is a popular acronym in many different languages, there
+   are no internationalization considerations.
+
+8. Acknowledgments
+
+   The ideas documented in this document are inspired by communications
+   we had with numerous people and ideas published by other folk. Among
+   others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
+   Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
+   have contributed ideas and provided feedback.
+
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 6]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+   This document saw the light during a workshop on DNSSEC operations
+   hosted by USC/ISI in August 2002.
+
+Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [3]  Lewis, E., "DNS Security Extension Clarification on Zone
+        Status", RFC 3090, March 2001.
+
+   [4]  Weiler, S., "Legacy Resolver Compatibility for Delegation
+        Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work
+        in progress), October 2003.
+
+Informative References
+
+   [5]  Gudmundsson, O., "Delegation Signer Resource Record",
+        draft-ietf-dnsext-delegation-signer-15 (work in progress), June
+        2003.
+
+   [6]  Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
+        Story", ISBN 0151002177 (50th anniversary edition), April 1996.
+
+
+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
+   Karl Gustavsgatan 15
+   Goteborg  SE-411 25
+   Sweden
+
+   EMail: jakob@schlyter.se
+
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 7]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+   Edward P. Lewis
+   ARIN
+   3635 Concorde Parkway Suite 200
+   Chantilly, VA  20151
+   US
+
+   Phone: +1 703 227 9854
+   EMail: edlewis@arin.net
+   URI:   http://www.arin.net/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 8]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights. Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11. Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard. Please address the information to the IETF Executive
+   Director.
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003). 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 assignees.
+
+   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
+
+
+
+Kolkman, et al.          Expires June 17, 2004                  [Page 9]
+
+Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
+
+
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman, et al.          Expires June 17, 2004                 [Page 10]
+
+

doc/draft/draft-ietf-dnsext-nsid-01.txt

@@ -0,0 +1,840 @@
+
+
+
+Network Working Group                                         R. Austein
+Internet-Draft                                                       ISC
+Expires: July 15, 2006                                  January 11, 2006
+
+
+                DNS Name Server Identifier Option (NSID)
+                       draft-ietf-dnsext-nsid-01
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on July 15, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   With the increased use of DNS anycast, load balancing, and other
+   mechanisms allowing more than one DNS name server to share a single
+   IP address, it is sometimes difficult to tell which of a pool of name
+   servers has answered a particular query.  While existing ad-hoc
+   mechanism allow an operator to send follow-up queries when it is
+   necessary to debug such a configuration, the only completely reliable
+   way to obtain the identity of the name server which responded is to
+   have the name server include this information in the response itself.
+   This note defines a protocol extension to support this functionality.
+
+
+
+Austein                   Expires July 15, 2006                 [Page 1]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.1.  Resolver Behavior  . . . . . . . . . . . . . . . . . . . .  4
+     2.2.  Name Server Behavior . . . . . . . . . . . . . . . . . . .  4
+     2.3.  The NSID Option  . . . . . . . . . . . . . . . . . . . . .  4
+     2.4.  Presentation Format  . . . . . . . . . . . . . . . . . . .  5
+   3.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+     3.1.  The NSID Payload . . . . . . . . . . . . . . . . . . . . .  6
+     3.2.  NSID Is Not Transitive . . . . . . . . . . . . . . . . . .  8
+     3.3.  User Interface Issues  . . . . . . . . . . . . . . . . . .  8
+     3.4.  Truncation . . . . . . . . . . . . . . . . . . . . . . . .  9
+   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 13
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
+   Intellectual Property and Copyright Statements . . . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                 [Page 2]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+1.  Introduction
+
+   With the increased use of DNS anycast, load balancing, and other
+   mechanisms allowing more than one DNS name server to share a single
+   IP address, it is sometimes difficult to tell which of a pool of name
+   servers has answered a particular query.
+
+   Existing ad-hoc mechanisms allow an operator to send follow-up
+   queries when it is necessary to debug such a configuration, but there
+   are situations in which this is not a totally satisfactory solution,
+   since anycast routing may have changed, or the server pool in
+   question may be behind some kind of extremely dynamic load balancing
+   hardware.  Thus, while these ad-hoc mechanisms are certainly better
+   than nothing (and have the advantage of already being deployed), a
+   better solution seems desirable.
+
+   Given that a DNS query is an idempotent operation with no retained
+   state, it would appear that the only completely reliable way to
+   obtain the identity of the name server which responded to a
+   particular query is to have that name server include identifying
+   information in the response itself.  This note defines a protocol
+   enhancement to achieve this.
+
+1.1.  Reserved Words
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                 [Page 3]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+2.  Protocol
+
+   This note uses an EDNS [RFC2671] option to signal the resolver's
+   desire for information identifying the name server and to hold the
+   name server's response, if any.
+
+2.1.  Resolver Behavior
+
+   A resolver signals its desire for information identifying a name
+   server by sending an empty NSID option (Section 2.3) in an EDNS OPT
+   pseudo-RR in the query message.
+
+   The resolver MUST NOT include any NSID payload data in the query
+   message.
+
+   The semantics of an NSID request are not transitive.  That is: the
+   presence of an NSID option in a query is a request that the name
+   server which receives the query identify itself.  If the name server
+   side of a recursive name server receives an NSID request, the client
+   is asking the recursive name server to identify itself; if the
+   resolver side of the recursive name server wishes to receive
+   identifying information, it is free to add NSID requests in its own
+   queries, but that is a separate matter.
+
+2.2.  Name Server Behavior
+
+   A name server which understands the NSID option and chooses to honor
+   a particular NSID request responds by including identifying
+   information in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR
+   in the response message.
+
+   The name server MUST ignore any NSID payload data that might be
+   present in the query message.
+
+   The NSID option is not transitive.  A name server MUST NOT send an
+   NSID option back to a resolver which did not request it.  In
+   particular, while a recursive name server may choose to add an NSID
+   option when sending a query, this has no effect on the presence or
+   absence of the NSID option in the recursive name server's response to
+   the original client.
+
+   As stated in Section 2.1, this mechanism is not restricted to
+   authoritative name servers; the semantics are intended to be equally
+   applicable to recursive name servers.
+
+2.3.  The NSID Option
+
+   The OPTION-CODE for the NSID option is [TBD].
+
+
+
+Austein                   Expires July 15, 2006                 [Page 4]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+   The OPTION-DATA for the NSID option is an opaque byte string the
+   semantics of which are deliberately left outside the protocol.  See
+   Section 3.1 for discussion.
+
+2.4.  Presentation Format
+
+   User interfaces MUST read and write the content of the NSID option as
+   a sequence of hexadecimal digits, two digits per payload octet.
+
+   The NSID payload is binary data.  Any comparison between NSID
+   payloads MUST be a comparison of the raw binary data.  Copy
+   operations MUST NOT assume that the raw NSID payload is null-
+   terminated.  Any resemblance between raw NSID payload data and any
+   form of text is purely a convenience, and does not change the
+   underlying nature of the payload data.
+
+   See Section 3.3 for discussion.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                 [Page 5]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+3.  Discussion
+
+   This section discusses certain aspects of the protocol and explains
+   considerations that led to the chosen design.
+
+3.1.  The NSID Payload
+
+   The syntax and semantics of the content of the NSID option is
+   deliberately left outside the scope of this specification.  This
+   section describe some of the kinds of data that server administrators
+   might choose to provide as the content of the NSID option, and
+   explains the reasoning behind choosing a simple opaque byte string.
+
+   There are several possibilities for the payload of the NSID option:
+
+   o  It could be the "real" name of the specific name server within the
+      name server pool.
+
+   o  It could be the "real" IP address (IPv4 or IPv6) of the name
+      server within the name server pool.
+
+   o  It could be some sort of pseudo-random number generated in a
+      predictable fashion somehow using the server's IP address or name
+      as a seed value.
+
+   o  It could be some sort of probabilisticly unique identifier
+      initially derived from some sort of random number generator then
+      preserved across reboots of the name server.
+
+   o  It could be some sort of dynamicly generated identifier so that
+      only the name server operator could tell whether or not any two
+      queries had been answered by the same server.
+
+   o  It could be a blob of signed data, with a corresponding key which
+      might (or might not) be available via DNS lookups.
+
+   o  It could be a blob of encrypted data, the key for which could be
+      restricted to parties with a need to know (in the opinion of the
+      server operator).
+
+   o  It could be an arbitrary string of octets chosen at the discretion
+      of the name server operator.
+
+   Each of these options has advantages and disadvantages:
+
+   o  Using the "real" name is simple, but the name server may not have
+      a "real" name.
+
+
+
+
+Austein                   Expires July 15, 2006                 [Page 6]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+   o  Using the "real" address is also simple, and the name server
+      almost certainly does have at least one non-anycast IP address for
+      maintenance operations, but the operator of the name server may
+      not be willing to divulge its non-anycast address.
+
+   o  Given that one common reason for using anycast DNS techniques is
+      an attempt to harden a critical name server against denial of
+      service attacks, some name server operators are likely to want an
+      identifier other than the "real" name or "real" address of the
+      name server instance.
+
+   o  Using a hash or pseudo-random number can provide a fixed length
+      value that the resolver can use to tell two name servers apart
+      without necessarily being able to tell where either one of them
+      "really" is, but makes debugging more difficult if one happens to
+      be in a friendly open environment.  Furthermore, hashing might not
+      add much value, since a hash based on an IPv4 address still only
+      involves a 32-bit search space, and DNS names used for servers
+      that operators might have to debug at 4am tend not to be very
+      random.
+
+   o  Probabilisticly unique identifiers have similar properties to
+      hashed identifiers, but (given a sufficiently good random number
+      generator) are immune to the search space issues.  However, the
+      strength of this approach is also its weakness: there is no
+      algorithmic transformation by which even the server operator can
+      associate name server instances with identifiers while debugging,
+      which might be annoying.  This approach also requires the name
+      server instance to preserve the probabilisticly unique identifier
+      across reboots, but this does not appear to be a serious
+      restriction, since authoritative nameservers almost always have
+      some form of nonvolatile storage in any case, and in the rare case
+      of a name server that does not have any way to store such an
+      identifier, nothing terrible will happen if the name server just
+      generates a new identifier every time it reboots.
+
+   o  Using an arbitrary octet string gives name server operators yet
+      another thing to configure, or mis-configure, or forget to
+      configure.  Having all the nodes in an anycast name server
+      constellation identify themselves as "My Name Server" would not be
+      particularly useful.
+
+   Given all of the issues listed above, there does not appear to be a
+   single solution that will meet all needs.  Section 2.3 therefore
+   defines the NSID payload to be an opaque byte string and leaves the
+   choice up to the implementor and name server operator.  The following
+   guidelines may be useful to implementors and server operators:
+
+
+
+
+Austein                   Expires July 15, 2006                 [Page 7]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+   o  Operators for whom divulging the unicast address is an issue could
+      use the raw binary representation of a probabilisticly unique
+      random number.  This should probably be the default implementation
+      behavior.
+
+   o  Operators for whom divulging the unicast address is not an issue
+      could just use the raw binary representation of a unicast address
+      for simplicity.  This should only be done via an explicit
+      configuration choice by the operator.
+
+   o  Operators who really need or want the ability to set the NSID
+      payload to an arbitrary value could do so, but this should only be
+      done via an explicit configuration choice by the operator.
+
+   This approach appears to provide enough information for useful
+   debugging without unintentionally leaking the maintenance addresses
+   of anycast name servers to nogoodniks, while also allowing name
+   server operators who do not find such leakage threatening to provide
+   more information at their own discretion.
+
+3.2.  NSID Is Not Transitive
+
+   As specified in Section 2.1 and Section 2.2, the NSID option is not
+   transitive.  This is strictly a hop-by-hop mechanism.
+
+   Most of the discussion of name server identification to date has
+   focused on identifying authoritative name servers, since the best
+   known cases of anycast name servers are a subset of the name servers
+   for the root zone.  However, given that anycast DNS techniques are
+   also applicable to recursive name servers, the mechanism may also be
+   useful with recursive name servers.  The hop-by-hop semantics support
+   this.
+
+   While there might be some utility in having a transitive variant of
+   this mechanism (so that, for example, a stub resolver could ask a
+   recursive server to tell it which authoritative name server provided
+   a particular answer to the recursive name server), the semantics of
+   such a variant would be more complicated, and are left for future
+   work.
+
+3.3.  User Interface Issues
+
+   Given the range of possible payload contents described in
+   Section 3.1, it is not possible to define a single presentation
+   format for the NSID payload that is efficient, convenient,
+   unambiguous, and aesthetically pleasing.  In particular, while it is
+   tempting to use a presentation format that uses some form of textual
+   strings, attempting to support this would significantly complicate
+
+
+
+Austein                   Expires July 15, 2006                 [Page 8]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+   what's intended to be a very simple debugging mechanism.
+
+   In some cases the content of the NSID payload may be binary data
+   meaningful only to the name server operator, and may not be
+   meaningful to the user or application, but the user or application
+   must be able to capture the entire content anyway in order for it to
+   be useful.  Thus, the presentation format must support arbitrary
+   binary data.
+
+   In cases where the name server operator derives the NSID payload from
+   textual data, a textual form such as US-ASCII or UTF-8 strings might
+   at first glance seem easier for a user to deal with.  There are,
+   however, a number of complex issues involving internationalized text
+   which, if fully addressed here, would require a set of rules
+   significantly longer than the rest of this specification.  See
+   [RFC2277] for an overview of some of these issues.
+
+   It is much more important for the NSID payload data to be passed
+   unambiguously from server administrator to user and back again than
+   it is for the payload data data to be pretty while in transit.  In
+   particular, it's critical that it be straightforward for a user to
+   cut and paste an exact copy of the NSID payload output by a debugging
+   tool into other formats such as email messages or web forms without
+   distortion.  Hexadecimal strings, while ugly, are also robust.
+
+3.4.  Truncation
+
+   In some cases, adding the NSID option to a response message may
+   trigger message truncation.  This specification does not change the
+   rules for DNS message truncation in any way, but implementors will
+   need to pay attention to this issue.
+
+   Including the NSID option in a response is always optional, so this
+   specification never requires name servers to truncate response
+   messages.
+
+   By definition, a resolver that requests NSID responses also supports
+   EDNS, so a resolver that requests NSID responses can also use the
+   "sender's UDP payload size" field of the OPT pseudo-RR to signal a
+   receive buffer size large enough to make truncation unlikely.
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                 [Page 9]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+4.  IANA Considerations
+
+   This mechanism requires allocation of one ENDS option code for the
+   NSID option (Section 2.3).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                [Page 10]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+5.  Security Considerations
+
+   This document describes a channel signaling mechanism, intended
+   primarily for debugging.  Channel signaling mechanisms are outside
+   the scope of DNSSEC per se.  Applications that require integrity
+   protection for the data being signaled will need to use a channel
+   security mechanism such as TSIG [RFC2845].
+
+   Section 3.1 discusses a number of different kinds of information that
+   a name server operator might choose to provide as the value of the
+   NSID option.  Some of these kinds of information are security
+   sensitive in some environments.  This specification deliberately
+   leaves the syntax and semantics of the NSID option content up to the
+   implementation and the name server operator.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                [Page 11]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+6.  Acknowledgements
+
+   Joe Abley, Harald Alvestrand, Mark Andrews, Roy Arends, Steve
+   Bellovin, Randy Bush, David Conrad, Johan Ihren, Daniel Karrenberg,
+   Peter Koch, Mike Patton, Mike StJohns, Paul Vixie, Sam Weiler, and
+   Suzanne Woolf.  Apologies to anyone inadvertently omitted from the
+   above list.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                [Page 12]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", RFC 2119, BCP 14, March 1997.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+7.2.  Informative References
+
+   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
+              Languages", RFC 2277, BCP 18, January 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                [Page 13]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+Author's Address
+
+   Rob Austein
+   ISC
+   950 Charter Street
+   Redwood City, CA  94063
+   USA
+
+   Email: sra@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                   Expires July 15, 2006                [Page 14]
+
+Internet-Draft                  DNS NSID                    January 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Austein                   Expires July 15, 2006                [Page 15]
+

doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt

@@ -0,0 +1,464 @@
+
+INTERNET-DRAFT                                DSA Information in the DNS
+OBSOLETES: RFC 2536                               Donald E. Eastlake 3rd
+                                                   Motorola Laboratories
+Expires: September 2006                                       March 2006
+
+
+            DSA Keying and Signature Information in the DNS
+            --- ------ --- --------- ----------- -- --- ---
+               <draft-ietf-dnsext-rfc2536bis-dsa-07.txt>
+                         Donald E. Eastlake 3rd
+
+
+Status of This Document
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Distribution of this document is unlimited. Comments should be sent
+   to the DNS extensions working group mailing list
+   <namedroppers@ops.ietf.org>.
+
+   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/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+
+
+Abstract
+
+   The standard method of encoding US Government Digital Signature
+   Algorithm keying and signature information for use in the Domain Name
+   System is specified.
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 1]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+Table of Contents
+
+      Status of This Document....................................1
+      Abstract...................................................1
+
+      Table of Contents..........................................2
+
+      1. Introduction............................................3
+      2. DSA Keying Information..................................3
+      3. DSA Signature Information...............................4
+      4. Performance Considerations..............................4
+      5. Security Considerations.................................5
+      6. IANA Considerations.....................................5
+      Copyright, Disclaimer, and Additional IPR Provisions.......5
+
+      Normative References.......................................7
+      Informative References.....................................7
+
+      Author's Address...........................................8
+      Expiration and File Name...................................8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 2]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+1. Introduction
+
+   The Domain Name System (DNS) is the global hierarchical replicated
+   distributed database system for Internet addressing, mail proxy, and
+   other information [RFC 1034, 1035]. The DNS has been extended to
+   include digital signatures and cryptographic keys as described in
+   [RFC 4033, 4034, 4035] and additional work is underway which would
+   require the storage of keying and signature information in the DNS.
+
+   This document describes how to encode US Government Digital Signature
+   Algorithm (DSA) keys and signatures in the DNS.  Familiarity with the
+   US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
+
+
+
+2. DSA Keying Information
+
+   When DSA public keys are stored in the DNS, the structure of the
+   relevant part of the RDATA part of the RR being used is the fields
+   listed below in the order given.
+
+   The period of key validity is not included in this data but is
+   indicated separately, for example by an RR such as RRSIG which signs
+   and authenticates the RR containing the keying information.
+
+        Field     Size
+        -----     ----
+         T         1  octet
+         Q        20  octets
+         P        64 + T*8  octets
+         G        64 + T*8  octets
+         Y        64 + T*8  octets
+
+   As described in [FIPS 186-2] and [Schneier], T is a key size
+   parameter chosen such that 0 <= T <= 8.  (The meaning if the T octet
+   is greater than 8 is reserved and the remainder of the data may have
+   a different format in that case.)  Q is a prime number selected at
+   key generation time such that 2**159 < Q < 2**160. Thus Q is always
+   20 octets long and, as with all other fields, is stored in "big-
+   endian" network order.  P, G, and Y are calculated as directed by the
+   [FIPS 186-2] key generation algorithm [Schneier].  P is in the range
+   2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long.  G
+   and Y are quantities modulo P and so can be up to the same length as
+   P and are allocated fixed size fields with the same number of octets
+   as P.
+
+   During the key generation process, a random number X must be
+   generated such that 1 <= X <= Q-1.  X is the private key and is used
+   in the final step of public key generation where Y is computed as
+
+
+
+D. Eastlake 3rd                                                 [Page 3]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+        Y = G**X mod P
+
+
+
+3. DSA Signature Information
+
+   The portion of the RDATA area used for US Digital Signature Algorithm
+   signature information is shown below with fields in the order they
+   are listed and the contents of each multi-octet field in "big-endian"
+   network order.
+
+        Field     Size
+        -----     ----
+         T         1 octet
+         R        20 octets
+         S        20 octets
+
+   First, the data signed must be determined.  Then the following steps
+   are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
+   specified in the public key [Schneier]:
+
+        hash = SHA-1 ( data )
+
+        Generate a random K such that 0 < K < Q.
+
+        R = ( G**K mod P ) mod Q
+
+        S = ( K**(-1) * (hash + X*R) ) mod Q
+
+   For information on the SHA-1 hash function see [FIPS 180-2] and [RFC
+   3174].
+
+   Since Q is 160 bits long, R and S can not be larger than 20 octets,
+   which is the space allocated.
+
+   T is copied from the public key.  It is not logically necessary in
+   the SIG but is present so that values of T > 8 can more conveniently
+   be used as an escape for extended versions of DSA or other algorithms
+   as later standardized.
+
+
+
+4. Performance Considerations
+
+   General signature generation speeds are roughly the same for RSA [RFC
+   3110] and DSA.  With sufficient pre-computation, signature generation
+   with DSA is faster than RSA.  Key generation is also faster for DSA.
+   However, signature verification is an order of magnitude slower than
+   RSA when the RSA public exponent is chosen to be small, as is
+   recommended for some applications.
+
+
+D. Eastlake 3rd                                                 [Page 4]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+   Current DNS implementations are optimized for small transfers,
+   typically less than 512 bytes including DNS overhead.  Larger
+   transfers will perform correctly and extensions have been
+   standardized [RFC 2671] to make larger transfers more efficient, it
+   is still advisable at this time to make reasonable efforts to
+   minimize the size of RR sets containing keying and/or signature
+   inforamtion consistent with adequate security.
+
+
+
+5. Security Considerations
+
+   Keys retrieved from the DNS should not be trusted unless (1) they
+   have been securely obtained from a secure resolver or independently
+   verified by the user and (2) this secure resolver and secure
+   obtainment or independent verification conform to security policies
+   acceptable to the user.  As with all cryptographic algorithms,
+   evaluating the necessary strength of the key is essential and
+   dependent on local policy.
+
+   The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
+   current DSA standard may limit the security of DSA.  For particular
+   applications, implementors are encouraged to consider the range of
+   available algorithms and key sizes.
+
+   DSA assumes the ability to frequently generate high quality random
+   numbers.  See [random] for guidance.  DSA is designed so that if
+   biased rather than random numbers are used, high bandwidth covert
+   channels are possible.  See [Schneier] and more recent research.  The
+   leakage of an entire DSA private key in only two DSA signatures has
+   been demonstrated.  DSA provides security only if trusted
+   implementations, including trusted random number generation, are
+   used.
+
+
+
+6. IANA Considerations
+
+   Allocation of meaning to values of the T parameter that are not
+   defined herein (i.e., > 8 ) requires an IETF standards actions.  It
+   is intended that values unallocated herein be used to cover future
+   extensions of the DSS standard.
+
+
+
+Copyright, Disclaimer, and Additional IPR Provisions
+
+   Copyright (C) The Internet Society (2006).  This document is subject to
+   the rights, licenses and restrictions contained in BCP 78, and except
+   as set forth therein, the authors retain all their rights.
+
+
+D. Eastlake 3rd                                                 [Page 5]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 6]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+Normative References
+
+   [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
+   Signature Standard, 27 January 2000.
+
+   [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
+   March 2005.
+
+
+
+Informative References
+
+   [RFC 1034] - "Domain names - concepts and facilities", P.
+   Mockapetris, 11/01/1987.
+
+   [RFC 1035] - "Domain names - implementation and specification", P.
+   Mockapetris, 11/01/1987.
+
+   [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
+   1999.
+
+   [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
+   (DNS)", D.  Eastlake 3rd. May 2001.
+
+   [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
+   Jones, September 2001.
+
+   [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "DNS Security Introduction and Requirements", RFC 4033, March
+   2005.
+
+   [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "Protocol Modifications for the DNS Security Extensions", RFC
+   4035, March 2005.
+
+   [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+   "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+   [Schneier] - "Applied Cryptography Second Edition: protocols,
+   algorithms, and source code in C" (second edition), Bruce Schneier,
+   1996, John Wiley and Sons, ISBN 0-471-11709-9.
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 7]
+
+
+INTERNET-DRAFT                                DSA Information in the DNS
+
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   Motorola Labortories
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Telephone:   +1-508-786-7554(w)
+   EMail:       Donald.Eastlake@motorola.com
+
+
+
+Expiration and File Name
+
+   This draft expires in September 2006.
+
+   Its file name is draft-ietf-dnsext-rfc2536bis-dsa-07.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 8]
+

doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt

@@ -0,0 +1,580 @@
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+OBSOLETES: RFC 2539                               Donald E. Eastlake 3rd
+                                                   Motorola Laboratories
+Expires: September 2006                                       March 2006
+
+
+
+
+        Storage of Diffie-Hellman Keying Information in the DNS
+        ------- -- -------------- ------ ----------- -- --- ---
+               <draft-ietf-dnsext-rfc2539bis-dhk-07.txt>
+
+
+
+Status of This Document
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Distribution of this document is unlimited. Comments should be sent
+   to the DNS extensions working group mailing list
+   <namedroppers@ops.ietf.org>.
+
+   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/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+
+Abstract
+
+   The standard method for encoding Diffie-Hellman keys in the Domain
+   Name System is specified.
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 1]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+Acknowledgements
+
+   Part of the format for Diffie-Hellman keys and the description
+   thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
+   and Hemma Prafullchandra.  In addition, the following persons
+   provided useful comments that were incorporated into the predecessor
+   of this document: Ran Atkinson, Thomas Narten.
+
+
+
+Table of Contents
+
+          Status of This Document....................................1
+      Abstract...................................................1
+
+      Acknowledgements...........................................2
+      Table of Contents..........................................2
+
+      1. Introduction............................................3
+      1.1 About This Document....................................3
+      1.2 About Diffie-Hellman...................................3
+      2. Encoding Diffie-Hellman Keying Information..............4
+      3. Performance Considerations..............................5
+      4. IANA Considerations.....................................5
+      5. Security Considerations.................................5
+      Copyright, Disclaimer, and Additional IPR Provisions.......5
+
+      Normative References.......................................7
+      Informative Refences.......................................7
+
+      Author's Address...........................................8
+      Expiration and File Name...................................8
+
+      Appendix A: Well known prime/generator pairs...............9
+      A.1. Well-Known Group 1:  A 768 bit prime..................9
+      A.2. Well-Known Group 2:  A 1024 bit prime.................9
+      A.3. Well-Known Group 3:  A 1536 bit prime................10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 2]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+1. Introduction
+
+   The Domain Name System (DNS) is the global hierarchical replicated
+   distributed database system for Internet addressing, mail proxy, and
+   similar information [RFC 1034, 1035]. The DNS has been extended to
+   include digital signatures and cryptographic keys as described in
+   [RFC 4033, 4034, 4035] and additonal work is underway which would use
+   the storage of keying information in the DNS.
+
+
+
+1.1 About This Document
+
+   This document describes how to store Diffie-Hellman keys in the DNS.
+   Familiarity with the Diffie-Hellman key exchange algorithm is assumed
+   [Schneier, RFC 2631].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119.
+
+
+
+1.2 About Diffie-Hellman
+
+   Diffie-Hellman requires two parties to interact to derive keying
+   information which can then be used for authentication.  Thus Diffie-
+   Hellman is inherently a key agreement algorithm. As a result, no
+   format is defined for Diffie-Hellman "signature information".  For
+   example, assume that two parties have local secrets "i" and "j".
+   Assume they each respectively calculate X and Y as follows:
+
+        X = g**i ( mod p )
+
+        Y = g**j ( mod p )
+
+   They exchange these quantities and then each calculates a Z as
+   follows:
+
+        Zi = Y**i ( mod p )
+
+        Zj = X**j ( mod p )
+
+   Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
+   secret between the two parties that an adversary who does not know i
+   or j will not be able to learn from the exchanged messages (unless
+   the adversary can derive i or j by performing a discrete logarithm
+   mod p which is hard for strong p and g).
+
+   The private key for each party is their secret i (or j).  The public
+
+
+D. Eastlake 3rd                                                 [Page 3]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+   key is the pair p and g, which is the same for both parties, and
+   their individual X (or Y).
+
+   For further information about Diffie-Hellman and precautions to take
+   in deciding on a p and g, see [RFC 2631].
+
+
+
+2. Encoding Diffie-Hellman Keying Information
+
+   When Diffie-Hellman keys appear within the RDATA portion of a RR,
+   they are encoded as shown below.
+
+   The period of key validity is not included in this data but is
+   indicated separately, for example by an RR such as RRSIG which signs
+   and authenticates the RR containing the keying information.
+
+                            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
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |           KEY flags           |    protocol   |  algorithm=2  |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |     prime length (or flag)    |  prime (p) (or special)       /
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       /  prime (p)  (variable length) |       generator length        |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       | generator (g) (variable length)                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |     public value length       | public value (variable length)/
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       /  public value (g^i mod p)    (variable length)                |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Prime length is the length of the Diffie-Hellman prime (p) in bytes
+   if it is 16 or greater.  Prime contains the binary representation of
+   the Diffie-Hellman prime with most significant byte first (i.e., in
+   network order). If "prime length" field is 1 or 2, then the "prime"
+   field is actually an unsigned index into a table of 65,536
+   prime/generator pairs and the generator length SHOULD be zero.  See
+   Appedix A for defined table entries and Section 4 for information on
+   allocating additional table entries.  The meaning of a zero or 3
+   through 15 value for "prime length" is reserved.
+
+   Generator length is the length of the generator (g) in bytes.
+   Generator is the binary representation of generator with most
+   significant byte first.  PublicValueLen is the Length of the Public
+   Value (g**i (mod p)) in bytes.  PublicValue is the binary
+   representation of the DH public value with most significant byte
+   first.
+
+
+
+D. Eastlake 3rd                                                 [Page 4]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+3. Performance Considerations
+
+   Current DNS implementations are optimized for small transfers,
+   typically less than 512 bytes including DNS overhead.  Larger
+   transfers will perform correctly and extensions have been
+   standardized [RFC 2671] to make larger transfers more efficient. But
+   it is still advisable at this time to make reasonable efforts to
+   minimize the size of RR sets containing keying information consistent
+   with adequate security.
+
+
+
+4. IANA Considerations
+
+   Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
+   an IETF consensus as defined in [RFC 2434].
+
+   Well known prime/generator pairs number 0x0000 through 0x07FF can
+   only be assigned by an IETF standards action. [RFC 2539], the
+   Proposed Standard predecessor of this document, assigned 0x0001
+   through 0x0002. This document additionally assigns 0x0003.  Pairs
+   number 0s0800 through 0xBFFF can be assigned based on RFC
+   documentation. Pairs number 0xC000 through 0xFFFF are available for
+   private use and are not centrally coordinated. Use of such private
+   pairs outside of a closed environment may result in conflicts and/or
+   security failures.
+
+
+
+5. Security Considerations
+
+   Keying information retrieved from the DNS should not be trusted
+   unless (1) it has been securely obtained from a secure resolver or
+   independently verified by the user and (2) this secure resolver and
+   secure obtainment or independent verification conform to security
+   policies acceptable to the user.  As with all cryptographic
+   algorithms, evaluating the necessary strength of the key is important
+   and dependent on security policy.
+
+   In addition, the usual Diffie-Hellman key strength considerations
+   apply. (p-1)/2 SHOULD also be prime, g SHOULD be primitive mod p, p
+   SHOULD be "large", etc. See [RFC 2631, Schneier].
+
+
+
+Copyright, Disclaimer, and Additional IPR Provisions
+
+   Copyright (C) The Internet Society (2006).  This document is subject to
+   the rights, licenses and restrictions contained in BCP 78, and except
+   as set forth therein, the authors retain all their rights.
+
+
+D. Eastlake 3rd                                                 [Page 5]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 6]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+Normative References
+
+   [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
+   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC 2434] - "Guidelines for Writing an IANA Considerations Section
+   in RFCs", T.  Narten, H. Alvestrand, October 1998.
+
+   [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
+   1999.
+
+   [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
+   March 2005.
+
+
+
+Informative Refences
+
+   [RFC 1034] - "Domain names - concepts and facilities", P.
+   Mockapetris, November 1987.
+
+   [RFC 1035] - "Domain names - implementation and specification", P.
+   Mockapetris, November 1987.
+
+   [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name
+   System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC.
+
+   [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
+   1999.
+
+   [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "DNS Security Introduction and Requirements", RFC 4033, March
+   2005.
+
+   [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+   Rose, "Protocol Modifications for the DNS Security Extensions", RFC
+   4035, March 2005.
+
+   [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
+   Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
+   and Sons.
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 7]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   Motorola Laboratories
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Telephone:   +1-508-786-7554
+   EMail:       Donald.Eastlake@motorola.com
+
+
+
+Expiration and File Name
+
+   This draft expires in September 2006.
+
+   Its file name is draft-ietf-dnsext-rfc2539bis-dhk-07.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                 [Page 8]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+Appendix A: Well known prime/generator pairs
+
+   These numbers are copied from the IPSEC effort where the derivation
+   of these values is more fully explained and additional information is
+   available.  Richard Schroeppel performed all the mathematical and
+   computational work for this appendix.
+
+
+
+A.1. Well-Known Group 1:  A 768 bit prime
+
+   The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }.  Its
+   decimal value is
+          155251809230070893513091813125848175563133404943451431320235
+          119490296623994910210725866945387659164244291000768028886422
+          915080371891804634263272761303128298374438082089019628850917
+          0691316593175367469551763119843371637221007210577919
+
+   Prime modulus: Length (32 bit words): 24, Data (hex):
+            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+            E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
+
+   Generator: Length (32 bit words): 1, Data (hex): 2
+
+
+
+A.2. Well-Known Group 2:  A 1024 bit prime
+
+   The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
+   Its decimal value is
+         179769313486231590770839156793787453197860296048756011706444
+         423684197180216158519368947833795864925541502180565485980503
+         646440548199239100050792877003355816639229553136239076508735
+         759914822574862575007425302077447712589550957937778424442426
+         617334727629299387668709205606050270810842907692932019128194
+         467627007
+
+   Prime modulus:  Length (32 bit words): 32, Data (hex):
+            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+            E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+            EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
+            FFFFFFFF FFFFFFFF
+
+   Generator: Length (32 bit words): 1, Data (hex): 2
+
+
+
+
+D. Eastlake 3rd                                                 [Page 9]
+
+
+INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
+
+
+A.3. Well-Known Group 3:  A 1536 bit prime
+
+   The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] +  741804 }.
+   Its decimal value is
+            241031242692103258855207602219756607485695054850245994265411
+            694195810883168261222889009385826134161467322714147790401219
+            650364895705058263194273070680500922306273474534107340669624
+            601458936165977404102716924945320037872943417032584377865919
+            814376319377685986952408894019557734611984354530154704374720
+            774996976375008430892633929555996888245787241299381012913029
+            459299994792636526405928464720973038494721168143446471443848
+            8520940127459844288859336526896320919633919
+
+   Prime modulus Length (32 bit words): 48, Data (hex):
+              FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+              29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+              EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+              E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+              EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
+              C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
+              83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
+              670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
+
+   Generator: Length (32 bit words):  1, Data (hex): 2
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd                                                [Page 10]
+

doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt

@@ -0,0 +1,480 @@
+
+
+
+
+
+
+DNSEXT Working Group                                Paul Vixie, ISC
+INTERNET-DRAFT
+<draft-ietf-dnsext-rfc2671bis-edns0-01.txt>          March 17, 2008
+
+Intended Status: Standards Track
+Obsoletes: 2671 (if approved)
+
+
+              Revised extension mechanisms for DNS (EDNS0)
+
+
+Status of this Memo
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+
+                                 Abstract
+
+   The Domain Name System's wire protocol includes a number of fixed
+   fields whose range has been or soon will be exhausted and does not
+   allow clients to advertise their capabilities to servers.  This
+   document describes backward compatible mechanisms for allowing the
+   protocol to grow.
+
+
+
+Expires September 2008                                          [Page 1]
+
+INTERNET-DRAFT                    EDNS0                       March 2008
+
+
+1 - Introduction
+
+1.1. DNS (see [RFC1035]) specifies a Message Format and within such
+messages there are standard formats for encoding options, errors, and
+name compression.  The maximum allowable size of a DNS Message is fixed.
+Many of DNS's protocol limits are too small for uses which are or which
+are desired to become common.  There is no way for implementations to
+advertise their capabilities.
+
+1.2. Unextended agents will not know how to interpret the protocol
+extensions detailed here.  In practice, these clients will be upgraded
+when they have need of a new feature, and only new features will make
+use of the extensions.  Extended agents must be prepared for behaviour
+of unextended clients in the face of new protocol elements, and fall
+back gracefully to unextended DNS.  RFC 2671 originally has proposed
+extensions to the basic DNS protocol to overcome these deficiencies.
+This memo refines that specification and obsoletes RFC 2671.
+
+1.3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2 - Affected Protocol Elements
+
+2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit
+word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of
+1-bit flags.  The original reserved Z bits have been allocated to
+various purposes, and most of the RCODE values are now in use.  More
+flags and more possible RCODEs are needed.  The OPT pseudo-RR specified
+in Section 4 contains subfields that carry a bit field extension of the
+RCODE field and additional flag bits, respectively; for details see
+Section 4.6 below.
+
+2.2. The first two bits of a wire format domain label are used to denote
+the type of the label.  [RFC1035 4.1.4] allocates two of the four
+possible types and reserves the other two.  Proposals for use of the
+remaining types far outnumber those available.  More label types were
+needed, and an extension mechanism was proposed in RFC 2671 [RFC2671
+Section 3].  Section 3 of this document reserves DNS labels with a first
+octet in the range of 64-127 decimal (label type 01) for future
+standardization of Extended DNS Labels.
+
+
+
+
+
+
+
+Expires September 2008                                          [Page 2]
+
+INTERNET-DRAFT                    EDNS0                       March 2008
+
+
+2.3. DNS Messages are limited to 512 octets in size when sent over UDP.
+While the minimum maximum reassembly buffer size still allows a limit of
+512 octets of UDP payload, most of the hosts now connected to the
+Internet are able to reassemble larger datagrams.  Some mechanism must
+be created to allow requestors to advertise larger buffer sizes to
+responders.  To this end, the OPT pseudo-RR specified in Section 4
+contains a maximum payload size field; for details see Section 4.5
+below.
+
+3 - Extended Label Types
+
+The first octet in the on-the-wire representation of a DNS label
+specifies the label type; the basic DNS specification [RFC1035]
+dedicates the two most significant bits of that octet for this purpose.
+
+This document reserves DNS label type 0b01 for use as an indication for
+Extended Label Types.  A specific extended label type is selected by the
+6 least significant bits of the first octet.  Thus, Extended Label Types
+are indicated by the values 64-127 (0b01xxxxxx) in the first octet of
+the label.
+
+Allocations from this range are to be made for IETF documents fully
+describing the syntax and semantics as well as the applicability of the
+particular Extended Label Type.
+
+This document does not describe any specific Extended Label Type.
+
+4 - OPT pseudo-RR
+
+4.1. One OPT pseudo-RR (RR type 41) MAY be added to the additional data
+section of a request, and to responses to such requests.  An OPT is
+called a pseudo-RR because it pertains to a particular transport level
+message and not to any actual DNS data.  OPT RRs MUST NOT be cached,
+forwarded, or stored in or loaded from master files.  The quantity of
+OPT pseudo-RRs per message MUST be either zero or one, but not greater.
+
+4.2. An OPT RR has a fixed part and a variable set of options expressed
+as {attribute, value} pairs.  The fixed part holds some DNS meta data
+and also a small collection of new protocol elements which we expect to
+be so popular that it would be a waste of wire space to encode them as
+{attribute, value} pairs.
+
+
+
+
+
+
+
+Expires September 2008                                          [Page 3]
+
+INTERNET-DRAFT                    EDNS0                       March 2008
+
+
+4.3. The fixed part of an OPT RR is structured as follows:
+
+Field Name   Field Type     Description
+------------------------------------------------------
+NAME         domain name    empty (root domain)
+TYPE         u_int16_t      OPT (41)
+CLASS        u_int16_t      sender's UDP payload size
+TTL          u_int32_t      extended RCODE and flags
+RDLEN        u_int16_t      describes RDATA
+RDATA        octet stream   {attribute,value} pairs
+
+
+4.4. The variable part of an OPT RR is encoded in its RDATA and is
+structured as zero or more of the following:
+
+      :          +0 (MSB)             :              +1 (LSB)         :
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+   0: |                          OPTION-CODE                          |
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+   2: |                         OPTION-LENGTH                         |
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+   4: |                                                               |
+      /                          OPTION-DATA                          /
+      /                                                               /
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+
+OPTION-CODE    (Assigned by IANA.)
+
+OPTION-LENGTH  Size (in octets) of OPTION-DATA.
+
+OPTION-DATA    Varies per OPTION-CODE.
+
+4.4.1. Order of appearance of option tuples is never relevant.  Any
+option whose meaning is affected by other options is so affected no
+matter which one comes first in the OPT RDATA.
+
+4.4.2. Any OPTION-CODE values not understood by a responder or requestor
+MUST be ignored.  So, specifications of such options might wish to
+include some kind of signalled acknowledgement.  For example, an option
+specification might say that if a responder sees option XYZ, it SHOULD
+include option XYZ in its response.
+
+
+
+
+
+
+Expires September 2008                                          [Page 4]
+
+INTERNET-DRAFT                    EDNS0                       March 2008
+
+
+4.5. The sender's UDP payload size (which OPT stores in the RR CLASS
+field) is the number of octets of the largest UDP payload that can be
+reassembled and delivered in the sender's network stack.  Note that path
+MTU, with or without fragmentation, may be smaller than this.  Values
+lower than 512 are undefined, and may be treated as format errors, or
+may be treated as equal to 512, at the implementor's discretion.
+
+4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
+reassembly buffer.  Choosing 1280 on an Ethernet connected requestor
+would be reasonable.  The consequence of choosing too large a value may
+be an ICMP message from an intermediate gateway, or even a silent drop
+of the response message.
+
+4.5.2. Both requestors and responders are advised to take account of the
+path's discovered MTU (if already known) when considering message sizes.
+
+4.5.3. The requestor's maximum payload size can change over time, and
+therefore MUST NOT be cached for use beyond the transaction in which it
+is advertised.
+
+4.5.4. The responder's maximum payload size can change over time, but
+can be reasonably expected to remain constant between two sequential
+transactions; for example, a meaningless QUERY to discover a responder's
+maximum UDP payload size, followed immediately by an UPDATE which takes
+advantage of this size.  (This is considered preferrable to the outright
+use of TCP for oversized requests, if there is any reason to suspect
+that the responder implements EDNS, and if a request will not fit in the
+default 512 payload size limit.)
+
+4.5.5. Due to transaction overhead, it is unwise to advertise an
+architectural limit as a maximum UDP payload size.  Just because your
+stack can reassemble 64KB datagrams, don't assume that you want to spend
+more than about 4KB of state memory per ongoing transaction.
+
+4.6. The extended RCODE and flags (which OPT stores in the RR TTL field)
+are structured as follows:
+
+      :          +0 (MSB)             :              +1 (LSB)         :
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+   0: |         EXTENDED-RCODE        |            VERSION            |
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+   2: | DO|                           Z                               |
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+
+
+
+
+Expires September 2008                                          [Page 5]
+
+INTERNET-DRAFT                    EDNS0                       March 2008
+
+
+EXTENDED-RCODE  Forms upper 8 bits of extended 12-bit RCODE.  Note that
+                EXTENDED-RCODE value zero (0) indicates that an
+                unextended RCODE is in use (values zero (0) through
+                fifteen (15)).
+
+VERSION         Indicates the implementation level of whoever sets it.
+                Full conformance with this specification is indicated by
+                version zero (0).  Requestors are encouraged to set this
+                to the lowest implemented level capable of expressing a
+                transaction, to minimize the responder and network load
+                of discovering the greatest common implementation level
+                between requestor and responder.  A requestor's version
+                numbering strategy should ideally be a run time
+                configuration option.
+
+                If a responder does not implement the VERSION level of
+                the request, then it answers with RCODE=BADVERS.  All
+                responses MUST be limited in format to the VERSION level
+                of the request, but the VERSION of each response MUST be
+                the highest implementation level of the responder.  In
+                this way a requestor will learn the implementation level
+                of a responder as a side effect of every response,
+                including error responses, including RCODE=BADVERS.
+
+DO              DNSSEC OK bit [RFC3225].
+
+Z               Set to zero by senders and ignored by receivers, unless
+                modified in a subsequent specification [IANAFLAGS].
+
+5 - Transport Considerations
+
+5.1. The presence of an OPT pseudo-RR in a request is an indication that
+the requestor fully implements the given version of EDNS, and can
+correctly understand any response that conforms to that feature's
+specification.
+
+5.2. Lack of use of these features in a request is an indication that
+the requestor does not implement any part of this specification and that
+the responder SHOULD NOT use any protocol extension described here in
+its response.
+
+5.3. Responders who do not understand these protocol extensions are
+expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL, or
+to appear to "time out" due to inappropriate action by a "middle box"
+such as a NAT, or to ignore extensions and respond only to unextended
+
+
+
+Expires September 2008                                          [Page 6]
+
+INTERNET-DRAFT                    EDNS0                       March 2008
+
+
+protocol elements.  Therefore use of extensions SHOULD be "probed" such
+that a responder who isn't known to support them be allowed a retry with
+no extensions if it responds with such an RCODE, or does not respond.
+If a responder's capability level is cached by a requestor, a new probe
+SHOULD be sent periodically to test for changes to responder capability.
+
+5.4. If EDNS is used in a request, and the response arrives with TC set
+and with no EDNS OPT RR, a requestor should assume that truncation
+prevented the OPT RR from being appended by the responder, and further,
+that EDNS is not used in the response.  Correspondingly, an EDNS
+responder who cannot fit all necessary elements (including an OPT RR)
+into a response, should respond with a normal (unextended) DNS response,
+possibly setting TC if the response will not fit in the unextended
+response message's 512-octet size.
+
+6 - Security Considerations
+
+Requestor-side specification of the maximum buffer size may open a new
+DNS denial of service attack if responders can be made to send messages
+which are too large for intermediate gateways to forward, thus leading
+to potential ICMP storms between gateways and responders.
+
+7 - IANA Considerations
+
+IANA has allocated RR type code 41 for OPT.
+
+This document controls the following IANA sub-registries in registry
+"DOMAIN NAME SYSTEM PARAMETERS":
+
+   "EDNS Extended Label Type"
+   "EDNS Option Codes"
+   "EDNS Version Numbers"
+   "Domain System Response Code"
+
+IANA is advised to re-parent these subregistries to this document.
+
+This document assigns label type 0b01xxxxxx as "EDNS Extended Label
+Type."  We request that IANA record this assignment.
+
+This document assigns option code 65535 to "Reserved for future
+expansion."
+
+This document assigns EDNS Extended RCODE "16" to "BADVERS".
+
+
+
+
+
+Expires September 2008                                          [Page 7]
+
+INTERNET-DRAFT                    EDNS0                       March 2008
+
+
+IESG approval is required to create new entries in the EDNS Extended
+Label Type or EDNS Version Number registries, while any published RFC
+(including Informational, Experimental, or BCP) is grounds for
+allocation of an EDNS Option Code.
+
+8 - Acknowledgements
+
+Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
+Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Thomas Narten,
+Alfred Hoenes and Markku Savela were each instrumental in creating and
+refining this specification.
+
+9 - References
+
+[RFC1035]    P. Mockapetris, "Domain Names - Implementation and
+             Specification," RFC 1035, USC/Information Sciences
+             Institute, November 1987.
+
+[RFC2119]    S. Bradner, "Key words for use in RFCs to Indicate
+             Requirement Levels," RFC 2119, Harvard University, March
+             1997.
+
+[RFC2671]    P. Vixie, "Extension mechanisms for DNS (EDNS0)," RFC 2671,
+             Internet Software Consortium, August 1999.
+
+[RFC3225]    D. Conrad, "Indicating Resolver Support of DNSSEC," RFC
+             3225, Nominum Inc., December 2001.
+
+[IANAFLAGS]  IANA, "DNS Header Flags and EDNS Header Flags," web site
+             http://www.iana.org/assignments/dns-header-flags, as of
+             June 2005 or later.
+
+10 - Author's Address
+
+Paul Vixie
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, CA 94063
+   +1 650 423 1301
+   EMail: vixie@isc.org
+
+
+
+
+
+
+
+
+Expires September 2008                                          [Page 8]
+
+INTERNET-DRAFT                    EDNS0                       March 2008
+
+
+Full Copyright Statement
+
+Copyright (C) IETF Trust (2007).
+
+This document is subject to the rights, licenses and restrictions
+contained in BCP 78, and except as set forth therein, the authors retain
+all their rights.
+
+This document and the information contained herein are provided on an
+"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
+IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE
+INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+The IETF takes no position regarding the validity or scope of any
+Intellectual Property Rights or other rights that might be claimed to
+pertain to the implementation or use of the technology described in this
+document or the extent to which any license under such rights might or
+might not be available; nor does it represent that it has made any
+independent effort to identify any such rights.  Information on the
+procedures with respect to rights in RFC documents can be found in BCP
+78 and BCP 79.
+
+Copies of IPR disclosures made to the IETF Secretariat and any
+assurances of licenses to be made available, or the result of an attempt
+made to obtain a general license or permission for the use of such
+proprietary rights by implementers or users of this specification can be
+obtained from the IETF on-line IPR repository at
+http://www.ietf.org/ipr.
+
+The IETF invites any interested party to bring to its attention any
+copyrights, patents or patent applications, or other proprietary rights
+that may cover technology that may be required to implement this
+standard.  Please address the information to the IETF at
+ietf-ipr@ietf.org.
+
+Acknowledgement
+
+Funding for the RFC Editor function is provided by the IETF
+Administrative Support Activity (IASA).
+
+
+
+
+Expires September 2008                                          [Page 9]
+

doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt

@@ -0,0 +1,755 @@
+
+
+Network Working Group                                          B. Laurie
+Internet-Draft                                                   Nominet
+Expires: March 2, 2005                                         R. Loomis
+                                                                    SAIC
+                                                          September 2004
+
+
+
+      Requirements related to DNSSEC Signed Proof of Non-Existence
+         draft-ietf-dnsext-signed-nonexistence-requirements-01
+
+
+Status of this Memo
+
+
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
+   RFC 3668.
+
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+   This Internet-Draft will expire on March 2, 2005.
+
+
+Copyright Notice
+
+
+   Copyright (C) The Internet Society (2004).
+
+
+Abstract
+
+
+   DNSSEC-bis uses the NSEC record to provide authenticated denial of
+   existence of RRsets.  NSEC also has the side-effect of permitting
+   zone enumeration, even if zone transfers have been forbidden.
+   Because some see this as a problem, this document has been assembled
+   to detail the possible requirements for denial of existence A/K/A
+   signed proof of non-existence.
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 1]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+Table of Contents
+
+
+   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.   Non-purposes . . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.   Zone Enumeration . . . . . . . . . . . . . . . . . . . . . .   3
+   4.   Zone Enumeration II  . . . . . . . . . . . . . . . . . . . .   4
+   5.   Zone Enumeration III . . . . . . . . . . . . . . . . . . . .   4
+   6.   Exposure of Contents . . . . . . . . . . . . . . . . . . . .   4
+   7.   Zone Size  . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   8.   Single Method  . . . . . . . . . . . . . . . . . . . . . . .   5
+   9.   Empty Non-terminals  . . . . . . . . . . . . . . . . . . . .   5
+   10.  Prevention of Precomputed Dictionary Attacks . . . . . . . .   6
+   11.  DNSSEC-Adoption and Zone-Growth Relationship . . . . . . . .   6
+   12.  Non-overlap of denial records with possible zone records . .   7
+   13.  Exposure of Private Keys . . . . . . . . . . . . . . . . . .   7
+   14.  Minimisation of Zone Signing Cost  . . . . . . . . . . . . .   8
+   15.  Minimisation of Asymmetry  . . . . . . . . . . . . . . . . .   8
+   16.  Minimisation of Client Complexity  . . . . . . . . . . . . .   8
+   17.  Completeness . . . . . . . . . . . . . . . . . . . . . . . .   8
+   18.  Purity of Namespace  . . . . . . . . . . . . . . . . . . . .   8
+   19.  Replay Attacks . . . . . . . . . . . . . . . . . . . . . . .   8
+   20.  Compatibility with NSEC  . . . . . . . . . . . . . . . . . .   8
+   21.  Compatibility with NSEC II . . . . . . . . . . . . . . . . .   9
+   22.  Compatibility with NSEC III  . . . . . . . . . . . . . . . .   9
+   23.  Coexistence with NSEC  . . . . . . . . . . . . . . . . . . .   9
+   24.  Coexistence with NSEC II . . . . . . . . . . . . . . . . . .   9
+   25.  Protocol Design  . . . . . . . . . . . . . . . . . . . . . .   9
+   26.  Process  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
+   27.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .   9
+   28.  Requirements notation  . . . . . . . . . . . . . . . . . . .   9
+   29.  Security Considerations  . . . . . . . . . . . . . . . . . .  10
+   30.  References . . . . . . . . . . . . . . . . . . . . . . . . .  10
+   30.1   Normative References . . . . . . . . . . . . . . . . . . .  10
+   30.2   Informative References . . . . . . . . . . . . . . . . . .  10
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  10
+        Intellectual Property and Copyright Statements . . . . . . .  11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 2]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+1.  Introduction
+
+
+   NSEC records allow trivial enumeration of zones - a situation that
+   has existed for several years but which has recently been raised as a
+   significant concern for DNSSECbis deployment in several zones.
+   Alternate proposals have been made that make zone enumeration more
+   difficult, and some previous proposals to modify DNSSEC had related
+   requirements/desirements that are relevant to the discussion.  In
+   addition the original designs for NSEC/NXT records were based on
+   working group discussions and the choices made were not always
+   documented with context and requirements-- so some of those choices
+   may need to be restated as requirements.  Overall, the working group
+   needs to better understand the requirements for denial of existence
+   (and certain other requirements related to DNSSECbis deployment) in
+   order to evaluate the proposals that may replace NSEC.
+
+
+   In the remainder of this document, "NSEC++" is used as shorthand for
+   "a denial of existence proof that will replace NSEC".  "NSECbis" has
+   also been used as shorthand for this, but we avoid that usage since
+   NSECbis will not be part of DNSSECbis and therefore there might be
+   some confusion.
+
+
+2.  Non-purposes
+
+
+   This document does not currently document the reasons why zone
+   enumeration might be "bad" from a privacy, security, business, or
+   other perspective--except insofar as those reasons result in
+   requirements.  Once the list of requirements is complete and vaguely
+   coherent, the trade-offs (reducing zone enumeration will have X cost,
+   while providing Y benefit) may be revisited.  The editors of this
+   compendium received inputs on the potential reasons why zone
+   enumeration is bad (and there was significant discussion on the
+   DNSEXT WG mailing list) but that information fell outside the scope
+   of this document.
+
+
+   Note also that this document does not assume that NSEC *must* be
+   replaced with NSEC++, if the requirements can be met through other
+   methods (e.g., "white lies" with the current NSEC).  As is stated
+   above, this document is focused on requirements collection and
+   (ideally) prioritization rather than on the actual implementation.
+
+
+3.  Zone Enumeration
+
+
+   Authenticated denial should not permit trivial zone enumeration.
+
+
+   Additional discussion:  NSEC (and NXT before it) provide a linked
+   list that could be "walked" to trivially enumerate all the signed
+   records in a zone.  This requirement is primarily (though not
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 3]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+   exclusively) important for zones that either are delegation-only/
+   -mostly or do not have reverse lookup (PTR) records configured, since
+   enterprises that have PTR records for all A records have already
+   provided a similar capability to enumerate the contents of DNS zones.
+
+
+   Contributor: various
+
+
+4.  Zone Enumeration II
+
+
+   Zone enumeration should be at least as difficult as it would be to
+   effect a dictionary attack using simple DNS queries to do the same in
+   an unsecured zone.
+
+
+   (Editor comment: it is not clear how to measure difficulty in this
+   case.  Some examples could be monetary cost, bandwidth, processing
+   power or some combination of these.  It has also been suggested that
+   the requirement is that the graph of difficulty of enumeration vs.
+   the fraction of the zone enumerated should be approximately the same
+   shape in the two cases)
+
+
+   Contributor: Nominet
+
+
+5.  Zone Enumeration III
+
+
+   Enumeration of a zone with random contents should computationally
+   infeasible.
+
+
+   Editor comment: this is proposed as a way of evaluating the
+   effectiveness of a proposal rather than as a requirement anyone would
+   actually have in practice.
+
+
+   Contributor: Alex Bligh
+
+
+6.  Exposure of Contents
+
+
+   NSEC++ should not expose any of the contents of the zone (apart from
+   the NSEC++ records themselves, of course).
+
+
+   Editor comment: this is a weaker requirement than prevention of
+   enumeration, but certainly any zone that satisfied this requirement
+   would also satisfy the trivial prevention of enumeration requirement.
+
+
+   Contributor: Ed Lewis
+
+
+7.  Zone Size
+
+
+   Requirement:  NSEC++ should make it possible to take precautions
+   against trivial zone size estimates.  Since not all zone owners care
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 4]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+   about others estimation of the size of a zone, it is not always
+   necessary to prohibit trivial estimation of the size of the zone but
+   NSEC++ should allow such measures.
+
+
+   Additional Discussion: Even with proposals based on obfuscating names
+   with hashes it is trivial to give very good estimates of the number
+   of domains in a certain zone.  Just send 10 random queries and look
+   at the range between the two hash values returned in each NSEC++.  As
+   hash output can be assumed to follow a rectangular random
+   distribution, using the mean difference between the two values, you
+   can estimate the total number of records.  It is probably sufficient
+   to look at even one NSEC++, since the two hash values should follow a
+   (I believe) Poisson distribution.
+
+
+   The concern is motivated by some wording remembered from NSEC, which
+   stated that NSEC MUST only be present for existing owner names in the
+   zone, and MUST NOT be present for non-existing owner names.  If
+   similar wording were carried over to NSEC++, introducing bogus owner
+   names in the hash chain (an otherwise simple solution to guard
+   against trivial estimates of zone size) wouldn't be allowed.
+
+
+   One simple attempt at solving this is to describe in the
+   specifications how zone signer tools can add a number of random
+   "junk" records.
+
+
+   Editor's comment: it is interesting that obfuscating names might
+   actually make it easier to estimate zone size.
+
+
+   Contributor: Simon Josefsson.
+
+
+8.  Single Method
+
+
+   Requirement:  A single NSEC++ method must be able to carry both
+   old-style denial (i.e.  plain labels) and whatever the new style
+   looks like.  Having two separate denial methods could result in
+   cornercases where one method can deny the other and vice versa.
+
+
+   Additional discussion:  This requirement can help -bis folks to a
+   smooth upgrade to -ter.  First they'd change the method while the
+   content is the same, then they can change content of the method.
+
+
+   Contributor: Roy Arends.
+
+
+9.  Empty Non-terminals
+
+
+   Requirement:  Empty-non-terminals (ENT) should remain empty.  In
+   other words, adding NSEC++ records to an existing DNS structure
+   should not cause the creation of NSEC++ records (or related records)
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 5]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+   at points that are otherwise ENT.
+
+
+   Additional discussion:  Currently NSEC complies with ENT requirement:
+   b.example.com NSEC a.c.example.com implies the existence of an ENT
+   with ownername c.example.com.  NSEC2 breaks that requirement, since
+   the ownername is entirely hashed causing the structure to disappear.
+   This is why EXIST was introduced.  But EXIST causes ENT to be
+   non-empty-terminals.  Next to the dissappearance of ENT, it causes
+   (some) overhead since an EXIST record needs a SIG, NSEC2 and
+   SIG(NSEC2).  DNSNR honours this requirement by hashing individual
+   labels instead of ownernames.  However this causes very long labels.
+   Truncation is a measure against very long ownernames, but that is
+   controversial.  There is a fair discussion of the validity of
+   truncation in the DNSNR draft, but that hasn't got proper review yet.
+
+
+   Contributor: Roy Arends.
+
+
+   (Editor comment: it is not clear to us that an EXIST record needs an
+   NSEC2 record, since it is a special purpose record only used for
+   denial of existence)
+
+
+10.  Prevention of Precomputed Dictionary Attacks
+
+
+   Requirement:  NSEC++ needs to provide a method to reduce the
+   effectiveness of precomputed dictionary attacks.
+
+
+   Additional Discussion:  Salt is a measure against dictionary attacks.
+   There are other possible measures (such as iterating hashes in
+   NSEC2).  The salt needs to be communicated in every response, since
+   it is needed in every verification.  Some have suggested to move the
+   salt to a special record instead of the denial record.  I think this
+   is not wise.  Response size has more priority over zone size.  An
+   extra record causes a larger response than a larger existing record.
+
+
+   Contributor: Roy Arends.
+
+
+   (Editor comment: the current version of NSEC2 also has the salt in
+   every NSEC2 record)
+
+
+11.  DNSSEC-Adoption and Zone-Growth Relationship
+
+
+   Background:  Currently with NSEC, when a delegation centric zone
+   deploys DNSSEC, the zone-size multiplies by a non-trivial factor even
+   when the DNSSEC-adoption rate of the subzones remains low--because
+   each delegation point creates at least one NSEC record and
+   corresponding signature in the parent even if the child is not
+   signed.
+
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 6]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+   Requirements:  A delegation-only (or delegation-mostly) zone that is
+   signed but which has no signed child zones should initially need only
+   to add SIG(SOA), DNSKEY, and SIG(DNSKEY) at the apex, along with some
+   minimal set of NSEC++ records to cover zone contents.  Further,
+   during the transition of a delegation-only zone from 0% signed
+   children to 100% signed children, the growth in the delegation-only
+   zone should be roughly proportional to the percentage of signed child
+   zones.
+
+
+   Additional Discussion: This is why DNSNR has the Authoritative Only
+   bit.  This is similar to opt-in for delegations only.  This (bit) is
+   currently the only method to help delegation-centric zone cope with
+   zone-growth due to DNSSEC adoption.  As an example, A delegation only
+   zone which deploys DNSSEC with the help of this bit, needs to add
+   SIG(SOA), DNSKEY, SIG(DNSKEY), DNSNR, SIG(DNSNR) at the apex.  No
+   more than that.
+
+
+   Contributor: Roy Arends.
+
+
+12.  Non-overlap of denial records with possible zone records
+
+
+   Requirement:  NSEC++ records should in some way be differentiated
+   from regular zone records, so that there is no possibility that a
+   record in the zone could be duplicated by a non-existence proof
+   (NSEC++) record.
+
+
+   Additional discussion:  This requirement is derived from a discussion
+   on the DNSEXT mailing list related to copyrights and domain names.
+   As was outlined there, one solution is to put NSEC++ records in a
+   separate namespace, e.g.: $ORIGIN co.uk.
+   873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your
+   delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSEC++ 881345...
+   ; for amazon.co.uk.
+
+
+   Contributor: various
+
+
+   (Editor comment:  One of us still does not see why a conflict
+   matters.  Even if there is an apparent conflict or overlap, the
+   "conflicting" NSEC2 name _only_ appears in NSEC2 records, and the
+   other name _never_ appears in NSEC2 records.)
+
+
+13.  Exposure of Private Keys
+
+
+   Private keys associated with the public keys in the DNS should be
+   exposed as little as possible.  It is highly undesirable for private
+   keys to be distributed to nameservers, or to otherwise be available
+   in the run-time environment of nameservers.
+
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 7]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+   Contributors: Nominet, Olaf Kolkman, Ed Lewis
+
+
+14.  Minimisation of Zone Signing Cost
+
+
+   The additional cost of creating an NSEC++ signed zone should not
+   significantly exceed the cost of creating an ordinary signed zone.
+
+
+   Contributor: Nominet
+
+
+15.  Minimisation of Asymmetry
+
+
+   Nameservers should have to do as little additional work as necessary.
+   More precisely, it is desirable for any increase in cost incurred by
+   the nameservers to be offset by a proportionate increase in cost to
+   DNS `clients', e.g.  stub and/or `full-service' resolvers.
+
+
+   Contributor: Nominet
+
+
+16.  Minimisation of Client Complexity
+
+
+   Caching, wildcards, CNAMEs, DNAMEs should continue to work without
+   adding too much complexity at the client side.
+
+
+   Contributor: Olaf Kolkman
+
+
+17.  Completeness
+
+
+   A proof of nonexistence should be possible for all nonexistent data
+   in the zone.
+
+
+   Contributor: Olaf Kolkman
+
+
+18.  Purity of Namespace
+
+
+   The name space should not be muddied with fake names or data sets.
+
+
+   Contributor: Ed Lewis
+
+
+19.  Replay Attacks
+
+
+   NSEC++ should not allow a replay to be used to deny existence of an
+   RR that actually exists.
+
+
+   Contributor: Ed Lewis
+
+
+20.  Compatibility with NSEC
+
+
+   NSEC++ should not introduce changes incompatible with NSEC.
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 8]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+   Contributor: Ed Lewis
+
+
+21.  Compatibility with NSEC II
+
+
+   NSEC++ should differ from NSEC in a way that is transparent to the
+   resolver or validator.
+
+
+   Contributor: Ed Lewis
+
+
+22.  Compatibility with NSEC III
+
+
+   NSEC++ should differ from NSEC as little as possible whilst achieving
+   other requirements.
+
+
+   Contributor: Alex Bligh
+
+
+23.  Coexistence with NSEC
+
+
+   NSEC++ should be optional, allowing NSEC to be used instead.
+
+
+   Contributor: Ed Lewis, Alex Bligh
+
+
+24.  Coexistence with NSEC II
+
+
+   NSEC++ should not impose extra work on those content with NSEC.
+
+
+   Contributor: Ed Lewis
+
+
+25.  Protocol Design
+
+
+   A good security protocol would allow signing the nonexistence of some
+   selected names without revealing anything about other names.
+
+
+   Contributor: Dan Bernstein
+
+
+26.  Process
+
+
+   Clearly not all of these requirements can be met.  Therefore the next
+   phase of this document will be to either prioritise them or narrow
+   them down to a non-contradictory set, which should then allow us to
+   judge proposals on the basis of their fit.
+
+
+27.  Acknowledgements
+
+
+28.  Requirements notation
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                  [Page 9]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+   document are to be interpreted as            described in [RFC2119].
+
+
+29.  Security Considerations
+
+
+   There are currently no security considerations called out in this
+   draft.  There will be security considerations in the choice of which
+   requirements will be implemented, but there are no specific security
+   requirements during the requirements collection process.
+
+
+30.  References
+
+
+30.1  Normative References
+
+
+   [dnssecbis-protocol]
+              "DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some
+              Month 2004.
+
+
+30.2  Informative References
+
+
+   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
+              3", BCP 9, RFC 2026, October 1996.
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
+              Procedures", BCP 25, RFC 2418, September 1998.
+
+
+
+Authors' Addresses
+
+
+   Ben Laurie
+   Nominet
+   17 Perryn Road
+   London  W3 7LR
+   England
+
+
+   Phone: +44 (20) 8735 0686
+   EMail: ben@algroup.co.uk
+
+
+
+   Rip Loomis
+   Science Applications International Corporation
+   7125 Columbia Gateway Drive, Suite 300
+   Columbia, MD  21046
+   US
+
+
+   EMail: gilbert.r.loomis@saic.com
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                 [Page 10]
+Internet-Draft      signed-nonexistence-requirements      September 2004
+
+
+
+Intellectual Property Statement
+
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+Disclaimer of Validity
+
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+Copyright Statement
+
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+
+Acknowledgment
+
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+Laurie & Loomis          Expires March 2, 2005                 [Page 11]

doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt

@@ -0,0 +1,729 @@
+
+
+
+Network Working Group                                         M. StJohns
+Internet-Draft                                             Nominum, Inc.
+Intended status: Informational                         November 29, 2006
+Expires: June 2, 2007
+
+
+               Automated Updates of DNSSEC Trust Anchors
+                draft-ietf-dnsext-trustupdate-timers-05
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on June 2, 2007.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes a means for automated, authenticated and
+   authorized updating of DNSSEC "trust anchors".  The method provides
+   protection against N-1 key compromises of N keys in the trust point
+   key set.  Based on the trust established by the presence of a current
+   anchor, other anchors may be added at the same place in the
+   hierarchy, and, ultimately, supplant the existing anchor(s).
+
+   This mechanism will require changes to resolver management behavior
+
+
+
+StJohns                   Expires June 2, 2007                  [Page 1]
+
+Internet-Draft             trustanchor-update              November 2006
+
+
+   (but not resolver resolution behavior), and the addition of a single
+   flag bit to the DNSKEY record.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Compliance Nomenclature  . . . . . . . . . . . . . . . . .  3
+   2.  Theory of Operation  . . . . . . . . . . . . . . . . . . . . .  4
+     2.1.  Revocation . . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.2.  Add Hold-Down  . . . . . . . . . . . . . . . . . . . . . .  5
+     2.3.  Active Refresh . . . . . . . . . . . . . . . . . . . . . .  5
+     2.4.  Resolver Parameters  . . . . . . . . . . . . . . . . . . .  6
+       2.4.1.  Add Hold-Down Time . . . . . . . . . . . . . . . . . .  6
+       2.4.2.  Remove Hold-Down Time  . . . . . . . . . . . . . . . .  6
+       2.4.3.  Minimum Trust Anchors per Trust Point  . . . . . . . .  6
+   3.  Changes to DNSKEY RDATA Wire Format  . . . . . . . . . . . . .  6
+   4.  State Table  . . . . . . . . . . . . . . . . . . . . . . . . .  6
+     4.1.  Events . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+     4.2.  States . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+   5.  Trust Point Deletion . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Scenarios - Informative  . . . . . . . . . . . . . . . . . . .  9
+     6.1.  Adding a Trust Anchor  . . . . . . . . . . . . . . . . . .  9
+     6.2.  Deleting a Trust Anchor  . . . . . . . . . . . . . . . . .  9
+     6.3.  Key Roll-Over  . . . . . . . . . . . . . . . . . . . . . . 10
+     6.4.  Active Key Compromised . . . . . . . . . . . . . . . . . . 10
+     6.5.  Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10
+     6.6.  Trust Point Deletion . . . . . . . . . . . . . . . . . . . 10
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
+     8.1.  Key Ownership vs Acceptance Policy . . . . . . . . . . . . 11
+     8.2.  Multiple Key Compromise  . . . . . . . . . . . . . . . . . 11
+     8.3.  Dynamic Updates  . . . . . . . . . . . . . . . . . . . . . 11
+   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 12
+   Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
+   Intellectual Property and Copyright Statements . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+StJohns                   Expires June 2, 2007                  [Page 2]
+
+Internet-Draft             trustanchor-update              November 2006
+
+
+1.  Introduction
+
+   As part of the reality of fielding DNSSEC (Domain Name System
+   Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has
+   come to the realization that there will not be one signed name space,
+   but rather islands of signed name space each originating from
+   specific points (i.e. 'trust points') in the DNS tree.  Each of those
+   islands will be identified by the trust point name, and validated by
+   at least one associated public key.  For the purpose of this document
+   we'll call the association of that name and a particular key a 'trust
+   anchor'.  A particular trust point can have more than one key
+   designated as a trust anchor.
+
+   For a DNSSEC-aware resolver to validate information in a DNSSEC
+   protected branch of the hierarchy, it must have knowledge of a trust
+   anchor applicable to that branch.  It may also have more than one
+   trust anchor for any given trust point.  Under current rules, a chain
+   of trust for DNSSEC-protected data that chains its way back to ANY
+   known trust anchor is considered 'secure'.
+
+   Because of the probable balkanization of the DNSSEC tree due to
+   signing voids at key locations, a resolver may need to know literally
+   thousands of trust anchors to perform its duties. (e.g.  Consider an
+   unsigned ".COM".)  Requiring the owner of the resolver to manually
+   manage this many relationships is problematic.  It's even more
+   problematic when considering the eventual requirement for key
+   replacement/update for a given trust anchor.  The mechanism described
+   herein won't help with the initial configuration of the trust anchors
+   in the resolvers, but should make trust point key replacement/
+   rollover more viable.
+
+   As mentioned above, this document describes a mechanism whereby a
+   resolver can update the trust anchors for a given trust point, mainly
+   without human intervention at the resolver.  There are some corner
+   cases discussed (e.g. multiple key compromise) that may require
+   manual intervention, but they should be few and far between.  This
+   document DOES NOT discuss the general problem of the initial
+   configuration of trust anchors for the resolver.
+
+1.1.  Compliance Nomenclature
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, [RFC2119].
+
+
+
+
+
+
+
+StJohns                   Expires June 2, 2007                  [Page 3]
+
+Internet-Draft             trustanchor-update              November 2006
+
+
+2.  Theory of Operation
+
+   The general concept of this mechanism is that existing trust anchors
+   can be used to authenticate new trust anchors at the same point in
+   the DNS hierarchy.  When a zone operator adds a new SEP key (i.e. a
+   DNSKEY with the Secure Entry Point bit set) (see [RFC4034]section
+   2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is
+   validated by an existing trust anchor, then the resolver can add the
+   new key to its valid set of trust anchors for that trust point.
+
+   There are some issues with this approach which need to be mitigated.
+   For example, a compromise of one of the existing keys could allow an
+   attacker to add their own 'valid' data.  This implies a need for a
+   method to revoke an existing key regardless of whether or not that
+   key is compromised.  As another example, assuming a single key
+   compromise, we need to prevent an attacker from adding a new key and
+   revoking all the other old keys.
+
+2.1.  Revocation
+
+   Assume two trust anchor keys A and B. Assume that B has been
+   compromised.  Without a specific revocation bit, B could invalidate A
+   simply by sending out a signed trust point key set which didn't
+   contain A. To fix this, we add a mechanism which requires knowledge
+   of the private key of a DNSKEY to revoke that DNSKEY.
+
+   A key is considered revoked when the resolver sees the key in a self-
+   signed RRSet and the key has the REVOKE bit (see Section 7 below) set
+   to '1'.  Once the resolver sees the REVOKE bit, it MUST NOT use this
+   key as a trust anchor or for any other purposes except validating the
+   RRSIG it signed over the DNSKEY RRSet specifically for the purpose of
+   validating the revocation.  Unlike the 'Add' operation below,
+   revocation is immediate and permanent upon receipt of a valid
+   revocation at the resolver.
+
+   A self-signed RRSet is a DNSKEY RRSet which contains the specific
+   DNSKEY and for which there is a corresponding validated RRSIG record.
+   It's not a special DNSKEY RRSet, just a way of describing the
+   validation requirements for that RRSet.
+
+   N.B. A DNSKEY with the REVOKE bit set has a different fingerprint
+   than one without the bit set.  This affects the matching of a DNSKEY
+   to DS records in the parent, or the fingerprint stored at a resolver
+   used to configure a trust point.
+
+   In the given example, the attacker could revoke B because it has
+   knowledge of B's private key, but could not revoke A.
+
+
+
+
+StJohns                   Expires June 2, 2007                  [Page 4]
+
+Internet-Draft             trustanchor-update              November 2006
+
+
+2.2.  Add Hold-Down
+
+   Assume two trust point keys A and B. Assume that B has been
+   compromised.  An attacker could generate and add a new trust anchor
+   key - C (by adding C to the DNSKEY RRSet and signing it with B), and
+   then invalidate the compromised key.  This would result in both the
+   attacker and owner being able to sign data in the zone and have it
+   accepted as valid by resolvers.
+
+   To mitigate but not completely solve this problem, we add a hold-down
+   time to the addition of the trust anchor.  When the resolver sees a
+   new SEP key in a validated trust point DNSKEY RRSet, the resolver
+   starts an acceptance timer, and remembers all the keys that validated
+   the RRSet.  If the resolver ever sees the DNSKEY RRSet without the
+   new key but validly signed, it stops the acceptance process for that
+   key and resets the acceptance timer.  If all of the keys which were
+   originally used to validate this key are revoked prior to the timer
+   expiring, the resolver stops the acceptance process and resets the
+   timer.
+
+   Once the timer expires, the new key will be added as a trust anchor
+   the next time the validated RRSet with the new key is seen at the
+   resolver.  The resolver MUST NOT treat the new key as a trust anchor
+   until the hold down time expires AND it has retrieved and validated a
+   DNSKEY RRSet after the hold down time which contains the new key.
+
+   N.B.: Once the resolver has accepted a key as a trust anchor, the key
+   MUST be considered a valid trust anchor by that resolver until
+   explictly revoked as described above.
+
+   In the given example, the zone owner can recover from a compromise by
+   revoking B and adding a new key D and signing the DNSKEY RRSet with
+   both A and B.
+
+   The reason this does not completely solve the problem has to do with
+   the distributed nature of DNS.  The resolver only knows what it sees.
+   A determined attacker who holds one compromised key could keep a
+   single resolver from realizing that key had been compromised by
+   intercepting 'real' data from the originating zone and substituting
+   their own (e.g. using the example, signed only by B).  This is no
+   worse than the current situation assuming a compromised key.
+
+2.3.  Active Refresh
+
+   A resolver which has been configured for automatic update of keys
+   from a particular trust point MUST query that trust point (e.g. do a
+   lookup for the DNSKEY RRSet and related RRSIG records) no less often
+   than the lesser of 15 days or half the original TTL for the DNSKEY
+
+
+
+StJohns                   Expires June 2, 2007                  [Page 5]
+
+Internet-Draft             trustanchor-update              November 2006
+
+
+   RRSet or half the RRSIG expiration interval and no more often than
+   once per hour.  The expiration interval is the amount of time from
+   when the RRSIG was last retrieved until the expiration time in the
+   RRSIG.
+
+   If the query fails, the resolver MUST repeat the query until
+   satisfied no more often than once an hour and no less often than the
+   lesser of 1 day or 10% of the original TTL or 10% of the original
+   expiration interval.  I.e.: retryTime = MAX (1 hour, MIN (1 day, .1 *
+   origTTL, .1 * expireInterval)).
+
+2.4.  Resolver Parameters
+
+2.4.1.  Add Hold-Down Time
+
+   The add hold-down time is 30 days or the expiration time of the
+   original TTL of the first trust point DNSKEY RRSet which contained
+   the new key, whichever is greater.  This ensures that at least two
+   validated DNSKEY RRSets which contain the new key MUST be seen by the
+   resolver prior to the key's acceptance.
+
+2.4.2.  Remove Hold-Down Time
+
+   The remove hold-down time is 30 days.  This parameter is solely a key
+   management database bookeeping parameter.  Failure to remove
+   information about the state of defunct keys from the database will
+   not adversely impact the security of this protocol, but may end up
+   with a database cluttered with obsolete key information.
+
+2.4.3.  Minimum Trust Anchors per Trust Point
+
+   A compliant resolver MUST be able to manage at least five SEP keys
+   per trust point.
+
+
+3.  Changes to DNSKEY RDATA Wire Format
+
+   Bit n [msj2]of the DNSKEY Flags field is designated as the 'REVOKE'
+   flag.  If this bit is set to '1', AND the resolver sees an
+   RRSIG(DNSKEY) signed by the associated key, then the resolver MUST
+   consider this key permanently invalid for all purposes except for
+   validating the revocation.
+
+
+4.  State Table
+
+   The most important thing to understand is the resolver's view of any
+   key at a trust point.  The following state table describes that view
+
+
+
+StJohns                   Expires June 2, 2007                  [Page 6]
+
+Internet-Draft             trustanchor-update              November 2006
+
+
+   at various points in the key's lifetime.  The table is a normative
+   part of this specification.  The initial state of the key is 'Start'.
+   The resolver's view of the state of the key changes as various events
+   occur.
+
+   This is the state of a trust point key as seen from the resolver.
+   The column on the left indicates the current state.  The header at
+   the top shows the next state.  The intersection of the two shows the
+   event that will cause the state to transition from the current state
+   to the next.
+
+
+                             NEXT STATE
+           --------------------------------------------------
+    FROM   |Start  |AddPend |Valid  |Missing|Revoked|Removed|
+   ----------------------------------------------------------
+   Start   |       |NewKey  |       |       |       |       |
+   ----------------------------------------------------------
+   AddPend |KeyRem |        |AddTime|       |       |
+   ----------------------------------------------------------
+   Valid   |       |        |       |KeyRem |Revbit |       |
+   ----------------------------------------------------------
+   Missing |       |        |KeyPres|       |Revbit |       |
+   ----------------------------------------------------------
+   Revoked |       |        |       |       |       |RemTime|
+   ----------------------------------------------------------
+   Removed |       |        |       |       |       |       |
+   ----------------------------------------------------------
+
+
+                                State Table
+
+4.1.  Events
+   NewKey  The resolver sees a valid DNSKEY RRSet with a new SEP key.
+      That key will become a new trust anchor for the named trust point
+      after it's been present in the RRSet for at least 'add time'.
+   KeyPres  The key has returned to the valid DNSKEY RRSet.
+   KeyRem  The resolver sees a valid DNSKEY RRSet that does not contain
+      this key.
+   AddTime  The key has been in every valid DNSKEY RRSet seen for at
+      least the 'add time'.
+   RemTime  A revoked key has been missing from the trust point DNSKEY
+      RRSet for sufficient time to be removed from the trust set.
+   RevBit  The key has appeared in the trust anchor DNSKEY RRSet with
+      its "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
+      signed by this key.
+
+
+
+
+
+StJohns                   Expires June 2, 2007                  [Page 7]
+
+Internet-Draft             trustanchor-update              November 2006
+
+
+4.2.  States
+   Start  The key doesn't yet exist as a trust anchor at the resolver.
+      It may or may not exist at the zone server, but either hasn't yet
+      been seen at the resolver or was seen but was absent from the last
+      DNSKEY RRSet (e.g.  KeyRem event).
+   AddPend  The key has been seen at the resolver, has its 'SEP' bit
+      set, and has been included in a validated DNSKEY RRSet.  There is
+      a hold-down time for the key before it can be used as a trust
+      anchor.
+   Valid  The key has been seen at the resolver and has been included in
+      all validated DNSKEY RRSets from the time it was first seen up
+      through the hold-down time.  It is now valid for verifying RRSets
+      that arrive after the hold down time.  Clarification: The DNSKEY
+      RRSet does not need to be continuously present at the resolver
+      (e.g. its TTL might expire).  If the RRSet is seen, and is
+      validated (i.e. verifies against an existing trust anchor), this
+      key MUST be in the RRSet otherwise a 'KeyRem' event is triggered.
+   Missing  This is an abnormal state.  The key remains as a valid trust
+      point key, but was not seen at the resolver in the last validated
+      DNSKEY RRSet.  This is an abnormal state because the zone operator
+      should be using the REVOKE bit prior to removal.
+   Revoked  This is the state a key moves to once the resolver sees an
+      RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
+      this key with its REVOKE bit set to '1'.  Once in this state, this
+      key MUST permanently be considered invalid as a trust anchor.
+   Removed  After a fairly long hold-down time, information about this
+      key may be purged from the resolver.  A key in the removed state
+      MUST NOT be considered a valid trust anchor.  (Note: this state is
+      more or less equivalent to the "Start" state, except that it's bad
+      practice to re-introduce previously used keys - think of this as
+      the holding state for all the old keys for which the resolver no
+      longer needs to track state.)
+
+
+5.  Trust Point Deletion
+
+   A trust point which has all of its trust anchors revoked is
+   considered deleted and is treated as if the trust point was never
+   configured.  If there are no superior configured trust points, data
+   at and below the deleted trust point are considered insecure by the
+   resolver.  If there ARE superior configured trust points, data at and
+   below the deleted trust point are evaluated with respect to the
+   superior trust point(s).
+
+   Alternately, a trust point which is subordinate to another configured
+   trust point MAY be deleted by a resolver after 180 days where such
+   subordinate trust point validly chains to a superior trust point.
+   The decision to delete the subordinate trust anchor is a local
+
+
+
+StJohns                   Expires June 2, 2007                  [Page 8]
+
+Internet-Draft             trustanchor-update              November 2006
+
+
+   configuration decision.  Once the subordinate trust point is deleted,
+   validation of the subordinate zone is dependent on validating the
+   chain of trust to the superior trust point.
+
+
+6.  Scenarios - Informative
+
+   The suggested model for operation is to have one active key and one
+   stand-by key at each trust point.  The active key will be used to
+   sign the DNSKEY RRSet.  The stand-by key will not normally sign this
+   RRSet, but the resolver will accept it as a trust anchor if/when it
+   sees the signature on the trust point DNSKEY RRSet.
+
+   Since the stand-by key is not in active signing use, the associated
+   private key may (and should) be provided with additional protections
+   not normally available to a key that must be used frequently.  E.g.
+   locked in a safe, split among many parties, etc.  Notionally, the
+   stand-by key should be less subject to compromise than an active key,
+   but that will be dependent on operational concerns not addressed
+   here.
+
+6.1.  Adding a Trust Anchor
+
+   Assume an existing trust anchor key 'A'.
+   1.  Generate a new key pair.
+   2.  Create a DNSKEY record from the key pair and set the SEP and Zone
+       Key bits.
+   3.  Add the DNSKEY to the RRSet.
+   4.  Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
+       'A'.
+   5.  Wait a while (i.e. for various resolvers timers to go off and for
+       them to retrieve the new DNSKEY RRSet and signatures).
+   6.  The new trust anchor will be populated at the resolvers on the
+       schedule described by the state table and update algorithm - see
+       Section 2 above
+
+6.2.  Deleting a Trust Anchor
+
+   Assume existing trust anchors 'A' and 'B' and that you want to revoke
+   and delete 'A'.
+   1.  Set the revocation bit on key 'A'.
+   2.  Sign the DNSKEY RRSet with both 'A' and 'B'.
+   'A' is now revoked.  The operator should include the revoked 'A' in
+   the RRSet for at least the remove hold-down time, but then may remove
+   it from the DNSKEY RRSet.
+
+
+
+
+
+
+StJohns                   Expires June 2, 2007                  [Page 9]
+
+Internet-Draft             trustanchor-update              November 2006
+
+
+6.3.  Key Roll-Over
+
+   Assume existing keys A and B. 'A' is actively in use (i.e. has been
+   signing the DNSKEY RRSet.)  'B' was the stand-by key. (i.e. has been
+   in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
+   used to sign the RRSet.)
+   1.  Generate a new key pair 'C'.
+   2.  Add 'C' to the DNSKEY RRSet.
+   3.  Set the revocation bit on key 'A'.
+   4.  Sign the RRSet with 'A' and 'B'.
+   'A' is now revoked, 'B' is now the active key, and 'C' will be the
+   stand-by key once the hold-down expires.  The operator should include
+   the revoked 'A' in the RRSet for at least the remove hold-down time,
+   but may then remove it from the DNSKEY RRSet.
+
+6.4.  Active Key Compromised
+
+   This is the same as the mechanism for Key Roll-Over (Section 6.3)
+   above assuming 'A' is the active key.
+
+6.5.  Stand-by Key Compromised
+
+   Using the same assumptions and naming conventions as Key Roll-Over
+   (Section 6.3) above:
+   1.  Generate a new key pair 'C'.
+   2.  Add 'C' to the DNSKEY RRSet.
+   3.  Set the revocation bit on key 'B'.
+   4.  Sign the RRSet with 'A' and 'B'.
+   'B' is now revoked, 'A' remains the active key, and 'C' will be the
+   stand-by key once the hold-down expires.  'B' should continue to be
+   included in the RRSet for the remove hold-down time.
+
+6.6.  Trust Point Deletion
+
+   To delete a trust point which is subordinate to another configured
+   trust point (e.g. example.com to .com) requires some juggling of the
+   data.  The specific process is:
+   1.  Generate a new DNSKEY and DS record and provide the DS record to
+       the parent along with DS records for the old keys
+   2.  Once the parent has published the DSs, add the new DNSKEY to the
+       RRSet and revoke ALL of the old keys at the same time while
+       signing the DNSKEY RRSet with all of the old and new keys.
+   3.  After 30 days stop publishing the old, revoked keys and remove
+       any corresponding DS records in the parent.
+   Revoking the old trust point keys at the same time as adding new keys
+   that chain to a superior trust prevents the resolver from adding the
+   new keys as trust anchors.  Adding DS records for the old keys avoids
+   a race condition where either the subordinate zone becomes unsecure
+
+
+
+StJohns                   Expires June 2, 2007                 [Page 10]
+
+Internet-Draft             trustanchor-update              November 2006
+
+
+   (because the trust point was deleted) or becomes bogus (because it
+   didn't chain to the superior zone).
+
+
+7.  IANA Considerations
+
+   The IANA will need to assign a bit in the DNSKEY flags field (see
+   section 4.3 of [RFC3755]) for the REVOKE bit.  There are no other
+   IANA actions required.
+
+
+8.  Security Considerations
+
+   In addition to the following sections, see also Theory of Operation
+   above and especially Section 2.2 for related discussions.
+
+8.1.  Key Ownership vs Acceptance Policy
+
+   The reader should note that, while the zone owner is responsible for
+   creating and distributing keys, it's wholly the decision of the
+   resolver owner as to whether to accept such keys for the
+   authentication of the zone information.  This implies the decision to
+   update trust anchor keys based on trust for a current trust anchor
+   key is also the resolver owner's decision.
+
+   The resolver owner (and resolver implementers) MAY choose to permit
+   or prevent key status updates based on this mechanism for specific
+   trust points.  If they choose to prevent the automated updates, they
+   will need to establish a mechanism for manual or other out-of-band
+   updates outside the scope of this document.
+
+8.2.  Multiple Key Compromise
+
+   This scheme permits recovery as long as at least one valid trust
+   anchor key remains uncompromised.  E.g. if there are three keys, you
+   can recover if two of them are compromised.  The zone owner should
+   determine their own level of comfort with respect to the number of
+   active valid trust anchors in a zone and should be prepared to
+   implement recovery procedures once they detect a compromise.  A
+   manual or other out-of-band update of all resolvers will be required
+   if all trust anchor keys at a trust point are compromised.
+
+8.3.  Dynamic Updates
+
+   Allowing a resolver to update its trust anchor set based on in-band
+   key information is potentially less secure than a manual process.
+   However, given the nature of the DNS, the number of resolvers that
+   would require update if a trust anchor key were compromised, and the
+
+
+
+StJohns                   Expires June 2, 2007                 [Page 11]
+
+Internet-Draft             trustanchor-update              November 2006
+
+
+   lack of a standard management framework for DNS, this approach is no
+   worse than the existing situation.
+
+
+9.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
+              Signer (DS)", RFC 3755, May 2004.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, March 2005.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+Editorial Comments
+
+   [msj2]  msj: To be assigned.
+
+
+Author's Address
+
+   Michael StJohns
+   Nominum, Inc.
+   2385 Bay Road
+   Redwood City, CA  94063
+   USA
+
+   Phone: +1-301-528-4729
+   Email: Mike.StJohns@nominum.com
+   URI:   www.nominum.com
+
+
+
+
+
+
+
+
+
+
+
+StJohns                   Expires June 2, 2007                 [Page 12]
+
+Internet-Draft             trustanchor-update              November 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+StJohns                   Expires June 2, 2007                 [Page 13]
+
+

doc/draft/draft-ietf-dnsop-default-local-zones-05.txt

@@ -0,0 +1,672 @@
+
+
+
+Network Working Group                                         M. Andrews
+Internet-Draft                                                       ISC
+Intended status: BCP                                        June 5, 2008
+Expires: December 7, 2008
+
+
+                        Locally-served DNS Zones
+                draft-ietf-dnsop-default-local-zones-05
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on December 7, 2008.
+
+Abstract
+
+   Experience has shown that there are a number of DNS zones all
+   iterative resolvers and recursive nameservers should, unless
+   configured otherwise, automatically serve.  RFC 4193 specifies that
+   this should occur for D.F.IP6.ARPA.  This document extends the
+   practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space
+   and other well known zones with similar characteristics.
+
+
+
+
+
+
+
+
+
+Andrews                 Expires December 7, 2008                [Page 1]
+
+Internet-Draft          Locally-served DNS Zones               June 2008
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Effects on sites using RFC 1918 addresses. . . . . . . . . . .  4
+   3.  Changes to Iterative Resolver Behaviour. . . . . . . . . . . .  4
+   4.  Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . .  5
+     4.1.  RFC 1918 Zones . . . . . . . . . . . . . . . . . . . . . .  5
+     4.2.  RFC 3330 Zones . . . . . . . . . . . . . . . . . . . . . .  6
+     4.3.  Local IPv6 Unicast Addresses . . . . . . . . . . . . . . .  6
+     4.4.  IPv6 Locally Assigned Local Addresses  . . . . . . . . . .  6
+     4.5.  IPv6 Link Local Addresses  . . . . . . . . . . . . . . . .  7
+   5.  Zones that are Out-Of-Scope  . . . . . . . . . . . . . . . . .  7
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
+     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
+   Appendix A.  Change History [To Be Removed on Publication] . . . . 10
+     A.1.  draft-ietf-dnsop-default-local-zones-05.txt  . . . . . . . 10
+     A.2.  draft-ietf-dnsop-default-local-zones-04.txt  . . . . . . . 10
+     A.3.  draft-ietf-dnsop-default-local-zones-03.txt  . . . . . . . 10
+     A.4.  draft-ietf-dnsop-default-local-zones-02.txt  . . . . . . . 10
+     A.5.  draft-ietf-dnsop-default-local-zones-01.txt  . . . . . . . 11
+     A.6.  draft-ietf-dnsop-default-local-zones-00.txt  . . . . . . . 11
+     A.7.  draft-andrews-full-service-resolvers-03.txt  . . . . . . . 11
+     A.8.  draft-andrews-full-service-resolvers-02.txt  . . . . . . . 11
+   Appendix B.  Proposed Status [To Be Removed on Publication]  . . . 11
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   Intellectual Property and Copyright Statements . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andrews                 Expires December 7, 2008                [Page 2]
+
+Internet-Draft          Locally-served DNS Zones               June 2008
+
+
+1.  Introduction
+
+   Experience has shown that there are a number of DNS [RFC 1034] [RFC
+   1035] zones that all iterative resolvers and recursive nameservers
+   SHOULD, unless intentionally configured otherwise, automatically
+   serve.  These zones include, but are not limited to, the IN-ADDR.ARPA
+   zones for the address space allocated by [RFC 1918] and the IP6.ARPA
+   zones for locally assigned unique local IPv6 addresses, [RFC 4193].
+
+   This recommendation is made because data has shown that significant
+   leakage of queries for these name spaces is occurring, despite
+   instructions to restrict them, and because it has therefore become
+   necessary to deploy sacrificial name servers to protect the immediate
+   parent name servers for these zones from excessive, unintentional,
+   query load [AS112] [I-D.draft-ietf-dnsop-as112-ops]
+   [I-D.draft-ietf-dnsop-as112-under-attack-help-help].  There is every
+   expectation that the query load will continue to increase unless
+   steps are taken as outlined here.
+
+   Additionally, queries from clients behind badly configured firewalls
+   that allow outgoing queries for these name spaces but drop the
+   responses, put a significant load on the root servers (forward but no
+   reverse zones configured).  They also cause operational load for the
+   root server operators as they have to reply to enquiries about why
+   the root servers are "attacking" these clients.  Changing the default
+   configuration will address all these issues for the zones listed in
+   Section 4.
+
+   [RFC 4193] recommends that queries for D.F.IP6.ARPA be handled
+   locally.  This document extends the recommendation to cover the IN-
+   ADDR.ARPA zones for [RFC 1918] and other well known IN-ADDR.ARPA and
+   IP6.ARPA zones for which queries should not appear on the public
+   Internet.
+
+   It is hoped that by doing this the number of sacrificial servers
+   [AS112] will not have to be increased, and may in time be reduced.
+
+   This recommendation should also help DNS responsiveness for sites
+   which are using [RFC 1918] addresses but do not follow the last
+   paragraph in Section 3 of [RFC 1918].
+
+1.1.  Reserved Words
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+
+
+
+
+Andrews                 Expires December 7, 2008                [Page 3]
+
+Internet-Draft          Locally-served DNS Zones               June 2008
+
+
+2.  Effects on sites using RFC 1918 addresses.
+
+   For most sites using [RFC 1918] addresses, the changes here will have
+   little or no detrimental effect.  If the site does not already have
+   the reverse tree populated the only effect will be that the name
+   error responses will be generated locally rather than remotely.
+
+   For sites that do have the reverse tree populated, most will either
+   have a local copy of the zones or will be forwarding the queries to
+   servers which have local copies of the zone.  Therefore this
+   recommendation will not be relevant.
+
+   The most significant impact will be felt at sites that make use of
+   delegations for [RFC 1918] addresses and have populated these zones.
+   These sites will need to override the default configuration expressed
+   in this document to allow resolution to continue.  Typically, such
+   sites will be fully disconnected from the Internet and have their own
+   root servers for their own non-Internet DNS tree.
+
+
+3.  Changes to Iterative Resolver Behaviour.
+
+   Unless configured otherwise, an iterative resolver will now return
+   authoritatively (aa=1) name errors (RCODE=3) for queries within the
+   zones in Section 4, with the obvious exception of queries for the
+   zone name itself where SOA, NS and "no data" responses will be
+   returned as appropriate to the query type.  One common way to do this
+   is to serve empty (SOA and NS only) zones.
+
+   An implementation of this recommendation MUST provide a mechanism to
+   disable this new behaviour, and SHOULD allow this decision on a zone
+   by zone basis.
+
+   If using empty zones one SHOULD NOT use the same NS and SOA records
+   as used on the public Internet servers as that will make it harder to
+   detect the origin of the responses and thus any leakage to the public
+   Internet servers.  This document recommends that the NS record
+   defaults to the name of the zone and the SOA MNAME defaults to the
+   name of the only NS RR's target.  The SOA RNAME should default to
+   "nobody.invalid."  [RFC 2606].  Implementations SHOULD provide a
+   mechanism to set these values.  No address records need to be
+   provided for the name server.
+
+   Below is an example of a generic empty zone in master file format.
+   It will produce a negative cache TTL of 3 hours.
+
+   @ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800
+   @ 10800 IN NS @
+
+
+
+Andrews                 Expires December 7, 2008                [Page 4]
+
+Internet-Draft          Locally-served DNS Zones               June 2008
+
+
+   The SOA RR is needed to support negative caching [RFC 2308] of name
+   error responses and to point clients to the primary master for DNS
+   dynamic updates.
+
+   SOA values of particular importance are the MNAME, the SOA RR's TTL
+   and the negTTL value.  Both TTL values SHOULD match.  The rest of the
+   SOA timer values MAY be chosen arbitrarily since they are not
+   intended to control any zone transfer activity.
+
+   The NS RR is needed as some UPDATE [RFC 2136] clients use NS queries
+   to discover the zone to be updated.  Having no address records for
+   the name server is expected to abort UPDATE processing in the client.
+
+
+4.  Lists Of Zones Covered
+
+   The following subsections are intended to seed the IANA registry as
+   requested in the IANA Considerations Section.  The zone name is the
+   entity to be registered.
+
+4.1.  RFC 1918 Zones
+
+   The following zones correspond to the IPv4 address space reserved in
+   [RFC 1918].
+
+                         +----------------------+
+                         | Zone                 |
+                         +----------------------+
+                         | 10.IN-ADDR.ARPA      |
+                         | 16.172.IN-ADDR.ARPA  |
+                         | 17.172.IN-ADDR.ARPA  |
+                         | 18.172.IN-ADDR.ARPA  |
+                         | 19.172.IN-ADDR.ARPA  |
+                         | 20.172.IN-ADDR.ARPA  |
+                         | 21.172.IN-ADDR.ARPA  |
+                         | 22.172.IN-ADDR.ARPA  |
+                         | 23.172.IN-ADDR.ARPA  |
+                         | 24.172.IN-ADDR.ARPA  |
+                         | 25.172.IN-ADDR.ARPA  |
+                         | 26.172.IN-ADDR.ARPA  |
+                         | 27.172.IN-ADDR.ARPA  |
+                         | 28.172.IN-ADDR.ARPA  |
+                         | 29.172.IN-ADDR.ARPA  |
+                         | 30.172.IN-ADDR.ARPA  |
+                         | 31.172.IN-ADDR.ARPA  |
+                         | 168.192.IN-ADDR.ARPA |
+                         +----------------------+
+
+
+
+
+Andrews                 Expires December 7, 2008                [Page 5]
+
+Internet-Draft          Locally-served DNS Zones               June 2008
+
+
+4.2.  RFC 3330 Zones
+
+   The following zones correspond to those address ranges from [RFC
+   3330] that are not expected to appear as source or destination
+   addresses on the public Internet and to not have a unique name to
+   associate with.
+
+   The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not a
+   attempt to discourage any practice to provide a PTR RR for
+   1.0.0.127.IN-ADDR.ARPA locally.  In fact, a meaningful reverse
+   mapping should exist, but the exact setup is out of the scope of this
+   document.  Similar logic applies to the reverse mapping for ::1
+   (Section 4.3).  The recommendations made here simply assume no other
+   coverage for these domains exists.
+
+         +------------------------------+------------------------+
+         | Zone                         | Description            |
+         +------------------------------+------------------------+
+         | 0.IN-ADDR.ARPA               | IPv4 "THIS" NETWORK    |
+         | 127.IN-ADDR.ARPA             | IPv4 LOOP-BACK NETWORK |
+         | 254.169.IN-ADDR.ARPA         | IPv4 LINK LOCAL        |
+         | 2.0.192.IN-ADDR.ARPA         | IPv4 TEST NET          |
+         | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST         |
+         +------------------------------+------------------------+
+
+4.3.  Local IPv6 Unicast Addresses
+
+   The reverse mappings ([RFC 3596], Section 2.5 IP6.ARPA Domain) for
+   the IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC 4291],
+   Sections 2.4, 2.5.2 and 2.5.3) are covered by these two zones:
+
+               +-------------------------------------------+
+               | Zone                                      |
+               +-------------------------------------------+
+               | 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
+               | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA          |
+               | 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
+               | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA          |
+               +-------------------------------------------+
+
+   Note: Line breaks and a escapes '\' have been inserted above for
+   readability and to adhere to line width constraints.  They are not
+   parts of the zone names.
+
+4.4.  IPv6 Locally Assigned Local Addresses
+
+   Section 4.4 of [RFC 4193] already required special treatment of:
+
+
+
+
+Andrews                 Expires December 7, 2008                [Page 6]
+
+Internet-Draft          Locally-served DNS Zones               June 2008
+
+
+                             +--------------+
+                             | Zone         |
+                             +--------------+
+                             | D.F.IP6.ARPA |
+                             +--------------+
+
+4.5.  IPv6 Link Local Addresses
+
+   IPv6 Link-Local Addresses as of [RFC 4291], Section 2.5.6 are covered
+   by four distinct reverse DNS zones:
+
+                            +----------------+
+                            | Zone           |
+                            +----------------+
+                            | 8.E.F.IP6.ARPA |
+                            | 9.E.F.IP6.ARPA |
+                            | A.E.F.IP6.ARPA |
+                            | B.E.F.IP6.ARPA |
+                            +----------------+
+
+
+5.  Zones that are Out-Of-Scope
+
+   IPv6 site-local addresses, [RFC 4291] Sections 2.4 and 2.5.7, and
+   IPv6 Non-Locally Assigned Local addresses [RFC 4193] are not covered
+   here.  It is expected that IPv6 site-local addresses will be self
+   correcting as IPv6 implementations remove support for site-local
+   addresses.  However, sacrificial servers for C.E.F.IP6.ARPA through
+   F.E.F.IP6.ARPA may still need to be deployed in the short term if the
+   traffic becomes excessive.
+
+   For IPv6 Non-Locally Assigned Local addresses (L = 0) [RFC 4193],
+   there has been no decision made about whether the Regional Internet
+   Registries (RIRs) will provide delegations in this space or not.  If
+   they don't, then C.F.IP6.ARPA will need to be added to the list in
+   Section 4.4.  If they do, then registries will need to take steps to
+   ensure that name servers are provided for these addresses.
+
+   This document also ignores IP6.INT.  IP6.INT has been wound up with
+   only legacy resolvers now generating reverse queries under IP6.INT
+   [RFC 4159].
+
+   This document has also deliberately ignored names immediately under
+   the root domain.  While there is a subset of queries to the root name
+   servers which could be addressed using the techniques described here
+   (e.g. .local, .workgroup and IPv4 addresses), there is also a vast
+   amount of traffic that requires a different strategy (e.g. lookups
+   for unqualified hostnames, IPv6 addresses).
+
+
+
+Andrews                 Expires December 7, 2008                [Page 7]
+
+Internet-Draft          Locally-served DNS Zones               June 2008
+
+
+6.  IANA Considerations
+
+   This document requests that IANA establish a registry of zones which
+   require this default behaviour.  The initial contents of which are in
+   Section 4.  Implementors are encouraged to check this registry and
+   adjust their implementations to reflect changes therein.
+
+   This registry can be amended through "IETF Consensus" as per [RFC
+   2434].
+
+   IANA should co-ordinate with the RIRs to ensure that, as DNSSEC is
+   deployed in the reverse tree, delegations for these zones are made in
+   the manner described in Section 7.
+
+
+7.  Security Considerations
+
+   During the initial deployment phase, particularly where [RFC 1918]
+   addresses are in use, there may be some clients that unexpectedly
+   receive a name error rather than a PTR record.  This may cause some
+   service disruption until their recursive name server(s) have been re-
+   configured.
+
+   As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
+   namespaces, the zones listed above will need to be delegated as
+   insecure delegations, or be within insecure zones.  This will allow
+   DNSSEC validation to succeed for queries in these spaces despite not
+   being answered from the delegated servers.
+
+   It is recommended that sites actively using these namespaces secure
+   them using DNSSEC [RFC 4035] by publishing and using DNSSEC trust
+   anchors.  This will protect the clients from accidental import of
+   unsigned responses from the Internet.
+
+
+8.  Acknowledgements
+
+   This work was supported by the US National Science Foundation
+   (research grant SCI-0427144) and DNS-OARC.
+
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC 1034]
+              Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
+              STD 13, RFC 1034, November 1987.
+
+
+
+Andrews                 Expires December 7, 2008                [Page 8]
+
+Internet-Draft          Locally-served DNS Zones               June 2008
+
+
+   [RFC 1035]
+              Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
+              SPECIFICATION", STD 13, RFC 1035, November 1987.
+
+   [RFC 1918]
+              Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
+              and E. Lear, "Address Allocation for Private Internets",
+              BCP 5, RFC 1918, February 1996.
+
+   [RFC 2119]
+              Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC 2136]
+              Vixie, P., Thomson, A., Rekhter, Y., and J. Bound,
+              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+              RFC 2136, April 1997.
+
+   [RFC 2308]
+              Andrews, M., "Negative Caching of DNS Queries (DNS
+              NCACHE)", RFC 2398, March 1998.
+
+   [RFC 2434]
+              Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+              October 1998.
+
+   [RFC 2606]
+              Eastlake, D. and A. Panitz, "Reserved Top Level DNS
+              Names", BCP 32, RFC 2606, June 1999.
+
+   [RFC 3596]
+              Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+              "DNS Extensions to Support IPv6", RFC 3596, October 2003.
+
+   [RFC 4035]
+              Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+   [RFC 4159]
+              Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159,
+              August 2005.
+
+   [RFC 4193]
+              Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+              Addresses", RFC 4193, October 2005.
+
+
+
+
+Andrews                 Expires December 7, 2008                [Page 9]
+
+Internet-Draft          Locally-served DNS Zones               June 2008
+
+
+   [RFC 4291]
+              Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 4291, February 2006.
+
+9.2.  Informative References
+
+   [AS112]    "AS112 Project", <http://www.as112.net/>.
+
+   [I-D.draft-ietf-dnsop-as112-ops]
+              Abley, J. and W. Maton, "AS112 Nameserver Operations",
+              draft-ietf-dnsop-as112-ops-00 (work in progress),
+              February 2007.
+
+   [I-D.draft-ietf-dnsop-as112-under-attack-help-help]
+              Abley, J. and W. Maton, "I'm Being Attacked by
+              PRISONER.IANA.ORG!",
+              draft-ietf-dnsop-as112-under-attack-help-help-00 (work in
+              progress), February 2007.
+
+   [RFC 3330]
+              "Special-Use IPv4 Addresses", RFC 3330, September 2002.
+
+
+Appendix A.  Change History [To Be Removed on Publication]
+
+A.1.  draft-ietf-dnsop-default-local-zones-05.txt
+
+   none, expiry prevention
+
+A.2.  draft-ietf-dnsop-default-local-zones-04.txt
+
+   Centrally Assigned Local addresses -> Non-Locally Assigned Local
+   address
+
+A.3.  draft-ietf-dnsop-default-local-zones-03.txt
+
+   expanded section 4 descriptions
+
+   Added references [RFC 2136], [RFC 3596],
+   [I-D.draft-ietf-dnsop-as112-ops] and
+   [I-D.draft-ietf-dnsop-as112-under-attack-help-help].
+
+   Revised language.
+
+A.4.  draft-ietf-dnsop-default-local-zones-02.txt
+
+   RNAME now "nobody.invalid."
+
+
+
+
+Andrews                 Expires December 7, 2008               [Page 10]
+
+Internet-Draft          Locally-served DNS Zones               June 2008
+
+
+   Revised language.
+
+A.5.  draft-ietf-dnsop-default-local-zones-01.txt
+
+   Revised impact description.
+
+   Updated to reflect change in IP6.INT status.
+
+A.6.  draft-ietf-dnsop-default-local-zones-00.txt
+
+   Adopted by DNSOP.
+
+   "Author's Note" re-titled "Zones that are Out-Of-Scope"
+
+   Add note that these zone are expected to seed the IANA registry.
+
+   Title changed.
+
+A.7.  draft-andrews-full-service-resolvers-03.txt
+
+   Added "Proposed Status".
+
+A.8.  draft-andrews-full-service-resolvers-02.txt
+
+   Added 0.IN-ADDR.ARPA.
+
+
+Appendix B.  Proposed Status [To Be Removed on Publication]
+
+   This Internet-Draft is being submitted for eventual publication as an
+   RFC with a proposed status of Best Current Practice.
+
+
+Author's Address
+
+   Mark P. Andrews
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, CA  94063
+   US
+
+   Email: Mark_Andrews@isc.org
+
+
+
+
+
+
+
+
+
+Andrews                 Expires December 7, 2008               [Page 11]
+
+Internet-Draft          Locally-served DNS Zones               June 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+Andrews                 Expires December 7, 2008               [Page 12]
+

doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt

@@ -0,0 +1,300 @@
+Internet Engineering Task Force                         A.Durand
+INTERNET-DRAFT                             SUN Microsystems,inc.
+November, 24, 2003                                      J. Ihren
+Expires May 25, 2004                                  Autonomica
+
+
+               DNS IPv6 transport operational guidelines
+          <draft-ietf-dnsop-ipv6-transport-guidelines-01.txt>
+
+
+
+Status of this Memo
+
+   This memo provides information to the Internet community. It does not
+   specify an Internet standard of any kind. This memo is in full
+   conformance with all provisions of Section 10 of RFC2026
+
+   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/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+
+Abstract
+
+   This memo provides guidelines and Best Current Practice to operate
+   DNS in a world where queries and responses are carried in a mixed
+   environment of IPv4 and IPv6 networks.
+
+
+Acknowledgment
+
+   This document is the result of many conversations that happened in
+   the DNS community at IETF and elsewhere since 2001. During that
+   period of time, a number of Internet drafts have been published to
+   clarify various aspects of the issues at stake. This document focuses
+   on the conclusion of those discussions.
+
+   The authors would like to acknowledge the role of Pekka Savola in his
+   thorough review of the document.
+
+
+1. Terminology
+
+   The phrase "IPv4 name server" indicates a name server available over
+   IPv4 transport. It does not imply anything about what DNS data is
+   served. Likewise, "IPv6 name server" indicates a name server
+   available over IPv6 transport. The phrase "dual-stack DNS server"
+   indicates a DNS server that is actually configured to run both
+   protocols, IPv4 and IPv6, and not merely a server running on a system
+   capable of running both but actually configured to run only one.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [2119].
+
+
+2. Introduction to the Problem of Name Space Fragmentation:
+     following the referral chain
+
+   The caching resolver that tries to look up a name starts out at the
+   root, and follows referrals until it is referred to a nameserver that
+   is authoritative for the name.  If somewhere down the chain of
+   referrals it is referred to a nameserver that is only accessible over
+   an unavailable type of transport, a traditional nameserver is unable
+   to finish the task.
+
+   When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
+   only a matter of time until this starts to happen. The complete DNS
+   hierarchy then starts to fragment into a graph where authoritative
+   nameservers for certain nodes are only accessible over a certain
+   transport. What is feared is that a node using only a particular
+   version of IP, querying information about another node using the same
+   version of IP can not do it because, somewhere in the chain of
+   servers accessed during the resolution process, one or more of them
+   will only be accessible with the other version of IP.
+
+   With all DNS data only available over IPv4 transport everything is
+   simple. IPv4 resolvers can use the intended mechanism of following
+   referrals from the root and down while IPv6 resolvers have to work
+   through a "translator", i.e. they have to use a second name server on
+   a so-called "dual stack" host as a "forwarder" since they cannot
+   access the DNS data directly.
+
+   With all DNS data only available over IPv6 transport everything would
+   be equally simple, with the exception of old legacy IPv4 name servers
+   having to switch to a forwarding configuration.
+
+   However, the second situation will not arise in a foreseeable time.
+   Instead, it is expected that the transition will be from IPv4 only to
+   a mixture of IPv4 and IPv6, with DNS data of theoretically three
+   categories depending on whether it is available only over IPv4
+   transport, only over IPv6 or both.
+
+   Having DNS data available on both transports is the best situation.
+   The major question is how to ensure that it as quickly as possible
+   becomes the norm. However, while it is obvious that some DNS data
+   will only be available over v4 transport for a long time it is also
+   obvious that it is important to avoid fragmenting the name space
+   available to IPv4 only hosts. I.e. during transition it is not
+   acceptable to break the name space that we presently have available
+   for IPv4-only hosts.
+
+
+3. Policy Based Avoidance of Name Space Fragmentation
+
+   Today there are only a few DNS "zones" on the public Internet that
+   are  available over IPv6 transport, and most of them can be regarded
+   as "experimental". However, as soon as the root and top level domains
+   are available over IPv6 transport, it is reasonable to expect that it
+   will become more common to have zones served by IPv6 servers.
+
+   Having those zones served only by IPv6-only name server would not be
+   a good development, since this will fragment the previously
+   unfragmented IPv4 name space and there are strong reasons to find a
+   mechanism to avoid it.
+
+   The RECOMMENDED approach to maintain name space continuity is to use
+   administrative policies, as described in the next section.
+
+
+4. DNS IPv6 Transport RECOMMENDED Guidelines
+
+   In order to preserve name space continuity, the following administrative
+   policies are RECOMMENDED:
+      - every recursive DNS server SHOULD be either IPv4-only or dual
+      stack,
+      - every single DNS zone SHOULD be served by at least one IPv4
+      reachable DNS server.
+
+   This rules out IPv6-only DNS servers performing full recursion and
+   DNS zones served only by IPv6-only DNS servers.  However, one could
+   very well design a configuration where a chain of IPv6 only DNS
+   servers forward queries to a set of dual stack DNS servers actually
+   performing those recursive queries.  This approach could be revisited
+   if/when translation techniques between IPv4 and IPv6 were to be
+   widely deployed.
+
+   In order to help enforcing the second point, the optional operational
+   zone validation processes SHOULD ensure that there is at least one
+   IPv4 address record available for the name servers of any child
+   delegations within the zone.
+
+
+5. Security Considerations
+
+   Being a critical piece of the Internet infrastructure, the DNS is a
+   potential value target and thus should be protected.  Great care
+   should be taken not to weaken the security of DNS while introducing
+   IPv6 operation.
+
+   Keeping the DNS name space from fragmenting is a critical thing for
+   the availability and the operation of the Internet; this memo
+   addresses this issue by clear and simple operational guidelines.
+
+   The RECOMMENDED guidelines are compatible with the operation of
+   DNSSEC and do not introduce any new security issues.
+
+
+6. Author Addresses
+
+   Alain Durand
+   SUN Microsystems, Inc
+   17 Network circle UMPK17-202
+   Menlo Park, CA, 94025
+   USA
+   Mail: Alain.Durand@sun.com
+
+   Johan Ihren
+   Autonomica
+   Bellmansgatan 30
+   SE-118 47 Stockholm, Sweden
+   Mail: johani@autonomica.se
+
+
+7. Normative References
+
+   [2119]  Bradner, S., "Key Words for Use in RFCs to Indicate
+           Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+8. Full Copyright Statement
+
+   "Copyright (C) The Internet Society (2003).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt

@@ -0,0 +1,389 @@
+
+DNSOP                                                          G. Guette
+Internet-Draft                                             IRISA / INRIA
+Expires: July 19, 2005                                        O. Courtay
+                                                             Thomson R&D
+                                                        January 18, 2005
+
+           Requirements for Automated Key Rollover in DNSSEC
+           draft-ietf-dnsop-key-rollover-requirements-02.txt
+
+Status of this Memo
+
+   By submitting this Internet-Draft, I certify that any applicable 
+   patent or other IPR claims of which I am aware have been disclosed, 
+   and any of which I become aware will be disclosed, in accordance with 
+   RFC 3668.  
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on July 19, 2005.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).  All Rights Reserved.
+
+Abstract
+
+   This document describes problems that appear during an automated
+   rollover and gives the requirements for the design of communication
+   between parent zone and child zone during an automated rollover
+   process.  This document is essentially about in-band key rollover.
+
+
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 1]
+Internet-Draft      Automated Rollover Requirements         January 2005
+
+Table of Contents
+
+   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.   The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3
+   3.   Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4
+   4.   Messages authentication and information exchanged  . . . . . . 5
+   5.   Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5
+   6.   Security consideration . . . . . . . . . . . . . . . . . . . . 6
+   7.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 6
+   8.   Normative References . . . . . . . . . . . . . . . . . . . . . 6
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
+   A.   Documents details and changes  . . . . . . . . . . . . . . . . 7
+        Intellectual Property and Copyright Statements . . . . . . . . 8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 2]
+Internet-Draft      Automated Rollover Requirements         January 2005
+
+1.  Introduction
+
+   The DNS security extensions (DNSSEC) [4][6][5][7] uses public-key
+   cryptography and digital signatures.  It stores the public part of
+   keys in DNSKEY Resource Records (RRs).  Because old keys and
+   frequently used keys are vulnerable, they must be renewed
+   periodically.  In DNSSEC, this is the case for Zone Signing Keys
+   (ZSKs) and Key Signing Keys (KSKs) [1][2].  Automation of key
+   exchanges between parents and children is necessary for large zones
+   because there are too many changes to handle.
+
+   Let us consider for example a zone with 100000 secure delegations.
+   If the child zones change their keys once a year on average, that
+   implies 300 changes per day for the parent zone.  This amount of
+   changes is hard to manage manually.
+
+   Automated rollover is optional and resulting from an agreement
+   between the administrator of the parent zone and the administrator of
+   the child zone.  Of course, key rollover can also be done manually by
+   administrators.
+
+   This document describes the requirements for a protocol to perform
+   the automated key rollover process and focusses on interaction
+   between parent and child zone.
+
+2.  The Key Rollover Process
+
+   Key rollover consists of renewing the DNSSEC keys used to sign
+   resource records in a given DNS zone file.  There are two types of
+   rollover, ZSK rollovers and KSK rollovers.
+
+   During a ZSK rollover, all changes are local to the zone that renews
+   its key: there is no need to contact other zones administrators to
+   propagate the performed changes because a ZSK has no associated DS
+   record in the parent zone.
+
+   During a KSK rollover, new DS RR(s) must be created and stored in the
+   parent zone.  In consequence, data must be exchanged between child
+   and parent zones.
+
+   The key rollover is built from two parts of different nature:
+   o  An algorithm that generates new keys and signs the zone file.  It
+      can be local to the zone,
+   o  the interaction between parent and child zones.
+
+   One example of manual key rollover [3] is:
+   o  The child zone creates a new KSK,
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 3]
+Internet-Draft      Automated Rollover Requirements         January 2005
+
+   o  the child zone waits for the creation of the DS RR in its parent
+      zone,
+   o  the child zone deletes the old key,
+   o  the parent zone deletes the old DS RR.
+
+   This document concentrates on defining interactions between entities
+   present in key rollover process.
+
+3.  Basic Requirements
+
+   This section provides the requirements for automated key rollover in
+   case of normal use.  Exceptional case like emergency rollover is
+   specifically described later in this document.
+
+   The main condition during a key rollover is that the chain of trust
+   must be preserved to every validating DNS client.  No matter if this
+   client retrieves some of the RRs from recursive caching name server
+   or from the authoritative servers for the zone involved in the
+   rollover.
+
+   Automated key rollover solution may be interrupted by a manual
+   intervention.  This manual intervention should not compromise the
+   security state of the chain of trust.  If the chain is safe before
+   the manual intervention, the chain of trust must remain safe during
+   and after the manual intervention
+
+   Two entities act during a KSK rollover: the child zone and its parent
+   zone.  These zones are generally managed by different administrators.
+   These administrators should agree on some parameters like
+   availability of automated rollover, the maximum delay between
+   notification of changes in the child zone and the resigning of the
+   parent zone.  The child zone needs to know this delay to schedule its
+   changes and/or to verify that the changes had been taken into account
+   in the parent zone.  Hence, the child zone can also avoid some
+   critical cases where all child key are changed prior to the DS RR
+   creation.
+
+   By keeping some resource records during a given time, the recursive
+   cache servers can act on the automated rollover.  The existence of
+   recursive cache servers must be taken into account by automated
+   rollover solution.
+
+   Indeed, during an automated key rollover a name server could have to
+   retrieve some DNSSEC data.  An automated key rollover solution must
+   ensure that these data are not old DNSSEC material retrieved from a
+   recursive name server.
+
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 4]
+Internet-Draft      Automated Rollover Requirements         January 2005
+
+4.  Messages authentication and information exchanged
+
+   This section addresses in-band rollover, security of out-of-band
+   mechanisms is out of scope of this document.
+
+   The security provided by DNSSEC must not be compromised by the key
+   rollover, thus every exchanged message must be authenticated to avoid
+   fake rollover messages from malicious parties.
+
+   Once the changes related to a KSK are made in a child zone, there are
+   two ways for the parent zone to take this changes into account:
+   o  the child zone notify directly or not directly its parent zone in
+      order to create the new DS RR and store this DS RR in parent zone
+      file,
+   o  or the parent zone poll the child zone.
+
+   In both cases, the parent zone must receive all the child keys that
+   need the creation of associated DS RRs in the parent zone.
+
+   Because errors could occur during the transmission of keys between
+   child and parent, the key exchange protocol must be fault tolerant.
+   Should an error occured during the automated key rollover, an
+   automated key rollover solution must be able to keep the zone files
+   in a consistent state.
+
+5.  Emergency Rollover
+
+   Emergency key rollover is a special case of rollover decided by the
+   zone administrator generally for security reasons.  In consequence,
+   emergency key rollover can break some of the requirement described
+   above.
+
+   A zone key might be compromised and an attacker can use the
+   compromised key to create and sign fake records.  To avoid this, the
+   zone administrator may change the compromised key or all its keys as
+   soon as possible, without waiting for the creation of new DS RRs in
+   its parent zone.
+
+   Fast changes may break the chain of trust.  The part of DNS tree
+   having this zone as apex can become unverifiable, but the break of
+   the chain of trust is necessary if the administrator wants to prevent
+   the compromised key from being used (to spoof DNS data).
+
+   Parent and child zones sharing an automated rollover mechanism,
+   should have an out-of-band way to re-establish a consistent state at
+   the delegation point (DS and DNSKEY RRs).  This allows to avoid that
+   a malicious party uses the compromised key to roll the zone keys.
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 5]
+Internet-Draft      Automated Rollover Requirements         January 2005
+
+6.  Security consideration
+
+   The automated key rollover process in DNSSEC allows automated renewal
+   of any kind of DNS key (ZSK or KSK).  It is essential that parent
+   side and child side can do mutual authentication.  Moreover,
+   integrity of the material exchanged between the parent and child zone
+   must be provided to ensure the right DS are created.
+
+   As in any application using public key cryptography, in DNSSEC a key
+   may be compromised.  What to do in such a case can be describe in the
+   zone local policy and can violate some requirements described in this
+   draft.  The emergency rollover can break the chain of trust in order
+   to protect the zone against the use of the compromised key.
+
+7.  Acknowledgments
+
+   The authors want to thank members of IDsA project for their
+   contribution to this document.
+
+8  Normative References
+
+   [1]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
+        RFC 3658, December 2003.
+
+   [2]  Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
+        (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
+        RFC 3757, May 2004.
+
+   [3]  Kolkman, O., "DNSSEC Operational Practices",
+        draft-ietf-dnsop-dnssec-operational-practice-01 (work in
+        progress), May 2004.
+
+   [4]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [5]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
+        "Resource Records for the DNS Security Extensions",
+        draft-ietf-dnsext-dnssec-records-11 (work in progress), October
+        2004.
+
+   [6]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
+        "DNS Security Introduction and Requirements",
+        draft-ietf-dnsext-dnssec-intro-13 (work in progress), October
+        2004.
+
+   [7]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions",
+        draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 6]
+Internet-Draft      Automated Rollover Requirements         January 2005
+
+        2004.
+
+Authors' Addresses
+
+   Gilles Guette
+   IRISA / INRIA
+   Campus de Beaulieu
+   35042  Rennes CEDEX
+   FR
+
+   EMail: gilles.guette@irisa.fr
+   URI:   http://www.irisa.fr
+
+   Olivier Courtay
+   Thomson R&D
+   1, avenue Belle Fontaine
+   35510  Cesson S?vign? CEDEX
+   FR
+
+   EMail: olivier.courtay@thomson.net
+
+Appendix A.  Documents details and changes
+
+   This section is to be removed by the RFC editor if and when the
+   document is published.
+
+   Section about NS RR rollover has been removed
+
+   Remarks from Samuel Weiler and Rip Loomis added
+
+   Clarification about in-band rollover and in emergency section
+
+   Section 3, details about recursive cache servers added
+
+
+
+
+
+
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 7]
+Internet-Draft      Automated Rollover Requirements         January 2005
+
+Intellectual Property Statement
+
+     The IETF takes no position regarding the validity or scope of any 
+     intellectual property or other rights that might be claimed to 
+     pertain to the implementation or use of the technology described 
+     in this document or the extent to which any license under such 
+     rights might or might not be available; neither does it represent 
+     that it has made any effort to identify any such rights. 
+     Information on the IETF's procedures with respect to rights in 
+     IETF Documents can be found in BCP 78 and 79.   
+          
+     Copies of IPR disclosures made to the IETF Secretariat and any 
+     assurances of licenses to be made available, or the result of an 
+     attempt made to obtain a general license or permission for the use 
+     of such proprietary rights by implementers or users of this 
+     specification can be obtained from the IETF on-line IPR repository 
+     at http://www.ietf.org/ipr. 
+      
+     The IETF invites any interested party to bring to its attention 
+     any copyrights, patents or patent applications, or other 
+     proprietary rights which may cover technology that may be required 
+     to implement this standard. Please address the information to the 
+     IETF at ietf-ipr.org. 
+      
+    
+ Full Copyright Statement 
+    
+   Copyright (C) The Internet Society (2005).  This document is subject 
+   to the rights, licenses and restrictions contained in BCP 78, and 
+   except as set forth therein, the authors retain all their rights. 
+    
+   This document and the information contained herein are provided on an 
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+ Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+         
+
+
+Guette & Courtay         Expires July 19, 2005                  [Page 8]

doc/draft/draft-ietf-dnsop-serverid-06.txt

@@ -0,0 +1,618 @@
+
+
+
+
+Network Working Group                                           S. Woolf
+Internet-Draft                         Internet Systems Consortium, Inc.
+Expires: September 6, 2006                                     D. Conrad
+                                                           Nominum, Inc.
+                                                           March 5, 2006
+
+
+    Requirements for a Mechanism Identifying a Name Server Instance
+                      draft-ietf-dnsop-serverid-06
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on September 6, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   With the increased use of DNS anycast, load balancing, and other
+   mechanisms allowing more than one DNS name server to share a single
+   IP address, it is sometimes difficult to tell which of a pool of name
+   servers has answered a particular query.  A standardized mechanism to
+   determine the identity of a name server responding to a particular
+   query would be useful, particularly as a diagnostic aid for
+   administrators.  Existing ad hoc mechanisms for addressing this need
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 1]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+   have some shortcomings, not the least of which is the lack of prior
+   analysis of exactly how such a mechanism should be designed and
+   deployed.  This document describes the existing convention used in
+   some widely deployed implementations of the DNS protocol, including
+   advantages and disadvantages, and discusses some attributes of an
+   improved mechanism.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 2]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+1.  Introduction and Rationale
+
+   Identifying which name server is responding to queries is often
+   useful, particularly in attempting to diagnose name server
+   difficulties.  This is most obviously useful for authoritative
+   nameservers in the attempt to diagnose the source or prevalence of
+   inaccurate data, but can also conceivably be useful for caching
+   resolvers in similar and other situations.  Furthermore, the ability
+   to identify which server is responding to a query has become more
+   useful as DNS has become more critical to more Internet users, and as
+   network and server deployment topologies have become more complex.
+
+   The traditional means for determining which of several possible
+   servers is answering a query has traditionally been based on the use
+   of the server's IP address as a unique identifier.  However, the
+   modern Internet has seen the deployment of various load balancing,
+   fault-tolerance, or attack-resistance schemes such as shared use of
+   unicast IP addresses as documented in [RFC3258].  An unfortunate side
+   effect of these schemes has been to make the use of IP addresses as
+   identifiers somewhat problematic.  Specifically, a dedicated DNS
+   query may not go to the same server as answered a previous query,
+   even though sent to the same IP address.  Non-DNS methods such as
+   ICMP ping, TCP connections, or non-DNS UDP packets (such as those
+   generated by tools like "traceroute"), etc., may well be even less
+   certain to reach the same server as the one which receives the DNS
+   queries.
+
+   There is a well-known and frequently-used technique for determining
+   an identity for a nameserver more specific than the possibly-non-
+   unique "server that answered the query I sent to IP address XXX".
+   The widespread use of the existing convention suggests a need for a
+   documented, interoperable means of querying the identity of a
+   nameserver that may be part of an anycast or load-balancing cluster.
+   At the same time, however, it also has some drawbacks that argue
+   against standardizing it as it's been practiced so far.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 3]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+2.  Existing Conventions
+
+   For some time, the commonly deployed Berkeley Internet Name Domain
+   implementation of the DNS protocol suite from the Internet Systems
+   Consortium [BIND] has supported a way of identifying a particular
+   server via the use of a standards-compliant, if somewhat unusual, DNS
+   query.  Specifically, a query to a recent BIND server for a TXT
+   resource record in class 3 (CHAOS) for the domain name
+   "HOSTNAME.BIND." will return a string that can be configured by the
+   name server administrator to provide a unique identifier for the
+   responding server.  (The value defaults to the result of a
+   gethostname() call).  This mechanism, which is an extension of the
+   BIND convention of using CHAOS class TXT RR queries to sub-domains of
+   the "BIND." domain for version information, has been copied by
+   several name server vendors.
+
+   A refinement to the BIND-based mechanism, which dropped the
+   implementation-specific string, replaces ".BIND" with ".SERVER".
+   Thus the query string to learn the unique name of a server may be
+   queried as "ID.SERVER".
+
+   (For reference, the other well-known name used by recent versions of
+   BIND within the CHAOS class "BIND." domain is "VERSION.BIND."  A
+   query for a CHAOS TXT RR for this name will return an
+   administratively defined string which defaults to the version of the
+   server responding.  This is, however, not generally implemented by
+   other vendors.)
+
+2.1.  Advantages
+
+   There are several valuable attributes to this mechanism, which
+   account for its usefulness.
+
+   1.  The "HOSTNAME.BIND" or "ID.SERVER" query response mechanism is
+       within the DNS protocol itself.  An identification mechanism that
+       relies on the DNS protocol is more likely to be successful
+       (although not guaranteed) in going to the same system as a
+       "normal" DNS query.
+
+   2.  Since the identity information is requested and returned within
+       the DNS protocol, it doesn't require allowing any other query
+       mechanism to the server, such as holes in firewalls for
+       otherwise-unallowed ICMP Echo requests.  Thus it is likely to
+       reach the same server over a path subject to the same routing,
+       resource, and security policy as the query, without any special
+       exceptions to site security policy.
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 4]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+   3.  It is simple to configure.  An administrator can easily turn on
+       this feature and control the results of the relevant query.
+
+   4.  It allows the administrator complete control of what information
+       is given out in the response, minimizing passive leakage of
+       implementation or configuration details.  Such details are often
+       considered sensitive by infrastructure operators.
+
+   5.  Hypothetically, since it's an ordinary DNS record and the
+       relevant DNSSEC RRs are class independent, the id.server response
+       RR could be signed, which has the advantages described in
+       [RFC4033].
+
+2.2.  Disadvantages
+
+   At the same time, there are some serious drawbacks to the CHAOS/TXT
+   query mechanism that argue against standardizing it as it currently
+   operates.
+
+   1.  It requires an additional query to correlate between the answer
+       to a DNS query under normal conditions and the supposed identity
+       of the server receiving the query.  There are a number of
+       situations in which this simply isn't reliable.
+
+   2.  It reserves an entire class in the DNS (CHAOS) for what amounts
+       to one zone.  While CHAOS class is defined in [RFC1034] and
+       [RFC1035], it's not clear that supporting it solely for this
+       purpose is a good use of the namespace or of implementation
+       effort.
+
+   3.  The initial and still common form, using .BIND, is implementation
+       specific.  BIND is one DNS implementation.  At the time of this
+       writing, it is probably the most prevalent for authoritative
+       servers.  This does not justify standardizing on its ad hoc
+       solution to a problem shared across many operators and
+       implementors.  Meanwhile, the proposed refinement changes the
+       string but preserves the ad hoc CHAOS/TXT mechanism.
+
+   4.  There is no convention or shared understanding of what
+       information an answer to such a query for a server identity could
+       or should include, including a possible encoding or
+       authentication mechanism.
+
+   The first of the listed disadvantages may be technically the most
+   serious.  It argues for an attempt to design a good answer to the
+   problem that "I need to know what nameserver is answering my
+   queries", not simply a convenient one.
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 5]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+2.3.  Characteristics of an Implementation Neutral Convention
+
+   The discussion above of advantages and disadvantages to the
+   HOSTNAME.BIND mechanism suggest some requirements for a better
+   solution to the server identification problem.  These are summarized
+   here as guidelines for any effort to provide appropriate protocol
+   extensions:
+
+   1.  The mechanism adopted must be in-band for the DNS protocol.  That
+       is, it needs to allow the query for the server's identifying
+       information to be part of a normal, operational query.  It should
+       also permit a separate, dedicated query for the server's
+       identifying information.  But it should preserve the ability of
+       the CHAOS/TXT query-based mechanism to work through firewalls and
+       in other situations where only DNS can be relied upon to reach
+       the server of interest.
+
+   2.  The new mechanism should not require dedicated namespaces or
+       other reserved values outside of the existing protocol mechanisms
+       for these, i.e. the OPT pseudo-RR.  In particular, it should not
+       propagate the existing drawback of requiring support for a CLASS
+       and top level domain in the authoritative server (or the querying
+       tool) to be useful.
+
+   3.  Support for the identification functionality should be easy to
+       implement and easy to enable.  It must be easy to disable and
+       should lend itself to access controls on who can query for it.
+
+   4.  It should be possible to return a unique identifier for a server
+       without requiring the exposure of information that may be non-
+       public and considered sensitive by the operator, such as a
+       hostname or unicast IP address maintained for administrative
+       purposes.
+
+   5.  It should be possible to authenticate the received data by some
+       mechanism analogous to those provided by DNSSEC.  In this
+       context, the need could be met by including encryption options in
+       the specification of a new mechanism.
+
+   6.  The identification mechanism should not be implementation-
+       specific.
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 6]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+3.  IANA Considerations
+
+   This document proposes no specific IANA action.  Protocol extensions,
+   if any, to meet the requirements described are out of scope for this
+   document.  A proposed extension, specified and adopted by normal IETF
+   process, is described in [NSID], including relevant IANA action.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 7]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+4.  Security Considerations
+
+   Providing identifying information as to which server is responding to
+   a particular query from a particular location in the Internet can be
+   seen as information leakage and thus a security risk.  This motivates
+   the suggestion above that a new mechanism for server identification
+   allow the administrator to disable the functionality altogether or
+   partially restrict availability of the data.  It also suggests that
+   the serverid data should not be readily correlated with a hostname or
+   unicast IP address that may be considered private to the nameserver
+   operator's management infrastructure.
+
+   Propagation of protocol or service meta-data can sometimes expose the
+   application to denial of service or other attack.  As DNS is a
+   critically important infrastructure service for the production
+   Internet, extra care needs to be taken against this risk for
+   designers, implementors, and operators of a new mechanism for server
+   identification.
+
+   Both authentication and confidentiality of serverid data are
+   potentially of interest to administrators-- that is, operators may
+   wish to make serverid data available and reliable to themselves and
+   their chosen associates only.  This would imply both an ability to
+   authenticate it to themselves and keep it private from arbitrary
+   other parties.  This led to Characteristics 4 and 5 of an improved
+   solution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 8]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+5.  Acknowledgements
+
+   The technique for host identification documented here was initially
+   implemented by Paul Vixie of the Internet Software Consortium in the
+   Berkeley Internet Name Daemon package.  Comments and questions on
+   earlier drafts were provided by Bob Halley, Brian Wellington, Andreas
+   Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the
+   ICANN Root Server System Advisory Committee.  The newest version
+   takes a significantly different direction from previous versions,
+   owing to discussion among contributors to the DNSOP working group and
+   others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam
+   Weiler, and Rob Austein.
+
+6.  References
+
+   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+        RFC 1034, STD 0013, November 1987.
+
+   [2]  Mockapetris, P., "Domain Names - Implementation and
+        Specification", RFC 1035, STD 0013, November 1987.
+
+   [3]  Hardie, T., "Distributing Authoritative Name Servers via Shared
+        Unicast Addresses", RFC 3258, April 2002.
+
+   [4]  ISC, "BIND 9 Configuration Reference".
+
+   [5]  Austein, S., "DNS Name Server Identifier Option (NSID)",
+        Internet Drafts http://www.ietf.org/internet-drafts/
+        draft-ietf-dnsext-nsid-01.txt, January 2006.
+
+   [6]  Arends, R., Austein, S., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033,
+        March 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006               [Page 9]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+Authors' Addresses
+
+   Suzanne Woolf
+   Internet Systems Consortium, Inc.
+   950 Charter Street
+   Redwood City, CA  94063
+   US
+
+   Phone: +1 650 423-1333
+   Email: woolf@isc.org
+   URI:   http://www.isc.org/
+
+
+   David Conrad
+   Nominum, Inc.
+   2385 Bay Road
+   Redwood City, CA  94063
+   US
+
+   Phone: +1 1 650 381 6003
+   Email: david.conrad@nominum.com
+   URI:   http://www.nominum.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006              [Page 10]
+
+Internet-Draft                  Serverid                      March 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Woolf & Conrad          Expires September 6, 2006              [Page 11]
+
+

doc/draft/draft-ietf-secsh-dns-05.txt

@@ -0,0 +1,614 @@
+Secure Shell Working Group                                   J. Schlyter
+Internet-Draft                                                   OpenSSH
+Expires: March 5, 2004                                        W. Griffin
+                                                                  SPARTA
+                                                       September 5, 2003
+
+
+           Using DNS to Securely Publish SSH Key Fingerprints
+                      draft-ietf-secsh-dns-05.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups. Note that other
+   groups may also distribute working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time. It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at http://
+   www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on March 5, 2004.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+   This document describes a method to verify SSH host keys using
+   DNSSEC. The document defines a new DNS resource record that contains
+   a standard SSH key fingerprint.
+
+
+
+
+
+
+
+
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 1]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+Table of Contents
+
+   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.    SSH Host Key Verification  . . . . . . . . . . . . . . . . .  3
+   2.1   Method . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.2   Implementation Notes . . . . . . . . . . . . . . . . . . . .  3
+   2.3   Fingerprint Matching . . . . . . . . . . . . . . . . . . . .  4
+   2.4   Authentication . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.    The SSHFP Resource Record  . . . . . . . . . . . . . . . . .  4
+   3.1   The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . .  5
+   3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . .  5
+   3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . .  5
+   3.1.3 Fingerprint  . . . . . . . . . . . . . . . . . . . . . . . .  5
+   3.2   Presentation Format of the SSHFP RR  . . . . . . . . . . . .  6
+   4.    Security Considerations  . . . . . . . . . . . . . . . . . .  6
+   5.    IANA Considerations  . . . . . . . . . . . . . . . . . . . .  7
+         Normative References . . . . . . . . . . . . . . . . . . . .  8
+         Informational References . . . . . . . . . . . . . . . . . .  8
+         Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  9
+   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  9
+         Intellectual Property and Copyright Statements . . . . . . . 10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 2]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+1. Introduction
+
+   The SSH [6] protocol provides secure remote login and other secure
+   network services over an insecure network.  The security of the
+   connection relies on the server authenticating itself to the client
+   as well as the user authenticating itself to the server.
+
+   If a connection is established to a server whose public key is not
+   already known to the client, a fingerprint of the key is presented to
+   the user for verification.  If the user decides that the fingerprint
+   is correct and accepts the key, the key is saved locally and used for
+   verification for all following connections. While some
+   security-conscious users verify the fingerprint out-of-band before
+   accepting the key, many users blindly accept the presented key.
+
+   The method described here can provide out-of-band verification by
+   looking up a fingerprint of the server public key in the DNS [1][2]
+   and using DNSSEC [5] to verify the lookup.
+
+   In order to distribute the fingerprint using DNS, this document
+   defines a new DNS resource record, "SSHFP", to carry the fingerprint.
+
+   Basic understanding of the DNS system [1][2] and the DNS security
+   extensions [5] is assumed by this document.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [3].
+
+2. SSH Host Key Verification
+
+2.1 Method
+
+   Upon connection to a SSH server, the SSH client MAY look up the SSHFP
+   resource record(s) for the host it is connecting to.  If the
+   algorithm and fingerprint of the key received from the SSH server
+   match the algorithm and fingerprint of one of the SSHFP resource
+   record(s) returned from DNS, the client MAY accept the identity of
+   the server.
+
+2.2 Implementation Notes
+
+   Client implementors SHOULD provide a configurable policy used to
+   select the order of methods used to verify a host key. This document
+   defines one method: Fingerprint storage in DNS. Another method
+   defined in the SSH Architecture [6] uses local files to store keys
+   for comparison. Other methods that could be defined in the future
+   might include storing fingerprints in LDAP or other databases. A
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 3]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+   configurable policy will allow administrators to determine which
+   methods they want to use and in what order the methods should be
+   prioritized. This will allow administrators to determine how much
+   trust they want to place in the different methods.
+
+   One specific scenario for having a configurable policy is where
+   clients do not use fully qualified host names to connect to servers.
+   In this scenario, the implementation SHOULD verify the host key
+   against a local database before verifying the key via the fingerprint
+   returned from DNS. This would help prevent an attacker from injecting
+   a DNS search path into the local resolver and forcing the client to
+   connect to a different host.
+
+2.3 Fingerprint Matching
+
+   The public key and the SSHFP resource record are matched together by
+   comparing algorithm number and fingerprint.
+
+      The public key algorithm and the SSHFP algorithm number MUST
+      match.
+
+      A message digest of the public key, using the message digest
+      algorithm specified in the SSHFP fingerprint type, MUST match the
+      SSHFP fingerprint.
+
+
+2.4 Authentication
+
+   A public key verified using this method MUST NOT be trusted if the
+   SSHFP resource record (RR) used for verification was not
+   authenticated by a trusted SIG RR.
+
+   Clients that do validate the DNSSEC signatures themselves SHOULD use
+   standard DNSSEC validation procedures.
+
+   Clients that do not validate the DNSSEC signatures themselves MUST
+   use a secure transport, e.g. TSIG [9], SIG(0) [10] or IPsec [8],
+   between themselves and the entity performing the signature
+   validation.
+
+3. The SSHFP Resource Record
+
+   The SSHFP resource record (RR) is used to store a fingerprint of a
+   SSH public host key that is associated with a Domain Name System
+   (DNS) name.
+
+   The RR type code for the SSHFP RR is TBA.
+
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 4]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+3.1 The SSHFP RDATA Format
+
+   The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
+   type and the fingerprint of the public host key.
+
+         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
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+         |   algorithm   |    fp type    |                               /
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
+         /                                                               /
+         /                          fingerprint                          /
+         /                                                               /
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+3.1.1 Algorithm Number Specification
+
+   This algorithm number octet describes the algorithm of the public
+   key.  The following values are assigned:
+
+          Value    Algorithm name
+          -----    --------------
+          0        reserved
+          1        RSA
+          2        DSS
+
+   Reserving other types requires IETF consensus [4].
+
+3.1.2 Fingerprint Type Specification
+
+   The fingerprint type octet describes the message-digest algorithm
+   used to calculate the fingerprint of the public key.  The following
+   values are assigned:
+
+          Value    Fingerprint type
+          -----    ----------------
+          0        reserved
+          1        SHA-1
+
+   Reserving other types requires IETF consensus [4].
+
+   For interoperability reasons, as few fingerprint types as possible
+   should be reserved.  The only reason to reserve additional types is
+   to increase security.
+
+3.1.3 Fingerprint
+
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 5]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+   The fingerprint is calculated over the public key blob as described
+   in [7].
+
+   The message-digest algorithm is presumed to produce an opaque octet
+   string output which is placed as-is in the RDATA fingerprint field.
+
+3.2 Presentation Format of the SSHFP RR
+
+   The RDATA of the presentation format of the SSHFP resource record
+   consists of two numbers (algorithm and fingerprint type) followed by
+   the fingerprint itself presented in hex, e.g:
+
+         host.example.  SSHFP 2 1 123456789abcdef67890123456789abcdef67890
+
+   The use of mnemonics instead of numbers is not allowed.
+
+4. Security Considerations
+
+   Currently, the amount of trust a user can realistically place in a
+   server key is proportional to the amount of attention paid to
+   verifying that the public key presented actually corresponds to the
+   private key of the server. If a user accepts a key without verifying
+   the fingerprint with something learned through a secured channel, the
+   connection is vulnerable to a man-in-the-middle attack.
+
+   The overall security of using SSHFP for SSH host key verification is
+   dependent on the security policies of the SSH host administrator and
+   DNS zone administrator (in transferring the fingerprint), detailed
+   aspects of how verification is done in the SSH implementation, and in
+   the client's diligence in accessing the DNS in a secure manner.
+
+   One such aspect is in which order fingerprints are looked up (e.g.
+   first checking local file and then SSHFP).  We note that in addition
+   to protecting the first-time transfer of host keys, SSHFP can
+   optionally be used for stronger host key protection.
+
+      If SSHFP is checked first, new SSH host keys may be distributed by
+      replacing the corresponding SSHFP in DNS.
+
+      If SSH host key verification can be configured to require SSHFP,
+      SSH host key revocation can be implemented by removing the
+      corresponding SSHFP from DNS.
+
+   As stated in Section 2.2, we recommend that SSH implementors provide
+   a policy mechanism to control the order of methods used for host key
+   verification. One specific scenario for having a configurable policy
+   is where clients use unqualified host names to connect to servers. In
+   this case, we recommend that SSH implementations check the host key
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 6]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+   against a local database before verifying the key via the fingerprint
+   returned from DNS. This would help prevent an attacker from injecting
+   a DNS search path into the local resolver and forcing the client to
+   connect to a different host.
+
+   A different approach to solve the DNS search path issue would be for
+   clients to use a trusted DNS search path, i.e., one not acquired
+   through DHCP or other autoconfiguration mechanisms. Since there is no
+   way with current DNS lookup APIs to tell whether a search path is
+   from a trusted source, the entire client system would need to be
+   configured with this trusted DNS search path.
+
+   Another dependency is on the implementation of DNSSEC itself.  As
+   stated in Section 2.4, we mandate the use of secure methods for
+   lookup and that SSHFP RRs are authenticated by trusted SIG RRs.  This
+   is especially important if SSHFP is to be used as a basis for host
+   key rollover and/or revocation, as described above.
+
+   Since DNSSEC only protects the integrity of the host key fingerprint
+   after it is signed by the DNS zone administrator, the fingerprint
+   must be transferred securely from the SSH host administrator to the
+   DNS zone administrator.  This could be done manually between the
+   administrators or automatically using secure DNS dynamic update [11]
+   between the SSH server and the nameserver.  We note that this is no
+   different from other key enrollment situations, e.g. a client sending
+   a certificate request to a certificate authority for signing.
+
+5. IANA Considerations
+
+   IANA needs to allocate a RR type code for SSHFP from the standard RR
+   type space (type 44 requested).
+
+   IANA needs to open a new registry for the SSHFP RR type for public
+   key algorithms.  Defined types are:
+
+         0 is reserved
+         1 is RSA
+         2 is DSA
+
+    Adding new reservations requires IETF consensus [4].
+
+   IANA needs to open a new registry for the SSHFP RR type for
+   fingerprint types.  Defined types are:
+
+         0 is reserved
+         1 is SHA-1
+
+    Adding new reservations requires IETF consensus [4].
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 7]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+Normative References
+
+   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [2]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [4]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+   [5]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [6]  Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
+        Lehtinen, "SSH Protocol Architecture",
+        draft-ietf-secsh-architecture-14 (work in progress), July 2003.
+
+   [7]  Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
+        Lehtinen, "SSH Transport Layer Protocol",
+        draft-ietf-secsh-transport-16 (work in progress), July 2003.
+
+Informational References
+
+   [8]   Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
+         Roadmap", RFC 2411, November 1998.
+
+   [9]   Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+         "Secret Key Transaction Authentication for DNS (TSIG)", RFC
+         2845, May 2000.
+
+   [10]  Eastlake, D., "DNS Request and Transaction Signatures (
+         SIG(0)s)", RFC 2931, September 2000.
+
+   [11]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+         Update", RFC 3007, November 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 8]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+Authors' Addresses
+
+   Jakob Schlyter
+   OpenSSH
+   812 23rd Avenue SE
+   Calgary, Alberta  T2G 1N8
+   Canada
+
+   EMail: jakob@openssh.com
+   URI:   http://www.openssh.com/
+
+
+   Wesley Griffin
+   SPARTA
+   7075 Samuel Morse Drive
+   Columbia, MD  21046
+   USA
+
+   EMail: wgriffin@sparta.com
+   URI:   http://www.sparta.com/
+
+Appendix A. Acknowledgements
+
+   The authors gratefully acknowledge, in no particular order, the
+   contributions of the following persons:
+
+      Martin Fredriksson
+
+      Olafur Gudmundsson
+
+      Edward Lewis
+
+      Bill Sommerfeld
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                  [Page 9]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights. Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11. Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard. Please address the information to the IETF Executive
+   Director.
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003). 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 assignees.
+
+   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
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                 [Page 10]
+
+Internet-Draft          DNS and SSH Fingerprints          September 2003
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter & Griffin       Expires March 5, 2004                 [Page 11]
+

doc/draft/draft-ihren-dnsext-threshold-validation-00.txt

@@ -0,0 +1,519 @@
+
+Internet Draft                                          Johan Ihren
+draft-ihren-dnsext-threshold-validation-00.txt          Autonomica
+February 2003
+Expires in six months
+
+
+                        Threshold Validation: 
+
+	 A Mechanism for Improved Trust and Redundancy for DNSSEC Keys
+
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups. Note that
+   other groups may also distribute working documents as
+   Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six
+   months and may be updated, replaced, or obsoleted by other
+   documents at any time. It is inappropriate to use Internet-Drafts
+   as reference material or to cite them other than as "work in
+   progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+
+Abstract
+
+   This memo documents a proposal for a different method of validation
+   for DNSSEC aware resolvers. The key change is that by changing from
+   a model of one Key Signing Key, KSK, at a time to multiple KSKs it
+   will be possible to increase the aggregated trust in the signed
+   keys by leveraging from the trust associated with the different
+   signees. 
+
+   By having multiple keys to chose from validating resolvers get the
+   opportunity to use local policy to reflect actual trust in
+   different keys. For instance, it is possible to trust a single,
+   particular key ultimately, while requiring multiple valid
+   signatures by less trusted keys for validation to succeed.
+   Furthermore, with multiple KSKs there are additional redundancy
+   benefits available since it is possible to roll over different KSKs
+   at different times which may make rollover scenarios easier to
+   manage.
+
+Contents
+
+	1. Terminology
+	2. Introduction and Background
+
+	3. Trust in DNSSEC Keys
+	3.1. Key Management, Split Keys and Trust Models
+	3.2. Trust Expansion: Authentication versus Authorization
+
+	4. Proposed Semantics for Signing the KEY Resource Record 
+           Set
+	4.1. Packet Size Considerations
+
+	5. Proposed Use of Multiple "Trusted Keys" in a Validating 
+           Resolver
+	5.1. Not All Possible KSKs Need to Be Trusted
+	5.2. Possible to do Threshold Validation
+	5.3. Not All Trusted Keys Will Be Available
+
+	6. Additional Benefits from Having Multiple KSKs
+	6.1. More Robust Key Rollovers
+	6.2. Evaluation of Multiple Key Distribution Mechanisms
+
+	7. Security Considerations
+	8. IANA Considerations.
+	9. References
+	9.1. Normative.
+	9.2. Informative.
+	10. Acknowledgments.
+	11. Authors' Address
+
+
+1. Terminology
+
+   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
+   and "MAY" in this document are to be interpreted as described in
+   RFC 2119. 
+
+   The term "zone" refers to the unit of administrative control in the
+   Domain Name System. "Name server" denotes a DNS name server that is
+   authoritative (i.e. knows all there is to know) for a DNS zone,
+   typically the root zone. A "resolver", is a DNS "client", i.e. an
+   entity that sends DNS queries to authoritative nameservers and
+   interpret the results. A "validating resolver" is a resolver that
+   attempts to perform DNSSEC validation on data it retrieves by doing
+   DNS lookups.
+
+
+2. Introduction and Background
+
+   From a protocol perspective there is no real difference between
+   different keys in DNSSEC. They are all just keys. However, in
+   actual use there is lots of difference. First and foremost, most
+   DNSSEC keys have in-band verification. I.e. the keys are signed by
+   some other key, and this other key is in its turn also signed by
+   yet another key. This way a "chain of trust" is created. Such
+   chains have to end in what is referred to as a "trusted key" for
+   validation of DNS lookups to be possible. 
+
+   A "trusted key" is a the public part of a key that the resolver
+   acquired by some other means than by looking it up in DNS. The
+   trusted key has to be explicitly configured.
+
+   A node in the DNS hierarchy that issues such out-of-band "trusted
+   keys" is called a "security apex" and the trusted key for that apex
+   is the ultimate source of trust for all DNS lookups within that
+   entire subtree.
+
+   DNSSEC is designed to be able to work with more than on security
+   apex. These apexes will all share the problem of how to distribute
+   their "trusted keys" in a way that provides validating resolvers
+   confidence in the distributed keys. 
+
+   Maximizing that confidence is crucial to the usefulness of DNSSEC
+   and this document tries to address this issue.
+
+
+3. Trust in DNSSEC Keys
+
+   In the end the trust that a validating resolver will be able to put
+   in a key that it cannot validate within DNSSEC will have to be a
+   function of
+
+   	    * trust in the key issuer, aka the KSK holder
+
+	    * trust in the distribution method
+
+	    * trust in extra, out-of-band verification
+
+   The KSK holder needs to be trusted not to accidentally lose private
+   keys in public places. Furthermore it needs to be trusted to
+   perform correct identification of the ZSK holders in case they are
+   separate from the KSK holder itself.
+
+   The distribution mechanism can be more or less tamper-proof. If the
+   key holder publishes the public key, or perhaps just a secure
+   fingerprint of the key in a major newspaper it may be rather
+   difficult to tamper with. A key acquired that way may be easier to
+   trust than if it had just been downloaded from a web page.
+
+   Out-of-band verification can for instance be the key being signed
+   by a certificate issued by a known Certificate Authority that the
+   resolver has reason to trust.
+
+3.1. Simplicity vs Trust 
+
+   The fewer keys that are in use the simpler the key management
+   becomes. Therefore increasing the number of keys should only be
+   considered when the complexity is not the major concern. A perfect
+   example of this is the distinction between so called Key Signing
+   Keys, KSK, and Zone Signing Keys, ZSK. This distinction adds
+   overall complexity but simplifies real life operations and was an
+   overall gain since operational simplification was considered to be
+   a more crucial issue than the added complexity.
+
+   In the case of a security apex there are additional issues to
+   consider, among them
+
+      * maximizing trust in the KSK received out-of-band
+
+      * authenticating the legitimacy of the ZSKs used
+
+   In some cases this will be easy, since the same entity will manage
+   both ZSKs and KSKs (i.e. it will authenticate itself, somewhat
+   similar to a self-signed certificate). In some environments it will
+   be possible to get the trusted key installed in the resolver end by
+   decree (this would seem to be a likely method within corporate and
+   government environments).
+
+   In other cases, however, this will possibly not be sufficient. In
+   the case of the root zone this is obvious, but there may well be
+   other cases.
+
+3.2. Expanding the "Trust Base"
+
+   For a security apex where the ZSKs and KSK are not held by the same
+   entity the KSK will effectively authenticate the identity of
+   whoever does real operational zone signing. The amount of trust
+   that the data signed by a ZSK will get is directly dependent on
+   whether the end resolver trusts the KSK or not, since the resolver
+   has no OOB access to the public part of the ZSKs (for practical
+   reasons).
+
+   Since the KSK holder is distinct from the ZSK holder the obvious
+   question is whether it would then be possible to further improve
+   the situation by using multiple KSK holders and thereby expanding
+   the trust base to the union of that available to each individual
+   KSK holder. "Trust base" is an invented term intended to signify
+   the aggregate of Internet resolvers that will eventually choose to
+   trust a key issued by a particular KSK holder.
+
+   A crucial issue when considering trust expansion through addition
+   of multiple KSK holders is that the KSK holders are only used to
+   authenticate the ZSKs used for signing the zone. I.e. the function
+   performed by the KSK is basically:
+
+   	     "This is indeed the official ZSK holder for this zone,
+   	     I've verified this fact to the best of my abilitites."
+
+   Which can be thought of as similar to the service of a public
+   notary. I.e. the point with adding more KSK holders is to improve
+   the public trust in data signed by the ZSK holders by improving the
+   strength of available authentication. 
+
+   Therefore adding more KSK holders, each with their own trust base,
+   is by definition a good thing. More authentication is not
+   controversial. On the contrary, when it comes to authentication,
+   the more the merrier.
+
+   
+4. Proposed Semantics for Signing the KEY Resource Record Set
+
+   In DNSSEC according to RFC2535 all KEY Resource Records are used to
+   sign all authoritative data in the zone, including the KEY RRset
+   itself, since RFC2535 makes no distinction between Key Signing
+   Keys, KSK, and Zone Signing Keys, ZSK.  With Delegation Signer [DS]
+   it is possible to change this to the KEY RRset being signed with
+   all KSKs and ZSKs but the rest of the zone only being signed by the
+   ZSKs.
+
+   This proposal changes this one step further, by recommending that
+   the KEY RRset is only signed by the Key Signing Keys, KSK, and
+   explicitly not by the Zone Signing Keys, ZSK. The reason for this
+   is to maximize the amount of space in the DNS response packet that
+   is available for additional KSKs and signatures thereof. The rest
+   of the authoritative zone contents are as previously signed by only
+   the ZSKs.
+
+4.1. Packet Size Considerations
+
+   The reason for the change is to keep down the size of the aggregate
+   of KEY RRset plus SIG(KEY) that resolvers will need to acquire to
+   perform validation of data below a security apex. For DNSSEC data
+   to be returned the DNSSEC OK bit in the EDNS0 OPT Record has to be
+   set, and therefore the allowed packet size can be assumed to be at
+   least the EDNS0 minimum of 4000 bytes.
+
+   When querying for KEY + SIG(KEY) for "." (the case that is assumed
+   to be most crucial) the size of the response packet after the
+   change to only sign the KEY RR with the KSKs break down into a
+   rather large space of possibilities. Here are a few examples for
+   the possible alternatives for different numbers of KSKs and ZSKs
+   for some different key lengths (all RSA keys, with a public
+   exponent that is < 254). This is all based upon the size of the
+   response for the particular example of querying for
+   
+	". KEY IN"
+
+   with a response of entire KEY + SIG(KEY) with the authority and
+   additional sections empty:
+
+   	      ZSK/768 and KSK/1024   (real small)
+	      Max 12 KSK +  3 ZSK  at 3975
+	          10 KSK +  8 ZSK  at 3934
+		   8 KSK + 13 ZSK  at 3893
+
+	      ZSK/768 + KSK/1280
+	      MAX 10 KSK +  2 ZSK  at 3913
+	           8 KSK +  9 ZSK  at 3970
+                   6 KSK + 15 ZSK  at 3914
+
+	      ZSK/768 + KSK/1536
+	      MAX  8 KSK +  4 ZSK  at 3917
+                   7 KSK +  8 ZSK  at 3938
+                   6 KSK + 12 ZSK  at 3959
+
+              ZSK/768 + KSK/2048
+              MAX  6 KSK +  5 ZSK  at 3936
+                   5 KSK + 10 ZSK  at 3942
+
+              ZSK/1024 + KSK/1024
+              MAX 12 KSK +  2 ZSK  at 3943
+                  11 KSK +  4 ZSK  at 3930
+                  10 KSK +  6 ZSK  at 3917
+                   8 KSK + 10 ZSK  at 3891
+
+              ZSK/1024 + KSK/1536
+              MAX  8 KSK +  3 ZSK  at 3900
+                   7 KSK +  6 ZSK  at 3904
+                   6 KSK +  9 ZSK  at 3908
+
+              ZSK/1024 + KSK/2048
+              MAX  6 KSK +  4 ZSK  at 3951
+                   5 KSK +  8 ZSK  at 3972
+                   4 KSK + 12 ZSK  at 3993
+
+   Note that these are just examples and this document is not making
+   any recommendations on suitable choices of either key lengths nor
+   number of different keys employed at a security apex.
+
+   This document does however, based upon the above figures, make the
+   recommendation that at a security apex that expects to distribute
+   "trusted keys" the KEY RRset should only be signed with the KSKs
+   and not with the ZSKs to keep the size of the response packets
+   down.
+
+
+5. Proposed Use of Multiple "Trusted Keys" in a Validating Resolver
+
+   In DNSSEC according to RFC2535[RFC2535] validation is the process
+   of tracing a chain of signatures (and keys) upwards through the DNS
+   hierarchy until a "trusted key" is reached. If there is a known
+   trusted key present at a security apex above the starting point
+   validation becomes an exercise with a binary outcome: either the
+   validation succeeds or it fails. No intermediate states are
+   possible.
+
+   With multiple "trusted keys" (i.e. the KEY RRset for the security
+   apex signed by multiple KSKs) this changes into a more complicated
+   space of alternatives. From the perspective of complexity that may
+   be regarded as a change for the worse. However, from a perspective
+   of maximizing available trust the multiple KSKs add value to the
+   system.
+
+5.1. Possible to do Threshold Validation
+
+   With multiple KSKs a new option that opens for the security
+   concious resolver is to not trust a key individually. Instead the
+   resolver may decide to require the validated signatures to exceed a
+   threshold. For instance, given M trusted keys it is possible for
+   the resolver to require N-of-M signatures to treat the data as
+   validated.
+
+   I.e. with the following pseudo-configuration in a validating
+   resolver
+
+   	security-apex "." IN {
+	   keys { ksk-1 .... ;
+      	          ksk-2 .... ;
+	          ksk-3 .... ; 
+		  ksk-4 .... ;
+		  ksk-5 .... ;
+	        };
+	   validation {
+	      # Note that ksk-4 is not present below
+	      keys { ksk-1; ksk-2; ksk-3; ksk-5; }; 
+              # 3 signatures needed with 4 possible keys, aka 75%
+              needed-signatures 3;
+           };
+	};
+
+   we configure five trusted keys for the root zone, but require two
+   valid signatures for the top-most KEY for validation to
+   succeed. I.e.  threshold validation does not force multiple
+   signatures on the entire signature chain, only on the top-most
+   signature, closest to the security apex for which the resolver has
+   trusted keys.		    
+
+5.2. Not All Trusted Keys Will Be Available
+
+   With multiple KSKs held and managed by separate entities the end
+   resolvers will not always manage to get access to all possible
+   trusted keys. In the case of just a single KSK this would be fatal
+   to validation and necessary to avoid at whatever cost. But with
+   several fully trusted keys available the resolver can decide to
+   trust several of them individually. An example based upon more
+   pseudo-configuration:
+
+   	security-apex "." IN {
+	   keys { ksk-1 .... ;
+      	          ksk-2 .... ;
+	          ksk-3 .... ; 
+		  ksk-4 .... ;
+		  ksk-5 .... ;
+	        };
+	   validation {
+	      # Only these two keys are trusted independently
+	      keys { ksk-1; ksk-4; }; 
+              # With these keys a single signature is sufficient
+	      needed-signatures 1;
+           };
+	};
+
+   Here we have the same five keys and instruct the validating
+   resolver to fully trust data that ends up with just one signature
+   from by a fully trusted key.
+
+   The typical case where this will be useful is for the case where
+   there is a risk of the resolver not catching a rollover event by
+   one of the KSKs. By doing rollovers of different KSKs with
+   different schedules it is possible for a resolver to "survive"
+   missing a rollover without validation breaking. This improves
+   overall robustness from a management point of view.
+
+5.3. Not All Possible KSKs Need to Be Trusted
+
+   With just one key available it simply has to be trusted, since that
+   is the only option available. With multiple KSKs the validating
+   resolver immediately get the option of implementing a local policy
+   of only trusting some of the possible keys.
+
+   This local policy can be implemented either by simply not
+   configuring keys that are not trusted or, possibly, configure them
+   but specify to the resolver that certain keys are not to be
+   ultimately trusted alone.
+
+
+6. Additional Benefits from Having Multiple KSKs
+
+6.1. More Robust Key Rollovers
+
+   With only one KSK the rollover operation will be a delicate
+   operation since the new trusted key needs to reach every validating
+   resolver before the old key is retired. For this reason it is
+   expected that long periods of overlap will be needed.
+
+   With multiple KSKs this changes into a system where different
+   "series" of KSKs can have different rollover schedules, thereby
+   changing from one "big" rollover to several "smaller" rollovers.
+
+   If the resolver trusts several of the available keys individually
+   then even a failure to track a certain rollover operation within
+   the overlap period will not be fatal to validation since the other
+   available trusted keys will be sufficient.
+
+6.2. Evaluation of Multiple Key Distribution Mechanisms
+
+   Distribution of the trusted keys for the DNS root zone is
+   recognized to be a difficult problem that ...
+
+   With only one trusted key, from one single "source" to distribute
+   it will be difficult to evaluate what distribution mechanism works
+   best. With multiple KSKs, held by separate entitites it will be
+   possible to measure how large fraction of the resolver population
+   that is trusting what subsets of KSKs.
+
+
+7. Security Considerations
+
+   From a systems perspective the simplest design is arguably the
+   best, i.e. one single holder of both KSK and ZSKs. However, if that
+   is not possible in all cases a more complex scheme is needed where
+   additional trust is injected by using multiple KSK holders, each
+   contributing trust, then there are only two alternatives
+   available. The first is so called "split keys", where a single key
+   is split up among KSK holders, each contributing trust. The second
+   is the multiple KSK design outlined in this proposal.
+
+   Both these alternatives provide for threshold mechanisms. However
+   split keys makes the threshold integral to the key generating
+   mechanism (i.e. it will be a property of the keys how many
+   signatures are needed). In the case of multiple KSKs the threshold
+   validation is not a property of the keys but rather local policy in
+   the validating resolver. A benefit from this is that it is possible
+   for different resolvers to use different trust policies. Some may
+   configure threshold validation requiring multiple signatures and
+   specific keys (optimizing for security) while others may choose to
+   accept a single signature from a larger set of keys (optimizing for
+   redundancy). Since the security requirements are different it would
+   seem to be a good idea to make this choice local policy rather than
+   global policy.
+
+   Furthermore, a clear issue for validating resolvers will be how to
+   ensure that they track all rollover events for keys they
+   trust. Even with operlap during the rollover (which is clearly
+   needed) there is still a need to be exceedingly careful not to miss
+   any rollovers (or fail to acquire a new key) since without this
+   single key validation will fail. With multiple KSKs this operation
+   becomes more robust, since different KSKs may roll at different
+   times according to different rollover schedules and losing one key,
+   for whatever reason, will not be crucial unless the resolver
+   intentionally chooses to be completely dependent on that exact key.
+
+8. IANA Considerations.
+
+   NONE.
+
+
+9. References
+
+9.1. Normative.
+
+   [RFC2535] Domain Name System Security Extensions. D. Eastlake. 
+	     March 1999.
+
+   [RFC3090] DNS Security Extension Clarification on Zone Status. 
+	     E. Lewis.  March 2001.
+
+
+9.2. Informative.
+
+   [RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
+	     (DNS). D.  Eastlake 3rd. May 2001.
+
+   [RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad. 
+	     December 2001.
+
+   [DS]      Delegation Signer Resource Record. 
+	     O. Gudmundsson. October 2002. Work In Progress.
+
+10. Acknowledgments.
+
+   Bill Manning came up with the original idea of moving complexity
+   from the signing side down to the resolver in the form of threshold
+   validation. I've also had much appreciated help from (in no
+   particular order) Jakob Schlyter, Paul Vixie, Olafur Gudmundson and
+   Olaf Kolkman.
+
+
+11. Authors' Address
+Johan Ihren
+Autonomica AB
+Bellmansgatan 30
+SE-118 47 Stockholm, Sweden
+johani@autonomica.se