idnits 2.17.1 draft-mglt-dnsop-dnssec-validator-requirements-08.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 173 has weird spacing: '...lidator the e...' == Line 176 has weird spacing: '...idation valid...' == Line 179 has weird spacing: '...a Store a mod...' == Line 263 has weird spacing: '... Engine follo...' == Line 291 has weird spacing: '...dations which...' == (2 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 17, 2019) is 1621 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 8 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: May 20, 2020 ICANN 6 D. York 7 ISOC 8 November 17, 2019 10 Operational recommendations for management of DNSSEC Validator 11 draft-mglt-dnsop-dnssec-validator-requirements-08 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 May 20, 2020. 43 Copyright Notice 45 Copyright (c) 2019 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. IANA Trust Anchor Bootstrapping . . . . . . . . . . . 10 69 7.2. Trust Anchor Update . . . . . . . . . . . . . . . . . . . 11 70 7.2.1. Automated Updates to DNSSEC Trust Anchors . . . . . . 11 71 7.2.2. Automated Trust Anchor Check . . . . . . . . . . . . 12 72 8. ZSK / KSK (non TA) Related Recommendations . . . . . . . . . 13 73 9. DNSKEY Related Recommendations . . . . . . . . . . . . . . . 14 74 9.1. Automated Reporting . . . . . . . . . . . . . . . . . . . 15 75 9.2. Negative Trust Anchors . . . . . . . . . . . . . . . . . 15 76 9.3. Interactions with the cached RRsets . . . . . . . . . . . 16 77 10. Cryptography Deprecation Recommendations . . . . . . . . . . 16 78 11. Invalid Reporting Recommendations . . . . . . . . . . . . . . 17 79 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 80 13. Security Considerations . . . . . . . . . . . . . . . . . . . 17 81 14. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 18 82 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 15.1. Normative References . . . . . . . . . . . . . . . . . . 19 84 15.2. Informative References . . . . . . . . . . . . . . . . . 20 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 87 1. Requirements Notation 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 91 "OPTIONAL" in this document are to be interpreted as described BCP 14 92 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 93 as shown here. 95 2. Introduction 97 The purpose of DNSSEC Resolver Operator (DRO) is to enable DNSSEC 98 validation in their resolvers. The act of DNSSEC validation 99 [RFC4033][RFC4035] can be broken into two part: 101 1) Signature Validation: which consists in checking the cryptographic 102 signature of a Resource Record Set (RRset). The signature validation 103 involves among other parameters a DNSKEY Resource Record (RR) and 104 RRSIG RR and the RRset itself. The signature validation process 105 results in assertion that the owner of the private part of the public 106 key contained in the DNSKEY RR has effectively published the RRset. 107 The binding between the private key and the RRset is provided by the 108 trust that the private key used to generate the signature is known 109 only to the authorized party. (It's more likely that the key is 110 "exposed" or "guessed" than the algorithm "becomes broken.") 112 2) Trust: Signature Validation results in asserting a RRset is 113 accurately validated if there is sufficient trust that the owner of 114 the private key associated to the DNSKEY RR is the owner of the RRset 115 - i.e. that is to say is the legitimate owner. Such trust is 116 provided by a Trust Anchor (TA), and the chain of trust established 117 between the TA and the DNSKEY RR. The chain of trust is obtained by 118 recursively validating the DNSKEY RRs. As a result, such trust 119 results from the trust placed in the TA as well as the delegation 120 mechanism provided by DNSSEC and the Signature Validation. As TAs 121 need to be managed over time, the trust also concerns the management 122 procedure of the TA. This is the main concern of this document. 124 Data's authenticity and integrity is tied to the operator of the key 125 that generates the signature. It is conceivable that a validator 126 could "know" the keys of each data source, but this is not practical 127 at large scale. To counter this, DNSSEC relied on securely chaining 128 keys in a manner isomorphic to the way names are delegated. Keys for 129 a name will "vouch for" keys at a name delegated via the signing of a 130 DS resource record set. 132 Using keys to vouch for keys, recursively, works when a manageable 133 set of key to name associations are determined to be "trusted" - and 134 are called trust anchors. In DNSSEC, a validator needs one or more 135 Trust Anchors from which to grow chains of verified keys. 137 With operational experience, a twist has emerged. More often, to 138 date, failed validation is due to operator error and not an attempt 139 to forge data. In general badly signed RRsets or zone badly 140 delegated are out of scope of the DRO's responsibility. However, the 141 DRO may reflect this operational error with a temporary solution 142 designated as Negative Trust Anchors (NTA) [RFC7646]. A NTA 143 instructs a validator to ignore the presence of keys for a name, 144 reacting as if the name is unsigned. 146 Once accurately validated the RRset is assumed to be accurately 147 validated and trusted during the time indicated by its TTL. 149 The responsibilities of a DRO are limited to the management of TAs as 150 well as providing the necessary infrastructure to perform the 151 signature validation, e.g. appropriated libraries and time. More 152 specifically, badly signed zones or insertion of malicious DNSKEY 153 fall out of the DRO's responsibilities. Even though these threats 154 fall out of these responsibilities, a DRO may collaborate with 155 authoritative servers to limit the damage of their operational 156 errors. 158 This document is focused on operational recommendations that DRO 159 SHOULD put in place in order to implement sufficient trust that makes 160 DNSSEC validation output accurate. The recommendations described in 161 this document include, provisioning mechanisms as well as monitoring 162 and management mechanisms. 164 The mechanisms provided are designed in accordance of the DNSSEC 165 trust model as to meet the current operations of DNSSEC. Such trust 166 model is briefly recapped in Section 4 so operators understand the 167 limits and motivations for such mechanisms. 169 3. Terminology 171 This document uses the following terminology: 173 DNSSEC validator the entity that performs DNSSEC resolution and 174 performs signature validation. 176 Accurate validation validation that avoids false positives and 177 catches true negatives. 179 Trust Anchor Data Store a module (of code) implementing functions 180 related to the trust anchors used by the validator. This is 181 essentially a database allowing access, monitoring of, and changes 182 to trust anchors. 184 DNSSEC Resolver Operator (DRO) The operator providing DNSSEC 185 validation service and managing DNSSEC validators 187 4. DNSSEC Validator Description 189 This is a conceptual block diagram of the elements involved with 190 DNSSEC validation. This is not meant to be an architecture for code, 191 this is meant to be a framework for discussion and explanation. 193 +-------------+ +---------------+ 194 | | | | 195 | Time Source | | Cryptographic | 196 | | | Libraries | 197 | | | | 198 +-------------+ +---------------+ 199 | | 200 v v 201 +--------------------------------+ +--------------+ 202 | | | | 203 | |<--| Trust Anchor | 204 | DNSSEC Validation Engine | | Manager & | 205 | |-->| Storage | 206 | | | | 207 +--------------------------------+ +--------------+ 208 ^ | ^ | 209 | v | | 210 +-------------+ +---------------+ | 211 | | | | | 212 | DNS Caches | | DNS Messages |<---------+ 213 | | | | 214 +-------------+ +---------------+ 216 Figure 1: DNSSEC Validator Description 218 Time Source The wall clock time provides the DNSSEC Validation 219 Engine the current time. Time is among other used to validate the 220 RRSIG Signature and Inception Fields to provide some protection 221 against replay attacks. 223 Cryptograhic Libraries The code performing mathematical functions 224 provides the DNSSEC Validation Engine the ability to check the 225 Signature Field that contains the cryptographic signature covering 226 the RRSIG RDATA. 228 DNS Message DNS responses are used to carry the information from the 229 DNS system. The receiver of the DNS message can be any kind of 230 application including DNS-related application such as in the case 231 of automated Trust Anchor update performed by the Trust Anchor 232 Manager & Storage. The DNSSEC Validator Engine accurately 233 validates the DNS responses before caching them in the DNS Cache 234 and forwarding them to the DNS receiver. In case of validation 235 failure, an error is returned and the information may be 236 negatively cached. 238 DNS Caches Include positive and negative caches. The DNSSEC 239 Validation Engine fills DNS Caches with the results of a 240 validation (positive data, negative failures). The DNSSEC trust 241 model considers that once a RRset has been accurately validated by 242 the DNSSEC Validator Engine, the RRset is considered trusted (or 243 untrusted) for its associated TTL. DNS Caches contain RRsets that 244 may contain information requested by the application (RRset of 245 type AAAA for example) as well as RRset necessary to accurately 246 validate the RRsets (RRsets of type DNSKET or RRSIG for example). 247 It also worth noticing that RRset validated with DNSSEC or RRset 248 that are not validated with DNSSEC fill the DNS Cache with the 249 same level of trust. 251 Trust Anchor Manager The database of trust anchors associated to 252 database management processes. This function provides the DNSSEC 253 Validation Engine Trust Anchor information when needed. When TA 254 needs to be updated, the Trust Anchor Manager is also responsible 255 to handle the updating procedure. This includes sending DNS 256 Messages as well as treating appropriately the DNS responses that 257 have been accurately validated by the DNSSEC Validator Engine. 258 This will require the DNSSEC Validator to update Trust Anchor 259 information, whether via methods like Automated Updates of DNSSEC 260 Trust Anchors [RFC5011], management of Negative Trust Anchors, or 261 other, possibly not yet defined, means. 263 DNSSEC Validation Engine follows local policy to approve data. The 264 approved data is returned to the requesting application as well as 265 in the DNS Caches. While the cryptographic computation of the 266 RRSIG signature may be the most visible step, the RRSIG record 267 also contains other information intended to help the validator 268 perform its work, in some cases "sane value" checks are performed. 269 For instance, the original TTL (needed to prepare the RR set for 270 validation) ought to be equal to or higher than the received TTL. 272 Not shown - Name Server Process Management interfaces to elements, 273 handling of Checking Disabled request, responses, as well as all API 274 requests made of the name server. 276 5. Recommendations Categories 278 DRO needs to be able to enable DNSSEC validation with sufficient 279 confidence they will not be held responsible in case their resolver 280 does not validate the DNSSEC response. The minimization of these 281 risks is provided by setting automated procedures, when a resolver is 282 started or while it is operating, as well as some on-demand 283 operations that enable the DRO to perform a specific operation. The 284 recommendations do not come with the same level of requirements and 285 some are likely to be required. other are optional and may be 286 followed by more advanced DROs. 288 The RECOMMENDATIONS in this document are subdivided into the 289 following categories: 291 Start-up recommendations which describes RECOMMENDED operations the 292 DRO is expected to perform when the resolver is started. These 293 operations typically includes health check of the infrastructure 294 the resolver is instantiated on as well as configuration check. 296 Run time recommendations which describes RECOMMENDED operations the 297 DRO is expected to perform on its running resolvers. These 298 operations typically include health checks of the infrastructure 299 as well as the resolvers. 301 On demand recommendations which describes the RECOMMENDED operations 302 a DRO may perform. This includes the ability to operate health 303 check at a given time as well as specific operations such as 304 flushing the cache. The reason the document mentions these 305 recommendations is to enable DROs to have the appropriates tools 306 as well as to restrict their potential interventions. 308 6. Time deviation and absence of Real Time Clock Recommendations 310 With M2M communication some devices are not expected to embed Real 311 Time Clock (Raspberry Pi is one example of such devices). When these 312 devices are re-plugged the initial time is set to January 1 1970. 313 Other devices that have clocks that may suffer from time deviation. 314 These devices cannot rely on their time estimation to perform DNSSEC 315 validation. 317 Time synchronization may be performed manually, but for the sake of 318 operations it is strongly RECOMMENDED to automate the time 319 synchronization on each resolver. In addition, it is RECOMMENDED the 320 operator regularly proceed to sanity checks of its resolver and 322 START-UP REC: 324 o DRO MUST provide means to update the time without relying on 325 DNSSEC when the DNSSEC validator is started. The resolver MUST 326 NOT start if the time synchronization does not succeed at start 327 time. 329 Note that updating time in order to be able to perform DNSSEC 330 validation may become a form of a chicken-and-egg problem when the 331 NTP server is designated by its FQDN. The update mechanisms must 332 consider the DNSSEC validator may not able to validate the DNSSEC 333 queries. In other words, the mechanisms may have to update the time 334 over an unsecure DNSSEC resolution. 336 RUN TIME REC: 338 o While operating, DRO MUST closely monitor time derivations of the 339 resolvers and maintain the time synchronized. 341 ON DEMAND REC: 343 o A DRO SHOULD be able to check and synchronize, on demand, the time 344 of the system of its resolver. 346 Note that time synchronization is a sensible operation and DRO MUST 347 update the time of the systems over an authenticated and secure 348 channel. 350 For all recommendations, it is strongly RECOMMENDED that 351 recommendations are supported by automated processes. 353 7. Trust Anchor Related Recommendations 355 A TA store maintains associations between domain names and keys 356 (whether stored as in a DNSKEY resource record or a DS resource 357 record) and domain names whose key are to be ignored (negative trust 358 anchors). The TA store is essentially a simple database, storing the 359 positive trust anchors and negative trust anchors and enabling 360 changes to the lists. Management of the TA/NTA can be done manually 361 or in an automated way. 363 Management of TA/MTA can be subdivided into the following sub- 364 categories: 366 1. Configuration management, that is the ability, for a DRO, to 367 check the validity of TA/NTA when provisioned in the 368 configuration of a resolver that is stated as well as the ability 369 to add a NTA. 371 2. TA update management, that is the ability for a DRO to check TA 372 updates properly. 374 3. TA reporting management, that is the ability for a DRO to report 375 the TA in use by its resolver. The reporting can be made to the 376 DRO as well as the authoritative servers which are hold 377 responsible for making their zone validated by DNSSEC resolvers. 379 7.1. Trust Anchor Configuration 381 When a DRO starts a DNSSEC resolver, the DNSSEC resolver is generally 382 provisioned with a configuration file which contains the TAs. The 383 provisioned TS reflects a trust model, that is the definition of the 384 security entry points by the DRO, as well as the values associated to 385 these security entry points. The latest may change over time even 386 when the trust model of the DRO does not. As a result, the 387 envisioned way to generate the TA part associated to the DNSSEC 388 configuration file could be envisioned as follows: 390 a) Definition by the DRO of a trust model, that is domain name is 391 considered as a security entry point as well as domain name that are 392 known to be unsecured.. The default trust model consists in the root 393 zone as a security entry point, and no zones being considered as 394 unsecured. 396 b) Retrieval by a third party software of the TA associated to the 397 security entry points defined in a). The purpose is clearly to 398 retrieve DNSKEY as well as DS RRsets with a valid RDATA. 400 c) Generation of a configuration file, possibly generic and 401 implementation independent. 403 d) Starting resolvers. 405 The purpose of these steps is to prevent that a resolver is started 406 with a deprecated or invalid configuration. The DRO MUST ensure this 407 cannot happen as well as this will be detected if this were 408 happening. 410 This document does not provide recommendations regarding the number 411 of TA a DRO needs to configure its DNSSEC resolver with. There are 412 many reasons a DRO may be willing to consider multiple TAs as opposed 413 to a single Root Zone Trust Anchor. In fact it is not always 414 possible to build a trusted delegation between the Root Zone and any 415 sub zone. This may happen for example if one of the upper zones does 416 not handle the secure delegation or improperly implement it. A DS 417 RRset may not be properly filled or its associated signature cannot 418 be validated. As the chain of trust between a zone and the root zone 419 may not be validated, the DNSSEC validation for the zone requires a 420 TA. Such DNS(SEC) resolutions may be critical for infrastructure 421 management. A company "Example" may, for example, address all its 422 devices under the domain example.com and may not want disruption to 423 happen if the .com delegation cannot be validated for any reason. 424 Such companies may operate DNSSEC with a TA for the zone example.com 425 in addition to the regular DNSSEC delegation. Similarly some some 426 domains may present different views such as a "private" view and a 427 "public view". These zones may have some different content, and may 428 use a different KSK for each view. 430 Although some bootstrapping mechanisms to securely retrieve publish 431 [RFC7958] and retrieve [UNBOUND-ANCHOR] the Root Zone Trust Anchor 432 have been defined, it is believed these mechanisms should be extended 433 to other KSKs or Trust Anchors. Such bootstrapping process enables a 434 DRO to start a DNSSEC resolver from a configuration file, that 435 reflects the trust model of the DRO. 437 START-UP REC: 439 o DRO SHOULD only rely on TA associated with a bootstrapping 440 mechanism. 442 START-UP REC: 444 o DNS resolver MUST validate the TA before starting the DNSSEC 445 resolver, and a failure of TA validity check MUST prevent the 446 DNSSEC resolver to be started. Validation of the TA includes 447 coherence between out-out band values, values stored in the DNS as 448 well as corresponding DS RRsets. 450 Note that a simple implementation of these recommendations includes a 451 DRO that uses the default trust model with the root zone as the 452 single TA. The TA is provisioned by software update in the 453 configuration file and checked at start-up. More complex trust model 454 would require more complex operation though. 456 7.1.1. IANA Trust Anchor Bootstrapping 458 For validators that may be used on the global public Internet (with 459 "may be" referring to general purpose, general release code), 460 handling the IANA managed root zone KSK trust anchor is a 461 consideration. 463 The IANA managed root zone KSK is an operationally significant trust 464 point in the global public Internet. Attention to the trust anchor 465 for this point is paramount. Trust anchor management ought to 466 recognize that the majority of operators deploying DNSSEC validators 467 will need to explicitly or implicitly rely on this trust anchor. 468 Trust anchor management needs to recognize that there may be other 469 trust anchors of interest to operators. Besides deployments in 470 networks other than the global public Internet (hence a different 471 root), operators may want to configure other trust points. 473 The IANA managed root zone KSK is managed and published as described 474 in "DNSSEC Trust Anchor Publication for the Root Zone" [RFC7598]. 476 That document is written as specific to that trust point. Other 477 trust points may adopt the technique describe (or may use other 478 approaches). 480 This represents a consideration for implementations. On one hand, 481 operators will place special emphasis on how the root zone DNSSEC KSK 482 is managed. On the other hand, implementations ought to accommodate 483 trust anchors in a general manner, despite the odds that other trust 484 anchors will not be configured in a specific deployment. 486 Because of this, it is recommended that implementations make the root 487 zone trust anchor obvious to the operator while still enabling 488 configuration of general trust points. 490 7.2. Trust Anchor Update 492 Updating the TA reflects the evolution of the trust and needs to be 493 operated in a reliable and trusted way. 495 A DRO configures its resolver with TA associated to specific domains. 496 The configuration may be updated by adding new domains for which the 497 corresponding TAs need to be retrieved using an automated 498 bootstrapping procedure. This case is not considered in this section 499 and is instead addressed in the bootstrapping Section 7.1. 501 On the other hand, the value associated to the TA may be updated over 502 time which is part of the maintenance of the configuration and needs 503 to be performed by the DNSSEC resolver without any intervention of 504 the DRO. This is the purpose of this section. 506 TA update is expected to be transparent to the DRO (see 507 Section 7.2.1. However, a DRO MAY wish to ensure its resolvers 508 operate according to the provisioned configurations and are updated 509 normally (see Section 7.2.2. This includes for a DRO the ability to 510 check which TA are in used as well as to resolve in collaboration of 511 authoritative servers and report the used TAs. 513 7.2.1. Automated Updates to DNSSEC Trust Anchors 515 Trust is inherently a matter of an operations policy. As such, a DRO 516 will need to be able to update the list of Trust Anchors. TA updates 517 is not expected to be handled manually. This introduces a 518 potentially huge vector for configuration errors, but due to human 519 intervention as well as potential misunderstanding of ongoing 520 operations. 522 START-UP REC: 524 o DRO SHOULD enable "Automated Updates to DNSSEC Trust Anchors" 525 [RFC5011] [I-D.ietf-dnsop-rfc5011-security-considerations]. 527 7.2.2. Automated Trust Anchor Check 529 A DRO SHOULD regularly check the trust anchor used by the DNSSEC 530 resolver is up-to-date and that values used by the resolvers are 531 conform to the ones in the configuration (see Section 7.1). Such 532 check is designated as TA health check. 534 Note that retrieving in an automated way the value of the trust 535 anchor removes old values from the configuration and ensures that 536 resolvers are always started with up-to-date values. In the case of 537 a key roll over, the resolver is moving from an old value to an up-to 538 date value. This up-to-date value does not need to survive reboot, 539 and there is no need to update the configuration file - configuration 540 is updated by a separate process. To put it in other words, the 541 updated value of the TA is only expected to be stored in the 542 resolver's memory. 544 The TA used by a resolver may be part of a configuration parameter as 545 well as part of an internal state of the resolver. It is NOT 546 RECOMMENDED a DRO accesses configuration or internal state of a 547 resolver as it may open the resolver to other vulnerabilities and 548 provides privileged access to a potential attacker. 550 START-UP REC: 552 o DRO SHOULD enable "Signaling Trust Anchor Knowledge in DNS 553 Security Extensions (DNSSEC)" [RFC8145] to provide visibility to 554 the TA used by the resolver. The TA can be queries using a DNS 555 KEY query. The channel MAY be protected and restricted to the 556 DRO. 558 Note also that [RFC8145] does not only concerns Trust Anchor but is 559 instead generic to DNSKEY RRsets. As a result, unless for the root 560 zone, it is not possible to determine if the KSK/ZSK or DS is a Trust 561 Anchor or a KSK/ZSK obtained from regular DNSSEC resolutions. 563 TA health check includes validating DNSKEY RRsets and associated DS 564 RRsets in the resolver, on the DNS authoritative servers as well as 565 those obtained out-of-band. TA health check results MUST be logged. 566 The check SHOULD evaluate if the mismatch result from an ongoing 567 normal roll over, a potential emergency key roll over, failed roll 568 over or any other envisioned cases. Conflicts are not inherently a 569 problem as some keys may be withheld from distribution via the DNS. 570 A failed key roll over or any other abnormal situation MUST trigger 571 an alarm. 573 RUN TIME REC: 575 o A DRO SHOULD regularly run TA health checks. 577 If the mismatch is due to a failed key roll-over, this SHOULD be 578 considered as a bug by the DRO. The DRO MUST restart the resolver 579 with updated TA. 581 ON DEMAND REC: 583 o A DRO SHOULD be able to check the status of a TA 585 8. ZSK / KSK (non TA) Related Recommendations 587 KSK / ZSK are not part of the DNSSEC validator configuration. Their 588 values in the DNS Caches may not reflect those published by the 589 authoritative servers or may be incoherent with the RRset in the DNS 590 Cache they are validating. However, such incoherence primary results 591 from error in the management of the authoritative servers. As a 592 result, it is not expected that the DNSSEC validator provides complex 593 management facilities to address these issues as this will modify the 594 DNS architecture and add complexity that is not proved to be 595 beneficial. 597 As a result, recommendations always belong to the run time of on 598 demand category of recommendations. The main difference between TA 599 and KSK/ZSK is that the DRO does not necessarily have an out of band 600 mechanism to retrieve the RRsets. As a result, the DRO has less 601 information to determine and confirm what is happening. The default 602 recommendation is to let things go. 604 A number of reasons may result in inconsistencies between the RRsets 605 stored in the cache and those published by the authoritative server. 607 An emergency KSK / ZSK rollover may result in a new KSK / ZSK with 608 associated new RRSIG published in the authoritative zone, while 609 DNSSEC validator may still cache the old value of the ZSK / KSK. For 610 a RRset not cached, the DNSSEC validator performs a DNSSEC query to 611 the authoritative server that returns the RRset signed with the new 612 KSK / ZSK. The DNSSEC validator may not be able to retrieve the new 613 KSK / ZSK while being unable to validate the signature with the old 614 KSK / ZSK. This either result in a bogus resolution or in an invalid 615 signature check. Note that by comparing the Key Tag Fields, the 616 DNSSEC validator is able to notice the new KSK / ZSK used for signing 617 differs from the one used to generate the received generated 618 signature. However, the DNSSEC validator is not expected to retrieve 619 the new ZSK / KSK, as such behavior could be used by an attacker. 621 Instead, ZSK / KSK key roll over procedures are expected to avoid 622 such inconsistencies. 624 Similarly, a KSK / ZSK roll over may be performed normally, that is 625 as described in [RFC6781] and [RFC7583]. While the KSK / ZSK roll 626 over is performed, there is no obligation to flush the RRsets in the 627 cache that have been associated with the old key. In fact, these 628 RRset may still be considered as trusted and be removed from the 629 cache as their TTL timeout. With very long TTL, these RRsets may 630 remain in the cache while the ZSK / KSK with a shorter TTL is no 631 longer published nor in the cache. In such situations, the purpose 632 of the KSK / ZSK used to validate the data is considered trusted at 633 the time it enters the cache, and such trust may remain after the KSK 634 / ZSK is being rolled over. Note also that even though the data may 635 not be associated to the KSK / ZSK that has been used to validate the 636 data, the link between the KSK / ZSK and the data is still stored in 637 the cache using the RRSIG. Note also that inconsistencies between 638 the ZSK / KSK stored in the cache and those published on the 639 authoritative server, may lead to inconsistencies to downstream 640 DNSSEC validators that rely on multiple cache over time. Typically, 641 a request for the KSK / ZSK may have been provided by a cache that is 642 storing the new published value, while the data and associated 643 signatures may be associated to the old KSK / ZSK. 645 Incoherence between RRsets and DNSKEYs may be limited by configuring 646 the DNSSEC validator with generic rules that applies to the 647 validation process. Typically, the TTL associate to the DNSKEY is an 648 engagement from the authoritative server that the DNSKEY will remain 649 valid over this period. As this engagement supersedes the validation 650 of any RRSIG and by extension to any RRset in the zone, this TTL 651 value may be used as the maximum value for the TTL associated to 652 FQDNs in the zone. This would at least reduce inconsistencies during 653 regular KSK roll over. In addition, the DNSSEC validator should also 654 be able to provide a maximum values for TTLs. 656 RUN TIME REC: 658 o To limit the risks of incoherent data in the cache, it is 659 RECOMMENDED DRO enforce TTL policies of RRsets based on the TTL of 660 the KSK/ZSK. RRsets TTL SHOULD NOT exceed the KSK / ZSK initial 661 TTL value. 663 9. DNSKEY Related Recommendations 665 This section considers the recommendations that are common to TA as 666 well as non TA DNSKEY RRsets. 668 9.1. Automated Reporting 670 A DRO MAY regularly report the Trust Anchor used to the authoritative 671 server. This would at least provide insight to the authoritative 672 server and provide it some context before moving a key roll over 673 further. 675 The purpose of reporting the currently used Trust Anchor for a domain 676 name is to establish an informational channel between the resolver 677 and the authoritative server. This data may not directly be useful 678 for the DNSSEC Resolver, but instead to the authoritative server. In 679 return it is likely the authoritative server will take the 680 appropriated steps in operating the authoritative server and consider 681 this information. As a result, 683 RUNNING REC: 685 o A DRO SHOULD enable TA reporting to the authoritative server as 686 specified in "Signaling Trust Anchor Knowledge in DNS Security 687 Extensions (DNSSEC)" [RFC8145] 689 9.2. Negative Trust Anchors 691 When the DNSSEC Resolver is not able to validate signatures because a 692 key or DS has been published with an error, the DNSSEC Operator MAY 693 temporarily disable the signature check for that key the time the 694 error is addressed. This is performed using NTA[RFC7646]. NTA 695 represents the only permitted intervention in the resolving process 696 for a DRO. 698 ON DEMAND REC: 700 o DRO SHOULD be able to handle NTA as defined in "Definition and Use 701 of DNSSEC Negative Trust Anchors" [RFC7646]. 703 Note that adding a Negative Trust Anchor only requires the domain 704 name to be specified. Note also that NTA can disable any sort of 705 DNSKEY and is not restricted to TA. 707 A failure in signaling validation is associated to a mismatch between 708 the key and the signature.DNSKEY/DS RRsets for TA have a higher level 709 of trust then regular KSK/ZSK. In addition, DRO are likely to have 710 specific communication channel with TA maintainer which eases trouble 711 shooting. 713 A signature validation failure is either an attack or a failure into 714 the signing operation on the authoritative servers. The DRO is 715 expected to confirm this off line before introducing the Negative 716 Trust Anchor. This is likely to happen via a human confirmation. As 717 a result here are the following recommendations: 719 RUN TIME REC: 721 o DRO SHOULD monitor the number of signature failure associated to 722 each DNSKEY. These number are only hints and MUST NOT trigger 723 automated insertion of NTA. 725 RUN TIME REC: 727 o A DRO MAY collect additional information associated each DNSKEY 728 RRSets. This information may be useful to follow-up roll over 729 when these happen and evaluate when a key roll over is not 730 performed appropriately on the resolver side or on the 731 authoritative server. It would provide some means to the DRO to 732 take action with full knowledge without necessary asking for a 733 confirmation. In other cases it could prevent invalidation to 734 happen. These check may be performed for a limited subset of 735 domains or generalized. 737 9.3. Interactions with the cached RRsets 739 The purpose of automated checks is to enable early detection of 740 failed operations, which provides enough time to the DRO to react 741 without any consequences. On the other hand, these checks MAY reveal 742 as well that a rogue TA has been placed and that the resolver is 743 corrupted. Similarly, a DRO may be informed by other channel a rogue 744 or unwilling DNSKEY has been emitted. 746 In such situation, the DRO SHOULD be able to remove the RRsets 747 validated by the rogue DNSKEY. 749 ON DEMAND REC: 751 o A DRO MUST be able to flush the cached data associated to a DNSKEY 753 10. Cryptography Deprecation Recommendations 755 As mentioned in [RFC8247] and [RFC8221] cryptography used one day is 756 expected over the time to be replaced by new and more robust 757 cryptographic mechanisms. In the case of DNSSEC signature protocols 758 are likely to be updated over time. In order to anticipate the 759 sunset of one of the signature scheme, a DNSSEC validator may willing 760 to estimate the impact of deprecating one signature scheme. 762 Currently [RFC6975] provides the ability for a DNSSEC validator to 763 announce an authoritative server the supported signature schemes. 765 However, a DNSSEC validator is not able to determine other than by 766 trying whether a signature scheme is supported by the authoritative 767 server. 769 To safely deprecate one signature scheme, the DNSSEC validator 770 operator is expected to follow the recommendation below: 772 RUN TIME REC: 774 o A DNSSEC validator operator SHOULD regularly request and monitor 775 the signature scheme supported by an authoritative server. 777 11. Invalid Reporting Recommendations 779 A DNSSEC validator receiving a DNS response cannot make the 780 difference between receiving an non-secure response versus an attack. 781 Dropping DNSSEC fields by a misconfigured middle boxes, such as DS, 782 RRRSIG is considered as an attack. A DNSSEC validator is expected to 783 perform secure DNS resolution and as such protect its stub client. 784 An invalid response may be the result of an attack or a 785 misconfiguration, and the DNSSEC validator may play an important role 786 in sharing this information. 788 RUN TIME REC: 790 o DRO SHOULD monitor and report the unavailability of the DNSSEC 791 service. 793 RUN TIME REC: 795 o DRO SHOULD monitor and report an invalid DNSSEC validation. 797 12. IANA Considerations 799 There are no IANA consideration for this document. 801 13. Security Considerations 803 The recommendations listed in this document have two goals. First 804 ensuring the DNSSEC validator has appropriated information to 805 appropriately perform DNSSEC validation. Second, monitoring the 806 necessary elements that would enable a DNSSEC validator operator to 807 ease a potential analysis. The recommendations provide very limited 808 ability for a DNSSEC validator operator to alter or directly 809 interfere on the validation process and the main purpose in providing 810 the recommendations was to let the protocol run as much as possible. 811 Providing inappropriate information can lead to misconfiguring the 812 DNSSEC validator, and thus disrupting the DNSSEC resolution service. 814 As a result, enabling the setting of configuration parameters by a 815 third party may open a wide surface of attacks. In addition, such 816 changes may lead to unexpected corner cases that would result in 817 making analysis and trouble shooting very hard. 819 As an appropriate time value is necessary to perform signature check, 820 an attacker may provide rogue time value to prevent the DNSSEC 821 validator to check signatures. 823 An attacker may also affect the resolution service by regularly 824 asking the DNSSEC validator to flush the KSK/ZSK from its cache. All 825 associated data will also be flushed. This generates additional 826 DNSSEC resolution and additional validations, as RRSet that were 827 cached require a DNSSEC resolution over the Internet. This affects 828 the resolution service by slowing down responses, and increases the 829 load on the DNSSEC validator. 831 An attacker may ask the DNSSEC validator to consider a rogue KSK/ZSK, 832 thus hijacking the DNS zone. Similarly, an attacker may inform the 833 DNSSEC validator not to trust a given KSK in order to prevent DNSSEC 834 validation to be performed. 836 An attacker (cf. Section 7) can advertise a "known insecure" KSK or 837 ZSK is "back to secure" to prevent signature check to be performed 838 correctly. 840 As a result, information considered by the DNSSEC validator should be 841 from a trusted party. This trust party should have been 842 authenticated, and the channel used to exchange the information 843 should also be protected and authenticated. 845 14. Acknowledgment 847 The need to address DNSSEC issues on the resolver side started in the 848 Home Networks mailing list and during the IETF87 in Berlin. Among 849 others, people involved in the discussion were Ted Lemon, Ralph 850 Weber, Normen Kowalewski, and Mikael Abrahamsson. People involved in 851 the email discussion initiated by Jim Gettys were, with among others, 852 Paul Wouters, Joe Abley and Michael Richardson. 854 The current document has been initiated after a discussion with Paul 855 Wouter and Evan Hunt. 857 15. References 858 15.1. Normative References 860 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 861 Requirement Levels", BCP 14, RFC 2119, 862 DOI 10.17487/RFC2119, March 1997, 863 . 865 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 866 Rose, "DNS Security Introduction and Requirements", 867 RFC 4033, DOI 10.17487/RFC4033, March 2005, 868 . 870 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 871 Rose, "Protocol Modifications for the DNS Security 872 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 873 . 875 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 876 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 877 September 2007, . 879 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 880 Operational Practices, Version 2", RFC 6781, 881 DOI 10.17487/RFC6781, December 2012, 882 . 884 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic 885 Algorithm Understanding in DNS Security Extensions 886 (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, 887 . 889 [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, 890 "DNSSEC Key Rollover Timing Considerations", RFC 7583, 891 DOI 10.17487/RFC7583, October 2015, 892 . 894 [RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J., 895 and R. Weber, "Definition and Use of DNSSEC Negative Trust 896 Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015, 897 . 899 [RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust 900 Anchor Knowledge in DNS Security Extensions (DNSSEC)", 901 RFC 8145, DOI 10.17487/RFC8145, April 2017, 902 . 904 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 905 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 906 May 2017, . 908 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 909 Kivinen, "Cryptographic Algorithm Implementation 910 Requirements and Usage Guidance for Encapsulating Security 911 Payload (ESP) and Authentication Header (AH)", RFC 8221, 912 DOI 10.17487/RFC8221, October 2017, 913 . 915 [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, 916 "Algorithm Implementation Requirements and Usage Guidance 917 for the Internet Key Exchange Protocol Version 2 (IKEv2)", 918 RFC 8247, DOI 10.17487/RFC8247, September 2017, 919 . 921 15.2. Informative References 923 [I-D.ietf-dnsop-rfc5011-security-considerations] 924 Hardaker, W. and W. Kumari, "Security Considerations for 925 RFC5011 Publishers", draft-ietf-dnsop-rfc5011-security- 926 considerations-13 (work in progress), July 2018. 928 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 929 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 930 Configuration of Softwire Address and Port-Mapped 931 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 932 . 934 [RFC7958] Abley, J., Schlyter, J., Bailey, G., and P. Hoffman, 935 "DNSSEC Trust Anchor Publication for the Root Zone", 936 RFC 7958, DOI 10.17487/RFC7958, August 2016, 937 . 939 [UNBOUND-ANCHOR] 940 "unbound-anchor - Unbound anchor utility", n.d., 941 . 944 Authors' Addresses 945 Daniel Migault 946 Ericsson 947 8275 Trans Canada Route 948 Saint Laurent, QC 4S 0B6 949 Canada 951 EMail: daniel.migault@ericsson.com 953 Edward Lewis 954 ICANN 956 EMail: edward.lewis@icann.org 958 Dan York 959 ISOC 961 EMail: york@isoc.org