idnits 2.17.1 draft-mglt-dnsop-dnssec-validator-requirements-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 176 has weird spacing: '...lidator the e...' == Line 179 has weird spacing: '...idation valid...' == Line 182 has weird spacing: '...a Store a mod...' == Line 266 has weird spacing: '... Engine follo...' == Line 294 has weird spacing: '...dations which...' == (4 more instances...) -- The document date (April 29, 2020) is 1457 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop D. Migault 3 Internet-Draft Ericsson 4 Intended status: Informational E. Lewis 5 Expires: October 31, 2020 ICANN 6 D. York 7 ISOC 8 April 29, 2020 10 Recommendations for DNSSEC Resolvers Operators 11 draft-mglt-dnsop-dnssec-validator-requirements-09 13 Abstract 15 The DNS Security Extensions define a process for validating received 16 data and assert them authentic and complete as opposed to forged. 18 This document is focused clarifying the scope and responsibilities of 19 DNSSEC Resolver Operators (DRO) as well as operational 20 recommendations that DNSSEC validators operators SHOULD put in place 21 in order to implement sufficient Trust that makes DNSSEC validation 22 output accurate. The recommendations described in this document 23 include, provisioning mechanisms as well as monitoring and management 24 mechanisms. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 31, 2020. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. DNSSEC Validator Description . . . . . . . . . . . . . . . . 5 64 5. Recommendations Categories . . . . . . . . . . . . . . . . . 6 65 6. Time deviation and absence of Real Time Clock Recommendations 7 66 7. Trust Anchor Related Recommendations . . . . . . . . . . . . 8 67 7.1. Trust Anchor Configuration . . . . . . . . . . . . . . . 9 68 7.1.1. Definition of the Trust model . . . . . . . . . . . . 10 69 7.1.2. Trust Model Bootstrapping . . . . . . . . . . . . . . 11 70 7.1.3. Configuration Generation . . . . . . . . . . . . . . 12 71 7.1.4. DNSSEC Resolver Instantiation . . . . . . . . . . . . 12 72 7.2. Trust Anchor Update . . . . . . . . . . . . . . . . . . . 12 73 7.2.1. Automated Updates to DNSSEC Trust Anchors . . . . . . 13 74 7.2.2. Automated Trust Anchor Check . . . . . . . . . . . . 13 75 8. Negative Trust Anchors Related Recommendations . . . . . . . 14 76 9. ZSK / KSK (non TA) Related Recommendations . . . . . . . . . 16 77 10. DNSKEY Related Recommendations . . . . . . . . . . . . . . . 17 78 10.1. Automated Reporting . . . . . . . . . . . . . . . . . . 17 79 10.2. Interactions with the cached RRsets . . . . . . . . . . 18 80 11. Cryptography Deprecation Recommendations . . . . . . . . . . 18 81 12. Invalid Reporting Recommendations . . . . . . . . . . . . . . 19 82 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 83 14. Security Considerations . . . . . . . . . . . . . . . . . . . 19 84 15. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 20 85 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 16.1. Normative References . . . . . . . . . . . . . . . . . . 20 87 16.2. Informative References . . . . . . . . . . . . . . . . . 22 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 90 1. Requirements Notation 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in 95 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 96 capitals, as shown here. 98 2. Introduction 100 The purpose of DNSSEC Resolver Operator (DRO) is to enable DNSSEC 101 validation in their resolvers. The act of DNSSEC validation 102 [RFC4033][RFC4035] can be broken into two part: 104 1) Signature Validation: which consists in checking the cryptographic 105 signature of a Resource Record Set (RRset). The signature validation 106 involves among other parameters a DNSKEY Resource Record (RR) and 107 RRSIG RR and the RRset itself. The signature validation process 108 results in assertion that the owner of the private part of the public 109 key contained in the DNSKEY RR has effectively published the RRset. 110 The binding between the private key and the RRset is provided by the 111 trust that the private key used to generate the signature is known 112 only to the authorized party. (It's more likely that the key is 113 "exposed" or "guessed" than the algorithm "becomes broken.") 115 2) Trust: Signature Validation results in asserting a RRset is 116 accurately validated if there is sufficient trust that the owner of 117 the private key associated to the DNSKEY RR is the owner of the RRset 118 - i.e. that is to say is the legitimate owner. Such trust is 119 provided by a Trust Anchor (TA), and the chain of trust established 120 between the TA and the DNSKEY RR. The chain of trust is obtained by 121 recursively validating the DNSKEY RRs. As a result, such trust 122 results from the trust placed in the TA as well as the delegation 123 mechanism provided by DNSSEC and the Signature Validation. As TAs 124 need to be managed over time, the trust also concerns the management 125 procedure of the TA. This is the main concern of this document. 127 Data's authenticity and integrity is tied to the operator of the key 128 that generates the signature. It is conceivable that a validator 129 could "know" the keys of each data source, but this is not practical 130 at large scale. To counter this, DNSSEC relied on securely chaining 131 keys in a manner isomorphic to the way names are delegated. Keys for 132 a name will "vouch for" keys at a name delegated via the signing of a 133 DS resource record set. 135 Using keys to vouch for keys, recursively, works when a manageable 136 set of key to name associations are determined to be "trusted" - and 137 are called trust anchors. In DNSSEC, a validator needs one or more 138 Trust Anchors from which to grow chains of verified keys. 140 With operational experience, a twist has emerged. More often, to 141 date, failed validation is due to operator error and not an attempt 142 to forge data. In general badly signed RRsets or zone badly 143 delegated are out of scope of the DRO's responsibility. However, the 144 DRO may reflect this operational error with a temporary solution 145 designated as Negative Trust Anchors (NTA) [RFC7646]. A NTA 146 instructs a validator to ignore the presence of keys for a name, 147 reacting as if the name is unsigned. 149 Once accurately validated the RRset is assumed to be accurately 150 validated and trusted during the time indicated by its TTL. 152 The responsibilities of a DRO are limited to the management of TAs as 153 well as providing the necessary infrastructure to perform the 154 signature validation, e.g. appropriated libraries and time. More 155 specifically, badly signed zones or insertion of malicious DNSKEY 156 fall out of the DRO's responsibilities. Even though these threats 157 fall out of these responsibilities, a DRO may collaborate with 158 authoritative servers to limit the damage of their operational 159 errors. 161 This document is focused on operational recommendations that DRO 162 SHOULD put in place in order to implement sufficient trust that makes 163 DNSSEC validation output accurate. The recommendations described in 164 this document include, provisioning mechanisms as well as monitoring 165 and management mechanisms. 167 The mechanisms provided are designed in accordance of the DNSSEC 168 trust model as to meet the current operations of DNSSEC. Such trust 169 model is briefly recapped in Section 4 so operators understand the 170 limits and motivations for such mechanisms. 172 3. Terminology 174 This document uses the following terminology: 176 DNSSEC validator the entity that performs DNSSEC resolution and 177 performs signature validation. 179 Accurate validation validation that avoids false positives and 180 catches true negatives. 182 Trust Anchor Data Store a module (of code) implementing functions 183 related to the trust anchors used by the validator. This is 184 essentially a database allowing access, monitoring of, and changes 185 to trust anchors. 187 DNSSEC Resolver Operator (DRO) The operator providing DNSSEC 188 validation service and managing DNSSEC validators 190 4. DNSSEC Validator Description 192 This is a conceptual block diagram of the elements involved with 193 DNSSEC validation. This is not meant to be an architecture for code, 194 this is meant to be a framework for discussion and explanation. 196 +-------------+ +---------------+ 197 | | | | 198 | Time Source | | Cryptographic | 199 | | | Libraries | 200 | | | | 201 +-------------+ +---------------+ 202 | | 203 v v 204 +--------------------------------+ +--------------+ 205 | | | | 206 | |<--| Trust Anchor | 207 | DNSSEC Validation Engine | | Manager & | 208 | |-->| Storage | 209 | | | | 210 +--------------------------------+ +--------------+ 211 ^ | ^ | 212 | v | | 213 +-------------+ +---------------+ | 214 | | | | | 215 | DNS Caches | | DNS Messages |<---------+ 216 | | | | 217 +-------------+ +---------------+ 219 Figure 1: DNSSEC Validator Description 221 Time Source The wall clock time provides the DNSSEC Validation 222 Engine the current time. Time is among other used to validate the 223 RRSIG Signature and Inception Fields to provide some protection 224 against replay attacks. 226 Cryptograhic Libraries The code performing mathematical functions 227 provides the DNSSEC Validation Engine the ability to check the 228 Signature Field that contains the cryptographic signature covering 229 the RRSIG RDATA. 231 DNS Message DNS responses are used to carry the information from the 232 DNS system. The receiver of the DNS message can be any kind of 233 application including DNS-related application such as in the case 234 of automated Trust Anchor update performed by the Trust Anchor 235 Manager & Storage. The DNSSEC Validator Engine accurately 236 validates the DNS responses before caching them in the DNS Cache 237 and forwarding them to the DNS receiver. In case of validation 238 failure, an error is returned and the information may be 239 negatively cached. 241 DNS Caches Include positive and negative caches. The DNSSEC 242 Validation Engine fills DNS Caches with the results of a 243 validation (positive data, negative failures). The DNSSEC trust 244 model considers that once a RRset has been accurately validated by 245 the DNSSEC Validator Engine, the RRset is considered trusted (or 246 untrusted) for its associated TTL. DNS Caches contain RRsets that 247 may contain information requested by the application (RRset of 248 type AAAA for example) as well as RRset necessary to accurately 249 validate the RRsets (RRsets of type DNSKET or RRSIG for example). 250 It also worth noticing that RRset validated with DNSSEC or RRset 251 that are not validated with DNSSEC fill the DNS Cache with the 252 same level of trust. 254 Trust Anchor Manager The database of trust anchors associated to 255 database management processes. This function provides the DNSSEC 256 Validation Engine Trust Anchor information when needed. When TA 257 needs to be updated, the Trust Anchor Manager is also responsible 258 to handle the updating procedure. This includes sending DNS 259 Messages as well as treating appropriately the DNS responses that 260 have been accurately validated by the DNSSEC Validator Engine. 261 This will require the DNSSEC Validator to update Trust Anchor 262 information, whether via methods like Automated Updates of DNSSEC 263 Trust Anchors [RFC5011], management of Negative Trust Anchors, or 264 other, possibly not yet defined, means. 266 DNSSEC Validation Engine follows local policy to approve data. The 267 approved data is returned to the requesting application as well as 268 in the DNS Caches. While the cryptographic computation of the 269 RRSIG signature may be the most visible step, the RRSIG record 270 also contains other information intended to help the validator 271 perform its work, in some cases "sane value" checks are performed. 272 For instance, the original TTL (needed to prepare the RR set for 273 validation) ought to be equal to or higher than the received TTL. 275 Not shown - Name Server Process Management interfaces to elements, 276 handling of Checking Disabled request, responses, as well as all API 277 requests made of the name server. 279 5. Recommendations Categories 281 DRO needs to be able to enable DNSSEC validation with sufficient 282 confidence they will not be held responsible in case their resolver 283 does not validate the DNSSEC response. The minimization of these 284 risks is provided by setting automated procedures, when a resolver is 285 started or while it is operating, as well as some on-demand 286 operations that enable the DRO to perform a specific operation. The 287 recommendations do not come with the same level of requirements and 288 some are likely to be required. other are optional and may be 289 followed by more advanced DROs. 291 The RECOMMENDATIONS in this document are subdivided into the 292 following categories: 294 Start-up recommendations which describes RECOMMENDED operations the 295 DRO is expected to perform when the resolver is started. These 296 operations typically includes health check of the infrastructure 297 the resolver is instantiated on as well as configuration check. 299 Run time recommendations which describes RECOMMENDED operations the 300 DRO is expected to perform on its running resolvers. These 301 operations typically include health checks of the infrastructure 302 as well as the resolvers. 304 On demand recommendations which describes the RECOMMENDED operations 305 a DRO may perform. This includes the ability to operate health 306 check at a given time as well as specific operations such as 307 flushing the cache. The reason the document mentions these 308 recommendations is to enable DROs to have the appropriates tools 309 as well as to restrict their potential interventions. 311 6. Time deviation and absence of Real Time Clock Recommendations 313 With M2M communication some devices are not expected to embed Real 314 Time Clock (Raspberry Pi is one example of such devices). When these 315 devices are re-plugged the initial time is set to January 1 1970. 316 Other devices that have clocks that may suffer from time deviation. 317 These devices cannot rely on their time estimation to perform DNSSEC 318 validation. 320 Time synchronization may be performed manually, but for the sake of 321 operations it is strongly RECOMMENDED to automate the time 322 synchronization on each resolver. In addition, it is RECOMMENDED the 323 operator regularly proceed to sanity checks of its resolver and 325 START-UP REC: 327 o DRO MUST provide means to update the time without relying on 328 DNSSEC when the DNSSEC validator is started. The resolver MUST 329 NOT start if the time synchronization does not succeed at start 330 time. 332 Note that updating time in order to be able to perform DNSSEC 333 validation may become a form of a chicken-and-egg problem when the 334 NTP server is designated by its FQDN. The update mechanisms must 335 consider the DNSSEC validator may not able to validate the DNSSEC 336 queries. In other words, the mechanisms may have to update the time 337 over an unsecure DNSSEC resolution. 339 RUN TIME REC: 341 o While operating, DRO MUST closely monitor time derivations of the 342 resolvers and maintain the time synchronized. 344 ON DEMAND REC: 346 o A DRO SHOULD be able to check and synchronize, on demand, the time 347 of the system of its resolver. 349 Note that time synchronization is a sensible operation and DRO MUST 350 update the time of the systems over an authenticated and secure 351 channel. 353 For all recommendations, it is strongly RECOMMENDED that 354 recommendations are supported by automated processes. 356 7. Trust Anchor Related Recommendations 358 A TA store maintains associations between domain names and keys 359 (whether stored as in a DNSKEY resource record or a DS resource 360 record) and domain names whose key are to be ignored (negative trust 361 anchors). The TA store is essentially a simple database, storing the 362 positive trust anchors. Management of the TA can be done manually or 363 in an automated way. 364 Automatic management of the TA is RECOMMENDED and can be subdivided 365 into the following sub-categories: 367 1. 369 Initial TA provisioning that is the ability, for a DRO, to 370 ensure a starting resolver is automatically provisioned with 371 an up-to-date configuration. This includes the TA associated 372 to the trust model established by the DRO. 374 2. 376 TA update over time while the trust model may not evolve, the 377 cryptographic keys associated to the security entry points are 378 subject to change and thus TA needs to be updated over time. 379 A DRO needs to check TA updates properly. 381 3. 383 TA reporting The reporting of the TA used by the resolver is 384 made to the DRO as well as the authoritative servers which are 385 hold responsible for making their zone validated by DNSSEC 386 resolvers. 388 This section is only considering TA and not NTA. The handling of NTA 389 is detailed in section Section 8. 391 7.1. Trust Anchor Configuration 393 When a DRO starts a DNSSEC resolver, the DNSSEC resolver is generally 394 provisioned with a configuration file which contains the TAs. The 395 provisioned TA reflects a trust model, that is the definition of the 396 security entry points by the DRO, as well as the values associated to 397 these security entry points. The latest may change over time even 398 when the trust model of the DRO does not. As a result, the 399 envisioned way to configure the TA of a DNSSEC resolver is envisioned 400 as follows: 402 1. Trust model definition :The DRO defines the domain names that 403 constitutes security entry point (TA). (See Section 7.1.1 for 404 more details.) 406 2. 408 Trust model bootstrapping A bootstrapping procedure is applied 409 to each TA to retrieve in a trusted way the necessary values 410 associated to each TA. 411 (See Section 7.1.2 for more details.) 413 3. 415 DNSSEC resolver configuration generation The TA with associated 416 values are formatted appropriately for the DNSSEC resolver 417 that will be instantiated. (See Section 7.1.3 for more 418 details.) 420 4. 422 DNSSEC resolver instantiation The DNSSEC resolver is started, 423 performs some checks before becoming operational. (See 424 Section 7.1.4 for more details.) 426 The purpose of these steps is to prevent that a resolver is started 427 with a deprecated or invalid configuration. The DRO MUST ensure this 428 cannot happen as well as this will be detected if this were 429 happening. 431 Note that a simple implementation of these recommendations includes a 432 DRO that uses the default trust model with the root zone as the 433 single TA. The TA is provisioned by software update in the 434 configuration file and checked at start-up. In such case the trust 435 of the bootstrapping relies on the code signing key of the software 436 provider. 438 More complex trust model would require more complex operation though. 440 7.1.1. Definition of the Trust model 442 The DRO defines its trust model by explicitly mentioning the domain 443 name that constitutes security entry point as well as domain name 444 that are known to be unsecured. 446 This document does not provide recommendations regarding the number 447 of TA a DRO needs to configure its DNSSEC resolver with. 448 There are many reasons a DRO may be willing to consider multiple TAs 449 as opposed to a single Root Zone Trust Anchor. 450 In fact it is not always possible to build a trusted delegation 451 between the Root Zone and any sub zone. 452 This may happen for example if one of the upper zones does not handle 453 the secure delegation or improperly implement it. A DS RRset may not 454 be properly filled or its associated signature cannot be validated. 455 As the chain of trust between a zone and the root zone may not be 456 validated, the DNSSEC validation for the zone requires a TA. 457 Such DNS(SEC) resolutions may be critical for infrastructure 458 management. 459 A company "Example" may, for example, address all its devices under 460 the domain example.com and may not want disruption to happen if the 461 .com delegation cannot be validated for any reason. 462 Such companies may operate DNSSEC with a TA for the zone example.com 463 in addition to the regular DNSSEC delegation. 464 Similarly some some domains may present different views such as a 465 "private" view and a "public view". 466 These zones may have some different content, and may use a different 467 KSK for each view. 469 The domain name chosen as security entry point may overlap themselves 470 such as example.com and .com for example. The TA associated to a 471 domain name is determined by the longest match. However, the trust 472 model must at least ensure that any domain name in the DNS be related 473 to a TA. As the number of top level domains is evolving overtime, it 474 remains safe to keep the root zone as a security entry point in order 475 to cover the full domain name space. 477 The default trust model consists in the root zone as a security entry 478 point, and no zones being considered as unsecured. 480 7.1.2. Trust Model Bootstrapping 482 The definition of the Retrieval by a third party software of the TA 483 associated to the security entry points defined in a). The purpose 484 is clearly to retrieve DNSKEY as well as DS RRsets with a valid 485 RDATA. This third party software clearly aim at instantiating the 486 trust model. The retrieval of the corresponding value may be 487 performed via various ways that are usually expected a pre- 488 established trusted relationship between the DRO and the publisher of 489 the RRsets. 491 Although some bootstrapping mechanisms to securely retrieve publish 492 [RFC7958] and retrieve [UNBOUND-ANCHOR] the Root Zone Trust Anchor 493 have been defined, it is believed these mechanisms should be extended 494 to other KSKs or Trust Anchors. Such bootstrapping process enables a 495 DRO to start a DNSSEC resolver from a configuration file, that 496 reflects the trust model of the DRO. 498 START-UP REC: 500 o DRO SHOULD only rely on TA associated with a bootstrapping 501 mechanism. 503 7.1.2.1. IANA Trust Anchor Bootstrapping 505 For validators that may be used on the global public Internet (with 506 "may be" referring to general purpose, general release code), 507 handling the IANA managed root zone KSK trust anchor is a 508 consideration. 510 The IANA managed root zone KSK is an operationally significant trust 511 point in the global public Internet. Attention to the trust anchor 512 for this point is paramount. Trust anchor management ought to 513 recognize that the majority of operators deploying DNSSEC validators 514 will need to explicitly or implicitly rely on this trust anchor. 515 Trust anchor management needs to recognize that there may be other 516 trust anchors of interest to operators. Besides deployments in 517 networks other than the global public Internet (hence a different 518 root), operators may want to configure other trust points. 520 The IANA managed root zone KSK is managed and published as described 521 in "DNSSEC Trust Anchor Publication for the Root Zone" [RFC7598]. 522 That document is written as specific to that trust point. 523 Other trust points may adopt the technique describe (or may use other 524 approaches). 526 This represents a consideration for implementations. 528 On one hand, operators will place special emphasis on how the root 529 zone DNSSEC KSK is managed. 530 On the other hand, implementations ought to accommodate trust anchors 531 in a general manner, despite the odds that other trust anchors will 532 not be configured in a specific deployment. 534 Because of this, it is recommended that implementations make the root 535 zone trust anchor obvious to the operator while still enabling 536 configuration of general trust points. 538 7.1.3. Configuration Generation 540 The generation of a configuration file associated to the TA is 541 expected to be implementation independent. The necessity of tweaking 542 the data depending of the software implementer or eventually the 543 software version introduces a vector for configuration errors. 545 7.1.4. DNSSEC Resolver Instantiation 547 START-UP REC: 549 o DNS resolver MUST validate the TA before starting the DNSSEC 550 resolver, and a failure of TA validity check MUST prevent the 551 DNSSEC resolver to be started. Validation of the TA includes 552 coherence between out-out band values, values stored in the DNS as 553 well as corresponding DS RRsets. 555 7.2. Trust Anchor Update 557 Updating the TA reflects the evolution of the trust. It is important 558 to understand that this section does not consider the trust model to 559 be updated by the DRO. This has been defined in section Section 7.1. 560 Instead, it considered the evolution over time of the instantiation 561 of the trust model, that is the update of the values associated to 562 the TA. 563 Such updates need to be operated in a reliable and trusted way. 565 The value associated to the TA may be updated over time which is part 566 of the maintenance of the configuration and needs to be performed by 567 the DNSSEC resolver without any intervention of the DRO. This is the 568 purpose of this section. 570 TA update is expected to be transparent to the DRO (see 571 Section 7.2.1. However, a DRO MAY wish to ensure its resolvers 572 operate according to the provisioned configurations and are updated 573 normally (see Section 7.2.2. This includes for a DRO the ability to 574 check which TA are in used as well as to resolve in collaboration of 575 authoritative servers and report the used TAs. 577 7.2.1. Automated Updates to DNSSEC Trust Anchors 579 Trust is inherently a matter of an operations policy. As such, a DRO 580 will need to be able to update the list of Trust Anchors. TA updates 581 is not expected to be handled manually. 582 This introduces a potentially huge vector for configuration errors, 583 but due to human intervention as well as potential misunderstanding 584 of ongoing operations. 586 START-UP REC: 588 o DRO SHOULD enable "Automated Updates to DNSSEC Trust Anchors" 589 [RFC5011] [I-D.ietf-dnsop-rfc5011-security-considerations]. 591 7.2.2. Automated Trust Anchor Check 593 A DRO SHOULD regularly check the trust anchor used by the DNSSEC 594 resolver is up-to-date and that values used by the resolvers are 595 conform to the ones in the configuration (see Section 7.1). Such 596 check is designated as TA health check. 598 Note that retrieving in an automated way the value of the TA removes 599 old values from the configuration and ensures that resolvers are 600 always started with up-to-date values. In the case of a key roll 601 over, the resolver is moving from an old value to an up-to date 602 value. This up-to-date value does not need to survive reboot, and 603 there is no need to update the configuration file - configuration is 604 updated by a separate process. To put it in other words, the updated 605 value of the TA is only expected to be stored in the resolver's 606 memory. Not updating the configuration file prevents a failed 607 synchronization to to the absence of write permission that are hardly 608 in the control of the software. 610 The TA used by a resolver may be part of a configuration parameter as 611 well as part of an internal state of the resolver. It is NOT 612 RECOMMENDED a DRO accesses configuration or internal state of a 613 resolver as it may open the resolver to other vulnerabilities and 614 provides privileged access to a potential attacker. 616 START-UP REC: 618 o DRO SHOULD enable "Signaling Trust Anchor Knowledge in DNS 619 Security Extensions (DNSSEC)" [RFC8145] to provide visibility to 620 the TA used by the resolver. The TA can be queries using a DNS 621 KEY query. The channel MAY be protected and restricted to the 622 DRO. 624 Note also that [RFC8145] does not only concerns Trust Anchor but is 625 instead generic to DNSKEY RRsets. As a result, unless for the root 626 zone, it is not possible to determine if the KSK/ZSK or DS is a Trust 627 Anchor or a KSK/ZSK obtained from regular DNSSEC resolutions. 629 TA health check includes validating DNSKEY RRsets and associated DS 630 RRsets in the resolver, on the DNS authoritative servers as well as 631 those obtained out-of-band. 632 TA health check results MUST be logged. The check SHOULD evaluate if 633 the mismatch result from an ongoing normal roll over, a potential 634 emergency key roll over, failed roll over or any other envisioned 635 cases. 636 Conflicts are not inherently a problem as some keys may be withheld 637 from distribution via the DNS. 638 A failed key roll over or any other abnormal situation MUST trigger 639 an alarm. 641 RUN TIME REC: 643 o A DRO SHOULD regularly run TA health checks. 645 If the mismatch is due to a failed key roll-over, this SHOULD be 646 considered as a bug by the DRO. The DRO MUST restart the resolver 647 with updated TA. 649 ON DEMAND REC: 651 o A DRO SHOULD be able to check the status of a TA 653 8. Negative Trust Anchors Related Recommendations 655 When the DNSSEC Resolver is not able to validate signatures because a 656 key or DS has been published with an error, the DNSSEC Operator MAY 657 temporarily disable the signature check for that key the time the 658 error is addressed. This is performed using NTA[RFC7646]. NTA 659 represents the only permitted intervention in the resolving process 660 for a DRO. 662 NTA are considered as temporary fix for a known unsecured domain, 663 which is different from an TA that would not be trusted. The 664 designation of NTA might be misleading, but NTA are not expected to 665 be part of the trust model. This does not prevents a DRO to 666 provision NTA as a configuration parameters NTA. The management of 667 the configuration SHOULD be automated as described in Section 7.1. 669 Handling NTA is described in "Definition and Use of DNSSEC Negative 670 Trust Anchors" [RFC7646] and a DRO SHOULD follow these guidelines. 672 The intent of this section is to position these guidelines toward the 673 operational recommendations provided in this document. 675 START-UP REC: 677 o DRO SHOULD be able to automatically configure NTA when starting 678 DNSSEC resolvers. 680 ON DEMAND REC: 682 o DRO SHOULD set automated procedures to determine the NTA of DNSSEC 683 resolvers. 685 o DRO SHOULD be able to handle NTA as defined in "Definition and Use 686 of DNSSEC Negative Trust Anchors" [RFC7646]. 688 Note that adding a Negative Trust Anchor only requires the domain 689 name to be specified. Note also that NTA can disable any sort of 690 DNSKEY and is not restricted to TA. 692 A failure in signaling validation is associated to a mismatch between 693 the key and the signature. DNSKEY/DS RRsets for TA have a higher 694 level of trust then regular KSK/ZSK. In addition, DRO are likely to 695 have specific communication channel with TA maintainer which eases 696 trouble shooting. 698 A signature validation failure is either an attack or a failure into 699 the signing operation on the authoritative servers. The DRO is 700 expected to confirm this off line before introducing the Negative 701 Trust Anchor. This is likely to happen via a human confirmation. As 702 a result here are the following recommendations: 704 RUN TIME REC: 706 o DRO SHOULD monitor the number of signature failure associated to 707 each DNSKEY. These number are only hints and MUST NOT trigger 708 automated insertion of NTA. 710 o A DRO MAY collect additional information associated each DNSKEY 711 RRSets. 712 This information may be useful to follow-up roll over when these 713 happen and evaluate when a key roll over is not performed 714 appropriately on the resolver side or on the authoritative server. 715 It would provide some means to the DRO to take action with full 716 knowledge without necessary asking for a confirmation. In other 717 cases it could prevent invalidation to happen. These check may be 718 performed for a limited subset of domains or generalized. 720 9. ZSK / KSK (non TA) Related Recommendations 722 KSK / ZSK are not part of the DNSSEC validator configuration. Their 723 values in the DNS Caches may not reflect those published by the 724 authoritative servers or may be incoherent with the RRset in the DNS 725 Cache they are validating. However, such incoherence primary results 726 from error in the management of the authoritative servers. As a 727 result, it is not expected that the DNSSEC validator provides complex 728 management facilities to address these issues as this will modify the 729 DNS architecture and add complexity that is not proved to be 730 beneficial. 732 As a result, recommendations always belong to the run time of on 733 demand category of recommendations. The main difference between TA 734 and KSK/ZSK is that the DRO does not necessarily have an out of band 735 mechanism to retrieve the RRsets. As a result, the DRO has less 736 information to determine and confirm what is happening. The default 737 recommendation is to let things go. 739 A number of reasons may result in inconsistencies between the RRsets 740 stored in the cache and those published by the authoritative server. 742 An emergency KSK / ZSK rollover may result in a new KSK / ZSK with 743 associated new RRSIG published in the authoritative zone, while 744 DNSSEC validator may still cache the old value of the ZSK / KSK. 745 For a RRset not cached, the DNSSEC validator performs a DNSSEC query 746 to the authoritative server that returns the RRset signed with the 747 new KSK / ZSK. The DNSSEC validator may not be able to retrieve the 748 new KSK / ZSK while being unable to validate the signature with the 749 old KSK / ZSK. This either result in a bogus resolution or in an 750 invalid signature check. 751 Note that by comparing the Key Tag Fields, the DNSSEC validator is 752 able to notice the new KSK / ZSK used for signing differs from the 753 one used to generate the received generated signature. 754 However, the DNSSEC validator is not expected to retrieve the new ZSK 755 / KSK, as such behavior could be used by an attacker. Instead, ZSK / 756 KSK key roll over procedures are expected to avoid such 757 inconsistencies. 759 Similarly, a KSK / ZSK roll over may be performed normally, that is 760 as described in [RFC6781] and [RFC7583]. While the KSK / ZSK roll 761 over is performed, there is no obligation to flush the RRsets in the 762 cache that have been associated with the old key. In fact, these 763 RRset may still be considered as trusted and be removed from the 764 cache as their TTL timeout. 765 With very long TTL, these RRsets may remain in the cache while the 766 ZSK / KSK with a shorter TTL is no longer published nor in the cache. 767 In such situations, the purpose of the KSK / ZSK used to validate the 768 data is considered trusted at the time it enters the cache, and such 769 trust may remain after the KSK / ZSK is being rolled over. Note also 770 that even though the data may not be associated to the KSK / ZSK that 771 has been used to validate the data, the link between the KSK / ZSK 772 and the data is still stored in the cache using the RRSIG. Note also 773 that inconsistencies between the ZSK / KSK stored in the cache and 774 those published on the authoritative server, may lead to 775 inconsistencies to downstream DNSSEC validators that rely on multiple 776 cache over time. 778 Typically, a request for the KSK / ZSK may have been provided by a 779 cache that is storing the new published value, while the data and 780 associated signatures may be associated to the old KSK / ZSK. 782 Incoherence between RRsets and DNSKEYs is not the responsibility of 783 the DRO, but instead it is the responsibility of authoritative server 784 publishing these data. A DRO may however limit the risks for these 785 inconsistencies to happen by configuring the DNSSEC validator with 786 generic rules that applies to the validation process. Typically, the 787 TTL associate to the DNSKEY is an engagement from the authoritative 788 server that the DNSKEY will remain valid over this period. As this 789 engagement supersedes the validation of any RRSIG and by extension to 790 any RRset in the zone, this TTL value may be used as the maximum 791 value for the TTL associated to FQDNs in the zone. This would at 792 least reduce inconsistencies during regular KSK roll over. In 793 addition, the DNSSEC validator should also be able to provide a 794 maximum values for TTLs. 796 RUN TIME REC: 798 o To limit the risks of incoherent data in the cache, it is 799 RECOMMENDED DRO enforce TTL policies of RRsets based on the TTL of 800 the DS, KSK and ZSK. RRsets TTL SHOULD NOT exceed the DS, KSK or 801 ZSK initial TTL value, that TTL SHOULD trigger delegation 802 revalidation as described in [I-D.huque-dnsop-ns-revalidation]. 804 10. DNSKEY Related Recommendations 806 This section considers the recommendations that are common to TA as 807 well as non TA DNSKEY RRsets. 809 10.1. Automated Reporting 811 A DRO MAY regularly report the Trust Anchor used to the authoritative 812 server. This would at least provide insight to the authoritative 813 server and provide it some context before moving a key roll over 814 further. 816 The purpose of reporting the currently used Trust Anchor for a domain 817 name is to establish an informational channel between the resolver 818 and the authoritative server. This data may not directly be useful 819 for the DNSSEC Resolver, but instead to the authoritative server. In 820 return it is likely the authoritative server will take the 821 appropriated steps in operating the authoritative server and consider 822 this information. As a result, 824 RUNNING REC: 826 o A DRO SHOULD enable TA reporting to the authoritative server as 827 specified in "Signaling Trust Anchor Knowledge in DNS Security 828 Extensions (DNSSEC)" [RFC8145] 830 10.2. Interactions with the cached RRsets 832 The purpose of automated checks is to enable early detection of 833 failed operations, which provides enough time to the DRO to react 834 without any consequences. On the other hand, these checks MAY reveal 835 as well that a rogue TA has been placed and that the resolver is 836 corrupted. Similarly, a DRO may be informed by other channel a rogue 837 or unwilling DNSKEY has been emitted. 839 In such situation, the DRO SHOULD be able to remove the RRsets 840 validated by the rogue DNSKEY. 842 ON DEMAND REC: 844 o A DRO MUST be able to flush the cached data associated to a DNSKEY 846 11. Cryptography Deprecation Recommendations 848 As mentioned in [RFC8247] and [RFC8221] cryptography used one day is 849 expected over the time to be replaced by new and more robust 850 cryptographic mechanisms. In the case of DNSSEC signature protocols 851 are likely to be updated over time. In order to anticipate the 852 sunset of one of the signature scheme, a DNSSEC validator may willing 853 to estimate the impact of deprecating one signature scheme. 855 Currently [RFC6975] provides the ability for a DNSSEC validator to 856 announce an authoritative server the supported signature schemes. 857 However, a DNSSEC validator is not able to determine other than by 858 trying whether a signature scheme is supported by the authoritative 859 server. 861 To safely deprecate one signature scheme, the DNSSEC validator 862 operator is expected to follow the recommendation below: 864 RUN TIME REC: 866 o A DNSSEC validator operator SHOULD regularly request and monitor 867 the signature scheme supported by an authoritative server. 869 12. Invalid Reporting Recommendations 871 A DNSSEC validator receiving a DNS response cannot make the 872 difference between receiving an non-secure response versus an attack. 873 Dropping DNSSEC fields by a misconfigured middle boxes, such as DS, 874 RRRSIG is considered as an attack. A DNSSEC validator is expected to 875 perform secure DNS resolution and as such protect its stub client. 876 An invalid response may be the result of an attack or a 877 misconfiguration, and the DNSSEC validator may play an important role 878 in sharing this information. 880 RUN TIME REC: 882 o DRO SHOULD monitor and report the unavailability of the DNSSEC 883 service. 885 RUN TIME REC: 887 o DRO SHOULD monitor and report an invalid DNSSEC validation. 889 13. IANA Considerations 891 There are no IANA consideration for this document. 893 14. Security Considerations 895 The recommendations listed in this document have two goals. First 896 ensuring the DNSSEC validator has appropriated information to 897 appropriately perform DNSSEC validation. Second, monitoring the 898 necessary elements that would enable a DNSSEC validator operator to 899 ease a potential analysis. 900 The recommendations provide very limited ability for a DNSSEC 901 validator operator to alter or directly interfere on the validation 902 process and the main purpose in providing the recommendations was to 903 let the protocol run as much as possible. Providing inappropriate 904 information can lead to misconfiguring the DNSSEC validator, and thus 905 disrupting the DNSSEC resolution service. As a result, enabling the 906 setting of configuration parameters by a third party may open a wide 907 surface of attacks. In addition, such changes may lead to unexpected 908 corner cases that would result in making analysis and trouble 909 shooting very hard. 911 As an appropriate time value is necessary to perform signature check, 912 an attacker may provide rogue time value to prevent the DNSSEC 913 validator to check signatures. 915 An attacker may also affect the resolution service by regularly 916 asking the DNSSEC validator to flush the KSK/ZSK from its cache. All 917 associated data will also be flushed. This generates additional 918 DNSSEC resolution and additional validations, as RRSet that were 919 cached require a DNSSEC resolution over the Internet. This affects 920 the resolution service by slowing down responses, and increases the 921 load on the DNSSEC validator. 923 An attacker may ask the DNSSEC validator to consider a rogue KSK/ZSK, 924 thus hijacking the DNS zone. Similarly, an attacker may inform the 925 DNSSEC validator not to trust a given KSK in order to prevent DNSSEC 926 validation to be performed. 928 An attacker (cf. Section 7) can advertise a "known insecure" KSK or 929 ZSK is "back to secure" to prevent signature check to be performed 930 correctly. 932 As a result, information considered by the DNSSEC validator should be 933 from a trusted party. This trust party should have been 934 authenticated, and the channel used to exchange the information 935 should also be protected and authenticated. 937 15. Acknowledgment 939 The need to address DNSSEC issues on the resolver side started in the 940 Home Networks mailing list and during the IETF87 in Berlin. Among 941 others, people involved in the discussion were Ted Lemon, Ralph 942 Weber, Normen Kowalewski, and Mikael Abrahamsson. People involved in 943 the email discussion initiated by Jim Gettys were, with among others, 944 Paul Wouters, Joe Abley and Michael Richardson. 946 The current document has been initiated after a discussion with Paul 947 Wouter and Evan Hunt. 949 16. References 951 16.1. Normative References 953 [I-D.huque-dnsop-ns-revalidation] 954 Huque, S., Vixie, P., and R. Dolmans, "Delegation 955 Revalidation by DNS Resolvers", draft-huque-dnsop-ns- 956 revalidation-01 (work in progress), March 2020. 958 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 959 Requirement Levels", BCP 14, RFC 2119, 960 DOI 10.17487/RFC2119, March 1997, 961 . 963 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 964 Rose, "DNS Security Introduction and Requirements", 965 RFC 4033, DOI 10.17487/RFC4033, March 2005, 966 . 968 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 969 Rose, "Protocol Modifications for the DNS Security 970 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 971 . 973 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 974 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 975 September 2007, . 977 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 978 Operational Practices, Version 2", RFC 6781, 979 DOI 10.17487/RFC6781, December 2012, 980 . 982 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic 983 Algorithm Understanding in DNS Security Extensions 984 (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, 985 . 987 [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, 988 "DNSSEC Key Rollover Timing Considerations", RFC 7583, 989 DOI 10.17487/RFC7583, October 2015, 990 . 992 [RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J., 993 and R. Weber, "Definition and Use of DNSSEC Negative Trust 994 Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015, 995 . 997 [RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust 998 Anchor Knowledge in DNS Security Extensions (DNSSEC)", 999 RFC 8145, DOI 10.17487/RFC8145, April 2017, 1000 . 1002 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1003 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1004 May 2017, . 1006 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 1007 Kivinen, "Cryptographic Algorithm Implementation 1008 Requirements and Usage Guidance for Encapsulating Security 1009 Payload (ESP) and Authentication Header (AH)", RFC 8221, 1010 DOI 10.17487/RFC8221, October 2017, 1011 . 1013 [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, 1014 "Algorithm Implementation Requirements and Usage Guidance 1015 for the Internet Key Exchange Protocol Version 2 (IKEv2)", 1016 RFC 8247, DOI 10.17487/RFC8247, September 2017, 1017 . 1019 16.2. Informative References 1021 [I-D.ietf-dnsop-rfc5011-security-considerations] 1022 Hardaker, W. and W. Kumari, "Security Considerations for 1023 RFC5011 Publishers", draft-ietf-dnsop-rfc5011-security- 1024 considerations-13 (work in progress), July 2018. 1026 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 1027 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 1028 Configuration of Softwire Address and Port-Mapped 1029 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 1030 . 1032 [RFC7958] Abley, J., Schlyter, J., Bailey, G., and P. Hoffman, 1033 "DNSSEC Trust Anchor Publication for the Root Zone", 1034 RFC 7958, DOI 10.17487/RFC7958, August 2016, 1035 . 1037 [UNBOUND-ANCHOR] 1038 "unbound-anchor - Unbound anchor utility", n.d., 1039 . 1042 Authors' Addresses 1044 Daniel Migault 1045 Ericsson 1046 8275 Trans Canada Route 1047 Saint Laurent, QC 4S 0B6 1048 Canada 1050 EMail: daniel.migault@ericsson.com 1051 Edward Lewis 1052 ICANN 1054 EMail: edward.lewis@icann.org 1056 Dan York 1057 ISOC 1059 EMail: york@isoc.org