idnits 2.17.1 draft-ietf-dnsext-ad-is-secure-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 80: '... "The AD bit MUST NOT be set on a re...' RFC 2119 keyword, line 89: '... "The AD bit MUST NOT be set on a re...' RFC 2119 keyword, line 91: '... any data, the server MUST NOT include...' RFC 2119 keyword, line 95: '... The AD bit MUST NOT be set on a res...' RFC 2119 keyword, line 97: '... A resolver MUST NOT blindly trust t...' (3 more instances...) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2000) is 8562 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC1034' on line 49 looks like a reference -- Missing reference section? 'RFC1035' on line 133 looks like a reference -- Missing reference section? 'RFC2535' on line 136 looks like a reference -- Missing reference section? 'RFC2845' on line 139 looks like a reference -- Missing reference section? 'RFC2931' on line 143 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT Working Group Brian Wellington (Nominum) 3 INTERNET-DRAFT Olafur Gudmundsson (NAI Labs) 4 November 2000 6 Updates: RFC 2535 8 Redefinition of DNS AD bit 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Comments should be sent to the authors or the DNSEXT WG mailing list 32 namedroppers@ops.ietf.org 34 This draft expires on May 17, 2001. 36 Copyright Notice 38 Copyright (C) The Internet Society (2000). All rights reserved. 40 Abstract 42 Based on implementation experience, the current definition of the AD 43 bit in the DNS header is not useful. This draft changes the 44 specification so that the AD bit is only set on answers where 45 signatures have been cryptographically verified. 47 1 - Introduction 49 Familiarity with the DNS system [RFC1034, RFC1035] and DNS security 50 extensions [RFC2535] is helpful but not necessary. 52 As specified in RFC 2535 (section 6.1), the AD bit indicates in a 53 response that all the data included in the answer and authority 54 portion of the response has been authenticated by the server 55 according to the policies of that server. This is not especially 56 useful in practice, since a conformant server should never reply with 57 data that failed its security policy. 59 This draft proposes to redefine the AD bit such that it is only set 60 if all data in the response has been cryptographically verified. 61 Thus, a response containing properly delegated insecure data will not 62 have AD set, as will a response from a server configured without 63 DNSSEC keys. As before, data which failed to verify will not be 64 returned. An application can then use the value of the AD bit to 65 determine if the data is secure or not. 67 1.1 - Requirements 69 The key words "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this 70 document are to be interpreted as described in RFC2119. 72 1.2 - Updated documents and sections 74 The definition of the AD bit in RFC2535, Section 6.1, is changed. 76 2 - Setting of AD bit 78 Section 6.1 of RFC2535 says: 80 "The AD bit MUST NOT be set on a response unless all of the RRs in 81 the answer and authority sections of the response are either 82 Authenticated or Insecure." 84 The changes are to delete the words "either" and "or Insecure" from 85 the sentence. 87 The replacement text reads: 89 "The AD bit MUST NOT be set on a response unless all of the RRsets in 90 the answer and authority sections of the response are Authenticated." 91 If the answer section contains any data, the server MUST NOT include 92 data in the authority section that would cause the AD bit to be 93 unset. 95 The AD bit MUST NOT be set on a response unless all of the RRsets in 96 the answer and authority sections are Authenticated. 97 A resolver MUST NOT blindly trust the AD bit unless it communicates 98 with the server over secure transport mechanism or using message 99 authentication such as TSIG[RFC2845] or SIG(0)[RFC2931], and the 100 resolver policy is that it can trust the server. 102 A DNS server following this modified specification will only set the 103 AD bit when it has verified the data in the answer. In the case of a 104 primary server for a secure zone, the data MAY be considered 105 Authenticated, depending on local policy. Secondary servers SHOULD 106 NOT consider data Authenticated unless the zone was transfered 107 securely or the data was verified. 109 3 - Interpretation of the AD bit 111 A response containing data marked Insecure in the answer or authority 112 section will never have the AD bit set. In this case, the resolver 113 SHOULD treat the data as Insecure whether or not SIG records are 114 present. 116 4 - Security Considerations: 118 This document redefines a bit in the DNS header. If a resolver 119 trusts the value of the AD bit, it must be sure that the server is 120 using the updated definition. 122 5 - IANA Considerations: 124 None 126 6 - Acknowledgments: 128 The following people have provided input on this document: Andreas 129 Gustafsson, Bob Halley, Steven Jacob, 131 References: 133 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 134 Specification'', STD 13, RFC 1035, November 1987. 136 [RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC 137 2535, March 1999. 139 [RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, 140 ``Secret Key Transaction Authentication for DNS (TSIG)'', RFC 141 2845, May 2000. 143 [RFC2931] D. Eastlake, ``DNS Request and Transaction Signatures 144 (SIG(0))'', RFC 2931, September 2000. 146 Authors Addresses 148 Brian Wellington Olafur Gudmundsson 149 Nominum Inc. NAI Labs 150 950 Charter Street 3060 Washington Road (Rt. 97) 151 Redwood City, CA, 94063 Glenwood, MD, 21738 152 USA USA 153 +1 650 381 6022 +1 443 259 2389 154 156 Full Copyright Statement 158 Copyright (C) The Internet Society (2000). All Rights Reserved. 160 This document and translations of it may be copied and furnished to 161 others, and derivative works that comment on or otherwise explain it 162 or assist in its implementation may be prepared, copied, published 163 and distributed, in whole or in part, without restriction of any 164 kind, provided that the above copyright notice and this paragraph are 165 included on all such copies and derivative works. However, this 166 document itself may not be modified in any way, such as by removing 167 the copyright notice or references to the Internet Society or other 168 Internet organizations, except as needed for the purpose of 169 developing Internet standards in which case the procedures for 170 copyrights defined in the Internet Standards process must be 171 followed, or as required to translate it into languages other than 172 English. 174 The limited permissions granted above are perpetual and will not be 175 revoked by the Internet Society or its successors or assigns. 177 This document and the information contained herein is provided on an 178 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 179 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 180 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 181 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 182 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."