idnits 2.17.00 (12 Aug 2021) /tmp/idnits35971/draft-ietf-dnsop-interim-signed-root-01.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. == There are 4 instances of lines with non-ascii characters in the document. == 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 769 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 24 instances of lines with control characters in the document. ** 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 212: '...al property that MUST be preserved in ...' RFC 2119 keyword, line 215: '... failure SHOULD NOT be introduced by...' RFC 2119 keyword, line 294: '...tures in the signed root zone MUST NOT...' 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 (February 2003) is 7034 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? 'RFC2535' on line 662 looks like a reference -- Missing reference section? 'RFC3090' on line 665 looks like a reference -- Missing reference section? 'DS' on line 110 looks like a reference -- Missing reference section? 'Threshold-Validation' on line 717 looks like a reference -- Missing reference section? 'RFC1996' on line 670 looks like a reference -- Missing reference section? 'RFC1995' on line 668 looks like a reference -- Missing reference section? 'AXFR-clarify' on line 700 looks like a reference -- Missing reference section? 'RFC2845' on line 673 looks like a reference -- Missing reference section? 'RFC2930' on line 679 looks like a reference -- Missing reference section? 'RFC3007' on line 682 looks like a reference -- Missing reference section? 'RFC3008' on line 685 looks like a reference -- Missing reference section? 'RFC3110' on line 688 looks like a reference -- Missing reference section? 'RFC3225' on line 691 looks like a reference -- Missing reference section? 'RFC3226' on line 694 looks like a reference -- Missing reference section? 'Delegation-Signer' on line 697 looks like a reference -- Missing reference section? 'AD-secure' on line 704 looks like a reference -- Missing reference section? 'Opt-In' on line 708 looks like a reference -- Missing reference section? 'Wild-card-optimize' on line 712 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Johan Ihr‰n 3 draft-ietf-dnsop-interim-signed-root-01.txt Autonomica 4 February 2003 5 Expires in six months 7 An Interim Scheme for Signing the Public DNS Root 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 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-Drafts 22 as reference material or to cite them other than as "work in 23 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 Abstract 33 This memo documents a proposed mechanism for a first stage of a 34 transition from an unsigned DNS root to a signed root, such that 35 the data in the root zone is accompanied by DNSSEC signatures to 36 allow validation. 38 The underlying reason for signing the root zone is to be able to 39 provide a more secure DNS hierarchy, where it is possible to 40 distinguish false answers from correct answers. 42 For the special case of the DNS root zone, an interim scheme is 43 proposed. This scheme is mostly aimed at securing the root zone 44 itself for technical and operational reasons, and to give 45 operational experience of DNSSEC. 47 1. Terminology 49 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 50 and "MAY" in this document are to be interpreted as described in 51 RFC 2119. 53 The term "zone" refers to the unit of administrative control in the 54 Domain Name System. "Name server" denotes a DNS name server that is 55 authoritative (i.e. knows all there is to know) for a DNS zone, 56 typically the root zone. A "resolver", finally, is a DNS "client", 57 i.e. an entity that sends DNS queries to authoritative nameservers 58 and interpret the results. 60 2. Motivation for signing the DNS root 62 In the special case of the root zone there are very strong reasons 63 to take a slow and conservative approach to any changes with 64 operational impact. Signing the root is such a change. 66 DNSSEC[RFC2535, RFC3090] has been in development for a number of 67 years now and still has not reached the point where the last flag 68 day is behind us. 70 However, during the years of DNSSEC development and refinement 71 [RFC2930, RFC3007, RFC3008, RFC3110, RFC3225, RFC3226, AD-secure, 72 Opt-in, Wild-card-optimize], the Internet has matured and more and 73 more businesses and other organizations have become dependent on 74 the stability and constant availability of the Internet. 76 It is therefore prudent to do everything in our power to ensure 77 that the DNS infrastructure works as well as possible and, when 78 appropriate and possible, adding enhancements and functionality. 80 The time is now right for yet another step of improvement by 81 signing the root zone. By doing that any Internet user that so 82 wishes will obtain the ability of verifying responses received from 83 the root nameservers. 85 Since this is new operational ground the objective is not maximum 86 security but rather an "Internet-wide" controlled experiment with a 87 signed root zone, where the trade off is that we utilize the fact 88 that there are operators in place that can help even though they 89 are not sufficiently staffed to do off-line signing in a 24x7 90 mode. For this reason it is fully possible to even do automatic 91 signing, since the purpose is to ensure that DNSSEC works 92 operationally with a signed root zone and gain experience from the 93 exercise. 95 It should be pointed out, however, that the experimental part is 96 only the added DNSSEC records. The traditional records in the root 97 zone remain unchanged and the new records will only be visible to 98 DNSSEC-aware resolvers that explicitly ask to see these new 99 records. 101 2.1. Motivation for signing the root zone now 103 The reason DNSSEC is not yet widely deployable is that the problem 104 of key management remains unsolved, especially where communication 105 between the zone administrators for a parent zone and child zone is 106 required. 108 However, during the past year a solution to this problem has been 109 found (in the form of a new record type, DS aka Delegation Signer) 110 [DS], discussed, implemented and tested. Therefore, it is finally 111 reasonable to consider DNSSEC deployment to be a real possibility 112 within the next 12 months. 114 In the case of the root zone the particular importance of managing 115 the transition with zero operational mistakes is a strong reason to 116 separate the signing of the zone itself, with the associated key 117 management issues, from the future management of signed delegations 118 (of top level domains). 120 Although support for Delegation Signer has been implemented and 121 tested it is not yet generally available except experimentally. For 122 this reason signed delegations for productions zones will have to 123 wait a bit longer. Furthermore, it will take some time to ensure 124 that the entire RSS aka Root Server System is capable of supporting 125 the protocol changes that accompany the new support for Delegation 126 Signer. 128 By signing now it will be possible to work through the operational 129 issues with signing the zone itself without at the same time having 130 to manage the additional complexity of signed delegations. Also, by 131 explicitly not supporting any signed delegations, it is also 132 possible to recover in a graceful way should new operational 133 problems turn up. 135 Because of these operational and technical issues there is a 136 "window of opportunity" to sign the root zone before the status of 137 implementation of "full DNSSEC", including Delegation Signer 138 support, change to "generally available", thereby increasing the 139 pressure for signed delegations from the root zone. 141 3. Trust in DNSSEC Keys 143 In the end the trust that a validating resolver will be able to put 144 in a key that it cannot validate within DNSSEC will have to be a 145 function of 147 * trust in the key issuer 149 * trust in the distribution method 151 * trust in extra, out-of-band verification 153 For any security apex, i.e. a node in the DNS hierarchy that issues 154 out-of-band "trusted keys", it is of critical importance that this 155 function produces a positive result (i.e. the resolver gains 156 sufficient confidence in the keys to decide to trust them). The 157 particular case of the root zone is no different, although possibly 158 it is more crucial than many other security apexes. 160 To ensure that the resulting trust is maximized it is necessary to 161 work with all the parameters that are available. In the case of the 162 key issuer there is the possibility of chosing a key issuer that 163 has a large "trust base" (i.e. is already trusted by a large 164 fraction of the resolver population). However, it is also possible 165 to expand the aggregated trust base by using multiple simultaneous 166 key issuers, as described in [Threshold-Validation]. 168 Furthermore, with multiple trusted keys it will be possible for a 169 validating resolver to optimize for the "right compromise" between 171 * maximum security (as expressed by all available signatures by all 172 available keys verifying correctly 174 * maximum redundancy (as in the DNS lookup being validated if there 175 is any signature by any trusted key available) 177 Without multiple, independent trusted keys the rollover operation 178 will always be a dangerous operation where it is likely that some 179 fraction of the resolver population lose their ability to verify 180 lookups (and hence start to fail hard). I.e. the validating 181 resolver will be forced to adopt the "maximum security" policy, 182 since there is no alternative. 184 With multiple, independent trusted keys, however, it is possible to 185 design for improved redundancy by trusting lookups that are only 186 validated against a subset of the available keys. This will make 187 rollovers much less risky to the extent that it will be possible to 188 "survive" even emergency rollovers without any immediate 189 configuration chagnes in the validating resolver. 191 4. Interim signing of the root zone 193 At present all the authoritative servers for the root zone pull the 194 zone from a primary master. I.e. any changes at the primary master 195 will propagate via NOTIFY[RFC1996] and subsequent 196 AXFR/IXFR[RFC1995, AXFR-clarify] to the slave servers. 198 Between the primary master and the slaves transactions are signed 199 with TSIG[RFC2845] signatures. This mechanism is already in place, 200 and there is operational experience with periodic key rollover of 201 the TSIG keys. 203 4.1. Design philosophy 205 By introducing a signing step into the distribution of the zone 206 file complexity is increased. To avoid introducing new single 207 points of failure it is therefore important to ensure that any 208 added or changed steps are as redundant as possible. 210 The assumption is that the operators of the root servers are 211 trusted and that consistency of the zone among the root servers is 212 a crucial property that MUST be preserved in emergencies. 214 To ensure that consistency is maintained new single points of 215 failure SHOULD NOT be introduced by the signing step. Therefore a 216 structure where several parties have the ability to sign the zone 217 is proposed. Furthermore, such a design helps avoid any individual 218 party becoming a de facto single zone signing authority. 220 4.2. Proposed new management structure for the root zone 222 Taking into account the already existing infrastructure for 223 management of TSIG keys and rollover of these keys the following 224 structure is proposed: 226 * Day-to-day signing of the root zone is performed by a subgroup of 227 the root server operators referred to as "signing operators". For 228 this task individual, per-operator, Zone Signing Keys, ZSKs, are 229 used. 231 * The set of Zone Signing Keys are signed by several Key Signing 232 Keys, KSKs, at any particular time. The public part of KSKs in 233 use have to be statically configured as "trusted keys" in all 234 resolvers that want to be able to perform validation of 235 responses. 237 * Key rollover, the operation when an old KSK is exchanged for a 238 new KSK, is managed with minimal overlap and on a frequent basis 239 of no less than three times per year per KSK. The rollover 240 schedule is chosen to be frequent enough to not make long-term 241 trust possible while being low enough to not become operationally 242 infeasible. 244 4.2.1. Management and distribution of the zone file 246 The present, unsigned zone is published by the official slaves, the 247 "root nameservers", transferring the zone securely from a primary 248 master and subsequently using the data to respond to queries. This 249 mechanism is changed into: 251 * The unsigned root zone is transferred securely from the primary 252 master to a set of "signing primaries" managed by the operators 253 participating in signing the zone. This is done via the 254 traditional mechanisms NOTIFY + AXFR/IXFR + TSIG. 256 * The root nameservers change their configuration so that they 257 replace the present, single, primary master as the source of the 258 zone with a set of multiple possible "signing primaries" as 259 masters that provide the signed zone. 261 * When a new, unsigned zone, is published by the primary master it 262 will automatically be transferred to the pre-signing servers. The 263 responsible operator will then sign the new zone and publish it 264 from his signing primary. Since the serial number is higher than 265 what the official root nameservers presently have the official 266 root nameservers will all transfer the zone from this source 267 (because of the redundant configuration with multiple possible 268 masters for the signed zone). 270 * The operators that participate in signing rotate the signing 271 responsibility among themselves. Should the responsible operator 272 be unable to do this for any reason then any of the others are 273 able to do the signing instead. Traceability is maintained since 274 the zone signing keys are individual. 276 * To avoid having several "backup signing operators" possibly sign 277 at exactly the same time backups are allocated "time windows" 278 within which they are allowed to publish a signed zone. 280 With N signers, each signer is assigned a unique number R in 281 [1..N]. 283 T = 2*k*((S-R) mod N) 285 T is time to wait in seconds, S current serial number. The length 286 of the window is k, thereby separating each signing window with 287 an interval where signing is not allowed. 289 The constant k is used to create sufficient separation of the 290 signers with respect to time used to sign and time needed to 291 distribute the zone. A reasonable value for k would be in the 292 order of 1800 seconds. 294 * Because the digital signatures in the signed root zone MUST NOT 295 expire it is necessary to ensure that the unsigned zone does 296 change sufficiently often to cause new signing to occur within 297 the validity period of the old signatures. This is most easily 298 accomplished by a dummy update that only increments the serial 299 number in the SOA record. 301 This new requirement will not cause any operational problems, 302 since in fact the root zone is maintained this way since several 303 years back. 305 4.2.2. Management of the Key Signing Keys 307 Key Signing Keys, KSKs, are periodically issued by a several "Key 308 Signing Key Holders", KSK holders, individually. These KSKs consist 309 of a private part that should always be kept secret and a public 310 part that should be published as widely as possible since it will 311 be used as a "trusted key" in resolver configurations. 313 The public part of each KSK should be included in the keyset for 314 "." as described in [Threshold-Validation]. I.e. the keyset will be 315 the union of the public parts of all KSKs and all ZSKs, Zone 316 Signing Keys. 318 * Each KSK holder should generate a sequence of KSKs where the 319 public parts will be used to include in the keyset for "." and 320 the private parts will be used for signing the keyset. 322 * Each KSK holder should, on request from the signing operators, 323 send in the public part of the KSK. The union of the public parts 324 of KSKs and the corresponding public parts of ZSKs, as collected 325 by the signing operators, constitute a "keyset". 327 * Each KSK holder should, on request from the signing operators, 328 sign the complete keyset with the private part of the associated 329 KSK and send in the resulting signature to the signing operators 330 for inclusion in the signed zone. 332 4.2.3. Management of the Zone Signing Keys and the keyset signatures 334 A subgroup of the root operators that choose to participate in 335 signing the zone each hold an individual "Zone Signing Key", 336 ZSK. The subgroup of operators may include all operators, but that 337 is not necessary as long as a sufficient number to achieve 338 redundancy in "signing ability" participates. 340 * The complete keyset (i.e. all the public parts of KSKs and ZSKs) 341 should be signed by each KSK holder individually, generating a 342 new signature for the keyset which is sent back to the signing 343 operators via an out-of-band mechanism. 345 * The signing operators should verify each received signature 346 against the corresponding key in the keyset and, unless invalid, 347 accept the signature into the set of signatures associated with 348 this keyset as described in [Threshold-Validation]. 350 * The signing operators should include one of the keysets together 351 with all the KSK signatures in the zone file according to an 352 agreed upon rotation schedule. 354 4.2.4. Management of key rollover 356 The Key Signing Keys should, for this interim scheme, be relatively 357 short-lived and rolled over frequently. The direct intent is that 358 it should not be possible to put long term trust in the keys. 359 Therefore, by design, every resolver that chooses to configure 360 these as "trusted keys" (to be able to validate lookups) will have 361 to change the configuration periodically. 363 This is, after all, only an interim method of root zone signing. 365 * Key rollover is executed by changing from one signed keyset to 366 another. I.e. from a keyset signed by one set of KSKs to a keyset 367 signed by a partially different set of KSKs. By not rolling all 368 the KSKs at the same time redundancy is improved. 370 * Technically the signing operators are able to initiate key 371 rollover, although except for the case of a suspected key 372 compromise (with subsequent immediate key rollover) this ability 373 should only be used according to an established schedule. 375 * New Key Signing Keys will be published as widely as possible, 376 however exactly how and where to publish the keys is by itself an 377 area where it is necessary to acquire more experience. Especially 378 for the case of individual hosts and other devices this will be a 379 significant issue to deal with. 381 * Since the keys expire within a few months the aim is to make it 382 as difficult as possible to configure an interim key and then 383 forget about it long enough to still trust an interim key when a 384 long term design for signing the root zone emerges. 386 4.2.5. The role of the KSK holder 388 With multiple KSKs it is possible to have multiple individual KSK 389 holders. Each will perform the role of authenticating the identity 390 of the signing operators, through the act of signing the keyset 391 that includes the operator Zone Signing Keys. 393 The chain of authority that defines editorial control over the zone 394 contents is entirely separate from this and is in no way affected. 396 I.e. the KSK holder is only asserting identity of the holders of 397 ZSKs and does not in any way take part in issues regarding zone 398 contents. In this respect the role of a KSK holder is much like 399 that of a public notary or a Certificate Authority. 401 The primary function that the KSK holder is performing is adding 402 trust to the authenticity of the Zone Signing Keys and this trust 403 has to be propagated down to validating resolvers. Therefore an 404 obvious key characteristic of a KSK holder is that it should 405 already be trusted by as large a fraction of the "resolver 406 population" as possible. In this document that fraction is referred 407 to as the "trust base" of a KSK holder. 409 The key characteristics of a KSK holder will be entities that 411 * already are trusted by some part of the "resolver population", 412 i.e. have a "trust base" 414 * are multiple entities that complement each other (so that the 415 aggregated "trust base" grows) 417 * are willing to help work on methods for distributing their 418 trusted keys to the resolvers (hard problem) 420 The requirement on the individual KSK holders is that they must be 421 able to 423 * establish a secure out-of-band communication path in 424 collaboration with the signing operators which will be used for 425 authenticated exchange of the unsigned keyset and generated 426 signatures 428 * periodically generate strong keys using a good random number 429 generator 431 * manage their keys (i.e. use them for signing the operator keyset 432 and keeping the private key appropriately secret) 434 4.2.5.6. Suggestions for KSK holders 436 Regional Internet Registries, RIRs, are suggested to be one 437 suitable choice of KSK holders. However, since every KSK holder 438 will act on its own there is no requirement that all RIRs 439 participate, although more than one would be good. Other suitable 440 KSK holders may exist and as long as the requirements are met more 441 would be better within the packe size limitations that are 442 discussed in [Threshold-Validation]. 444 The basis of the suggestion of RIRs is 446 * their neutrality 448 * their proven record of service to the Internet community 450 * that they don't have the domain name system as their primary 451 field of activity 453 * their geographical diversity 455 * the fact that they are, by definition, not a single entity, but 456 rather a collective of organizations. 458 5. Risk Analysis 460 A change in the management of the root zone is always a risk. But 461 that is all the more reason to do it carefully and after due 462 consideration, rather than as a result of an immediate and urgent 463 need. The gains of a signed root zone have to be judged against the 464 added complexity of the signing step. 466 However, added complexity, in one form or another, is basically 467 unavoidable. It is possible to argue for or against implementation 468 details, but in the end the benefits of a signed root will have to 469 be compared against some amount of added complexity. If the cost or 470 risk of this complexity is deemed to be too high, then it is not 471 possible to sign the DNS root zone. If that is the conclusion; then 472 it is obviously important to reach it as soon as possible. 474 The same is true for the need for operational experience with a 475 signed root zone. There is no method of acquiring this experience 476 except by signing the root zone, so that is what is being proposed. 478 Some identified scenarios: 480 5.1. What will the consequences of a signed root zone be for old 481 resolver software? 483 Nameservers that are authoritative for signed zones only give out 484 these signatures when explicitly asked for them. Therefore, the 485 presence of signatures in the root zone will not have any impact at 486 all on the majority of resolvers on the Internet that does not 487 validate lookups. 489 5.2. What happens if a signing operator fails to sign the zone on 490 time? 492 Literally nothing. I.e. the root zone that is published will be the 493 version prior to the last change. This is not believed to be a 494 major problem, since all changes to the data in the root zone are 495 characterized by long overlaps in time. Furthermore every change is 496 preceded by an administrative process that takes several days or 497 even weeks. Because of this, a failure to install a new version of 498 the root zone for even so long as a day will not noticeably change 499 the turn-around time for changes in the root zone. 501 5.3. What happens if several signing operators by mistake sign the 502 same version? 504 Literally nothing. One signing operator will be first, according to 505 the mechanism designed to separate the different backup signing 506 operators described in 3.3.1. The signed zone published by this 507 operator will be the version of the signed root zone that all the 508 root nameservers pick up. 510 When the second signing operator signs the zone the serial number 511 in the zone will be unchanged, and therefore the root nameservers 512 will not pick this zone up but instead stay with the first version. 514 5.4. What happens if the unsigned zone is compromised between the 515 primary master and the signing primaries? 517 This is basically the same threat as the zone being compromised 518 between the primary master and the root servers in the traditional 519 unsigned case. To guard against this possibility every zone 520 transfer is already protected by a TSIG signature. 522 Because of this the root zone file cannot get transferred to the 523 signing primaries unless the transaction signature matches, thereby 524 proving that the zone contents are uncompromised. The consequence 525 is that if the zone transfers are somehow compromised in transit, 526 they will not get signed and therefore the published root zone will 527 remain the signed version of the last uncompromised transfer. 529 5.5. What are the security implications for the new "signing 530 primaries"? Will they not have to be as secure as the primary 531 master is now? 533 Yes. However, the entire root server system is based upon trust, 534 i.e. the entire Internet is trusting the present root server system 535 because there is no alternative to doing that. This proposal is not 536 about changing the need for trust in the root server system. It is 537 about providing a method of determining authenticity of data, 538 something that is presently missing. 540 The root operators are already trusted to provide a root server 541 system based upon secure servers lacking validation mechanisms. It 542 is therefore a bit difficult to argue for not trusting them to 543 provide an improved system that adds exactly the lacking validation 544 mechanisms on a basis of not trusting them to secure the servers 545 involved. In both cases trust is involved, the difference is that 546 in the latter case validation is possible. 548 Furthermore, the proposed signing primaries will not need to have 549 publicly known addresses (just as the present primary master is not 550 publicly known), nor will they need to be able to communicate with 551 anyone outside the well defined set of servers that are part of the 552 root server system. Because of this it will be significantly easier 553 to secure the signing primaries than the already present task of 554 securing the DNS root nameservers. 556 5.6. What happens if a Zone Signing Key is compromised? 558 If this happens it is necessary to do an emergency rollover of the 559 keyset that includes the compromised key. I.e. the old keyset (and 560 its signatures) is replaced by a new keyset containing new ZSKs but 561 the same, uncompromised, KSKs and its signatures. Then the root 562 zone is re-signed using one of the new Zone Signing Keys. 564 This problem is not unique to a signed root zone, it is inherent in 565 any activity involving cryptographic keys. 567 Also note that there will be no need to change any configuration in 568 the resolver end. The rollover is an entirely atomic operation 569 inside the management structure of the root zone. 571 5.7. What happens if a Key Signing Key is compromised? 573 Depending on the trust model used by individual validating 574 resolvers one of two things will happen. 576 Resolvers that through local policy have chosen to trust this KSK 577 alone will need to change their configuration to instead trust 578 other KSKs, either available from other KSK holders or a new 579 trusted key made available by the same KSK holder that held the 580 compromised key. 582 Resolvers that have chosen to require multiple signatures by KSKs 583 for the root zone will not have to do any emergency key rollover at 584 all, since validation of lookups will still work, based upon the 585 integrity of the other trusted keys that have not been compromised. 587 In the management end it is necessary to do an emergency rollover 588 of the keyset including the compromised key and the suggested 589 method is by switching to a keyset that only changes the 590 compromised KSK and the ZSKs and keeps all other KSKs. Such keysets 591 should be prepared and signed in advance. 593 The new signed keyset is added to the root zone and then the zone 594 is re-signed using one of the new Zone Signing Keys. In this case, 595 since a Key Signing Key is changed, every resolver that choose to 596 trust that KSK holder will over time have to configure the new key 597 to be able to validate lookups. 599 This problem is not unique to a signed root zone, it is inherent in 600 any activity involving cryptographic keys. 602 5.8. Does the out-of-band communication between the signing operators 603 and the RIRs holding the key-signing keys add a new failure mode? 605 Yes. The traditional DNSSEC design assumes that (for an arbitrary 606 zone, not particularly for the root zone) the key-signing key is 607 managed by the same entity that manages the operator keys and hence 608 no communication issue exists. 610 In this case it is important that the signing operators do not hold 611 the responsibility for the key-signing keys. The root server 612 operators should only act as a "publishing service" for the root 613 zone contents, not as the entity that verifies correctness of the 614 published data. 616 However, apart from established secure methods of out-of-band 617 communication being available, there is also the very real 618 possibility of managing these exchanges with actual eye-to-eye 619 contact. Representatives for the RIRs and the root server operators 620 already meet on a regular basis during IETF meetings and the 621 different RIR meetings. 623 6. Security Considerations 625 Signing the DNS root zone is all about security. A signed root zone 626 may aid applications and organizations all over the Internet in 627 improving their security by enabling validation of DNS lookups. 629 Signing the root zone does add a new management step and therefore 630 it is important to ensure that possible failures in this management 631 step does not leave the published root zone in a state that is 632 actually worse than the original unsigned state. 634 The various failure modes that have been identified all show this 635 property of not being any worse than the unsigned case. 637 There is however one scenario that changes drastically with the 638 proposed distributed signing scheme and that is the consequences of 639 one signing operator intentionally changing the contents of the 640 root zone prior to the actual signing. In the unsigned case this 641 will cause the root zone to become inconsistent (i.e. the responses 642 vary depending upon which server it comes from), while in the 643 signed case the root zone will remain consistent but with erroneous 644 data in it. 646 It is my belief (this is impossible to prove) that the risk of 647 human error among the operators, however small, is still far 648 greater than the risk of willful misconduct. Therefore, the 649 proposed design that enforces consistency among the roots, is 650 actually also an improvement in stability and security. 652 Se further section 4 for a more complete risk analysis. 654 7. IANA Considerations 656 NONE. 658 8. References 660 8.1. Normative. 662 [RFC2535] Domain Name System Security Extensions. D. Eastlake. 663 March 1999. 665 [RFC3090] DNS Security Extension Clarification on Zone Status. 666 E. Lewis. March 2001. 668 [RFC1995] Incremental Zone Transfer in DNS. M. Ohta. August 1996. 670 [RFC1996] A Mechanism for Prompt Notification of Zone Changes 671 (DNS NOTIFY). P. Vixie. August 1996. 673 [RFC2845] Secret Key Transaction Authentication for DNS (TSIG). 674 P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington. 675 May 2000. 677 8.2. Informative. 679 [RFC2930] Secret Key Establishment for DNS (TKEY RR). D. Eastlake. 680 September 2000. 682 [RFC3007] Secure Domain Name System (DNS) Dynamic Update. 683 B. Wellington. November 2000. 685 [RFC3008] Domain Name System Security (DNSSEC) Signing Authority. 686 B. Wellington. November 2000. 688 [RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System 689 (DNS). D. Eastlake 3rd. May 2001. 691 [RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad. 692 December 2001. 694 [RFC3226] DNSSEC and IPv6 A6 aware server/resolver message size 695 requirements. O. Gudmundsson. December 2001. 697 [Delegation-Signer] Delegation Signer Resource Record. 698 O. Gudmundsson. October 2002. Work In Progress. 700 [AXFR-clarify] draft-ietf-dnsext-axfr-clarify-NN.txt DNS Zone 701 Transfer Protocol Clarifications. A. Gustafsson. March 702 2002. Work In Progress. 704 [AD-secure] draft-ietf-dnsext-ad-is-secure-NN.txt Redefinition of 705 DNS AD bit. B. Wellington, O Gudmundsson. June 2002. 706 Work In Progress. 708 [Opt-In] draft-ietf-dnsext-dnssec-opt-in-NN.txt DNSSEC Opt-In 709 R. Arends, M Kosters, D. Blacka. June 2002. Work In 710 Progress. 712 [Wild-card-optimize] draft-olaf-dnsext-dnssec-wildcard- 713 optimization-NN.txt DNSSEC Wildcard optimization. 714 O. Kolkman, J. Ihren, R. Arends. September 2002. 715 Work In Progress. 717 [Threshold-Validation] 718 draft-ihren-dnsop-threshold-validation-00.txt Threshold 719 validation: A Mechanism for Improved Trust and Redundancy 720 for DNSSEC Keys. J. Ihren. February 2003. Work In 721 Progress. 723 9. Acknowledgments. 725 To help me produce this document I have received lots and lots of 726 comments from many people around the Internet with suggestions for 727 lots and lots sorely needed improvements. Among the folks who 728 helped out are, in no particular order: Paul Vixie, Bill Manning, 729 Ôlafur Gumundsson, Rob Austein, Patrik F„ltstr÷m, Olaf Kolkman, 730 Harald Alvestrand, Suzanne Woolf, John M. Brown, Lars-Johan Liman 731 and M…ns Nilsson. 733 10. Authors' Address 735 Johan Ihr‰n 736 Autonomica AB 737 Bellmansgatan 30 738 SE-118 47 Stockholm, Sweden 739 johani@autonomica.se