idnits 2.17.1 draft-ietf-dnsext-delegation-signer-06.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: ---------------------------------------------------------------------------- ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 172: '... that support DS MUST support the OK b...' RFC 2119 keyword, line 174: '...in a secure zone MUST contain a DS RRs...' RFC 2119 keyword, line 176: '... MUST include the following RRsets i...' RFC 2119 keyword, line 183: '...sage, the TC bit MUST be set. Additio...' RFC 2119 keyword, line 188: '...cure. DS RRsets MUST NOT appear at no...' (29 more instances...) -- The abstract seems to indicate that this document updates RFC3090, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC1035, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC2535, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC3008, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC2119. -- 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 (March 2002) is 8076 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) -- Missing reference section? 'RFC1035' on line 534 looks like a reference -- Missing reference section? 'RFC2535' on line 540 looks like a reference -- Missing reference section? 'RFC3090' on line 546 looks like a reference -- Missing reference section? 'RFC3008' on line 543 looks like a reference -- Missing reference section? 'RFC3225' on line 549 looks like a reference -- Missing reference section? 'RFC3226' on line 552 looks like a reference -- Missing reference section? 'RFC 2181' on line 206 looks like a reference -- Missing reference section? 'RFC2181' on line 537 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT Working Group Olafur Gudmundsson 3 INTERNET-DRAFT March 2002 4 6 Updates: RFC 1035, RFC 2535, RFC 3008, RFC 3090. 8 Delegation Signer Resource Record 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 DNSEXT WG mailing list 32 namedroppers@ops.ietf.org 34 This draft expires on September 1, 2002. 36 Copyright Notice 38 Copyright (C) The Internet Society (2002). All rights reserved. 40 Abstract 42 The delegation signer (DS) resource record is inserted at a zone cut 43 (i.e., a delegation point) to indicate that the delegated zone is 44 digitally signed and that the delegated zone recognizes the indicated 45 key as a valid zone key for the delegated zone. The DS RR is a 46 modification to the DNS Security Extensions definition, motivated by 47 operational considerations. The intent is to use this resource record 48 as an explicit statement about the delegation, rather than relying on 49 inference. 51 This document defines the DS RR, gives examples of how it is used and 52 the implications of this record on resolvers. This change is not 53 backwards compatible with RFC 2535. 54 This document updates RFC1035, RFC2535, RFC3008 and RFC3090. 56 1 Introduction 58 Familiarity with the DNS system [RFC1035], DNS security extensions 59 [RFC2535] and DNSSEC terminology [RFC3090] is important. 61 Experience shows that when the same data can reside in two 62 administratively different DNS zones, the data frequently gets out of 63 sync. The presence of an NS RRset in a zone anywhere other than at 64 the apex indicates a zone cut or delegation. The RDATA of the NS 65 RRset specifies the authoritative servers for the delegated or 66 "child" zone. Based on actual measurements, 10-30% of all delegations 67 on the Internet have differing NS RRsets at parent and child. There 68 are a number of reasons for this, including a lack of communication 69 between parent and child and bogus name servers being listed to meet 70 registrar requirements. 72 DNSSEC [RFC2535,RFC3008,RFC3090] specifies that a child zone needs to 73 have its KEY RRset signed by its parent to create a verifiable chain 74 of KEYs. There has been some debate on where the signed KEY RRset 75 should reside, whether at the child [RFC2535] or at the parent. If 76 the KEY RRset resides at the child, maintaining the signed KEY RRset 77 in the child requires frequent two-way communication between the two 78 parties. First the child transmits the KEY RRset to the parent and 79 then the parent sends the signature(s) to the child. Storing the KEY 80 RRset at the parent simplifies the communication. 82 DNSSEC [RFC2535] requires that the parent store a NULL KEY record for 83 an unsecure child zone to indicate that the child is unsecure. A NULL 84 KEY record is a waste: an entire signed RRset is used to communicate 85 effectively one bit of information--that the child is unsecure. 86 Chasing down NULL KEY RRsets complicates the resolution process in 87 many cases, because servers for both parent and child need to be 88 queried for the KEY RRset if the child server does not return it. 89 Storing the KEY RRset only in the parent zone simplifies this and 90 would allow the elimination of the NULL KEY RRsets entirely. For 91 large delegation zones the cost of NULL keys is a significant barrier 92 to deployment. 94 Another complication of the DNSSEC key model is that the KEY record 95 can be used to store public keys for other protocols in addition to 96 DNSSEC keys. There are number of potential problems with this, 97 including: 98 1. The KEY RRset can become quite large if many applications and 99 protocols store their keys at the zone apex. Possible protocols are 100 IPSEC, HTTP, SMTP, SSH and others that use public key cryptography. 101 2. The KEY RRset may require frequent updates. 102 3. The probability of compromised or lost keys, which trigger 103 emergency key rollover procedures, increases. 104 4. The parent may refuse sign KEY RRsets with non-DNSSEC zone keys. 105 5. The parent may not meet the child's expectations in turnaround 106 time for resigning the KEY RRset. 108 Given these and other reasons, there is good reason to explore 109 alternatives to using only KEY records to create a chain of trust. 111 Some of these problems can be reduced or eliminated by operational 112 rules or protocol changes. To reduce the number of keys at the zone 113 apex, a rule to require applications to store their KEY records at 114 the SRV name for that application is one possibility. Another is to 115 restrict the KEY record to only DNSSEC keys and create a new record 116 type for all non-DNSSEC keys. A third possible solution is to 117 prohibit the storage of non-DNSSEC keys at the zone apex. There are 118 other possible solutions, but they are outside the scope of this 119 document. 121 1.2 Reserved Words 123 The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", 124 "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be 125 interpreted as described in RFC2119. 127 2 DS (Delegation KEY Signer) 129 2.1 Delegation Signer Record Model 131 This document presents a replacement for the DNSSEC KEY record chain 132 of trust [RFC2535] that uses a new RR that resides only at the 133 parent. This record identifies the key(s) that the child uses to 134 self-sign its own KEY RRset. 136 The chain of trust is now established by verifying the parent KEY 137 RRset, the DS RRset from the parent and the KEY RRset at the child. 138 This is cryptographically equivalent to using just KEY records. 140 Communication between the parent and child is greatly reduced, since 141 the child only needs to notify the parent about changes in keys that 142 sign its apex KEY RRset. The parent is ignorant of all other keys in 143 the child's apex KEY RRset. Furthermore, the child maintains full 144 control over the apex KEY RRset and its content. The child can 145 maintain any policies regarding its KEY usage for DNSSEC and other 146 applications and protocols with minimal impact on the parent. Thus if 147 the child wants to have frequent key rollover for its DNS zone keys, 148 the parent does not need to be aware of it: the child can use one key 149 to sign only its apex KEY RRset and other keys to sign the other 150 RRsets in the zone. 152 This model fits well with a slow rollout of DNSSEC and the islands of 153 security model. In this model, someone who trusts "good.example." can 154 preconfigure a key from "good.example." as a trusted key, and from 155 then on trusts any data signed by that key or that has a chain of 156 trust to that key. If "example." starts advertising DS records, 157 "good.example." does not have to change operations by suspending 158 self-signing. DS records can also be used to identify trusted keys 159 instead of KEY records. Another significant advantage is that the 160 amount of information stored in large delegation zones is reduced: 161 rather than the NULL KEY record at every unsecure delegation required 162 by RFC 2535, only secure delegations require additional information 163 in the form of a signed DS RRset. 165 The main disadvantage of this approach is that verifying a zone's KEY 166 RRset requires two signature verification operations instead of the 167 one required by RFC 2535. There is no impact on the number of 168 signatures verified for other types of RRsets. 170 2.2 Protocol Change 172 All DNS servers and resolvers that support DS MUST support the OK bit 173 [RFC3225] and a larger message size [RFC3226]. Each secure 174 delegation in a secure zone MUST contain a DS RRset. If a query 175 contains the OK bit, a server returning a referral for the delegation 176 MUST include the following RRsets in the authority section in this 177 order: 178 parent NS 179 DS and SIG(DS) (if present) 180 parent NXT and SIG(parent NXT) 181 This increases the size of referral messages and may cause some or 182 all glue to be omitted. If the DS or NXT RRsets or their signatures 183 do not fit in the DNS message, the TC bit MUST be set. Additional 184 section processing is not changed. 186 A DS RRset accompanying an NS RRset indicates that the child zone is 187 secure. If an NS RRset exists without a DS RRset, the child zone is 188 unsecure. DS RRsets MUST NOT appear at non-delegation points or at a 189 zone's apex. 191 The following section 2.2.1 replaces RFC2535 sections 2.3.4 and 3.4, 192 section 2.2.2 replaces RFC3008 section 2.7, and RFC3090 updates are 193 in section 2.2.3. 195 2.2.1 RFC2535 2.3.4 and 3.4: Special Considerations at Delegation Points 197 DNS security views each zone as a unit of data completely under the 198 control of the zone owner with each entry (RRset) signed by a special 199 private key held by the zone manager. But the DNS protocol views the 200 leaf nodes in a zone that are also the apex nodes of a child zone 201 (i.e., delegation points) as "really" belonging to the child zone. 202 The corresponding domain names appear in two master files and might 203 have RRsets signed by both the parent and child zones' keys. A 204 retrieval could get a mixture of these RRsets and SIGs, especially 205 since one server could be serving both the zone above and below a 206 delegation point [RFC 2181]. 208 For every secure delegation there MUST be a DS RRset stored in the 209 parent zone signed by the parent zone's private key. The parent zone 210 MUST NOT contain a KEY RRset at any delegation points. Delegations in 211 the parent MAY contain only the following RR types: NS, DS, NXT and 212 SIG. The NS RRset MUST NOT be signed. The NXT RRset is the 213 exceptional case: it will always appear differently and 214 authoritatively in both the parent and child zones if both are 215 secure. 217 A secure zones MUST contain a self-signed KEY RRset at its apex. 218 Upon verifying the DS RRset from the parent, a resolver MAY trust any 219 KEY identified in the DS RRset as a valid signer of the child's apex 220 KEY RRset. Resolvers configured to trust one of the keys signing the 221 KEY RRset MAY now treat any data signed by the zone keys in the KEY 222 RRset as secure. In all other cases resolvers MUST consider the zone 223 unsecure. A DS RRset MUST NOT appear at a zone's apex. 225 An authoritative server queried for type DS MUST return the DS RRset 226 in the answer section along with the corresponding NXT RRset in the 227 authority section. If the server is authoritative for both parent 228 and child zones, the answer MUST be from the parent. A caching 229 server MUST behave the same way, returning the DS RRset and the 230 parent's NXT RRset, if records are available. 232 2.2.2 Signer's Name (replaces RFC3008 section 2.7) 234 The signer's name field of a data SIG MUST contain the name of the 235 zone to which the data and signature belong. The combination of 236 signer's name, key tag, and algorithm MUST identify a zone key if the 237 SIG is to be considered material. This document defines a standard 238 policy for DNSSEC validation; local policy may override the standard 239 policy. 241 There are no restrictions on the signer field of a SIG(0) record. 242 The combination of signer's name, key tag, and algorithm MUST 243 identify a key if this SIG(0) is to be processed. 245 2.2.4 Changes to RFC3090 247 A number of sections of RFC3090 need to be updated to reflect the DS 248 record. 250 2.2.4.1 RFC3090: Updates to section 1: Introduction 252 Most of the text is still relevant but the words ``NULL key'' are to 253 be replaced with ``missing DS RRset''. In section 1.3 the last three 254 paragraphs discuss the confusion in sections of RFC 2535 that are 255 replaced in section 2.2.1 above. Therefore, these paragraphs are now 256 obsolete. 258 2.2.4.2 RFC3090 section 2.1: Globally Secured 260 Rule 2.1.b is replaced by the following rule: 262 2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a 263 private key whose public counterpart MUST appear in a zone signing 264 KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to- 265 implement algorithm. This KEY RR MUST be identified by a DS RR in a 266 signed DS RRset in the parent zone. 268 If a zone cannot get its parent to advertise a DS record for it, the 269 child zone cannot be considered globally secured. The only exception 270 to this is the root zone, for which there is no parent zone. 272 2.2.4.3 RFC3090 section 3: Experimental Status. 274 The only difference between experimental status and globally secured 275 is the missing DS RRset in the parent zone. All locally secured zones 276 are experimental. 278 2.3 Comments on Protocol Changes 280 Over the years there have been various discussions surrounding the 281 DNS delegation model, declaring it to be broken because there is no 282 good way to assert if a delegation exists. In the RFC2535 version of 283 DNSSEC, the presence of the NS bit in the NXT bit map proves there is 284 a delegation at this name. Something more explicit is needed and the 285 DS record addresses this need for secure delegations. 287 The DS record is a major change to DNS: it is the first resource 288 record that can appear only on the upper side of a delegation. Adding 289 it will cause interoperability problems and requires a flag day for 290 DNSSEC. Many old servers and resolvers MUST be upgraded to take 291 advantage of DS. Some old servers will be able to be authoritative 292 for zones with DS records but will not add the NXT and DS records to 293 the authority section. The same is true for caching servers; in 294 fact, some may even refuse to pass on the DS and NXT records. 296 2.4 Wire Format of the DS record 298 The DS (type=TDB) record contains these fields: key tag, algorithm, 299 digest type, and the digest of a public key KEY record that is 300 allowed and/or used to sign the child's apex KEY RRset. Other keys 301 MAY sign the child's apex KEY RRset. 303 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 304 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | key tag | algorithm | Digest type | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | SHA-1 digest | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | (20 bytes) | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 314 | | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 316 | | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 The key tag is calculated as specified in RFC2535. Algorithm MUST be 320 an algorithm number assigned in the range 1..251 and the algorithm 321 MUST be allowed to sign DNS data. The digest type is an identifier 322 for the digest algorithm used. The digest is calculated over the 323 canonical name of the delegated domain name followed by the whole 324 RDATA of the KEY record. 326 Digest type value 0 is reserved, value 1 is SHA-1, and reserving 327 other types requires IETF standards action. For interoperability 328 reasons, as few digest algorithms as possible should be reserved. The 329 only reason to reserve additional digest types is to increase 330 security. 332 DS records MUST point to zone KEY records that are allowed to 333 authenticate DNS data. The indicated KEY record's protocol field 334 MUST be set to 3; flag field bits 0 and 6 MUST be set to 0; bit 7 335 MUST be set to 1. The value of other bits is not significant for the 336 purposes of this document. 338 The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless 339 of key size. 341 2.4.1 Justifications for Fields 343 The algorithm and key tag fields are present to allow resolvers to 344 quickly identify the candidate KEY records to examine. SHA-1 is a 345 strong cryptographic checksum: it is computationally infeasible for 346 an attacker to generate a KEY record that has the same SHA-1 digest. 347 Combining the name of the key and the key data as input to the digest 348 provides stronger assurance of the binding. Having the key tag in 349 the DS record adds greater assurance than the SHA-1 digest alone, as 350 there are now two different mapping functions that a KEY RR must 351 match. 353 This format allows concise representation of the keys that the child 354 will use, thus keeping down the size of the answer for the 355 delegation, reducing the probability of DNS message overflow. The 356 SHA-1 hash is strong enough to uniquely identify the key and is 357 similar to the PGP key footprint. The digest type field is present 358 for possible future expansion. 360 The DS record is well suited to listing trusted keys for islands of 361 security in configuration files. 363 2.5 Presentation Format of the DS Record 365 The presentation format of the DS record consists of three numbers 366 (key tag, algorithm and digest type) followed by the digest itself 367 presented in hex: 368 foo.example. DS 12345 3 1 123456789abcdef67890 370 2.6 Transition Issues for Installed Base 372 No backwards compatibility with RFC2535 is provided. 374 RFC2535-compliant resolvers will assume that all DS-secured 375 delegations are locally secure. This is bad, but the DNSEXT Working 376 Group has determined that rather than dealing with both 377 RFC2535-secured zones and DS-secured zones, a rapid adoption of DS is 378 preferable. Thus the only option for early adopters is to upgrade to 379 DS as soon as possible. 381 2.6.1 Backwards compatibility with RFC2535 and RFC1035 383 This section documents how a resolver determines the type of 384 delegation. 385 RFC1035 delegation (in parent) has: 387 RFC1035 NS 389 RFC2535 adds the following two cases: 391 Secure RFC2535: NS + NXT + SIG(NXT) 392 NXT bit map contains: NS SIG NXT 393 Unsecure RFC2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT) 394 NXT bit map contains: NS SIG KEY NXT 395 KEY must be a NULL key. 397 DS has the following two states: 399 Secure DS: NS + DS + SIG(DS) + NXT + SIG(NXT) 400 NXT bit map contains: NS SIG NXT DS 401 Unsecure DS: NS + NXT + SIG(NXT) 402 NXT bit map contains: NS SIG NXT 404 It is difficult for a resolver to determine if a delegation is secure 405 RFC 2535 or unsecure DS. This could be overcome by adding a flag to 406 the NXT bit map, but only upgraded resolvers would understand this 407 flag, anyway. Having both parent and child signatures for a KEY RRset 408 might allow old resolvers to accept a zone as secure, but the cost of 409 doing this for a long time is much higher than just prohibiting RFC 410 2535-style signatures at child zone apexes and forcing rapid 411 deployment of DS-enabled servers and resolvers. 413 RFC 2535 and DS can in theory be deployed in parallel, but this would 414 require resolvers to deal with RFC 2535 configurations forever. This 415 document obsoletes the NULL KEY in parent zones, which is a difficult 416 enough change that a flag day is required. 418 3 Resolver Example 420 To create a chain of trust, a resolver goes from trusted KEY to DS to 421 KEY. 423 Assume the key for domain "example." is trusted. Zone "example." 424 contains at least the following records: 425 example. SOA 426 example. NS ns.example. 427 example. KEY 428 example. NXT NS SOA KEY SIG NXT 429 example. SIG(SOA) 430 example. SIG(NS) 431 example. SIG(NXT) 432 example. SIG(KEY) 433 secure.example. NS ns1.secure.example. 434 secure.example. DS tag=10243 alg=3 digest_type=1 435 secure.example. NXT NS SIG NXT DS unsecure.example. 436 secure.example. SIG(NXT) 437 secure.example. SIG(DS) 438 unsecure.example NS ns1.unsecure.example. 439 unsecure.example. NXT NS SIG NXT .example. 440 unsecure.example. SIG(NXT) 442 In zone "secure.example." following records exist: 443 secure.example. SOA 444 secure.example. NS ns1.secure.example. 445 secure.example. KEY 446 secure.example. SIG(KEY) 447 secure.example. SIG(SOA) 448 secure.example. SIG(NS) 450 In this example the private key for "example." signs the DS record 451 for "secure.example.", making that a secure delegation. The DS record 452 states which key is expected to sign the KEY RRset at 453 "secure.example.". Here "secure.example." signs its KEY RRset with 454 the KEY identified in the DS RRset, thus the KEY RRset is validated 455 and trusted. 457 This example has only one DS record for the child, but parents MUST 458 allow multiple DS records to facilitate key rollover. It is strongly 459 recommended that the DS RRset be kept small: two or three DS records 460 SHOULD be sufficient in all cases. 462 The resolver determines the security status of "unsecure.example." by 463 examining the parent zone's NXT record for this name. The absence of 464 the DS bit indicates an unsecure delegation. 466 3.1 Resolver Cost Estimates for DS Records 468 From a RFC2535 resolver point of view, for each delegation followed 469 to chase down an answer, one KEY RRset has to be verified. 470 Additional RRsets might also need to be verified based on local 471 policy (e.g., the contents of the NS RRset). Once the resolver gets 472 to the appropriate delegation, validating the answer might require 473 verifying one or more signatures. A simple A record lookup requires 474 at least N delegations to be verified and one RRset. For a DS-enabled 475 resolver, the cost is 2N+1. For an MX record, where the target of 476 the MX record is in the same zone as the MX record, the costs are N+2 477 and 2N+2, for RFC 2535 and DS, respectively. In the case of negatives 478 answer the same ratios hold true. 480 The resolver may require an extra query to get the DS record and this 481 may add to the overall cost of the query, but this is never worse 482 than chasing down NULL KEY records from the parent in RFC2535 DNSSEC. 484 DS adds processing overhead on resolvers and increases the size of 485 delegation answers, but much less than storing signatures in the 486 parent zone. 488 4 Security Considerations: 490 This document proposes a change to the validation chain of KEY 491 records in DNSSEC. The change is not believed to reduce security in 492 the overall system. In RFC2535 DNSSEC, the child zone has to 493 communicate keys to its parent and prudent parents will require some 494 authentication with that transaction. The modified protocol will 495 require the same authentication, but allows the child to exert more 496 local control over its own KEY RRset. 498 There is a remote possibility that an attacker could generate a valid 499 KEY that matches all the DS fields and thus forge data from the 500 child. This possibility is considered impractical, as on average more 501 than 2^80 keys would have to be generated before a match would be 502 found. 504 The DS record represents a change to the DNSSEC protocol and there is 505 an installed base of implementations, as well as textbooks on how to 506 set up secure delegations. Implementations that do not understand the 507 DS record will not be able to follow the KEY to DS to KEY chain and 508 will consider all zones secured that way as unsecure. 510 5 IANA Considerations: 512 IANA needs to allocate an RR type code for DS from the standard RR 513 type space. 515 IANA needs to open a new registry for the DS type for digest 516 algorithms. Defined types are: 0 is Reserved, 1 is SHA-1. Adding new 517 reservations requires IETF standards action. 519 4 Acknowledgments 521 Over the last few years a number of people have contributed ideas 522 that are captured in this document. The core idea of using one key to 523 sign only the KEY RRset comes from discussions with Bill Manning and 524 Perry Metzger on how to put in a single root key in all resolvers. 525 Alexis Yushin, Brian Wellington, Paul Vixie, Jakob Schlyter, Scott 526 Rosen, Edward Lewis, Lars-Johan Liman, Matt Larson, Mark Kosters, Dan 527 Massey, Olaf Kolman, Phillip Hallam-Baker, Miek Gieben, Havard 528 Eidnes, Donald Eastlake 3rd., Randy Bush, David Blacka, Steve 529 Bellovin, Rob Austein, Derek Atkins, Roy Arends, Harald Alvestrand, 530 and others have provided useful comments. 532 References: 534 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 535 Specification'', STD 13, RFC 1035, November 1987. 537 [RFC2181] R. Elz, R. Bush, ``Clarifications to the DNS Specification'', 538 RFC 2181, July 1997. 540 [RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC 541 2535, March 1999. 543 [RFC3008] B. Wellington, ``Domain Name System Security (DNSSEC) Signing 544 Authority'', RFC 3008, November 2000. 546 [RFC3090] E. Lewis `` DNS Security Extension Clarification on Zone 547 Status'', RFC 3090, March 2001. 549 [RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC 550 3225, December 2001. 552 [RFC3226] O. Gudmundsson, ``DNSSEC and IPv6 A6 aware server/resolver 553 message size requirements'', RFC 3226, December 2001. 555 Author Address 557 Olafur Gudmundsson 558 3826 Legation Street, NW 559 Washington, DC, 20015 560 USA 561 563 Appendix A: Changes from Prior versions 565 Changes from version 05 566 Major wording changes for clarity contributed by Matt Larson. 567 Added explicit rule that query for type DS MUST be answered from the 568 upper side of delegation. 570 Changes from version 04 571 Reworded document to obsolete RFC2535 chain of trust, no backwards 572 compatibility. Require DS and NXT records in referrals in authority 573 section. Removed the NODS bit. 574 Added the requirement for OK bit and Message size. 575 Rewrote Abstract to better express what is in the document. 576 Removed size field from examples and simplified them. 578 Changes from version 03 579 Added strict rules on what KEY records can be pointed to by DS. 581 Changes from version 02 582 Added text outlawing DS at non delegations. 583 Added table showing the contents of DS, SIG@child, and RFC1034 584 delegations. 585 Added the NODS type/bit definition to distinguish insecure DS 586 delegation from secure SIG@child one. 587 Added the requirement that NXT be returned with referral answers. 588 Minor text edits. 590 Changes from version 01 591 Deleted KEY size field as it did not contribute anything but 592 complexity. 593 Number of wordsmith changes to make document more readable. 594 The word CAN was used when SHOULD was intended. 595 Deleted section 2.4 "Justifications for compact format" moved 596 relevant text to section 2.2. 597 Reverse alphabetized the acknowledgments section. 598 Reorganized sections 1 and 2 for readability. 600 Changes from version 00 601 Changed name from DK to DS based on working group comments. 602 Dropped verbose format based on WG comments. 603 Added text about TTL issue/problem in caching servers. 604 Added text about islands of security and clarified the cost impact. 605 Major editing of arguments and some reordering of text for clarity. 606 Added section on transition issues. 608 Full Copyright Statement 610 Copyright (C) The Internet Society (2002). All Rights Reserved. 612 This document and translations of it may be copied and furnished to 613 others, and derivative works that comment on or otherwise explain it 614 or assist in its implementation may be prepared, copied, published 615 and distributed, in whole or in part, without restriction of any 616 kind, provided that the above copyright notice and this paragraph are 617 included on all such copies and derivative works. However, this 618 document itself may not be modified in any way, such as by removing 619 the copyright notice or references to the Internet Society or other 620 Internet organizations, except as needed for the purpose of 621 developing Internet standards in which case the procedures for 622 copyrights defined in the Internet Standards process must be 623 followed, or as required to translate it into languages other than 624 English. 626 The limited permissions granted above are perpetual and will not be 627 revoked by the Internet Society or its successors or assigns. 629 This document and the information contained herein is provided on an 630 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 631 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 632 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 633 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 634 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."