idnits 2.17.1 draft-ietf-dnsop-parent-sig-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 212 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 51 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2535 (ref. '2') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Parent's SIG over child's KEY 2 draft-ietf-dnsop-parent-sig-00.txt 4 Miek Gieben, Ted Lindgreen 6 Status of This Document 8 This document is an Internet-Draft and is in full conformance with 9 all provisions of Section 10 of RFC 2026. Internet-Drafts are 10 working documents of the Internet Engineering Task Force (IETF), its 11 areas, and its working groups. Note that other groups may also 12 distribute working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet- Drafts as reference 17 material or to cite them other than as "work in progress." 19 The list of current Internet-Drafts can be accessed at 20 http://www.ietf.org/ietf/1id-abstracts.txt 22 The list of Internet-Draft Shadow Directories can be accessed at 23 http://www.ietf.org/shadow.html. 25 Abstract 27 When dealing with large amounts of keys the procedures to update a zone and 28 to sign a zone need to be clearly defined and practically possible. 29 The current idea is to have the KEY RR and the parent's SIG to reside in the 30 child's zone and perhaps also in the parent's zone. We feel that this would 31 lead to very complicated procedures for large TLD's. We propose a alternative 32 scheme in which the parent zone stores the parent's signature over the child's 33 key and also a copy of the child's key itself. 35 The advantage of this proposal is that all signatures signed by a key are in 36 the same zone file as the producing key. This allows for a simple key 37 rollover and resigning mechanism. For large TLD's this is extremely important. 39 We further discuss the impact on a secure aware resolver/forwarder. 41 Table of Contents 43 Status of This Document.................................... 44 Abstract................................................... 46 Table of Contents.......................................... 47 1 Introduction............................................. 48 2 Proposal................................................. 49 3 Impact on a secure aware resolver/forwarder.............. 50 3.1 Impact of key rollovers on resolver/forwarder.......... 51 4 Key rollovers............................................ 52 4.1 Scheduled key rollover................................. 53 4.2 Unscheduled key rollover............................... 54 5 Zone resiging............................................ 56 References................................................ 58 Authors' Addresses........................................ 59 References................................................ 61 1. Introduction 62 Within a CENTR working group NLnet Labs is researching the impact of 63 DNSSEC on the ccTLDs and gTLDs. 65 In this document we are considering a secure zone, somewhere under a secure 66 entry point and on-tree [1] validation between the secure entry point and the 67 zone in question. The resolver we are considering is security aware and is 68 preconfigured with the KEY of the secure entry point. 70 RFC 2535 [2] states that a zone key must be present in the apex of a zone. 71 This can be in the at the delegation point in the parent's zonefile 72 (normally the case for null keys), or in the child's zonefile, or in both. 73 This key is only valid if it is signed by the parent, so there is also the 74 question where this signature is located. 76 The original idea was to have the KEY RR and the parent's SIG to reside 77 in the child's zone and perhaps also in the parent's zone. There is a 78 draft proposal [3], that describes how a keyrollover can be handled. 80 At NLnet Labs we found that storing the parent's signature over the 81 child's key in the child's zone: 82 - makes resigning a KEY by the parent difficult 83 - makes a scheduled keyrollover very complicated 84 - makes an unscheduled keyrollover virtually impossible 86 We propose an alternative scheme in which the parent's signature over the 87 child's key is only stored in the parent's zone, i.e. where the signing key 88 resides. This would solve the above problems. 90 2. Proposal 91 The core of the new proposal is that the parent zone stores the parent's 92 signature over the child's key and also a copy of the child's key itself. 93 The child zone also contains its zonekey, where it is selfsigned. 95 The advantage of this proposal is that all signatures signed by a key are in 96 the same zone file as the producing key. This allows for a simple key 97 rollover and resigning mechanism. For large TLD's this is extremely important. 99 A disadvantage would be that not all the information concerning one zone is 100 stored at that zone, namely the (parent) SIG RR. Note that the same argument 101 can be applied to a zone's NULL key, which is also stored at the parent. 103 3. Impact on a secure aware resolver/forwarder 104 The resolver must be aware of the fact that the parent is more authoritative 105 than a child when it comes to deciding whether a zone is secured or not. 107 Without caching and with on-tree validation, a resolver will always start 108 its search at a secure entry point. In this way it can determine whether it 109 must expect SIG records or not. 111 Considering caching in a secure aware resolver or forwarder. If information 112 of a secure zone is cached, its validated KEY should also be cached. 114 If the KEY record expires, because the KEY TTL expires or because the SIG is 115 no longer valid, the KEY should be discarded. The resolver or forwarder 116 should then also discard other data concerning the zone because it is no 117 longer validated and possible bad data should not be cached. 119 3.1. Impact of key rollovers on resolver/forwarder 120 When a zone is in the process of a key rollover, there could be a discrepancy 121 between the KEY and the SIG in the apex of the zone and the KEY and SIG that 122 are stored in the cache of a resolver. 124 Suppose a resolver has cached the NS, KEY and SIG records of a zone. Next a 125 request comes for an A record in that zone. Also the zone is in the process 126 of a keyrollover and already has new keys in its zone. The resolver receives 127 an answer consisting of the A record and a SIG over the A record. It uses 128 the tag field in the SIG to determine if it has a KEY which is suitable to 129 validate the SIG. If it does not has such a KEY the resolver must ask the 130 parent of the zone for a new KEY and then try it again. Now the resolver 131 has 2 keys for the zone, according to the tag field in the SIG it can use 132 either one. 134 If the new key also does not validate the SIG the zone is marked bad. If the 135 KEY found at the parent is the NULL key the resolver knows that the child is 136 considered insecure. This could for instance be in the case the private key 137 of the zone is stolen. 139 4. Key rollovers 140 Private keys can be stolen or a key can become over used. In both 141 cases a new a new key must be signed and distributed. This event is 142 called keyrollover. We further distinguish between a scheduled and an 143 unscheduled key rollover. A scheduled rollover is announced before hand. 144 An unscheduled key rollover is needed when a private key is compromised. 146 4.1. Scheduled key rollover 147 When the signatures, produced by the key to be rolled over, are all 148 in one zone file, there are two parties involved. Let us look at an 149 example where a TLD rolls over its zone key. The new key needs to be 150 signed with the root's key before it can be used to sign the TLD zone 151 and the zone keys of the TLD's children. The steps that need to be taken 152 by TLD and root are: 153 - the TLD adds the new key to its keyset in its zonefile. This 154 zone and keyset are signed with the old zonekey 155 - then the TLD signals the parent 156 - the root copies the new keyset, consisting of the both new 157 and the old key, in its zonefile, resigns it and signals the TLD 158 - the TLD removes the old key from its keyset, resigns its zone 159 with the new key, and signals the the root 160 - the root copies the new keyset, now consisting of the new key 161 only, and resigns it 163 4.2. Unscheduled key rollover 164 Although nobody hopes that this will ever happen, we must be able to 165 cope with possible key compromises. When such an event occurs, an 166 immediate keyrollover is needed and must be completed in the shortest 167 possible time. With two parties involved, it will still be awkward, but 168 not impossible to update two zonefiles overnight. "Out-of-band" 169 communication between the two parties will be necessary, since the 170 compromised old key can not be trusted. We think that between two 171 parties this is doable, but this complicated procedure is beyond the 172 scope of this document. [4] 174 5. Zone resigning 175 Resigning a TLD is necessary before the current signatures expire. 176 When all SIG records, produced by the TLD's zone key are kept in the 177 TLD's zonefile, and only there, such a resign session is trivial, as 178 only one party (the TLD) and one zonefile is involved. 180 Authors' Addresses 182 R. Gieben 183 Stichting NLnet Labs 184 Kruislaan 419 185 1098 VA Amsterdam 186 miek@nlnetlabs.nl 188 T. Lindgreen 189 Stichting NLnet Labs 190 Kruislaan 419 191 1098 VA Amsterdam 192 ted@nlnetlabs.nl 194 References 196 [1] Lewis, E. "DNS Security Extension Clarification on Zone Status", 197 http://www.ietf.org/internet-drafts/draft-ietf-dnsext-zone-status-04.txt 198 [2] Eastlake, D. "DNS Security Extensions", RFC 2535 199 http://www.ietf.org/rfc/rfc2535.txt?number=2535 200 [3] Andrews, M., Eastlake, D. "Domain Name System (DNS) Security Key Rollover" 201 http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rollover-01.txt 202 [4] Gieben, R. "Chain of trust" 203 http://secnl.nlnetlabs.nl/thesis/thesis.html