idnits 2.17.1 draft-ietf-dnsext-ad-is-secure-06.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 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 are 2 instances of too long lines in the document, the longest one being 2 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 58: '...since a conformant server SHOULD never...' RFC 2119 keyword, line 82: '... The AD bit SHOULD be used by the lo...' RFC 2119 keyword, line 84: '... SHOULD be ignored when the remote r...' RFC 2119 keyword, line 90: '... SHOULD be used whenever possible....' RFC 2119 keyword, line 111: '...orm checking, but SHOULD still set the...' (20 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. == Line 44 has weird spacing: '...ges the speci...' == 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", "RECOMMENDED", in this document are to be interpreted as described in RFC2119. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In the absence of one or more of these factors AD bit from a resolver SHOULD NOT be trusted. For example, home users frequently depend on their ISP to provide recursive DNS service; it is not advisable to trust these resolvers. A roaming/traveling host SHOULD not use DNS resolvers offered by DHCP when looking up information where security status matters. -- 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 (June 2002) is 7984 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 242 looks like a reference -- Missing reference section? 'RFC2535' on line 245 looks like a reference -- Missing reference section? 'RFC3225' on line 255 looks like a reference -- Missing reference section? 'RFC2845' on line 248 looks like a reference -- Missing reference section? 'RFC2931' on line 252 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 8 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 June 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 December 25, 2002. 36 Copyright Notice 38 Copyright (C) The Internet Society (2002). All rights reserved. 40 Abstract 42 Based on implementation experience, the RFC2535 definition of the 43 Authenticated Data (AD) bit in the DNS header is not useful. This 44 draft changes the specification so that the AD bit is only set on 45 answers where signatures have been cryptographically verified or the 46 server is authoritative for the data and is allowed to set the bit by 47 policy. 49 1 - Introduction 51 Familiarity with the DNS system [RFC1035] and DNS security extensions 52 [RFC2535] is helpful but not necessary. 54 As specified in RFC 2535 (section 6.1), the AD (Authenticated Data) 55 bit indicates in a response that all data included in the answer and 56 authority sections of the response have been authenticated by the 57 server according to the policies of that server. This is not 58 especially useful in practice, since a conformant server SHOULD never 59 reply with data that failed its security policy. 61 This draft redefines the AD bit such that it is only set if all data 62 in the response has been cryptographically verified or otherwise 63 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 a 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 - Motivation 73 A full DNSSEC capable resolver called directly from an application 74 can return to the application the security status of the RRsets in 75 the answer. However, most applications use a limited stub resolver 76 that relies on an external full resolver. The remote resolver can 77 use the AD bit in a response to indicate the security status of the 78 data in the answer, and the local resolver can pass this information 79 to the application. The application in this context can be either a 80 human using a DNS tool or a software application. 82 The AD bit SHOULD be used by the local resolver if and only if it has 83 been explicitly configured to trust the remote resolver. The AD bit 84 SHOULD be ignored when the remote resolver is not trusted. 86 An alternate solution would be to embed a full DNSSEC resolver into 87 every application. This has several disadvantages. 89 - DNSSEC validation is both CPU and network intensive, and caching 90 SHOULD be used whenever possible. 92 - DNSSEC requires non-trivial configuration - the root key must be 93 configured, as well as keys for any "islands of security" that will 94 exist until DNSSEC is fully deployed. The number of configuration 95 points should be minimized. 97 1.2 - Requirements 99 The key words "MAY", "MAY NOT" "MUST", "MUST NOT", "SHOULD", "SHOULD 100 NOT", "RECOMMENDED", in this document are to be interpreted as 101 described in RFC2119. 103 1.3 - Updated documents and sections 105 The definition of the AD bit in RFC2535, Section 6.1, is changed. 107 2 - Setting of AD bit 109 The presence of the CD (Checking Disabled) bit in a query does not 110 affect the setting of the AD bit in the response. If the CD bit is 111 set, the server will not perform checking, but SHOULD still set the 112 AD bit if the data has already been cryptographically verified or 113 complies with local policy. The AD bit MUST only be set if DNSSEC 114 records have been requested via the OK bit [RFC3225] and relevant SIG 115 records are returned. 117 2.1 - Setting of AD bit by recursive servers 119 Section 6.1 of RFC2535 says: 121 "The AD bit MUST NOT be set on a response unless all of the RRs in 122 the answer and authority sections of the response are either 123 Authenticated or Insecure." 125 The replacement text reads: 127 "The AD bit MUST NOT be set on a response unless all of the RRsets in 128 the answer and authority sections of the response are Authenticated." 130 "The AD bit SHOULD be set if and only if all RRs in the answer 131 section and any relevant negative response RRs in the authority 132 section are Authenticated." 134 A recursive DNS server following this modified specification will 135 only set the AD bit when it has cryptographically verified the data 136 in the answer. 138 2.2 - Setting of AD bit by authoritative servers 140 A primary server for a secure zone MAY have the policy of treating 141 authoritative secure zones as Authenticated. Secondary servers MAY 142 have the same policy, but SHOULD NOT consider zone data Authenticated 143 unless the zone was transferred securely and/or the data was 144 verified. An authoritative server MUST only set the AD bit for 145 authoritative answers from a secure zone if it has been explicitly 146 configured to do so. The default for this behavior SHOULD be off. 148 2.2.1 - Justification for setting AD bit w/o verifying data 150 The setting of the AD bit by authoritative servers affects only a 151 small set of resolvers that are configured to directly query and 152 trust authoritative servers. This only affects servers that function 153 as both recursive and authoritative. All recursive resolvers SHOULD 154 ignore the AD bit. 156 The cost of verifying all signatures on load by an authoritative 157 server can be high and increases the delay before it can begin 158 answering queries. Verifying signatures at query time is also 159 expensive and could lead to resolvers timing out on many queries 160 after the server reloads zones. 162 Organizations that require that all DNS responses contain 163 cryptographically verified data MUST separate the functions of 164 authoritative and recursive servers, as authoritative servers are not 165 required to validate local secure data. 167 3 - Interpretation of the AD bit 169 A response containing data marked Insecure in the answer or authority 170 section MUST never have the AD bit set. In this case, the resolver 171 SHOULD treat the data as Insecure whether or not SIG records are 172 present. 174 A resolver MUST NOT blindly trust the AD bit unless it communicates 175 with the full function resolver over a secure transport mechanism or 176 using message authentication such as TSIG [RFC2845] or SIG(0) 177 [RFC2931] and is explicitly configured to trust this resolver. 179 4 - Applicability statement 181 The AD bit is intended to allow the transmission of the indication 182 that a resolver has verified the DNSSEC signatures accompanying the 183 records in the Answer and Authority section. The AD bit MUST only be 184 trusted when the end consumer of the DNS data has confidence that the 185 intermediary resolver setting the AD bit is trustworthy. This can 186 only be accomplished via out of band mechanism such as: 188 - Fiat: An organization can dictate that it is OK to trust certain DNS 189 servers. 190 - Personal: Because of a personal relationship or the reputation of a 191 resolver operator, a DNS consumer can decide to trust that 192 resolver. 193 - Knowledge: If a resolver operator posts the configured policy of a 194 resolver a consumer can decide that resolver is trustworthy. 196 In the absence of one or more of these factors AD bit from a resolver 197 SHOULD NOT be trusted. For example, home users frequently depend on 198 their ISP to provide recursive DNS service; it is not advisable to 199 trust these resolvers. A roaming/traveling host SHOULD not use DNS 200 resolvers offered by DHCP when looking up information where security 201 status matters. 203 When faced with a situation where there are no satisfactory recursive 204 resolvers available, running one locally is RECOMMENDED. This has 205 the advantage that it can be trusted, and the AD bit can still be 206 used to allow applications to use stub resolvers. 208 4 - Security Considerations: 210 This document redefines a bit in the DNS header. If a resolver 211 trusts the value of the AD bit, it must be sure that the responder is 212 using the updated definition, which is any DNS server/resolver 213 supporting the OK bit[RFC3225]. 215 Authoritative servers can be explicitly configured to set the AD bit 216 on answers without doing cryptographic checks. This behavior MUST be 217 off by default. The only affected resolvers are those that directly 218 query and trust the authoritative server, and this functionality 219 SHOULD only be used on servers that act both as authoritative servers 220 and recursive resolver. 222 Resolvers (full or stub) that trust the AD bit on answers from a 223 configured set of resolvers are DNSSEC security compliant. 225 5 - IANA Considerations: 227 None. 229 6 - Internationalization Considerations: 231 None. This document does not change any textual data in any 232 protocol. 234 7 - Acknowledgments: 236 The following people have provided input on this document: Robert 237 Elz, Andreas Gustafsson, Bob Halley, Steven Jacob, Erik Nordmark, 238 Edward Lewis, Jakob Schlyter, Roy Arends, Ted Lindgreen. 240 Normative References: 242 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 243 Specification'', STD 13, RFC 1035, November 1987. 245 [RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC 246 2535, March 1999. 248 [RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, 249 ``Secret Key Transaction Authentication for DNS (TSIG)'', RFC 250 2845, May 2000. 252 [RFC2931] D. Eastlake, ``DNS Request and Transaction Signatures 253 (SIG(0))'', RFC 2931, September 2000. 255 [RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC 256 3225, December 2001. 258 Authors Addresses 260 Brian Wellington Olafur Gudmundsson 261 Nominum Inc. 262 2385 Bay Road 3826 Legation Street, NW 263 Redwood City, CA, 94063 Washington, DC, 20015 264 USA USA 265 267 Full Copyright Statement 269 Copyright (C) The Internet Society (2002>. All Rights Reserved. 271 This document and translations of it may be copied and furnished to 272 others, and derivative works that comment on or otherwise explain it 273 or assist in its implementation may be prepared, copied, published 274 and distributed, in whole or in part, without restriction of any 275 kind, provided that the above copyright notice and this paragraph are 276 included on all such copies and derivative works. However, this 277 document itself may not be modified in any way, such as by removing 278 the copyright notice or references to the Internet Society or other 279 Internet organizations, except as needed for the purpose of 280 developing Internet standards in which case the procedures for 281 copyrights defined in the Internet Standards process must be 282 followed, or as required to translate it into languages other than 283 English. 285 The limited permissions granted above are perpetual and will not be 286 revoked by the Internet Society or its successors or assigns. 288 This document and the information contained herein is provided on an 289 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 290 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 291 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 292 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 293 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."