idnits 2.17.1 draft-barwood-dnsop-ds-publish-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 -- The document date (12 June 2011) is 4692 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Domain Name System Operations Working Group G. Barwood 3 Internet-Draft 4 Intended status: Standards Track 12 June 2011 6 DNS Transport 7 draft-barwood-dnsop-ds-publish-02 9 Abstract 11 This document describes a new resource record type that allows a 12 child zone to update the parent DS RRset for a DNS zone. 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 12, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions 47 with respect to this document. 49 1. Introduction 51 This document defines a new resource record that may be used to 52 update the parent the DS RRset [RFC4034]. A new resource record type 53 is used, because the DS RR appears only on the upper (parental) side 54 of a delegation. 56 The DNSSEC DS RRset for a zone is defined by the child zone but stored 57 in the parent zone. After creating a new key signing key (or before an 58 existing key is to be withdrawn), the child zone needs to update the 59 parent zone. 61 There is currently no DNS protocol mechanism for accomplishing this. 62 It is assumed that the DS RRset is transferred by some out-of-band 63 mechanism. 65 The mnenomic for the new resource record type is "CDS", which is 66 intended to stand for "Child DS". 68 In particular the CDS RR MAY be used to securely automate the rollover 69 of the key signing key for a zone. 71 A new resource record type is preferred to using flags in the DNSKEY 72 RRset. It allows the DS to be published without revealing the public 73 key, delaying the time at which an attacker can start cryptanalysis; 74 the size of the DNSKEY RRset is not changed, which avoids potential 75 transport problems with large responses; it allows an algorithm to be 76 retired; and it allows arbitrary DS records to be published which may 77 have no corresponding DNSKEY, which might be useful in future for 78 defining transport parameters. 80 2. Definitions 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 3. Resource Record Format 88 The wire and presentation format is identical to the DS record. 90 However no special processing is performed by servers or clients when 91 serving or resolving. 93 The CDS record MUST be signed with a key that has the Secure Entry 94 Point flag set. 96 3. Usage 98 The CDS RRset MAY be used by the parent zone to create or update the 99 DS RRset. The parent zone MAY periodically check the child zone to see 100 if the CDS RRset has changed. The child zone MAY send a NOTIFY message 101 [RFC1996] to a name server for the parent zone to expidite the 102 process. The child zone SHOULD take into account timing considerations 103 to ensure that validation failures do not occur. 105 The parent zone SHOULD attempt to authenticate [RFC4033] the CDS 106 RRset. If the authentication succeeds extra security checks are not 107 needed. If the result is insecure, extra checks MAY be performed 108 according to the parent zone policy. If the authentication fails (the 109 result is Bogus), no action is taken, other than appropriate alerts 110 to inform operators or administrators that there is a problem. 112 The parent zone SHOULD check that the signing key(s) have the Secure 113 Entry Point flag set. 115 The parent zone SHOULD ensure that old versions of the CDS RRset do 116 not overwrite newer versions, which can occur if there is a delay 117 updating secondary name servers for the child zone. This MAY be 118 accomplished by checking that the signature inception in the RRSIG has 119 increased - that is the minimum inception of the new signatures 120 is greater than the maximum inception of the old signatures. 122 If the CDS RRset does not exist, the parent MUST take no action. 123 Specifically it MUST NOT delete the existing DS RRset. 125 If the child zone loses the secret key(s) for the zone, and needs to 126 reset the parent DS RRset, this must be accomplished by an out-of-band 127 mechanism not defined here. 129 To mitigate situations where a key signing key has been compromised, 130 the parent zone MAY take extra security measures, for example 131 informing ( by email or other methods ) the zone administrator of the 132 change, and delaying the acceptance of the new DS RRset for some 133 period of time. However the precise out-of-band measures that a parent 134 zone SHOULD take are outside the scope of this document. 136 4. IANA Considerations 138 IANA has assigned RR Type code 59 for CDS. 140 5. Security considerations 142 The CDS RRtype should allow for enhanced security. Since rollover is 143 automated, updating a DS RRset by other means may be regarded as 144 unusual and subject to extra security checks. 146 6. Acknowledgements 148 This document was created following discussion on automation of KSK 149 rollover on the DNS Operations Working Group mailing list. 151 Thanks to the people who provided review and suggestions: 152 Mark Andrews, Richard Doty, Olafur Gudmundsson, Shane Kerr, 153 Stephan Lagerholm, Chris Thompson. 155 7. Normative References 157 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 158 Requirement Levels", BCP 14, RFC 2119, March 1997. 160 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 161 Changes (DNS NOTIFY)", RFC 1996, August 1996. 163 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 164 Rose, "DNS Security Introduction and Requirements", RFC 165 4033, March 2005. 167 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 168 Rose, "Resource Records for the DNS Security Extensions", 169 RFC 4034, March 2005. 171 Appendix A. Example KSK rollover 173 The example given is a simple single signature rollover. Other 174 schemes are also possible. 176 Suppose the child zone is secure. 178 Step 1. 179 A new Key Signing Key is generated, and a new CDS record is added 180 to the child CDS RRset. 182 Step 2. 183 The parent zone retrieves the new CDS RRset from the child zone, and 184 updates the published DS RRset. 186 Step 3. 187 The child zone, after seeing the new DS record in the parent zone, 188 publishes the new DNSKEY. Note: the child zone may also publish the 189 new DNSKEY at Step 1. 191 Step 4. 192 The child zone waits for the new DNSKEY and DS records to fully 193 propagate to caches. 195 Step 5. 196 The child zone stops signing with the old Key Signing Key, and starts 197 signing with the new Key Signing Key. 199 Step 6. 200 The child zone waits for the old DNSKEY and any associated RRSIGs 201 to expire from caches. 203 Step 7. 204 The child zone removes the old CDS record from the child CDS RRset. 206 Step 8. 207 The parent zone retrieves the final CDS RRset from the child zone 208 and publishes the final DS RRset. 210 Note: when signing a zone for the first time, the DNSKEY RRset must 211 be published first, followed by a delay to allow the non-existence of 212 the DNSKEY RRset to expire from caches, before the CDS RRset is 213 published. 215 Author's Address 217 George Barwood 218 33 Sandpiper Close 219 Gloucester 220 GL2 4LZ 221 United Kingdom 223 Email: george.barwood@blueyonder.co.uk