idnits 2.17.1 draft-ietf-dnsind-keyreferral-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 expiration date. The document expiration date should appear on the first and last page. == 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 440 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (April 1, 1999) is 9157 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 4 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSIND WG Edward Lewis 2 INTERNET DRAFT TIS Labs 3 May Update: RFC 2535 Jerry Scharf 4 Catagory: I-D ISC 5 April 1, 1999 7 The Zone Key Referral 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Comments should be sent to the authors or the DNSIND WG mailing list 32 . 34 This draft expires on October 1, 1999 36 Copyright Notice 38 Copyright (C) The Internet Society (1999). All rights 39 reserved. 41 Notes on this document 43 This section will only appear in the -00.txt edition of this draft. 45 This document originated in the DNSSEC working group in June 1998. The 46 discussion of the issues in this draft were tabled until the publication 47 of the then current DNSSEC drafts as RFCs. 49 The first version of this document lists a third author, John Gilmore. 50 He is listed as an author because he was one of the initiators of what is 51 proposed. In this and following versions he is only listed in the 52 Acknowledgements (as opposed to being an author) as he has not been 53 involved in the writing/editing of the draft. This has been done to 54 avoid assigning his name to a document he may not have a chance to read, 55 this is not intended as a slight on his efforts. 57 When commenting on this draft, please be aware that some terms used here 58 are up for negotiation before progressing - such as "thief" and "road 59 block" appearing later in the draft. Comments which are left justified 60 were added during the re-issuing of the draft, they add context that 61 may have been lost over time. 63 Abstract 65 A new type of key is defined to address the problems of 66 performance in large delegeted zones and issues of liability of 67 registrars with regards to the storing of public keys belonging 68 to zone cuts. This new key type also brings DNSSEC more in line 69 with the DNS treatment of zone cuts and speeds recovery in 70 handling privatekey exposure. 72 The new type of key is a referral record that is stored, signed, 73 at the parent zone's place for the delegation point. A resolver 74 receiving this record is being informed that there are genuine 75 public keys at the child's authoritative name servers. The 76 parent no longer needs to store the child's public keys locally. 78 1 Introduction 80 There are a number of different reasons for the proposal of this 81 new key type. Reasons include: 82 o the performance impact that RFC 2535 has on name servers 83 o the problem of updating a widely delegated parent zone on demand 84 o statements in RFC 2181 on authoritative data at delegations 85 o perceived liability of the operator of a name server or registry 87 To address these issues, which are expanded upon below, a new 88 key type is proposed - a "zone key referral" - to join the user 89 key, host key, and zone key types defined in RFC 2535. 91 1.1 Performance Issues 93 A sample zone will be used to illustrate the problem. The 94 example will part from reality mostly in the length of zone 95 names, which changes the size of the owner and resource record 96 data fields. 98 # $ORIGIN test. 99 # @ IN SOA 100 # IN SIG SOA 101 # IN KEY <1024 bit zone key> 102 # IN SIG KEY 103 # IN SIG KEY 104 # IN NS ns.test. 105 # IN SIG NS 106 # IN NXT my-org.test. NS SOA SIG KEY NXT 107 # IN SIG NXT 108 # 109 # my-org IN KEY <1024 bit zone key> 110 # IN KEY <1024 bit zone key> 111 # IN SIG KEY 112 # IN NS ns1.my-org.test. 113 # IN NS ns2.my-org.test. 114 # IN NXT them.test. NS SIG KEY NXT 115 # IN SIG NXT 116 # 117 # them IN KEY 0xC100 3 1 118 # IN SIG KEY 119 # IN NS ns1.them.test. 120 # IN NS ns2.them.test. 121 # IN NXT test. NS SIG KEY NXT 122 # IN SIG NXT 124 In this zone file fragment, "my-org" is a delegation point of 125 interest with two registered public keys. Presumably, one key 126 is for signatures generated currently and the other is for still 127 living and valid but older signatures. "them" is another 128 delegation point, with a NULL key. This signifies that this zone 129 is unsecured. 131 To analyze the performance impact of the storing of keys, the 132 number of bytes used to represent the RRs in the procotol format 133 is used. The actual number of bytes stored will likely be 134 higher, accounting for data structure overhead and alignment. 135 The actual number of bytes transferred will be lower due to DNS 136 name compression. 138 The number of bytes for my-org's two 1024-bit keys, two NS 139 records, NXT and the associated signatures is 526. The bytes 140 needed for them (with the NULL key) is 346. Currently, there 141 are close to 2 million entries in com., so if we take my-org as 142 a typical domain, over 1GB on memory will be needed for com. 144 The zone keys used in the example are set to 1024 bits. This 145 number may range from as low as 512 bits upwards to over 3000 146 bits. To scale the above numbers to a different key size, 147 multiply the difference in key sizes by 4 for my-org and by 2 148 for them, and adjust the numbers accordingly. 150 The increased size of the data held for the zone cuts will have 151 two impacts at the transport and below layers. Bandwidth beyond 152 that currently needed will be used to carry the KEY records. 153 The inclusion of all of the child's keys will also push DNS over 154 the UDP size limit and start using TCP - which could cause 155 critical problems for current heavily used name servers, like 156 the roots. 158 Another impact, not illustrated by the example, is the frequency 159 of updates. If each time a public key for my-org is added or 160 deleted, the SOA serial number will have to increase, and the 161 SOA signed again. If an average zone changes its keys(s) once 162 per month, there will be on average 45 updates per minute in a 163 zone of 2 million delegations. 165 (The multiple algorithms issue is an extension of multiple keys. The 166 example should be updated to show at least a DSS key as well as an RSA 167 key.) 169 1.2 Security Incident Recovery (w/ respect to keys only) 171 Once a zone administrator is alerted that any key's private 172 counterpart has been discovered (exposed), the first action to 173 be taken is to stop advertising the public key in DNS. This 174 doesn't end the availability of the key - it will be residing in 175 caches - but is the closest action resembling revokation 176 available in DNS. 178 Stopping the advertisement in the zone's name servers is as 179 quick as altering the master file and restarting the name 180 server. Having to do this in two places will will only delay 181 the time until the recovery is complete. 183 For example, a registrar of a top level domain has decided to 184 update its zone only on Mondays and Fridays due to the size of 185 the zone. A customer/delegatee is the victim of a break in, in 186 which one of the items taken is the file of private keys used to 187 sign DNS data. If this occurs on a Tuesday, the thief has until 188 Friday to use the keys before they disappear from the DNS, even 189 if the child stops publishing them immediately. 191 If the public key set is in the parent zone, and the parent zone 192 is not able to make the change quickly, the public key cannot be 193 revoked quickly. If the parent only refers to there being a key 194 at the child zone, then the child has the agility to change the 195 keys - even issue a NULL key, which will force all signatures in 196 the zone to become suspect. 198 1.3 DNS Clarifications 200 RFC 2181, section 6, clarifies the status of data appearing at a 201 zone cut. Data at a zone cut is served authoritatively from the 202 servers listed in the NS set present at the zone cut. The data 203 is not (necessarily) served authoritatively from the parent. 204 (The exception is in servers handling both the parent and child 205 zone.) 207 Section 6 also mentions that there are two exceptions created by 208 DNSSEC, the NXT single record set and the KEY set. This 209 proposal addresses the exception relating to the KEY set, 210 limiting its severity (but falling short of removing it 211 altogether). By limiting the exception, we will be simplifying 212 DNS. 214 1.4 Liability 216 Liability is a legal concept, so it is not wise to attempt an 217 engineering solution to it. However, the perceived liability 218 incurred in using DNSSEC by registrars may prevent the adoption 219 of DNSSEC. Hence DNSSEC should be engineered in such a away to 220 address the concern. 222 One source of liability is the notion that by advertising a 223 public key for a child zone, a parent zone is providing a 224 service of security. With that comes responsibility. By having 225 the parent merely indicate that a child has a key (or has no 226 key), the parent is providing less in the way of security. If 227 the parent is wrong, the potential loss is less. Instead of 228 falsely authenticated data, configuration errors will be 229 apparent to the resolving client. 231 2 The Proposal 233 The proposal is to introduce a new key type which indicates 234 whether the delegated zone is running secured or not. Running 235 secured is either a zone signed with at least one key, an 236 experimental zone, or a zone with only NULL keys published. 238 The Zone Referral Key will resemble the NULL key in syntax. 239 There will be a flags field, an algorithm field, and a protocol 240 field, but no public key material. The Referral Key is signed 241 by the parent zone, as was the public key set in RFC 2065. 242 There is only one Referral Key RR present. 244 The Referral Key flags field will have the following values: 245 Field Bit(s) Value Meaning 247 A/C 0- 1 0b01 indicates a key will be found 248 0b11 indicates a key will not be found 249 0b?0 error (referral cannot encrypt) 250 XT 2 0 no extended flags are needed 251 Z 4- 5 0 must be zero for all keys 252 NAMTYP 6- 7 0b11 this is a referral to a zone key 253 Z 8-11 0 must be zero for all keys 254 SIG 12-15 0 must be zero for a referral key 256 The legal values of the flags field are (in summary): 258 Hex Value Indicates 259 0x4300 The delegation has a key record set 260 0xC300 The delegation has no key record 262 Other values are not valid for Referral Keys (but may be valid 263 for other keys). 265 The Protocol field must be set to 3, the DNSSEC protocol value. 267 The Algorithm field must be 0. 269 The algorithm is not important at this point. So long as the searcher 270 knows to expect a key set at the delegated zone's apex, a secure chain 271 is possible. One the key set is retrieved and verified, then the 272 algorithms used in the delegated zone are known. (The issue is that a 273 zone may be signed in algorithm 1 and not 3, 3 and not 1, both, etc., 274 and a secure resolver must know this in order to set signature arrival 275 expectations. 277 2.1 Example 279 The Referral key for my-org.test. and them.test. would appear as 280 the following in the zone master file: 282 my-org.test. IN KEY 0x4300 3 0 283 them.test. IN KEY 0xC300 3 0 285 In the example introduced earlier, the master file would change 286 to the following. 288 # $ORIGIN test. 289 # @ IN SOA 290 # IN SIG SOA 291 # IN KEY <1024 bit zone key> 292 # IN SIG KEY 293 # IN SIG KEY 294 # IN NS ns.test. 295 # IN SIG NS 296 # IN NXT my-org.test. NS SOA SIG KEY NXT 297 # IN SIG NXT 298 # 299 # my-org IN KEY 0x4300 3 0 300 # IN SIG KEY 301 # IN NS ns1.my-org.test. 302 # IN NS ns2.my-org.test. 303 # IN NXT them.test. NS SIG KEY NXT 304 # IN SIG NXT 305 # 306 # them IN KEY 0xC300 3 1 307 # IN SIG KEY 308 # IN NS ns1.them.test. 309 # IN NS ns2.them.test. 310 # IN NXT test. NS SIG KEY NXT 311 # IN SIG NXT 313 3 Analysis 315 By removing the public keys from the parent's master file, the 316 parent is no longer a road block during an emergency removal of 317 keys. A parent zone is unchanged as a zone changes from NULL 318 keys to experimental keys to fully signed. The parent is also 319 not providing a security service, other than to authentically 320 claim the existence of a KEY record set - akin to the "hints" of 321 the name servers. 323 The change also improves the prospect for performance. The need 324 for multiple KEY RR's, each one on the order of 100 bytes, is 325 removed and replaced by a single KEY RR of the order of 25 326 bytes. Saving bytes reduces the need to use TCP to avoid 327 truncated responses. Also, the need for updating the zone drops 328 - no longer will there be updates for each key change. 330 As far as the statements by RFC 2181 conerning authority levels, 331 the Referral Key is not authortative and would be superseeded by 332 a verified set of the real zone keys. The only caveat is that 333 once the verified set of keys expire (assuming the parent has to 334 learn the keys from another server), the Referal Key must 335 reappear. This is an example of what has been labelled "mount- 336 like semantics." 338 [No reference for mount-like semantics has yet been found.] 340 The last point is important. This requires the "mount-like 341 semantics" that have been discussed for the BIND name servers. 342 Once hints are overridden by learned, authorititative and 343 verified data, the hints are not discarded. Hints in this state 344 are stored and become visible when the learned data expires. 346 4 IANA Considerations 348 Other than using a new value in the flags field of the KEY RR, 349 no new number assignments are needed. The flags field is not 350 under the control of IANA as of yet. There are no requirements 351 placed on IANA by this draft. 353 5 Security Considerations 355 There has been some debate about whether the Referral key should 356 be treated as a hint - just like the NS records. If so, then 357 there is no need to sign the Referral Key, and an unsigned 358 (hence non-authenticated) security record is of little value. 359 So, is the Referral Key even needed? 361 Authentication in DNSSEC is done from the data "back" towards a 362 trusted point - e.g., "up" to the root. Since the 363 authentication is done by going repeatedly from child to parent, 364 why bother having the parent indicate the status of the child? 366 The answer is in the scenario in which a resolver somewhere has 367 obtained data which fails the verification process. Perhaps the 368 signature is wrong, a key in the chain of trust is unavailable, 369 the set should have had a signature, but none is found (or vice 370 versa), or the trail of signed-by names is not acceptable. In 371 this case, the resolver needs to find the authoritative zone, 372 its status and its name server set. 374 If a zone is being attacked by a masquerader, and parents do not 375 make any statements about the security of child zones, then an 376 easy and successfull attack may occur. An attacker only needs 377 to supply either fake name server records or glue records to 378 redirect queries. 380 While this attack will not be stopped as far as denial of 381 service, the masquerader can be stopped from being accepted as 382 an authoritative source if the parent of the zone claims the 383 child is secure and signs the public keys of the true child and 384 not the masquerader. 386 The masquerader cannot successfully claim that the zone is 387 unsigned, because it must have a zone key signed by the parent. 388 NULL or not, the key would not be trusted by the resolver, 389 assuming the parent has not also been duped. The resolver, 390 sensing this, should report an error or security incident, and 391 not accept data. 393 6 Acknowledgements 395 John Gilmore originally raised the issues that have led to this 396 document. 398 7 Author's addresses 400 Edward Lewis Jerry Scharf 401 402 3060 Washinton Rd (Rte 97) 403 Glenwood, MD 21738 404 +1(443)259-2352 406 8 References 408 RFC 2181 "Clarifications to the DNS Specification", Elz and Bush 409 RFC 2535 "Domain Name System Security Extensions", Eastlake 411 9 Full Copyright Statement 413 Copyright (C) The Internet Society (1999). All Rights Reserved. 415 This document and translations of it may be copied and furnished to 416 others, and derivative works that comment on or otherwise explain it 417 or assist in its implmentation may be prepared, copied, published and 418 distributed, in whole or in part, without restriction of any kind, 419 provided that the above copyright notice and this paragraph are 420 included on all such copies and derivative works. However, this 421 document itself may not be modified in any way, such as by removing 422 the copyright notice or references to the Internet Society or other 423 Internet organizations, except as needed for the purpose of 424 developing Internet standards in which case the procedures for 425 copyrights defined in the Internet Standards process must be 426 followed, or as required to translate it into languages other than 427 English. 429 The limited permissions granted above are perpetual and will not be 430 revoked by the Internet Society or its successors or assigns. 432 This document and the information contained herein is provided on an 433 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 434 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 435 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 436 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 437 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 439 This draft expires on October 1, 1999