idnits 2.17.00 (12 Aug 2021) /tmp/idnits8792/draft-ogud-dnsop-ds-remove-00.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 -- The document date (August 25, 2015) is 2461 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-dnsop-negative-trust-anchors has been published as RFC 7646 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Gudmundsson 3 Internet-Draft CloudFlare 4 Intended status: Informational August 25, 2015 5 Expires: February 26, 2016 7 Removing DS records from parent via CDS/CDNSKEY 8 draft-ogud-dnsop-ds-remove-00 10 Abstract 12 RFC7344 specifies how trust can be maintained in-band between parent 13 and child. There are two features missing in that specification: 14 initial trust setup and removal of trust anchor. This document 15 addresses the second omission. 17 There are many reasons why a domain may want to go unsigned. Some of 18 them are related to DNS operator changes, others are related to 19 DNSSEC signing system changes. The inability to turn off DNSSEC via 20 in-band signalling is seen as a liability in some circles. This 21 document addresses the issue in a sane way. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 26, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. DNSSEC Delete Algorithm . . . . . . . . . . . . . . . . . . . 3 60 3. Security considerations . . . . . . . . . . . . . . . . . . . 3 61 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 4 62 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 64 5.2. Informative References . . . . . . . . . . . . . . . . . 4 65 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 4 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 CDS/CDNSKEY [RFC7344] records are used to signal changes in trust 71 anchors, this is a great way to maintain delegations when the DNS 72 operator has no other way to notify parent that changes are needed. 73 The original versions of the draft that became RFC7344 contained a 74 "delete" signal, the DNSOP working group at the time did not want 75 that feature, thus it was removed. 77 This document re-introduces the delete option for both CDS and 78 CDNSKEY. The reason is simply that it is necessary to be able to 79 turn off DNSSEC. The main reason has to do with when a domain is 80 moved from one DNS operator to another one. Common scenarios 81 include: 83 (I) moving from a DNSSEC operator to a non-DNSSEC capable one 85 (II) moving to one that cannot/does-not-want to do a proper DNSSEC 86 rollover 88 (III) user does not want DNSSEC 90 Whatever the reason, the lack of a "remove my DS" option is turning 91 into the latest excuse as why DNSSEC cannot be deployed. 93 1.1. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 2. DNSSEC Delete Algorithm 101 The DNSKEY algorithm registry contains two reserved values: 0 and 102 255[RFC4034]. The CERT record [RFC4398] defines the value 0 to mean 103 the algorithm in the CERT record is not defined in DNSSEC. 104 For this reason, using the value 0 in CDS/CDNSKEY delete operations 105 is potentially problematic, but we propose that here anyway as the 106 risk is minimal. The alternative is to reserve one DNSSEC algorithm 107 number for this purpose. 109 Right now, no DNSSEC validator understands algorithm 0 as a valid 110 signature algorithm, thus if the validator sees a DNSKEY or DS record 111 with this value, it will treat it as unknown. Accordingly, the zone 112 is treated as unsigned unless there are other algorithms present. 114 In the context of CDS and CDNSKEY records, DNSSEC algorithm 0 is 115 defined and means delete the DS set. The contents of the records 116 MUST contain only the fixed fields as show below. 118 (I) CDS 0 0 0 120 (II) CDNSKEY 0 3 0 122 The there is no keying information in the records, just the command 123 to delete all DS records. This record is signed in the same way as 124 CDS/CDNSKEY is signed. 126 Once the parent has verified the CDS/CDNSKEY record and it has passed 127 other acceptance tests, the DS record MUST be removed. At this point 128 the child can start the process of turning DNSSEC off. 130 3. Security considerations 132 This document is about avoiding validation failures when a domain 133 moves from one DNS operator to another one. In most cases it is 134 preferable that operators collaborate on the rollover by doing a 135 KSK+ZSK rollover as part of the handoff, but that is not always 136 possible. This document addresses the case where unsigned state is 137 needed. 139 This document does not introduce any new problems, but like Negative 140 Trust Anchor[I-D.ietf-dnsop-negative-trust-anchors], it addresses 141 operational reality. 143 4. IANA considerations 145 This document updates the following IANA registries: "DNS Security 146 Algorithm Numbers" 148 Algorithm 0 adds a reference to this document. 150 5. References 152 5.1. Normative References 154 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 155 Rose, "Resource Records for the DNS Security Extensions", 156 RFC 4034, DOI 10.17487/RFC4034, March 2005, 157 . 159 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 160 DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 161 10.17487/RFC7344, September 2014, 162 . 164 5.2. Informative References 166 [I-D.ietf-dnsop-negative-trust-anchors] 167 Ebersman, P., Kumari, W., Griffiths, C., Livingood, J., 168 and R. Weber, "Definition and Use of DNSSEC Negative Trust 169 Anchors", draft-ietf-dnsop-negative-trust-anchors-13 (work 170 in progress), August 2015. 172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 174 RFC2119, March 1997, 175 . 177 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 178 System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006, 179 . 181 Appendix A. Acknowledgements 183 This document is generated using the mmark tool that Miek Gieben has 184 developed. 186 The kick in the rear to finally write this draft came from Jacques 187 LaTour and Paul Wouters. 189 Author's Address 191 Olafur Gudmundsson 192 CloudFlare 194 Email: olafur+ietf@cloudflare.com