idnits 2.17.1 draft-ietf-dnsext-ad-is-secure-03.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.) ** 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 79: '... "The AD bit MUST NOT be set on a re...' RFC 2119 keyword, line 88: '... "The AD bit MUST NOT be set on a re...' RFC 2119 keyword, line 91: '... "The AD bit SHOULD be set if and on...' RFC 2119 keyword, line 99: '... The AD bit MUST NOT be set on a res...' RFC 2119 keyword, line 101: '... A resolver MUST NOT blindly trust t...' (4 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 (July 2001) is 8319 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 139 looks like a reference -- Missing reference section? 'RFC2535' on line 142 looks like a reference -- Missing reference section? 'RFC2845' on line 145 looks like a reference -- Missing reference section? 'RFC2931' on line 149 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSEXT Working Group Brian Wellington 2 INTERNET-DRAFT Olafur Gudmundsson 3 July 2001 5 Updates: RFC 2535 7 Redefinition of DNS AD bit 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Comments should be sent to the authors or the DNSEXT WG mailing list 31 namedroppers@ops.ietf.org 33 This draft expires on January 17, 2002. 35 Copyright Notice 37 Copyright (C) The Internet Society (2001). All rights reserved. 39 Abstract 41 Based on implementation experience, the current definition of the AD 42 bit in the DNS header is not useful. This draft changes the 43 specification so that the AD bit is only set on answers where 44 signatures have been cryptographically verified. 46 1 - Introduction 48 Familiarity with the DNS system [RFC1035] and DNS security extensions 49 [RFC2535] is helpful but not necessary. 51 As specified in RFC 2535 (section 6.1), the AD bit indicates in a 52 response that all the data included in the answer and authority 53 portion of the response has been authenticated by the server 54 according to the policies of that server. This is not especially 55 useful in practice, since a conformant server should never reply with 56 data that failed its security policy. 58 This draft proposes to redefine the AD bit such that it is only set 59 if all data in the response has been cryptographically verified. 60 Thus, a response containing properly delegated insecure data will not 61 have AD set, neither will a response from a server configured without 62 DNSSEC keys. As before, data which failed to verify will not be 63 returned. An application can then use the value of the AD bit to 64 determine if the data is secure or not. 66 1.1 - Requirements 68 The key words "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this 69 document are to be interpreted as described in RFC2119. 71 1.2 - Updated documents and sections 73 The definition of the AD bit in RFC2535, Section 6.1, is changed. 75 2 - Setting of AD bit 77 Section 6.1 of RFC2535 says: 79 "The AD bit MUST NOT be set on a response unless all of the RRs in 80 the answer and authority sections of the response are either 81 Authenticated or Insecure." 83 The changes are to delete the words "either" and "or Insecure" from 84 the sentence. 86 The replacement text reads: 88 "The AD bit MUST NOT be set on a response unless all of the RRsets in 89 the answer and authority sections of the response are Authenticated." 91 "The AD bit SHOULD be set if and only if all RRs in the answer 92 section and any relevant negative response RRs in that authority 93 section are Authenticated." 95 AD should be set if and only if all RRs in the answer section, and 96 any relevant negative response RRs in the authority section are 97 Authenticated. 99 The AD bit MUST NOT be set on a response unless all of the RRsets in 100 the answer and authority sections are Authenticated. 101 A resolver MUST NOT blindly trust the AD bit unless it communicates 102 with the server over secure transport mechanism or using message 103 authentication such as TSIG[RFC2845] or SIG(0)[RFC2931], and the 104 resolver policy is that it can trust the server. 106 Any DNS server supporting the OK bit MUST support this definition of 107 the AD bit. A DNS server following this modified specification will 108 only set the AD bit when it has cryptographically verified the data 109 in the answer. In the case of a primary server for a secure zone, 110 the data MAY be considered Authenticated, depending on local policy. 111 Secondary servers SHOULD NOT consider data Authenticated unless the 112 zone was transfered securely or the data was verified. 114 3 - Interpretation of the AD bit 116 A response containing data marked Insecure in the answer or authority 117 section will never have the AD bit set. In this case, the resolver 118 SHOULD treat the data as Insecure whether or not SIG records are 119 present. 121 4 - Security Considerations: 123 This document redefines a bit in the DNS header. If a resolver 124 trusts the value of the AD bit, it must be sure that the server is 125 using the updated definition, which is any server supporting the OK 126 bit. 128 5 - IANA Considerations: 130 None 132 6 - Acknowledgments: 134 The following people have provided input on this document: Andreas 135 Gustafsson, Bob Halley, Steven Jacob. 137 References: 139 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 140 Specification'', STD 13, RFC 1035, November 1987. 142 [RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC 143 2535, March 1999. 145 [RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, 146 ``Secret Key Transaction Authentication for DNS (TSIG)'', RFC 147 2845, May 2000. 149 [RFC2931] D. Eastlake, ``DNS Request and Transaction Signatures 150 (SIG(0))'', RFC 2931, September 2000. 152 Authors Addresses 154 Brian Wellington Olafur Gudmundsson 155 Nominum Inc. 156 950 Charter Street 3826 Legation Street, NW 157 Redwood City, CA, 94063 Washington, DC, 20015 158 USA USA 159 161 Full Copyright Statement 163 Copyright (C) The Internet Society (2001). All Rights Reserved. 165 This document and translations of it may be copied and furnished to 166 others, and derivative works that comment on or otherwise explain it 167 or assist in its implementation may be prepared, copied, published 168 and distributed, in whole or in part, without restriction of any 169 kind, provided that the above copyright notice and this paragraph are 170 included on all such copies and derivative works. However, this 171 document itself may not be modified in any way, such as by removing 172 the copyright notice or references to the Internet Society or other 173 Internet organizations, except as needed for the purpose of 174 developing Internet standards in which case the procedures for 175 copyrights defined in the Internet Standards process must be 176 followed, or as required to translate it into languages other than 177 English. 179 The limited permissions granted above are perpetual and will not be 180 revoked by the Internet Society or its successors or assigns. 182 This document and the information contained herein is provided on an 183 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 184 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 185 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 186 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 187 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."