idnits 2.17.1 draft-barwood-dnsop-ds-publish-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 (22 May 2010) is 5085 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 22 May 2010 6 DNS Transport 7 draft-barwood-dnsop-ds-publish-00 9 Abstract 11 This document describes a new resource record type that allows a 12 child zone to publish the DS RRset. 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 October 7, 2010. 37 Copyright Notice 39 Copyright (c) 2010 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 publish the DS RRset [RFC4034] in the child zone. A new resource 53 record type is needed, because the DS RR appears only on the upper 54 (parental) side of a delegation. 56 The mnenomic for the new resource record type is "CDS", which is 57 intended to stand for "Child DS". 59 The DNSSEC DS RRset for a zone is defined by the child zone but 60 stored in the parent zone. After creating a new key signing key, the 61 child zone needs to update the parent zone. 63 There is currently no DNS protocol mechanism for accomplishing this. 64 It is assumed that the DS RRset is transferred by some out-of-band 65 mechanism. 67 In particular the CDS RR MAY be used to securely automate the rollover 68 of the key signing key for a zone. 70 2. Definitions 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 3. Resource Record Format 78 The wire and presentation format is identical to the DS record. 80 However no special processing is performed by servers or clients when 81 serving or resolving. 83 The CDS record MUST be signed with a Key Signing Key, that is a key 84 for which there is a DS record. 86 3. Usage 88 The CDS RRset MAY be used by the parent zone to create or update the 89 DS RRset. The parent zone MAY periodically check the child zone to see 90 if the CDS RRset has changed. No notification mechanism is defined in 91 this document, although a notification mechanism might be useful. 93 The parent zone SHOULD authenticate [RFC4033] the CDS RRset if 94 possible, using the current DS RRset. If the authentication succeeds, 95 or yields Insecure, extra security checks MAY be performed. If the 96 authentication fails (the result is Bogus), extra security checks MUST 97 be performed. This corresponds to a situation where the child zone has 98 lost the secret key(s) for the zone, and needs to reset the parent DS 99 RRset. 101 If the CDS RRset does not exist, the parent MUST take no action. 102 Specifically it MUST NOT delete the existing DS RRset, unless 103 stringent out-of-band security checks confirm that this is required. 105 To mitigate situations where a key signing key has been compromised, 106 the parent zone MAY take extra security measures, for example 107 informing ( by email ) the zone administrator of the change, 108 and delaying the acceptance of the new DS RRset for some period of 109 time. However the precise out-of-band measures that a parent zone 110 SHOULD take are outside the scope of this document. 112 4. IANA Considerations 114 IANA is requested to assign the DNS Resource Record Type code for 115 the CDS record. 117 5. Security considerations 119 This document is entirely concerned with security considerations. 121 6. Acknowledgements 123 This document was created following discussion on automation of KSK 124 rollover on the DNS Extensions Working Group mailing list. 126 The restriction on the signing key is due to Olafur Gudmundsson. 128 7. Normative References 130 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 131 Requirement Levels", BCP 14, RFC 2119, March 1997. 133 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 134 Rose, "DNS Security Introduction and Requirements", RFC 135 4033, March 2005. 137 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 138 Rose, "Resource Records for the DNS Security Extensions", 139 RFC 4034, March 2005. 141 Author's Address 143 George Barwood 144 33 Sandpiper Close 145 Gloucester 146 GL2 4LZ 147 United Kingdom 149 EMail: george.barwood@blueyonder.co.uk