idnits 2.17.1 draft-ietf-dnsext-ad-is-secure-04.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 == 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 84: '...orm checking, but SHOULD still set the...' RFC 2119 keyword, line 86: '...icy. The AD bit MUST only be set if D...' RFC 2119 keyword, line 93: '... "The AD bit MUST NOT be set on a re...' RFC 2119 keyword, line 99: '... "The AD bit MUST NOT be set on a re...' RFC 2119 keyword, line 102: '... "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 (February 2002) is 8105 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 191 looks like a reference -- Missing reference section? 'RFC2535' on line 194 looks like a reference -- Missing reference section? 'RFC3225' on line 204 looks like a reference -- Missing reference section? 'RFC2845' on line 197 looks like a reference -- Missing reference section? 'RFC2931' on line 201 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 6 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 February 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 July 10, 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 to the policies 57 of that server. This is not especially useful in practice, since a 58 conformant server should never reply with data that failed its 59 security policy. 61 This draft proposes to redefine the AD bit such that it is only set 62 if all data in the response has been cryptographically verified or 63 otherwise meets the server's local security policy. Thus, a response 64 containing properly delegated insecure data will not have AD set, nor 65 will a response from a server configured without DNSSEC keys. As 66 before, data which failed to verify will not be returned. An 67 application running on a host that has trust relationship with the 68 server performing the recursive query can now use the value of the AD 69 bit to determine if the data is secure or not. 71 1.1 - Requirements 73 The key words "MAY", "MAY NOT" "MUST", "MUST NOT", "SHOULD", "SHOULD 74 NOT", in this document are to be interpreted as described in RFC2119. 76 1.2 - Updated documents and sections 78 The definition of the AD bit in RFC2535, Section 6.1, is changed. 80 2 - Setting of AD bit 82 The presence of the CD (checking disabled) bit in a query does not 83 affect the setting of the AD bit in the response. If the CD bit is 84 set, the server will not perform checking, but SHOULD still set the 85 AD bit if the data has already been checked or complies with local 86 policy. The AD bit MUST only be set if DNSSEC records have been 87 requested [RFC3225] and relevant SIG records are returned. 89 2.1 - Setting of AD bit by recursive servers 91 Section 6.1 of RFC2535 says: 93 "The AD bit MUST NOT be set on a response unless all of the RRs in 94 the answer and authority sections of the response are either 95 Authenticated or Insecure." 97 The replacement text reads: 99 "The AD bit MUST NOT be set on a response unless all of the RRsets in 100 the answer and authority sections of the response are Authenticated." 102 "The AD bit SHOULD be set if and only if all RRs in the answer 103 section and any relevant negative response RRs in the authority 104 section are Authenticated." 106 A recursive DNS server following this modified specification will 107 only set the AD bit when it has cryptographically verified the data 108 in the answer. 110 2.2 - Setting of AD bit by authorative servers 112 A primary server for a secure zone the data MAY have a policy of 113 treating authoritative secure zones as Authenticated. Secondary 114 servers MAY have the same policy, but SHOULD NOT consider zone data 115 Authenticated unless the zone was transfered securely and/or the data 116 was verified. An authoritative server MUST only set the AD bit for 117 authoritative answers from a secure zone if it has been explicitly 118 configured to do so. The default for this behavior SHOULD be off. 120 2.2.1 - Justification for setting AD bit w/o verifying data 122 The setting of the AD bit by authoritative servers affects only a 123 small set of resolvers that are configured to directly query and 124 trust authoritative servers. This only affects servers that function 125 as both recursive and authorative. All recursive resolvers SHOULD 126 ignore the AD bit. 128 The cost of verifying all signatures on load by an authoritative 129 server can be high and increases the delay before it can answer begin 130 answering queries. Verifying signatures at query time is also 131 expensive and could lead to resolvers timing out on many queries 132 after the server reloads zones. 134 Organizations that require that all DNS responses contain 135 cryptographically verified data must separate the functions of 136 authoritative and recursive servers, as authoritative servers are not 137 required to validate local secure data. 139 3 - Interpretation of the AD bit 141 A response containing data marked Insecure in the answer or authority 142 section will never have the AD bit set. In this case, the resolver 143 SHOULD treat the data as Insecure whether or not SIG records are 144 present. 146 A resolver MUST NOT blindly trust the AD bit unless it communicates 147 with the server over a secure transport mechanism or using message 148 authentication such as TSIG [RFC2845] or SIG(0) [RFC2931] and is 149 configured to trust the server. 151 4 - Security Considerations: 153 This document redefines a bit in the DNS header. If a resolver 154 trusts the value of the AD bit, it must be sure that the server is 155 using the updated definition, which is any server supporting the OK 156 bit. 158 Authoritative servers that set the AD bit on answers without doing 159 cryptographic checks must only do so if explicitly configured to. 160 This only affects resolvers that directly query and trust the 161 authoritative server, and this functionality should only be used on 162 servers that act both as authoritative servers and recursive 163 resolver. 165 Authorative servers that set the AD bit on answers without doing 166 cryptographic checks must only do so on explicit zone by zone 167 enablement. This only affects resolvers that trust the server and 168 this functionality should only be used on servers that act both as 169 authorative servers and recursive resolver. 171 Resolvers (full or stub) that blindly trust the AD bit without 172 knowing the security policy of the server generating the answer can 173 not be considered security aware. 175 5 - IANA Considerations: 177 None 179 6 - Internationalization Considerations: 181 None, this document does not change any textual data in any protocol. 183 7 - Acknowledgments: 185 The following people have provided input on this document: Andreas 186 Gustafsson, Bob Halley, Steven Jacob, Edward Lewis, Jakob Schlyter, 187 Roy Arends, Ted Lindgreen. 189 References: 191 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 192 Specification'', STD 13, RFC 1035, November 1987. 194 [RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC 195 2535, March 1999. 197 [RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, 198 ``Secret Key Transaction Authentication for DNS (TSIG)'', RFC 199 2845, May 2000. 201 [RFC2931] D. Eastlake, ``DNS Request and Transaction Signatures 202 (SIG(0))'', RFC 2931, September 2000. 204 [RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC 205 3225, December 2001. 207 Authors Addresses 209 Brian Wellington Olafur Gudmundsson 210 Nominum Inc. 211 2385 Bay Street 3826 Legation Street, NW 212 Redwood City, CA, 94063 Washington, DC, 20015 213 USA USA 214 216 Full Copyright Statement 218 Copyright (C) The Internet Society (2001). All Rights Reserved. 220 This document and translations of it may be copied and furnished to 221 others, and derivative works that comment on or otherwise explain it 222 or assist in its implementation may be prepared, copied, published 223 and distributed, in whole or in part, without restriction of any 224 kind, provided that the above copyright notice and this paragraph are 225 included on all such copies and derivative works. However, this 226 document itself may not be modified in any way, such as by removing 227 the copyright notice or references to the Internet Society or other 228 Internet organizations, except as needed for the purpose of 229 developing Internet standards in which case the procedures for 230 copyrights defined in the Internet Standards process must be 231 followed, or as required to translate it into languages other than 232 English. 234 The limited permissions granted above are perpetual and will not be 235 revoked by the Internet Society or its successors or assigns. 237 This document and the information contained herein is provided on an 238 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 239 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 240 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 241 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 242 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."