idnits 2.17.1 draft-ietf-dnsop-obsolete-dlv-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6840, updated by this document, for RFC5378 checks: 2005-05-12) -- 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 (October 31, 2019) is 1638 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) ** Downref: Normative reference to an Historic RFC: RFC 4431 ** Downref: Normative reference to an Historic RFC: RFC 5074 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Operations W. Mekking 3 Internet-Draft D. Mahoney 4 Updates: 6698, 6840 (if approved) ISC 5 Intended status: Standards Track October 31, 2019 6 Expires: May 3, 2020 8 Moving DNSSEC Lookaside Validation (DLV) to Historic Status 9 draft-ietf-dnsop-obsolete-dlv-02 11 Abstract 13 This document obsoletes DNSSEC lookaside validation (DLV) and 14 reclassifies RFCs 4431 and 5074 as Historic. Furthermore, this 15 document updates RFC 6698 by excluding the DLV resource record from 16 certificates, and updates RFC 6840 by excluding the DLV registries 17 from the trust anchor selection. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 3, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 4. Moving DLV to Historic Status . . . . . . . . . . . . . . . . 3 57 4.1. Documents that reference the DLV RFCs . . . . . . . . . . 3 58 4.1.1. Documents that reference RFC 4431 . . . . . . . . . . 3 59 4.1.2. Documents that reference RFC 5074 . . . . . . . . . . 4 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 6. Security considerations . . . . . . . . . . . . . . . . . . . 4 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 63 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 DNSSEC Lookaside Validation (DLV) was introduced to assist with the 69 adoption of DNSSEC [RFC4033] [RFC4034] [RFC4035] in a time where the 70 root zone and many top level domains (TLDs) were unsigned, to help 71 entities with signed zones under an unsigned parent zone, or that 72 have registrars that don't accept DS records. The root zone is 73 signed since July 2010 and as of May 2019, 1389 out of 1531 TLDs have 74 a secure delegation from the root; thus DLV has served its purpose 75 and can now retire. 77 2. Terminology 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 81 "OPTIONAL" in this document are to be interpreted as described in 82 [RFC2119] and [RFC8174]. 84 3. Discussion 86 One could argue that DLV is still useful because there are still some 87 unsigned TLDs and entities under those zones will not benefit from 88 signing their zone. However, keeping the DLV mechanism also has 89 disadvantages: 91 o It reduces the pressure to get the parent zone signed. 93 o It reduces the pressure on registrars to accept DS records. 95 o It complicates validation code. 97 In addition, not every validator actually implemented DLV (only BIND 98 9 and Unbound) so even if an entity can use DLV to set up an 99 alternate path to its trust anchor, its effect is limited. 100 Furthermore, there was one well-known DLV registry (dlv.isc.org) and 101 that has been deprecated (replaced with a signed empty zone) on 102 September 30, 2017. With the absence of a well-known DLV registry 103 service it is unlikely that there is a real benefit for the protocol 104 on the Internet nowadays. 106 One other possible reason to keep DLV is to distribute trust anchors 107 for private enterprises. There are no known uses of DLV for this. 109 All things considered it is probably not worth the effort of 110 maintaining the DLV mechanism. 112 4. Moving DLV to Historic Status 114 There are two RFCs that specify DLV: 116 1. RFC 4431 [RFC4431] specifies the DLV resource record. 118 2. RFC 5074 [RFC5074] specifies the DLV mechanism for publishing 119 trust anchors outside the DNS delegation chain and how validators 120 can use them to validate DNSSEC-signed data. 122 This document moves both RFC 4431 [RFC4431] and RFC 5074 [RFC5074] to 123 Historic status. This is a clear signal to implementers that the DLV 124 resource record and the DLV mechanism SHOULD NOT be implemented or 125 deployed. 127 4.1. Documents that reference the DLV RFCs 129 The RFCs that are being moved to Historic status are referenced by a 130 couple of other documents. The sections below describe what changes 131 when the DLV RFCs have been reclassified as Historic. 133 4.1.1. Documents that reference RFC 4431 135 One RFC makes reference to RFC 4431 [RFC4431]. 137 4.1.1.1. RFC 5074 139 RFC 5074 [RFC5074], "DNSSEC Lookaside Validation (DLV)" describes the 140 DLV mechanism itself, and is being moved to Historic status too. 142 4.1.2. Documents that reference RFC 5074 144 Three RFCs make reference to RFC 5074 [RFC5074]. 146 4.1.2.1. RFC 6698 148 RFC 6698, "The DNS-Based Authentication of Named Entities (DANE) 149 Transport Layer Security (TLS) Protocol: TLSA" [RFC6698] specifies: 151 DNSSEC forms certificates (the binding of an identity to a key) by 152 combining a DNSKEY, DS, or DLV resource record with an associated 153 RRSIG record. These records then form a signing chain extending from 154 the client's trust anchors to the RR of interest. 156 This document updates RFC 6698 to exclude the DLV resource record 157 from certificates. 159 4.1.2.2. RFC 6840 161 RFC 6840, "Clarifications and Implementation Notes for DNS Security 162 (DNSSEC)" [RFC6840] says that when trust anchors come from different 163 sources, a validator may choose between them based on the perceived 164 reliability of those sources. But in reality this does not happen in 165 validators (both BIND 9 and Unbound have a option for a DLV trust 166 anchor that can be used solely as a fallback). 168 This document updates RFC 6840 to exclude the DLV registries from the 169 trust anchor selection. 171 4.1.2.3. RFC 8198 173 RFC 8198, "Aggressive Use of DNSSEC-Validated Cache" [RFC8198] only 174 references RFC 5074 because aggressive negative caching was first 175 proposed there. 177 5. IANA Considerations 179 IANA should update the annotation of the DLV RR type (code 32769) to 180 "Obsolete" in the DNS Parameters registry. 182 6. Security considerations 184 When the DLV mechanism goes away, zones that rely on DLV for their 185 validation will be treated as insecure. The chance that this 186 scenario actually occurs is very low, since no well-known DLV 187 registry exists. 189 7. Acknowledgements 191 Ondrej Sury for initial review. 193 8. Normative References 195 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 196 Requirement Levels", BCP 14, RFC 2119, 197 DOI 10.17487/RFC2119, March 1997, 198 . 200 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 201 Rose, "DNS Security Introduction and Requirements", 202 RFC 4033, DOI 10.17487/RFC4033, March 2005, 203 . 205 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 206 Rose, "Resource Records for the DNS Security Extensions", 207 RFC 4034, DOI 10.17487/RFC4034, March 2005, 208 . 210 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 211 Rose, "Protocol Modifications for the DNS Security 212 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 213 . 215 [RFC4431] Andrews, M. and S. Weiler, "The DNSSEC Lookaside 216 Validation (DLV) DNS Resource Record", RFC 4431, 217 DOI 10.17487/RFC4431, February 2006, 218 . 220 [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, 221 DOI 10.17487/RFC5074, November 2007, 222 . 224 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 225 of Named Entities (DANE) Transport Layer Security (TLS) 226 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 227 2012, . 229 [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and 230 Implementation Notes for DNS Security (DNSSEC)", RFC 6840, 231 DOI 10.17487/RFC6840, February 2013, 232 . 234 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 235 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 236 May 2017, . 238 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 239 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 240 July 2017, . 242 Authors' Addresses 244 Matthijs Mekking 245 ISC 246 Netherlands 248 Email: matthijs@isc.org 250 Dan Mahoney 251 ISC 252 950 Charter St 253 Redwood City, CA 94063 254 USA 256 Email: dmahoney@isc.org