idnits 2.17.1 draft-ietf-dnsext-ad-is-secure-05.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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages 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.) ** 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 83: '...orm checking, but SHOULD still set the...' RFC 2119 keyword, line 85: '...icy. The AD bit MUST only be set if D...' RFC 2119 keyword, line 92: '... "The AD bit MUST NOT be set on a re...' RFC 2119 keyword, line 98: '... "The AD bit MUST NOT be set on a re...' RFC 2119 keyword, line 101: '... "The AD bit SHOULD be set if and on...' (7 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 expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The key words "MAY", "MAY NOT" "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", in this document are to be interpreted as described in RFC2119. -- 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 (March 2002) is 8077 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? 'RFC1035' on line 190 looks like a reference -- Missing reference section? 'RFC2535' on line 193 looks like a reference -- Missing reference section? 'RFC3225' on line 203 looks like a reference -- Missing reference section? 'RFC2845' on line 196 looks like a reference -- Missing reference section? 'RFC2931' on line 200 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT Working Group Brian Wellington 3 INTERNET-DRAFT Olafur Gudmundsson 4 March 2002 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 September 25, 2002. 36 Copyright Notice 38 Copyright (C) The Internet Society (2002). 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 or the server is 46 authoritative for the data and is allowed to set the bit by policy. 48 1 - Introduction 50 Familiarity with the DNS system [RFC1035] and DNS security extensions 51 [RFC2535] is helpful but not necessary. 53 As specified in RFC 2535 (section 6.1), the AD bit indicates in a 54 response that all data included in the answer and authority sections 55 of the response have been authenticated by the server according to 56 the policies of that server. This is not especially useful in 57 practice, since a conformant server should never reply with data that 58 failed its security policy. 60 This draft proposes to redefine the AD bit such that it is only set 61 if all data in the response has been cryptographically verified or 62 otherwise meets the server's local security policy. Thus, a response 63 containing properly delegated insecure data will not have AD set, nor 64 will a response from a server configured without DNSSEC keys. As 65 before, data which failed to verify will not be returned. An 66 application running on a host that has trust relationship with the 67 server performing the recursive query can now use the value of the AD 68 bit to determine if the data is secure or not. 70 1.1 - Requirements 72 The key words "MAY", "MAY NOT" "MUST", "MUST NOT", "SHOULD", "SHOULD 73 NOT", in this document are to be interpreted as described in RFC2119. 75 1.2 - Updated documents and sections 77 The definition of the AD bit in RFC2535, Section 6.1, is changed. 79 2 - Setting of AD bit 81 The presence of the CD (checking disabled) bit in a query does not 82 affect the setting of the AD bit in the response. If the CD bit is 83 set, the server will not perform checking, but SHOULD still set the 84 AD bit if the data has already been checked or complies with local 85 policy. The AD bit MUST only be set if DNSSEC records have been 86 requested [RFC3225] and relevant SIG records are returned. 88 2.1 - Setting of AD bit by recursive servers 90 Section 6.1 of RFC2535 says: 92 "The AD bit MUST NOT be set on a response unless all of the RRs in 93 the answer and authority sections of the response are either 94 Authenticated or Insecure." 96 The replacement text reads: 98 "The AD bit MUST NOT be set on a response unless all of the RRsets in 99 the answer and authority sections of the response are Authenticated." 101 "The AD bit SHOULD be set if and only if all RRs in the answer 102 section and any relevant negative response RRs in the authority 103 section are Authenticated." 105 A recursive DNS server following this modified specification will 106 only set the AD bit when it has cryptographically verified the data 107 in the answer. 109 2.2 - Setting of AD bit by authoritative servers 111 Primary server for a secure zone the data, MAY have the policy of 112 treating authoritative secure zones as Authenticated. Secondary 113 servers MAY have the same policy, but SHOULD NOT consider zone data 114 Authenticated unless the zone was transfered securely and/or the data 115 was verified. An authoritative server MUST only set the AD bit for 116 authoritative answers from a secure zone if it has been explicitly 117 configured to do so. The default for this behavior SHOULD be off. 119 2.2.1 - Justification for setting AD bit w/o verifying data 121 The setting of the AD bit by authoritative servers affects only a 122 small set of resolvers that are configured to directly query and 123 trust authoritative servers. This only affects servers that function 124 as both recursive and authoritative. All recursive resolvers SHOULD 125 ignore the AD bit. 127 The cost of verifying all signatures on load by an authoritative 128 server can be high and increases the delay before it can begin 129 answering queries. Verifying signatures at query time is also 130 expensive and could lead to resolvers timing out on many queries 131 after the server reloads zones. 133 Organizations that require that all DNS responses contain 134 cryptographically verified data must separate the functions of 135 authoritative and recursive servers, as authoritative servers are not 136 required to validate local secure data. 138 3 - Interpretation of the AD bit 140 A response containing data marked Insecure in the answer or authority 141 section will never have the AD bit set. In this case, the resolver 142 SHOULD treat the data as Insecure whether or not SIG records are 143 present. 145 A resolver MUST NOT blindly trust the AD bit unless it communicates 146 with the server over a secure transport mechanism or using message 147 authentication such as TSIG [RFC2845] or SIG(0) [RFC2931] and is 148 configured to trust the server. 150 4 - Security Considerations: 152 This document redefines a bit in the DNS header. If a resolver 153 trusts the value of the AD bit, it must be sure that the server is 154 using the updated definition, which is any server supporting the OK 155 bit. 157 Authoritative servers that set the AD bit on answers without doing 158 cryptographic checks must only do so if explicitly configured to. 159 This only affects resolvers that directly query and trust the 160 authoritative server, and this functionality should only be used on 161 servers that act both as authoritative servers and recursive 162 resolver. 164 Authoritative servers that set the AD bit on answers without doing 165 cryptographic checks must only do so on explicit zone by zone 166 enablement. This only affects resolvers that trust the server and 167 this functionality should only be used on servers that act both as 168 authoritative servers and recursive resolver. 170 Resolvers (full or stub) that blindly trust the AD bit without 171 knowing the security policy of the server generating the answer can 172 not be considered security aware. 174 5 - IANA Considerations: 176 None. 178 6 - Internationalization Considerations: 180 None, this document does not change any textual data in any protocol. 182 7 - Acknowledgments: 184 The following people have provided input on this document: Andreas 185 Gustafsson, Bob Halley, Steven Jacob, Edward Lewis, Jakob Schlyter, 186 Roy Arends, Ted Lindgreen. 188 References: 190 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 191 Specification'', STD 13, RFC 1035, November 1987. 193 [RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC 194 2535, March 1999. 196 [RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, 197 ``Secret Key Transaction Authentication for DNS (TSIG)'', RFC 198 2845, May 2000. 200 [RFC2931] D. Eastlake, ``DNS Request and Transaction Signatures 201 (SIG(0))'', RFC 2931, September 2000. 203 [RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC 204 3225, December 2001. 206 Authors Addresses 208 Brian Wellington Olafur Gudmundsson 209 Nominum Inc. 210 2385 Bay Street 3826 Legation Street, NW 211 Redwood City, CA, 94063 Washington, DC, 20015 212 USA USA 213 215 Full Copyright Statement 217 Copyright (C) The Internet Society (2002>. All Rights Reserved. 219 This document and translations of it may be copied and furnished to 220 others, and derivative works that comment on or otherwise explain it 221 or assist in its implementation may be prepared, copied, published 222 and distributed, in whole or in part, without restriction of any 223 kind, provided that the above copyright notice and this paragraph are 224 included on all such copies and derivative works. However, this 225 document itself may not be modified in any way, such as by removing 226 the copyright notice or references to the Internet Society or other 227 Internet organizations, except as needed for the purpose of 228 developing Internet standards in which case the procedures for 229 copyrights defined in the Internet Standards process must be 230 followed, or as required to translate it into languages other than 231 English. 233 The limited permissions granted above are perpetual and will not be 234 revoked by the Internet Society or its successors or assigns. 236 This document and the information contained herein is provided on an 237 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 238 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 239 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 240 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 241 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."