DNSEXT R. Gieben Internet-Draft NLnet Labs Expires: May 17, 2005 November 16, 2004 Online Signing of Negative and Wildcard Responses draft-gieben-bert-response-00.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 May 17, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This draft contains a number of loose ends and does not include any text on any (known) corner cases. Its primary goal is to document the choices the DNSEXT working group has on the subject of fixing the NSEC enumeration in DNSSEC. If at any point in time the working group feels this idea needs further work, this draft will be updated. DNSSECbis [RFC LIST] allow for zone enumeration by walking NSEC chains. It also has a large impact on the zone size at the initial Gieben Expires May 17, 2005 [Page 1] Internet-Draft BERT Resource Record November 2004 deployment stage. This draft proposes a method to address these issues by the use of online signing of negative and wildcard responses. 1. Method To achieve the goal of online signing we will introduce the Basic Error Response Type (BERT) meta record (type = TBD). We will sign the BERT meta record to indicate the type of negative response and the type(s) covered. The BERT record contains two fields. A Rcode field, 8 bits long. Which can hold two values: "No Error" or "Name Error" [RFC 1034/35]. The second is the type covered field, which is 16 bits. Rcode field: No Error: A No Error rcode indicates that the tuple exists in the DNS but the QTYPE does not. Name Error: A Name Error rcode indicates that the tuple does not exist. Type covered field: This is normally the QTYPE value from the original query but MUST be set to `*` (255) for Name Error response and No Data responses from empty non-terminal nodes. This record is signed with online DNSKEY(s) by the authoritative server for the zone with a TTL derived from the SOA MINIMUM field. The resulting RRSIG is included in the response to the client. Multiple signatures are allowed. Since this method requires online signing there is no longer the need to special case wildcard records. These will now be signed on the fly. This in turn simplifies negative responses, as there is no longer the need to prove that the original QNAME does not exist. 2. DNSKEY Considerations A zone can choose whether to share a common key for online signing or each authoritative server can have its own zone signing key or use a mixture. The key signing key should not be shared amongst the servers. Note: all public keys used to perform online signing MUST be in the DNSKEY RRset. [Loose end] Gieben Expires May 17, 2005 [Page 2] Internet-Draft BERT Resource Record November 2004 3. RRSIG Considerations Signatures generated by this method can be cached by the authoritative server as a aid against DoS attacks or broken clients. [Loose end] 4. Interaction with DNSSECbis To permit this online signing method to interact with DNSSECbis we will take the high bit from the algorithm field of the DS record and use it to indicate whether the child zone is signed with DNSSECbis or this online signing method, 0 indicates DNSSECbis, 1 indicates this method. [Editors Note: Needs more work, Loose End] Islands of trust need to know a priori which DNSSEC method is being used. They can tell this by looking at the ALG field of the DS records. 5. Security Zones signed with this online signing method will appear to be insecure to DNSSECbis servers. The DNSSECbis resolvers will not understand the algorithm. Then there are the usual risks associated with keeping keys online. One of the operational impacts of using online signing is that a primary server feeding a couple of slave servers is less easily setup. Because an administrators is faced with the problem of how to distribute the private keys(s) used to generate the BERT RRs. The DS BERT records can either be generated on the fly or be precomputed. 6. Acknowledgements 7. Loose Ends Some of the loose ends not covered in this draft are, SERVFAIL reponses, DoS attacks on nameservers. Key consideration for slave servers. General key usage issues; how long to use, what length. RRSIG considerations. Empty non terminals. Rcode of the BERT message itself. In which section should these RR be placed. Ed Lewis:What happens if there is a mix of DNSSECbis and "this method" keys in a DS set? Maybe we need a different signalling Gieben Expires May 17, 2005 [Page 3] Internet-Draft BERT Resource Record November 2004 indicator. If the working group decides so, these loose ends will be tied up. Author's Address Miek Gieben NLnet Labs Kruislaan 419 Amsterdam 1098 VA The Netherlands EMail: miek@nlnetlabs.nl URI: http://www.nlnetlabs.nl Gieben Expires May 17, 2005 [Page 4] Internet-Draft BERT Resource Record November 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. Gieben Expires May 17, 2005 [Page 5]