idnits 2.17.1 draft-lewis-dnskey-referral-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. 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.) -- The document date (June 1, 1998) is 9460 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: 8 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Domain Name System Security WG Edward Lewis 2 INTERNET DRAFT TIS Labs 3 Jerry Scharff 4 ISC 5 John Gilmore 7 June 1, 1998 9 The Zone Referral Key 10 12 0.0 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 ``work in progress.'' 25 To view the entire list of current Internet-Drafts, please check 26 the ``1id-abstracts.txt'' listing contained in the Internet- 27 Drafts Shadow Directories on ftp.is.co.za (Africa), 28 ftp.nordu.net (Northen Europe), ftp.nis.garr.it (Sourthern 29 Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East 30 Coast), or ftp.isi.edu (US West Coast). 32 This Internet Draft expires on 1 December 1998. 34 Please send comments to the authors and dns-security@tis.com. 36 1.0 Abstract 38 A new type of key is defined to address the problems of 39 performance in large delegeted zones and issues of liability of 40 registrars with regards to the storing of public keys belonging 41 to zone cuts. This new key type also brings DNSSEC more in line 42 with the DNS treatment of zone cuts and speeds recovery in 43 handling key exposure. 45 The new type of key is a referral record that is stored, signed, 46 at the parent zone's place for the delegation point. A resolver 47 receiving this record is being informed that there are genuine 48 public keys at the child's authoritative name servers. The 49 parent no longer needs to store the child's public keys locally. 51 2.0 Introduction 53 There are a number of different reasons for the proposal of this 54 new key type. Reasons include: 55 o the performance impact the current proposal has on name servers 56 o the problem of updating a widely delegated parent zone on demand 58 Expires December 1, 1998 [Page 1] 59 o statements in RFC 2181 on authoritative data at delegations 60 o perceived liability of the operator of a name server or registry 62 To address these issues, which are expanded upon below, a new 63 key type is proposed - a "zone key referral" - to join the user 64 key, host key, and zone key types defined in ietf-draft-dnssec- 65 secext2-0?.txt. 67 2.1 Performance Issues 69 A sample zone will be used to illustrate the problem. The 70 example will part from reality mostly in the length of zone 71 names, which changes the size of the owner and resource record 72 data fields. 74 # $ORIGIN test. 75 # @ IN SOA 76 # IN SIG SOA 77 # IN KEY <1024 bit zone key> 78 # IN SIG KEY 79 # IN SIG KEY 80 # IN NS ns.test. 81 # IN SIG NS 82 # IN NXT my-org.test. NS SOA SIG KEY NXT 83 # IN SIG NXT 84 # 85 # my-org IN KEY <1024 bit zone key> 86 # IN KEY <1024 bit zone key> 87 # IN SIG KEY 88 # IN NS ns1.my-org.test. 89 # IN NS ns2.my-org.test. 90 # IN NXT them.test. NS SIG KEY NXT 91 # IN SIG NXT 92 # 93 # them IN KEY 0xC100 3 1 94 # IN SIG KEY 95 # IN NS ns1.them.test. 96 # IN NS ns2.them.test. 97 # IN NXT test. NS SIG KEY NXT 98 # IN SIG NXT 100 In this zone file fragment, "my-org" is a delegation point of 101 interest with two registered public keys. Presumably, one key 102 is for signatures generated currently and the other is for still 103 living and valid but older signatures. "them" is another 104 delegation point, with a NULL key. This signifies that this zone 105 is unsecured. 107 To analyze the performance impact of the storing of keys, the 108 number of bytes used to represent the RRs in the procotol format 109 is used. The actual number of bytes stored will likely be 110 higher, accounting for data structure overhead and alignment. 111 The actual number of bytes transferred will be lower due to DNS 112 name compression. 114 Expires December 1, 1998 [Page 2] 115 The number of bytes for my-org's two 1024-bit keys, two NS 116 records, NXT and the associated signatures is 526. The bytes 117 needed for them (with the NULL key) is 346. Currently, there 118 are close to 2 million entries in com., so if we take my-org as 119 a typical domain, over 1GB on memory will be needed for com. 121 The zone keys used in the example are set to 1024 bits. This 122 number may range from as low as 512 bits upwards to over 3000 123 bits. To scale the above numbers to a different key size, 124 multiply the difference in key sizes by 4 for my-org and by 2 125 for them, and adjust the numbers accordingly. 127 The increased size of the data held for the zone cuts will have 128 two impacts at the transport and below layers. Bandwidth beyond 129 that currently needed will be used to carry the KEY records. 130 The inclusion of all of the child's keys will also push DNS over 131 the UDP size limit and start using TCP - which could cause 132 critical problems for current heavily used name servers, like 133 the roots. 135 Another impact, not illustrated by the example, is the frequency 136 of updates. If each time a public key for my-org is added or 137 deleted, the SOA serial number will have to increase, and the 138 SOA signed again. If an average zone changes its keys(s) once 139 per month, there will be on average 45 updates per minute in a 140 zone of 2 million delegations. 142 2.2 Security Incident Recovery (w/ respect to keys only) 144 Once a zone administrator is alerted that any key's private 145 counterpart has been discovered (exposed), the first action to 146 be taken is to stop advertising the public key in DNS. This 147 doesn't end the availability of the key - it will be residing in 148 caches - but is the closest action resembling revokation 149 available in DNS. 151 Stopping the advertisement in the zone's name servers is as 152 quick as altering the master file and restarting the name 153 server. Having to do this in two places will will only delay 154 the time until the recovery is complete. 156 For example, a registrar of a top level domain has decided to 157 update its zone only on Mondays and Fridays due to the size of 158 the zone. A customer/delegatee is the victim of a break in, in 159 which one of the items taken is the file of private keys used to 160 sign DNS data. If this occurs on a Tuesday, the thief has until 161 Friday to use the keys before they disappear from the DNS, even 162 if the child stops publishing them immediately. 164 If the public key set is in the parent zone, and the parent zone 165 is not able to make the change quickly, the public key cannot be 166 revoked quickly. If the parent only refers to there being a key 167 at the child zone, then the child has the agility to change the 169 Expires December 1, 1998 [Page 3] 170 keys - even issue a NULL key, which will force all signatures in 171 the zone to become suspect. 173 2.3 DNS Clarifications 175 RFC 2181, section 6, clarifies the status of data appearing at a 176 zone cut. Data at a zone cut is served authoritatively from the 177 servers listed in the NS set present at the zone cut. The data 178 is not (necessarily) served authoritatively from the parent. 179 (The exception is in servers handling both the parent and child 180 zone.) 182 Section 6 also mentions that there are two exceptions created by 183 DNSSEC, the NXT single record set and the KEY set. This 184 proposal addresses the exception relating to the KEY set, 185 limiting its severity (but falling short of removing it 186 altogether). By limiting the exception, we will be simplifying 187 DNS. 189 2.4 Liability 191 Liability is a legal concept, so it is not wise to attempt an 192 engineering solution to it. However, the perceived liability 193 incurred in using DNSSEC by registrars may prevent the adoption 194 of DNSSEC. Hence DNSSEC should be engineered in such a away to 195 address the concern. 197 One source of liability is the notion that by advertising a 198 public key for a child zone, a parent zone is providing a 199 service of security. With that comes responsibility. By having 200 the parent merely indicate that a child has a key (or has no 201 key), the parent is providing less in the way of security. If 202 the parent is wrong, the potential loss is less. Instead of 203 falsely authenticated data, configuration errors will be 204 apparent to the resolving client. 206 3.0 The Proposal 208 The proposal is to introduce a new key type which indicates 209 whether the delegated zone is running secured or not. Running 210 secured is either a zone signed with at least one key, an 211 experimental zone, or a zone with only NULL keys published. 213 The Zone Referral Key will resemble the NULL key in syntax. 214 There will be a flags field, an algorithm field, and a protocol 215 field, but no public key material. The Referral Key is signed 216 by the parent zone, as was the public key set in RFC 2065. 217 There is only one Referral Key RR present. 219 Expires December 1, 1998 [Page 4] 220 The Referral Key flags field will have the following values: 221 Field Bit(s) Value Meaning 223 A/C 0- 1 0b01 indicates a key will be found 224 0b11 indicates a key will not be found 225 0b?0 error (referral cannot encrypt) 226 XT 2 0 no extended flags are needed 227 Z 4- 5 0 must be zero for all keys 228 NAMTYP 6- 7 0b11 this is a referral to a zone key 229 Z 8-11 0 must be zero for all keys 230 SIG 12-15 0 must be zero for a referral key 232 The legal values of the flags field are (in summary): 234 Hex Value Indicates 235 0x4300 The delegation has a key record set 236 0xC300 The delegation has no key record 238 Other values are not valid for Referral Keys (but may be valid 239 for other keys). 241 The Protocol field must be set to 3, the DNSSEC protocol value. 243 The Algorithm field must be set to 0. 245 3.1 Example 247 The Referral key for my-org.test. and them.test. would appear as 248 the following in the zone master file: 250 my-org.test. IN KEY 0x4300 3 0 251 them.test. IN KEY 0xC300 3 0 253 In the example introduced earlier, the master file would change 254 to the following. 256 # $ORIGIN test. 257 # @ IN SOA 258 # IN SIG SOA 259 # IN KEY <1024 bit zone key> 260 # IN SIG KEY 261 # IN SIG KEY 262 # IN NS ns.test. 263 # IN SIG NS 264 # IN NXT my-org.test. NS SOA SIG KEY NXT 265 # IN SIG NXT 266 # 267 # my-org IN KEY 0x4300 3 0 268 # IN SIG KEY 269 # IN NS ns1.my-org.test. 270 # IN NS ns2.my-org.test. 271 # IN NXT them.test. NS SIG KEY NXT 272 # IN SIG NXT 273 # 275 Expires December 1, 1998 [Page 5] 276 # them IN KEY 0xC300 3 1 277 # IN SIG KEY 278 # IN NS ns1.them.test. 279 # IN NS ns2.them.test. 280 # IN NXT test. NS SIG KEY NXT 281 # IN SIG NXT 283 4.0 Analysis 285 By removing the public keys from the parent's master file, the 286 parent is no longer a road block during an emergency removal of 287 keys. A parent zone is unchanged as a zone changes from NULL 288 keys to experimental keys to fully signed. The parent is also 289 not providing a security service, other than to authentically 290 claim the existence of a KEY record set - akin to the "hints" of 291 the name servers. 293 The change also improves the prospect for performance. The need 294 for multiple KEY RR's, each one on the order of 100 bytes, is 295 removed and replaced by a single KEY RR of the order of 25 296 bytes. Saving bytes reduces the need to use TCP to avoid 297 truncated responses. Also, the need for updating the zone drops 298 - no longer will there be updates for each key change. 300 As far as the statements by RFC 2181 conerning authority levels, 301 the Referral Key is not authortative and would be superseeded by 302 a verified set of the real zone keys. The only caveat is that 303 once the verified set of keys expire (assuming the parent has to 304 learn the keys from another server), the Referal Key must 305 reappear. This is an example of what has been labelled "mount- 306 like semantics." 308 [No reference for mount-like semantics has yet been found.] 310 The last point is important. This requires the "mount-like 311 semantics" that have been discussed for the BIND name servers. 312 Once hints are overridden by learned, authorititative and 313 verified data, the hints are not discarded. Hints in this state 314 are stored and become visible when the learned data expires. 316 5.0 IANA Considerations 318 Other than using a new value in the flags field of the KEY RR, 319 no new number assignments are needed. The flags field is not 320 under the control of IANA as of yet. There are no requirements 321 placed on IANA by this draft. 323 6.0 Security Considerations 325 There has been some debate about whether the Referral key should 326 be treated as a hint - just like the NS records. If so, then 327 there is no need to sign the Referral Key, and an unsigned 328 (hence non-authenticated) security record is of little value. 329 So, is the Referral Key even needed? 331 Expires December 1, 1998 [Page 6] 332 Authentication in DNSSEC is done from the data "back" towards a 333 trusted point - e.g., "up" to the root. Since the 334 authentication is done by going repeatedly from child to parent, 335 why bother having the parent indicate the status of the child? 337 The answer is in the scenario in which a resolver somewhere has 338 obtained data which fails the verification process. Perhaps the 339 signature is wrong, a key in the chain of trust is unavailable, 340 the set should have had a signature, but none is found (or vice 341 versa), or the trail of signed-by names is not acceptable. In 342 this case, the resolver needs to find the authoritative zone, 343 its status and its name server set. 345 If a zone is being attacked by a masquerader, and parents do not 346 make any statements about the security of child zones, then an 347 easy and successfull attack may occur. An attacker only needs 348 to supply either fake name server records or glue records to 349 redirect queries. 351 While this attack will not be stopped as far as denial of 352 service, the masquerader can be stopped from being accepted as 353 an authoritative source if the parent of the zone claims the 354 child is secure and signs the public keys of the true child and 355 not the masquerader. 357 The masquerader cannot successfully claim that the zone is 358 unsigned, because it must have a zone key signed by the parent. 359 NULL or not, the key would not be trusted by the resolver, 360 assuming the parent has not also been duped. The resolver, 361 sensing this, should report an error or security incident, and 362 not accept data. 364 7.0 Author's addresses 366 Edward Lewis Jerry Scharf John Gilmore 367 369 Expires December 1, 1998 [Page 7]