idnits 2.17.1 draft-ietf-dnsext-delegation-signer-14.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 170: '... that support DS MUST support the OK b...' RFC 2119 keyword, line 172: '...ecure the delegation MUST contain a DS...' RFC 2119 keyword, line 174: '...r the delegation MUST include the foll...' RFC 2119 keyword, line 185: '...e DNS message, the TC bit MUST be set....' RFC 2119 keyword, line 190: '...t of view). DS RRsets MUST NOT appear...' (30 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A server authoritative for only the child zone at a delegation point that is also a caching server MAY (if the RD bit is set in the query) perform recursion to find the DS record at the delegation point, and may return the DS record from its cache. In this case, the AA bit MUST not be set in the response. -- 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 (May 2003) is 7624 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: 'RFC1035' is mentioned on line 681, but not defined == Missing Reference: 'RFC2535' is mentioned on line 684, but not defined ** Obsolete undefined reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Missing Reference: 'RFC3090' is mentioned on line 690, but not defined ** Obsolete undefined reference: RFC 3090 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Missing Reference: 'RFC3008' is mentioned on line 687, but not defined ** Obsolete undefined reference: RFC 3008 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Missing Reference: 'RFC3225' is mentioned on line 693, but not defined == Missing Reference: 'RFC 2181' is mentioned on line 209, but not defined == Missing Reference: 'RFC3445' is mentioned on line 696, but not defined ** Obsolete undefined reference: RFC 3445 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Unused Reference: 'RFC2181' is defined on line 701, but no explicit reference was found in the text Summary: 7 errors (**), 0 flaws (~~), 13 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT Working Group Olafur Gudmundsson 3 INTERNET-DRAFT May 2003 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 December 6, 2003. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). 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 registry 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 was thought to simplify 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 100 are IPSEC, HTTP, SMTP, SSH and others that use public key 101 cryptography. 102 2. The KEY RRset may require frequent updates. 103 3. The probability of compromised or lost keys, which trigger 104 emergency key rollover procedures, increases. 105 4. The parent may refuse sign KEY RRsets with non-DNSSEC zone keys. 106 5. The parent may not meet the child's expectations in turnaround 107 time for resigning the KEY RRset. 109 Given these reasons, SIG@parent isn't any better than SIG/KEY@Child. 111 1.2 Reserved Words 113 The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", 114 "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be 115 interpreted as described in RFC2119. 117 2 Specification of the Delegation key Signer 119 This section defines the Delegation Signer (DS) RR type (type code 120 TBD) and the changes to DNS to accommodate it. 122 2.1 Delegation Signer Record Model 124 This document presents a replacement for the DNSSEC KEY record chain 125 of trust [RFC2535] that uses a new RR that resides only at the 126 parent. This record identifies the key(s) that the child uses to 127 self-sign its own KEY RRset. 129 The chain of trust is now established by verifying the parent KEY 130 RRset, the DS RRset from the parent and the KEY RRset at the child. 131 This is cryptographically equivalent to using just KEY records. 133 Communication between the parent and child is greatly reduced, since 134 the child only needs to notify the parent about changes in keys that 135 sign its apex KEY RRset. The parent is ignorant of all other keys in 136 the child's apex KEY RRset. Furthermore, the child maintains full 137 control over the apex KEY RRset and its content. The child can 138 maintain any policies regarding its KEY usage for DNSSEC with minimal 139 impact on the parent. Thus if the child wants to have frequent key 140 rollover for its DNS zone keys, the parent does not need to be aware 141 of it. The child can use one key to sign only its apex KEY RRset and 142 a different key to sign the other RRsets in the zone. 144 This model fits well with a slow roll out of DNSSEC and the islands 145 of security model. In this model, someone who trusts "good.example." 146 can preconfigure a key from "good.example." as a trusted key, and 147 from then on trusts any data signed by that key or that has a chain 148 of trust to that key. If "example." starts advertising DS records, 149 "good.example." does not have to change operations by suspending 150 self-signing. DS records can also be used to identify trusted keys 151 instead of KEY records. Another significant advantage is that the 152 amount of information stored in large delegation zones is reduced: 153 rather than the NULL KEY record at every unsecure delegation required 154 by RFC 2535, only secure delegations require additional information 155 in the form of a signed DS RRset. 157 The main disadvantage of this approach is that verifying a zone's KEY 158 RRset requires two signature verification operations instead of the 159 one required by RFC 2535. There is no impact on the number of 160 signatures verified for other types of RRsets. 162 Even though DS identifies two roles for KEY's, Key Signing Key (KSK) 163 and Zone Signing Key (ZSK), there is no requirement that zone use two 164 different keys for these roles. It is expected that many small zones 165 will only use one key, while larger organizations will be more likely 166 to use multiple keys. 168 2.2 Protocol Change 170 All DNS servers and resolvers that support DS MUST support the OK bit 171 [RFC3225] and a larger message size [RFC3226]. In order for a 172 delegation to be considered secure the delegation MUST contain a DS 173 RRset. If a query contains the OK bit, a server returning a referral 174 for the delegation MUST include the following RRsets in the authority 175 section in this order: 176 If DS RRset is present: 177 parents copy of childs NS RRset 178 DS and SIG(DS) 179 If no DS RRset is present: 180 parents copy of childs NS RRset 181 parents zone NXT and SIG(NXT) 183 This increases the size of referral messages and possilbly causing 184 some or all glue to be omitted. If the DS or NXT RRsets with 185 signatures do not fit in the DNS message, the TC bit MUST be set. 186 Additional section processing is not changed. 188 A DS RRset accompanying a NS RRset indicates that the child zone is 189 secure. If a NS RRset exists without a DS RRset, the child zone is 190 unsecure (from the parents point of view). DS RRsets MUST NOT appear 191 at non-delegation points or at a zone's apex. 193 Section 2.2.1 defines special considerations related to authoritative 194 servers responding to DS queries and replaces RFC2535 sections 2.3.4 195 and 3.4. Section 2.2.2 replaces RFC3008 section 2.7, and section 196 2.2.3 updates RFC3090. 198 2.2.1 RFC2535 2.3.4 and 3.4: Special Considerations at Delegation Points 200 DNS security views each zone as a unit of data completely under the 201 control of the zone owner with each entry (RRset) signed by a special 202 private key held by the zone manager. But the DNS protocol views the 203 leaf nodes in a zone that are also the apex nodes of a child zone 204 (i.e., delegation points) as "really" belonging to the child zone. 205 The corresponding domain names appear in two master files and might 206 have RRsets signed by both the parent and child zones' keys. A 207 retrieval could get a mixture of these RRsets and SIGs, especially 208 since one server could be serving both the zone above and below a 209 delegation point [RFC 2181]. 211 Each DS RRset stored in the parent zone MUST be signed by at least 212 one of the parent zone's private key. The parent zone MUST NOT 213 contain a KEY RRset at any delegation point. Delegations in the 214 parent MAY contain only the following RR types: NS, DS, NXT and SIG. 215 The NS RRset MUST NOT be signed. The NXT RRset is the exceptional 216 case: it will always appear differently and authoritatively in both 217 the parent and child zones if both are secure. 219 A secure zone MUST contain a self-signed KEY RRset at its apex. Upon 220 verifying the DS RRset from the parent, a resolver MAY trust any KEY 221 identified in the DS RRset as a valid signer of the child's apex KEY 222 RRset. Resolvers configured to trust one of the keys signing the KEY 223 RRset MAY now treat any data signed by the zone keys in the KEY RRset 224 as secure. In all other cases resolvers MUST consider the zone 225 unsecure. A DS RRset MUST NOT appear at a zone's apex. 227 An authoritative server queried for type DS MUST return the DS RRset 228 in the answer section. 230 2.2.1.1 Special processing for DS queries 232 When a server is authoritative for the parent zone at a delegation 233 point and receives a query for the DS record at that name, it will 234 return the DS from the parent zone. This is true whether or not it 235 is also authoritative for the child zone. 237 When the server is authoritative for the child zone at a delegation 238 point but not the parent zone, there is no natural response, since 239 the child zone is not authoritative for the DS record at the zone's 240 apex. As these queries are only expected to originate from recursive 241 servers which are not DS-aware, the authoritative server MUST answer 242 with: 243 RCODE: NOERROR 244 AA bit: set 245 Answer Section: Empty 246 Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)] 248 That is, it answers as if it is authoritative and the DS record does 249 not exist. DS-aware recursive servers will query the parent zone at 250 delegation points, so will not be affected by this. 252 A server authoritative for only the child zone at a delegation point 253 that is also a caching server MAY (if the RD bit is set in the query) 254 perform recursion to find the DS record at the delegation point, and 255 may return the DS record from its cache. In this case, the AA bit 256 MUST not be set in the response. 258 2.2.1.2 Special processing when child and an ancestor share server" 260 Special rules are needed to permit DS RR aware servers to gracefully 261 interact with older caches which otherwise might falsely label a 262 server as lame because of the new placement of the DS RR set. 264 Such a situation might arise when a server is authoritative for both 265 a zone and it's grandparent, but not the parent. This sounds like an 266 obscure example, but it is very real. The root zone is currently 267 served on 13 machines, and "root-servers.net." is served on 4 of the 268 same 13, but "net." is served elsewhere. 270 When a server receives a query for (, DS, IN), the response 271 MUST be determined from reading these rules in order: 273 1) If the server is authoritative for the zone that holds the DS RR 274 set (i.e., the zone that delegates away, aka the "parent" 275 zone), the response contains the DS RR set as an authoritative 276 answer. 278 2) If the server is offering recursive service and the RD bit is set 279 in the query, the server performs the query itself (according to the 280 rules for resolvers described below) and returns it's findings. 282 3) If the server is authoritative for the zone that holds the 283 's SOA RR set, the response is an authoritative negative 284 answer as described in 2.2.1.1. 286 4) If the server is authoritative for a zone or zones above the 287 QNAME, a referral to the most enclosing zone's servers is made. 289 5) If the server is not authoritative for any part of the QNAME, a 290 response indicating a lame server for QNAME is given. 292 Using these rules will require some special processing on the part of 293 a DS RR aware resolver. To illustrate this, an example is used. 295 Assuming a server is authoritative for roots.example.net. and for the 296 root zone but not the intervening two zones (or the intervening two 297 label deep zone). Assume that QNAME=roots.example.net., QTYPE=DS, 298 and QCLASS=IN. 300 The resolver will issue this request (assuming no cached data) 301 expecting a referral to a net. server. Instead, rule number 3 above 302 applies and a negative answer is returned by the server. The 303 reaction by the resolver is not to accept this answer as final as it 304 can determine from the SOA RR in the negative answer the context 305 within which the server has answered. 307 A solution to this is to instruct the resolver to hunt for the 308 authoritative zone of the data in a brute force manner. 310 This can be accomplished by taking the owner name of the returned SOA 311 RR and strip off enough left-hand labels until a successful NS 312 response is obtained. A successful response here means that the 313 answer has NS records in it. (Entertaining the possibility that a 314 cut point may be two labels down in a zone.) 316 Returning to the example, the response will include a negative answer 317 with either the SOA RR for "roots.example.net." or "example.net." 318 depending on whether roots.example.net is a delegated domain. In 319 either case, removing the least significant label of the SOA owner 320 name will lead to the location of the desired data. 322 2.2.1.3 Modification on KEY RR in the construction of Responses 324 This section updates RFC2535 section 3.5 by replacing it with the 325 following: 327 An query for KEY RR MUST NOT trigger any additional section 328 processing. Security aware resolver will include corresponding SIG 329 records in the answer section. 331 KEY records SHOULD NOT be added to additional records section in 332 response to any query. 334 RFC2535 included rules to in add KEY records to additional section 335 when SOA or NS records where included in an answer. The is was done 336 to reduce round trips (in the case of SOA) and to force out NULL 337 KEY's (in the NS case), as this document obsoletes NULL keys there is 338 no need for the second case, the first case causes redundant 339 transfers of KEY RRset as SOA is included in the authority section of 340 negative answers. 342 RFC2535 section 3.5 also included rule for adding KEY RRset to query 343 for A and AAAA, as Restrict KEY[RFC3445] eliminated use of KEY RR by 344 all applications therfore the rule is not needed anymore. 346 2.2.2 Signer's Name (replaces RFC3008 section 2.7) 348 The signer's name field of a SIG RR MUST contain the name of the zone 349 to which the data and signature belong. The combination of signer's 350 name, key tag, and algorithm MUST identify a zone key if the SIG is 351 to be considered material. This document defines a standard policy 352 for DNSSEC validation; local policy may override the standard policy. 354 There are no restrictions on the signer field of a SIG(0) record. 355 The combination of signer's name, key tag, and algorithm MUST 356 identify a key if this SIG(0) is to be processed. 358 2.2.3 Changes to RFC3090 360 A number of sections of RFC3090 need to be updated to reflect the DS 361 record. 363 2.2.3.1 RFC3090: Updates to section 1: Introduction 365 Most of the text is still relevant but the words ``NULL key'' are to 366 be replaced with ``missing DS RRset''. In section 1.3 the last three 367 paragraphs discuss the confusion in sections of RFC 2535 that are 368 replaced in section 2.2.1 above. Therefore, these paragraphs are now 369 obsolete. 371 2.2.3.2 RFC3090 section 2.1: Globally Secured 373 Rule 2.1.b is replaced by the following rule: 375 2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a 376 private key whose public counterpart MUST appear in a zone signing 377 KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to- 378 implement algorithm. This KEY RR MUST be identified by a DS RR in a 379 signed DS RRset in the parent zone. 381 If a zone cannot get its parent to advertise a DS record for it, the 382 child zone cannot be considered globally secured. The only exception 383 to this is the root zone, for which there is no parent zone. 385 2.2.3.3 RFC3090 section 3: Experimental Status. 387 The only difference between experimental status and globally secured 388 is the missing DS RRset in the parent zone. All locally secured zones 389 are experimental. 391 2.2.4 NULL KEY elimination 393 RFC3445 section 3 elminates the top two bits in the flags field of 394 KEY RR. These two bits where used to indicate NULL KEY or NO KEY. 395 RFC3090 defines that zone that defines that zone is either secure or 396 not, eliminates the possible need to put NULL keys in the zone apex 397 to indicate that the zone is not secured for a algorithm. Along with 398 this document these other two elminate all uses for the NULL KEY, 399 Thus this document obsoletes NULL KEY. 401 2.3 Comments on Protocol Changes 403 Over the years there have been various discussions surrounding the 404 DNS delegation model, declaring it to be broken because there is no 405 good way to assert if a delegation exists. In the RFC2535 version of 406 DNSSEC, the presence of the NS bit in the NXT bit map proves there is 407 a delegation at this name. Something more explicit is needed and the 408 DS record addresses this need for secure delegations. 410 The DS record is a major change to DNS: it is the first resource 411 record that can appear only on the upper side of a delegation. Adding 412 it will cause interoperabilty problems and requires a flag day for 413 DNSSEC. Many old servers and resolvers MUST be upgraded to take 414 advantage of DS. Some old servers will be able to be authoritative 415 for zones with DS records but will not add the NXT or DS records to 416 the authority section. The same is true for caching servers; in 417 fact, some may even refuse to pass on the DS or NXT records. 419 2.4 Wire Format of the DS record 421 The DS (type=TDB) record contains these fields: key tag, algorithm, 422 digest type, and the digest of a public key KEY record that is 423 allowed and/or used to sign the child's apex KEY RRset. Other keys 424 MAY sign the child's apex KEY RRset. 426 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | key tag | algorithm | Digest type | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | digest (length depends on type) | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | (SHA-1 digest is 20 bytes) | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 437 | | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 439 | | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 The key tag is calculated as specified in RFC2535. Algorithm MUST be 443 an algorithm number assigned in the range 1..251 and the algorithm 444 MUST be allowed to sign DNS data. The digest type is an identifier 445 for the digest algorithm used. The digest is calculated over the 446 canonical name of the delegated domain name followed by the whole 447 RDATA of the KEY record (all four fields). 449 digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata) 451 KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key 453 Digest type value 0 is reserved, value 1 is SHA-1, and reserving 454 other types requires IETF standards action. For interoperabilty 455 reasons, as few digest algorithms as possible should be reserved. The 456 only reason to reserve additional digest types is to increase 457 security. 459 DS records MUST point to zone KEY records that are allowed to 460 authenticate DNS data. The indicated KEY record's protocol field 461 MUST be set to 3; flag field bit 7 MUST be set to 1. The value of 462 other flag bits is not significant for the purposes of this document. 464 The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless 465 of key size, new digest types probably will have larger digests. 467 2.4.1 Justifications for Fields 469 The algorithm and key tag fields are present to allow resolvers to 470 quickly identify the candidate KEY records to examine. SHA-1 is a 471 strong cryptographic checksum: it is computationally infeasible for 472 an attacker to generate a KEY record that has the same SHA-1 digest. 473 Combining the name of the key and the key rdata as input to the 474 digest provides stronger assurance of the binding. Having the key 475 tag in the DS record adds greater assurance than the SHA-1 digest 476 alone, as there are now two different mapping functions that a KEY RR 477 must match. 479 This format allows concise representation of the keys that the child 480 will use, thus keeping down the size of the answer for the 481 delegation, reducing the probability of DNS message overflow. The 482 SHA-1 hash is strong enough to uniquely identify the key and is 483 similar to the PGP key footprint. The digest type field is present 484 for possible future expansion. 486 The DS record is well suited to listing trusted keys for islands of 487 security in configuration files. 489 2.5 Presentation Format of the DS Record 491 The presentation format of the DS record consists of three numbers 492 (key tag, algorithm and digest type) followed by the digest itself 493 presented in hex: 494 example. DS 12345 3 1 123456789abcdef67890123456789abcdef67890 496 2.6 Transition Issues for Installed Base 498 No backwards compatibility with RFC2535 is provided. 500 RFC2535-compliant resolvers will assume that all DS-secured 501 delegations are locally secure. This is bad, but the DNSEXT Working 502 Group has determined that rather than dealing with both 503 RFC2535-secured zones and DS-secured zones, a rapid adoption of DS is 504 preferable. Thus the only option for early adopters is to upgrade to 505 DS as soon as possible. 507 2.6.1 Backwards compatibility with RFC2535 and RFC1035 509 This section documents how a resolver determines the type of 510 delegation. 511 RFC1035 delegation (in parent) has: 513 RFC1035 NS 515 RFC2535 adds the following two cases: 517 Secure RFC2535: NS + NXT + SIG(NXT) 518 NXT bit map contains: NS SIG NXT 519 Unsecure RFC2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT) 520 NXT bit map contains: NS SIG KEY NXT 521 KEY must be a NULL key. 523 DNSSEC with DS has the following two states: 525 Secure DS: NS + DS + SIG(DS) 526 NXT bit map contains: NS SIG NXT DS 527 Unsecure DS: NS + NXT + SIG(NXT) 528 NXT bit map contains: NS SIG NXT 530 It is difficult for a resolver to determine if a delegation is secure 531 RFC 2535 or unsecure DS. This could be overcome by adding a flag to 532 the NXT bit map, but only upgraded resolvers would understand this 533 flag, anyway. Having both parent and child signatures for a KEY RRset 534 might allow old resolvers to accept a zone as secure, but the cost of 535 doing this for a long time is much higher than just prohibiting RFC 536 2535-style signatures at child zone apexes and forcing rapid 537 deployment of DS-enabled servers and resolvers. 539 RFC 2535 and DS can in theory be deployed in parallel, but this would 540 require resolvers to deal with RFC 2535 configurations forever. This 541 document obsoletes the NULL KEY in parent zones, which is a difficult 542 enough change that a flag day is required. 544 2.7 KEY and corresponding DS record example 546 This is an example of a KEY record and the corresponding DS record. 548 dskey.example. KEY 256 3 1 ( 549 AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj 550 4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt 551 ) ; key id = 28668 552 DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE 554 3 Resolver 556 3.1 DS Example 558 To create a chain of trust, a resolver goes from trusted KEY to DS to 559 KEY. 561 Assume the key for domain "example." is trusted. Zone "example." 562 contains at least the following records: 563 example. SOA 564 example. NS ns.example. 565 example. KEY 566 example. NXT NS SOA KEY SIG NXT secure.example. 567 example. SIG(SOA) 568 example. SIG(NS) 569 example. SIG(NXT) 570 example. SIG(KEY) 571 secure.example. NS ns1.secure.example. 572 secure.example. DS tag=12345 alg=3 digest_type=1 573 secure.example. NXT NS SIG NXT DS unsecure.example. 574 secure.example. SIG(NXT) 575 secure.example. SIG(DS) 576 unsecure.example NS ns1.unsecure.example. 577 unsecure.example. NXT NS SIG NXT example. 578 unsecure.example. SIG(NXT) 580 In zone "secure.example." following records exist: 581 secure.example. SOA 582 secure.example. NS ns1.secure.example. 583 secure.example. KEY 584 secure.example. KEY 585 secure.example. NXT 586 secure.example. SIG(KEY) 587 secure.example. SIG(SOA) 588 secure.example. SIG(NS) 589 secure.example. SIG(NXT) 591 In this example the private key for "example." signs the DS record 592 for "secure.example.", making that a secure delegation. The DS record 593 states which key is expected to sign the KEY RRset at 594 "secure.example.". Here "secure.example." signs its KEY RRset with 595 the KEY identified in the DS RRset, thus the KEY RRset is validated 596 and trusted. 598 This example has only one DS record for the child, but parents MUST 599 allow multiple DS records to facilitate key rollover and multiple KEY 600 algorithms. 602 The resolver determines the security status of "unsecure.example." by 603 examining the parent zone's NXT record for this name. The absence of 604 the DS bit indicates an unsecure delegation. Note the NXT record 605 SHOULD only be examined after verifying the corresponding signature. 607 3.1 Resolver Cost Estimates for DS Records 609 From a RFC2535 resolver point of view, for each delegation followed 610 to chase down an answer, one KEY RRset has to be verified. 611 Additional RRsets might also need to be verified based on local 612 policy (e.g., the contents of the NS RRset). Once the resolver gets 613 to the appropriate delegation, validating the answer might require 614 verifying one or more signatures. A simple A record lookup requires 615 at least N delegations to be verified and one RRset. For a DS-enabled 616 resolver, the cost is 2N+1. For an MX record, where the target of 617 the MX record is in the same zone as the MX record, the costs are N+2 618 and 2N+2, for RFC 2535 and DS, respectively. In the case of negatives 619 answer the same ratios hold true. 621 The resolver may require an extra query to get the DS record and this 622 may add to the overall cost of the query, but this is never worse 623 than chasing down NULL KEY records from the parent in RFC2535 DNSSEC. 625 DS adds processing overhead on resolvers and increases the size of 626 delegation answers, but much less than storing signatures in the 627 parent zone. 629 4 Security Considerations: 631 This document proposes a change to the validation chain of KEY 632 records in DNSSEC. The change is not believed to reduce security in 633 the overall system. In RFC2535 DNSSEC, the child zone has to 634 communicate keys to its parent and prudent parents will require some 635 authentication with that transaction. The modified protocol will 636 require the same authentication, but allows the child to exert more 637 local control over its own KEY RRset. 639 There is a remote possibility that an attacker could generate a valid 640 KEY that matches all the DS fields, of a specific DS set, and thus 641 forge data from the child. This possibility is considered 642 impractical, as on average more than 643 2 ^ (160 - ) 644 keys would have to be generated before a match would be found. 646 An attacker that wants to match any DS record will have to generate 647 on average at least 2^80 keys. 649 The DS record represents a change to the DNSSEC protocol and there is 650 an installed base of implementations, as well as textbooks on how to 651 set up secure delegations. Implementations that do not understand the 652 DS record will not be able to follow the KEY to DS to KEY chain and 653 will consider all zones secured that way as unsecure. 655 5 IANA Considerations: 657 IANA needs to allocate an RR type code for DS from the standard RR 658 type space (type 43 requested). 660 IANA needs to open a new registry for the DS RR type for digest 661 algorithms. Defined types are: 662 0 is Reserved, 663 1 is SHA-1. 664 Adding new reservations requires IETF standards action. 666 6 Acknowledgments 668 Over the last few years a number of people have contributed ideas 669 that are captured in this document. The core idea of using one key to 670 sign only the KEY RRset comes from discussions with Bill Manning and 671 Perry Metzger on how to put in a single root key in all resolvers. 672 Alexis Yushin, Brian Wellington, Sam Weiler, Paul Vixie, Jakob 673 Schlyter, Scott Rose, Edward Lewis, Lars-Johan Liman, Matt Larson, 674 Mark Kosters, Dan Massey, Olaf Kolman, Phillip Hallam-Baker, Miek 675 Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David 676 Blacka, Steve Bellovin, Rob Austein, Derek Atkins, Roy Arends, Mark 677 Andrews, Harald Alvestrand, and others have provided useful comments. 679 Normative References: 681 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 682 Specification'', STD 13, RFC 1035, November 1987. 684 [RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC 685 2535, March 1999. 687 [RFC3008] B. Wellington, ``Domain Name System Security (DNSSEC) Signing 688 Authority'', RFC 3008, November 2000. 690 [RFC3090] E. Lewis `` DNS Security Extension Clarification on Zone 691 Status'', RFC 3090, March 2001. 693 [RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC 694 3225, December 2001. 696 [RFC3445] D. Massey, S. Rose ``Limiting the scope of the KEY Resource 697 Record (RR)``, RFC 3445, December 2002. 699 Informational References 701 [RFC2181] R. Elz, R. Bush, ``Clarifications to the DNS Specification'', 702 RFC 2181, July 1997. 704 [RFC3226] O. Gudmundsson, ``DNSSEC and IPv6 A6 aware server/resolver 705 message size requirements'', RFC 3226, December 2001. 707 Author Address 709 Olafur Gudmundsson 710 3821 Village Park Drive 711 Chevy Chase, MD, 20815 712 USA 713 715 Full Copyright Statement 717 Copyright (C) The Internet Society (2003). All Rights Reserved. 719 This document and translations of it may be copied and furnished to 720 others, and derivative works that comment on or otherwise explain it 721 or assist in its implementation may be prepared, copied, published 722 and distributed, in whole or in part, without restriction of any 723 kind, provided that the above copyright notice and this paragraph are 724 included on all such copies and derivative works. However, this 725 document itself may not be modified in any way, such as by removing 726 the copyright notice or references to the Internet Society or other 727 Internet organizations, except as needed for the purpose of 728 developing Internet standards in which case the procedures for 729 copyrights defined in the Internet Standards process must be 730 followed, or as required to translate it into languages other than 731 English. 733 The limited permissions granted above are perpetual and will not be 734 revoked by the Internet Society or its successors or assigns. 736 This document and the information contained herein is provided on an 737 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 738 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 739 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 740 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 741 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."