idnits 2.17.1 draft-andrews-dlv-dns-rr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 182. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 159. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 166. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 172. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (December 23, 2005) is 6693 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) ** Obsolete normative reference: RFC 2929 (ref. '4') (Obsoleted by RFC 5395) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Andrews 3 Internet-Draft Internet Systems Consortium 4 Expires: June 26, 2006 S. Weiler 5 SPARTA, Inc. 6 December 23, 2005 8 The DNSSEC Lookaside Validation (DLV) DNS Resource Record 9 draft-andrews-dlv-dns-rr-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 26, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document defines a new DNS Resource Record, called the DNSSEC 43 Lookaside Validation (DLV) RR, for publishing DNSSEC trust anchors 44 outside of the DNS delegation chain. 46 1. Introduction 47 DNSSEC [1] [2] [3] authenticates DNS data by building public-key 48 signature chains along the DNS delegation chain from a trust anchor, 49 ideally a trust anchor for the DNS root. 51 This document defines a new resource record for publishing such trust 52 anchors outside of the DNS's normal delegation chain. Use of these 53 records by DNSSEC validators is outside the scope of this document, 54 but it is expected that these records will help resolvers validate 55 DNSSEC-signed data from zones whose ancestors either aren't signed or 56 refuse to publish DS records for their children. 58 2. DLV Resource Record 60 The DLV resource record has exactly the same wire and presentation 61 formats as the DS resource record, defined in RFC4034 Section 5. It 62 uses the same IANA-assigned values in the algorithm and digest type 63 fields as the DS record. (Those IANA registries are known as the 64 "DNS Security Algorithm Numbers" and "DS RR Type Algorithm Numbers" 65 registries.) 67 The DLV record is a normal DNS record type without any special 68 processing requirements. In particular, the DLV record does not 69 inherit any of the special processing or handling requirements of the 70 DS record type (described in section 3.1.4.1 of RFC4035). Unlike the 71 DS record, the DLV record may not appear on the parent's side of a 72 zone cut. A DLV record may, however, appear at the apex of a zone. 74 3. Security Considerations 76 For authoritative servers and resolvers that do not attempt to use 77 DLV RRs as part of DNSSEC validation, there are no particular 78 security concerns -- DLV RRs are just like any other DNS data. 80 Software using DLV RRs as part of DNSSEC validation will almost 81 certainly want to impose constraints on their use, but those 82 constraints are best left to be described by the documents that more 83 fully describe the particulars of how the records are used. At a 84 minimum, it would be unwise to use the records without some sort of 85 cryptographic authentication. More likely than not, DNSSEC itself 86 will be used to authenticate the DLV RRs. Depending on how a DLV RR 87 is used, failure to properly authenticate it could lead to 88 significant additional security problems including failure to detect 89 spoofed DNS data. 91 RFC4034 Section 8 describes security considerations specific to the 92 DS RR. Those considerations are equally applicable to DLV RRs. Of 93 particular note, the key tag field is used to help select DNSKEY RRs 94 efficiently, but it does not uniquely identify a single DNSKEY RR. 95 It is possible for two distinct DNSKEY RRs to have the same owner 96 name, the same algorithm type, and the same key tag. An 97 implementation that uses only the key tag to select a DNSKEY RR might 98 select the wrong public key in some circumstances. 100 For further discussion of the security implications of DNSSEC see 101 RFC4033, RFC4034, and RFC4035. 103 4. IANA Considerations 105 IANA has assigned DNS type code X to the DLV resource record from the 106 Specification Required portion of the DNS Resource Record Type 107 registry, as defined in [4]. 109 The DLV resource record reuses the same algorithm and digest type 110 registries already used for the DS resource record, currently known 111 as the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm 112 Numbers" registries. 114 5. Normative References 116 [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 117 "DNS Security Introduction and Requirements", RFC 4033, 118 March 2005. 120 [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 121 "Resource Records for the DNS Security Extensions", RFC 4034, 122 March 2005. 124 [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 125 "Protocol Modifications for the DNS Security Extensions", 126 RFC 4035, March 2005. 128 [4] Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain Name 129 System (DNS) IANA Considerations", BCP 42, RFC 2929, 130 September 2000. 132 Authors' Addresses 134 Mark Andrews 135 Internet Systems Consortium 136 950 Charter St. 137 Redwood City, CA 94063 138 US 140 Email: Mark_Andrews@isc.org 142 Samuel Weiler 143 SPARTA, Inc. 144 7075 Samuel Morse Drive 145 Columbia, Maryland 21046 146 US 148 Email: weiler@tislabs.com 150 Intellectual Property Statement 152 The IETF takes no position regarding the validity or scope of any 153 Intellectual Property Rights or other rights that might be claimed to 154 pertain to the implementation or use of the technology described in 155 this document or the extent to which any license under such rights 156 might or might not be available; nor does it represent that it has 157 made any independent effort to identify any such rights. Information 158 on the procedures with respect to rights in RFC documents can be 159 found in BCP 78 and BCP 79. 161 Copies of IPR disclosures made to the IETF Secretariat and any 162 assurances of licenses to be made available, or the result of an 163 attempt made to obtain a general license or permission for the use of 164 such proprietary rights by implementers or users of this 165 specification can be obtained from the IETF on-line IPR repository at 166 http://www.ietf.org/ipr. 168 The IETF invites any interested party to bring to its attention any 169 copyrights, patents or patent applications, or other proprietary 170 rights that may cover technology that may be required to implement 171 this standard. Please address the information to the IETF at 172 ietf-ipr@ietf.org. 174 Disclaimer of Validity 176 This document and the information contained herein are provided on an 177 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 178 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 179 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 180 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 181 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 182 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 184 Copyright Statement 186 Copyright (C) The Internet Society (2005). This document is subject 187 to the rights, licenses and restrictions contained in BCP 78, and 188 except as set forth therein, the authors retain all their rights. 190 Acknowledgment 192 Funding for the RFC Editor function is currently provided by the 193 Internet Society.