idnits 2.17.1 draft-andrews-dlv-dns-rr-00.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 179. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 156. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 163. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 169. ** 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 (June 23, 2005) is 6879 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: December 25, 2005 S. Weiler 5 SPARTA, Inc. 6 June 23, 2005 8 The DNSSEC Lookaside Validation (DLV) DNS Resource Record 9 draft-andrews-dlv-dns-rr-00 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 December 25, 2005. 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. These records allow resolvers 45 to validate DNSSEC-signed data from zones whose ancestors either 46 aren't signed or refuse to publish DS records for their children. 48 1. Introduction 50 DNSSEC [1] [2] [3] authenticates DNS data by building public-key 51 signature chains along the DNS delegation chain from a trust anchor, 52 ideally a trust anchor for the DNS root. Due to a myriad of 53 technical and political concerns, it appears unlikely that many 54 delegation-heavy zones, including the root and most generic top level 55 domains (gTLDs), will sign their zones in the near future, which 56 leaves DNS resolvers with no means to validate data from the children 57 of those zones without maintaining a large number of preconfigured 58 keys. 60 This document defines a new resource record for publishing trust 61 anchors outside of the DNS's normal delegation chain. Use of these 62 records by validators is outside the scope of this document. 64 2. DLV Resource Record 66 The DLV resource record has exactly the same wire and presentation 67 formats as the DS resource record, defined in RFC4034 Section 5. It 68 uses the same IANA-assigned values in the algorithm and digest type 69 fields as the DS record. (Those IANA registries are known as the 70 "DNS Security Algorithm Numbers" and "DS RR Type Algorithm Numbers" 71 registries.) 73 Unlike the DS record, the DLV record may not appear on the parent's 74 side of a zone cut. Consequently, DLV records do not require the 75 special processing described in section 3.1.4.1 of RFC4035. DLV 76 records may appear at the apex of a zone. 78 3. Security Considerations 80 Publishing DLV records introduces no security problems -- they're 81 just DNS data. 83 Users of DLV records will almost certainly want to impose constraints 84 on their use, but those constraints are best left to be described by 85 the users of the records. At a minimum, it would be wise to not use 86 the records without some sort of cryptographic authentication. 88 RFC4034 Section 8 describes security considerations specific to the 89 DS resource record. Those considerations are equally applicable to 90 DLV records. Of particular note, the key tag field is used to help 91 select DNSKEY resource records efficiently, but it does not uniquely 92 identify a single DNSKEY resource record. It is possible for two 93 distinct DNSKEY RRs to have the same owner name, the same algorithm 94 type, and the same key tag. An implementation that uses only the key 95 tag to select a DNSKEY RR might select the wrong public key in some 96 circumstances. 98 For discussion of the security implications of DNSSEC see RFC4033, 99 RFC4034, and RFC4035. 101 4. IANA Considerations 103 IANA has assigned DNS type code X to the DLV resource record from the 104 Specification Required portion of the DNS Resource Record Type 105 registry, as defined in [4]. 107 The DLV resource record reuses the same algorithm and digest type 108 registries already used for the DS resource record, currently known 109 as the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm 110 Numbers" registries. 112 5. Normative References 114 [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 115 "DNS Security Introduction and Requirements", RFC 4033, 116 March 2005. 118 [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 119 "Resource Records for the DNS Security Extensions", RFC 4034, 120 March 2005. 122 [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 123 "Protocol Modifications for the DNS Security Extensions", 124 RFC 4035, March 2005. 126 [4] Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain Name 127 System (DNS) IANA Considerations", BCP 42, RFC 2929, 128 September 2000. 130 Authors' Addresses 132 Mark Andrews 133 Internet Systems Consortium 134 950 Charter St. 135 Redwood City, CA 94063 136 US 138 Email: Mark_Andrews@isc.org 139 Samuel Weiler 140 SPARTA, Inc. 141 7075 Samuel Morse Drive 142 Columbia, Maryland 21046 143 US 145 Email: weiler@tislabs.com 147 Intellectual Property Statement 149 The IETF takes no position regarding the validity or scope of any 150 Intellectual Property Rights or other rights that might be claimed to 151 pertain to the implementation or use of the technology described in 152 this document or the extent to which any license under such rights 153 might or might not be available; nor does it represent that it has 154 made any independent effort to identify any such rights. Information 155 on the procedures with respect to rights in RFC documents can be 156 found in BCP 78 and BCP 79. 158 Copies of IPR disclosures made to the IETF Secretariat and any 159 assurances of licenses to be made available, or the result of an 160 attempt made to obtain a general license or permission for the use of 161 such proprietary rights by implementers or users of this 162 specification can be obtained from the IETF on-line IPR repository at 163 http://www.ietf.org/ipr. 165 The IETF invites any interested party to bring to its attention any 166 copyrights, patents or patent applications, or other proprietary 167 rights that may cover technology that may be required to implement 168 this standard. Please address the information to the IETF at 169 ietf-ipr@ietf.org. 171 Disclaimer of Validity 173 This document and the information contained herein are provided on an 174 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 175 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 176 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 177 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 178 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 179 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 181 Copyright Statement 183 Copyright (C) The Internet Society (2005). This document is subject 184 to the rights, licenses and restrictions contained in BCP 78, and 185 except as set forth therein, the authors retain all their rights. 187 Acknowledgment 189 Funding for the RFC Editor function is currently provided by the 190 Internet Society.