DNSSEC Validators Requirements
draft-mglt-dnsop-dnssec-validator-requirements-05

DNSOP                                                         D. Migault
Internet-Draft                                                  Ericsson
Intended status: Standards Track                                 D. York
Expires: December 29, 2017                              Internet Society
                                                                E. Lewis
                                                                   ICANN
                                                           June 27, 2017

                     DNSSEC Validators Requirements
           draft-mglt-dnsop-dnssec-validator-requirements-05

Abstract

   DNSSEC provides data integrity and source authentication to a basic
   DNS RRset.  Given a RRset, a public key and a signature, a DNSSEC
   validator checks the signature, time constraints, and other, local,
   policies.  In case of mismatch the RRSet is considered illegitimate
   and is rejected.

   Accuracy in DNSSEC validation, that is, avoiding false positives and
   catching true negatives, requires that both the signing process and
   validation process adhere to the protocol, which begins with external
   configuration parameters.  This document describes requirements for a
   validator to be able to perform accurate validation.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 29, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Migault, et al.         Expires December 29, 2017               [Page 1]
Internet-Draft        DNSSEC Validator Requirements            June 2017

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Time derivation and absence of Real Time Clock  . . . . . . .   3
   5.  Trust Anchor Datastore  . . . . . . . . . . . . . . . . . . .   4
   6.  Trust Anchor Data Store . . . . . . . . . . . . . . . . . . .   5
   7.  Interactions with the cached RRsets . . . . . . . . . . . . .   6
   8.  ZSK / KSK . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  KSK/ZSK Data Store  . . . . . . . . . . . . . . . . . . .   6
     8.2.  KSK/ZSK Data Store and Trust Anchor Data Store  . . . . .   8
     8.3.  Interactions with cached RRsets . . . . . . . . . . . . .   9
   9.  DS  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   10. Cryptography Deprecation  . . . . . . . . . . . . . . . . . .   9
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  10
   13. Acknowledgment  . . . . . . . . . . . . . . . . . . . . . . .  11
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     14.2.  Informational References . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   DNSSEC validation [refer to DNSSEC RFC documents; 4033-4035+updates]
   has two core concepts.  One is the matching of a RRSIG resource
   record's contents to a RRset, making use of a DNSKEY resource record
   (named in the RRSIG record).  Two is the placing of trust in the
   DNSKEY resource record.

Migault, et al.         Expires December 29, 2017               [Page 2]
Internet-Draft        DNSSEC Validator Requirements            June 2017

   Evaluation based on a RRSIG records involves a few steps.  Most
   visible is a cryptographic operation, matching the digital signature
   in the RRSIG with the specified public key in the named DNSKEY record
   and a properly prepared DNS RRset.  This is meant to demonstrate that
   the RRset came from an entity with the private component of the key
   (source authenticity).

   Not to be forgotten are the other matches to perform.  To address the
   threat of reply attacks, wall-clock (absolute) time is checked.  To
   address the authority of the source, the named DNSKEY record is
   checked for appropriateness (i.e., owned by the same zone is the
   default policy).

   The RRSIG record also contains other information intended to help the
   validator perform its work, in some cases "sane value" checks are
   performed.  For instance, the original TTL (needed to prepare the RR
   set for validation) ought to be equal to or higher than the received
   TTL.

   Requirements related to validation exist in RFC 4034/4035.  This
   document describes what an implementation is required to do to allow
   proper, accurate validation.

3.  Terminology

   This document uses the following terminology:

      DNSSEC validator: the entity that performs DNSSEC resolution and
      performs signature validation.

      Accurate validation: validation that avoids false positives and
      catches true negatives. (not sure if this is needed, but seems
      appropriate)

4.  Time derivation and absence of Real Time Clock

   With M2M communication some devices are not expecting to embed Real
   Time Clock (Raspberry Pi is one example of such devices).  When these
   devices are re-plugged the initial time is set to January 1 1970.
   Other devices that have clocks that may suffer from time derivation.
   All these devices cannot rely on their time estimation to perform
   DNSSEC validation.

   REQ1:  A DNSSEC validator MUST be provided means to update the time
          without relying on DNSSEC.

   Note that updating time in order to be able to perform DNSSEC
   validation may easily come with a chicken-and-egg problem when the

Migault, et al.         Expires December 29, 2017               [Page 3]
Internet-Draft        DNSSEC Validator Requirements            June 2017

   NTP server is designated by its FQDN.  The update mechanisms must
   consider the DNSSEC validator may not able to validate the DNSSEC
   queries.  In other words, the mechanisms may have to update the time
   over an unsecure DNSSEC resolution.

5.  Trust Anchor Datastore

   A validator needs to have trust anchors or it will never be able to
   construct a chain of trust.  Trust anchors are defined by DNSSEC to
   be keys that are inherently trusted, configured by authorized
   parties, in the validator.  The configuration can be via an automated
   process, such as Automated Updates of DNSSEC Trust Anchors [RFC 5011
   as reference], or via manual process.

   An implementation of a validator needs to allow an operator to choose
   any automated process supported by the validator.  (No requirements
   are stated about what processes to support, only one is standardized
   to date.)  An implementation needs to also afford the operator the
   ability to override or manage via a purely manual process, the
   storage of managed keys.  This includes adding, deleting, changing
   and inspecting.

   Beyond the scope of these requirements are the decision processes of
   authorized parties in placing trust in keys.

   REQ2:  A DNSSEC validator MUST check the validity of its Trust
          Anchors.  When a Trust Anchor cannot be verified, the DNSSEC
          validator MUST send a warning and SHOULD NOT start validating
          traffic without manual validation.

   REQ3:  A DNSSEC validator SHOULD be able to retrieve a Trust Anchor
          with bootstrapping mechanism.  Such mechanism' security MUST
          NOT be based on DNSSEC, but could instead include downloading
          a XML file from a trusted URL, or a PKIX certificate.

   Although some bootstrapping mechanisms to securely retrieve publish
   [RFC7958] and retrieve [UNBOUND-ANCHOR] the Root Zone Trust Anchor
   have been defined, it is believed these mechanisms should be extended
   to other KSKs or Trust Anchors.  In fact it is not always possible to
   build a trusted delegation between the Root Zone and any sub zone.
   This may happen for example if one of the upper zones does not handle
   the secure delegation or improperly implement it.  A DS RRset may not
   be properly filled or its associated signature cannot be validated.
   As the chain of trust between a zone and the root zone may not be
   validated, the DNSSEC validation for the zone requires a Trust
   Anchor.  Such DNS(SEC) resolutions may be critical for infrastructure
   management.  A company "Example" may for address all its devices
   under the domain example.com and may not want disruption to happen if

Migault, et al.         Expires December 29, 2017               [Page 4]
Internet-Draft        DNSSEC Validator Requirements            June 2017

   the .com delegation cannot be validated for any reason.  Such
   companies may provision there DNSSEC validator with the Trust Anchor
   KSK for the zone example.com in addition to the regular DNSSEC
   delegation.  Similarly some some domains may present different views
   such as a "private" view and a "public view".  These zones may have
   some different content, and may use a different KSK for each view.

6.  Trust Anchor Data Store

   When DNSSEC validator are running and a Trust Anchor KSK roll over is
   ongoing, a network administrator or any trust party may be willing to
   check whether the new published keys are being stored in a Trust
   Anchor Store with an appropriated status.  Such inspection is likely
   to avoid that an non successful Trust Anchor roll over be detected
   before traffic is being rejected.  When a new Trust Anchor has not
   been considered by the DNSSEC validator, a trusted party may be able
   to provision the DNSSEC validator with the new Trust Anchor, and
   eventually may remove the revoked Trust Anchor.

   While Trust Anchor configured with a KSK that has been removed
   results in the DNSSEC validator rejecting multiple legitimate
   responses, the consequences associated to accepting a rogue Trust
   Anchor as a legitimate Trust Anchor are even worst.  Such attacks
   would result in an attacker taking control of the entire naming space
   behind the Trust Anchor.  In the case of the Root Zone KSK, for
   example, almost all name space would be under the control of the
   attacker.  In addition, to the name space, once the rogue Trust
   Anchor is configured, there is little hope the DNSSEC validator be
   re-configured with the legitimate Trust Anchor without manual
   intervention.  As a result, it is crucial to cautiously handle
   operations related to the Trust Anchor provisioning.  Means must be
   provided so network administrator can clearly diagnose the reason a
   Trust Anchor is not valid to avoid accepting a rogue Trust Anchor
   inadvertently.

   DNSSEC may also be used in some private environment.  Corporate
   networks and home networks, for example, may want to take advantage
   of DNSSEC for a local scope network.  Typically, a corporate network
   may use a local scope KSK / ZSK to validate DNS RRsets provided by
   authoritative DNSSEC server in the corporate network.  This use case
   is also known as the "split-view" use case.  These RRsets within the
   corporate network may differ from those hosted on the public DNS
   infrastructure.  Note that using different KSK/ZSK for a given zone
   may expose a zone to signature invalidation.  This is especially the
   case for DNSSEC validators that are expected to flip-flop between
   local and public scope.  How validators have to handle the various
   provisioned KSK/ZSKs is out of scope of the document.

Migault, et al.         Expires December 29, 2017               [Page 5]
Internet-Draft        DNSSEC Validator Requirements            June 2017

   Homenet work may use DNSSEC with TLDs or associated domain names that
   are of local scope and not even registered in the public DNS
   infrastructure.  This requires the ability to manage the Trust Anchor
   DB as described in Section 5.

   The necessity to interact with the Trust Anchors lead to the
   following requirements:

   REQ4:  A DNSSEC validator MUST store its Trust Anchors in a dedicated
          Trust Anchor Data Base.  Such database MUST store informations
          associated to each Trust Anchor status as well as the time the
          status has been noticed by the DNSSEC validator.  Such
          database MUST be resilient to DNSSEC validator reboot.

   REQ5:  Trust Anchor states SHOULD at least consider those described
          in [RFC5011] (Start, AddPend, Valid, Missing, Revoked,
          Removed).  Additional states SHOULD also be able to indicate
          additional motivations for revoking the Trust Anchor such as a
          Trust Anchor known to be corrupted, a Trust anchor miss
          published, or part of a regular roll over procedure.

   REQ6:  A DNSSEC validator MUST provide access to the Trust Anchor
          data base to authorized user only.  Access control is expected
          to be based on a least privileged principles.

   REQ7:  A trusted party MUST be able to add, remove a Trust Anchor in
          the Trust Anchor Database.

7.  Interactions with the cached RRsets

   In addition when a Trust Anchor is revoked, the DNSSEC validator may
   behave differently if the revocation is motivated by a regular roll
   over operation or instead by revoking a Trust Anchor that is known as
   being corrupted.  In the case the roll over procedure, is motivated
   by revoking a Trust Anchor that is known to be corrupted, the DNSSEC
   validator may be willing to flush all RRsets that depends on the
   Trust Anchor.

   REQ8:  A DNSSEC validator MUST be able to flush the cached RRsets
          that rely on a Trust Anchor.

8.  ZSK / KSK

8.1.  KSK/ZSK Data Store

   A number of reasons may result in inconsistencies between the RRsets
   stored in the cache and those published by the authoritative server.

Migault, et al.         Expires December 29, 2017               [Page 6]
Internet-Draft        DNSSEC Validator Requirements            June 2017

   An emergency KSK / ZSK rollover may result in a new KSK / ZSK with
   associated new RRSIG published in the authoritative zone, while
   DNSSEC validator may still cache the old value of the ZSK / KSK.  For
   a RRset not cached, the DNSSEC validator performs a DNSSEC query to
   the authoritative server that returns the RRset signed with the new
   KSK / ZSK.  The DNSSEC validator may not be able to retrieve the new
   KSK / ZSK while being unable to validate the signature with the old
   KSK / ZSK.  This either result in a bogus resolution or in an invalid
   signature check.

   [I AM NOT SURE THE ABOVE TEXT IS CORRECT AS THE RRSIG CARRIES THE KEY
   ID, SO THE DNSSEC VALIDATOR SHOULD BE ABLE TO DETECT IT IS USING THE
   WRONG KEY.  WOULDN'T IT IN THAT CASE QUERY THE DNSKEY ? ]

   Similarly, a KSK / ZSK roll over may be performed normally, that is
   as described in [RFC6781] and [RFC7583].  While the KSK / ZSK is
   performed, there is no obligation to flush the RRsets in the cache
   that have been associated with the old key.  In fact, these RRset may
   still be considered as trusted and be removed from the cache as their
   TTL timeout.  With very long TTL, these RRset may remain in the cache
   while the ZSK / KSK with a shorter TTL is no longer published nor in
   the cache.

   KSK and ZSK are associated with configuration parameters, and as such
   are expected to be stored only in the cache.  As a result, flushing
   their value from the cache could constitute a way forward to refresh
   them.  On the other hand, their respective function is also to
   prevent illegitimate RRsets to be validated and so more understanding
   is need before taking any action associated to the KSK or ZSK.  More
   specifically, the network administrator SHOULD be provided the
   appropriated information required to distinguish a misconfiguration
   from an attack.

   The following requirements are thus considered for the KSK / ZSK.

   REQ9:  A DNSSEC validator MUST store its KSK/ZSK in a dedicated KSK/
          ZSK Data Base.  Such database MUST store informations
          associated to each KSK/ZSK status as well as the time the
          status has been noticed by the DNSSEC validator.  Such
          database MUST NOT be resilient to DNSSEC validator reboot.

   REQ10: KSK/ZSK status SHOULD be monitored continuously and associated
          with their respective state as well as verified time.  These
          states and MUST NOT be resilient to reboot.

   REQ11: KSK/ZSK states SHOULD at least consider those described in
          section 3.1 of [RFC7583] (Generated, Published, Ready, Active,
          Retired, Dead, Removed, Revoked ).  Additional states SHOULD

Migault, et al.         Expires December 29, 2017               [Page 7]
Internet-Draft        DNSSEC Validator Requirements            June 2017

          also be able to indicate additional motivations for revoking
          the KSK/ZSK such as a KSK/ZSK known to be corrupted, a KSK/ZSK
          miss published, or part of a regular roll over procedure.

   REQ12: A DNSSEC validator MUST provide access to the KSK/ZSK data
          base to authorized user only.  Access control is expected to
          be based on a least privileged principles.

   REQ13: A trusted party MUST be able to add, remove a Trust Anchor in
          the KSK/ZSK Database.

8.2.  KSK/ZSK Data Store and Trust Anchor Data Store

   A zone may have been badly signed, which means that the KSK or ZSK
   cannot validate the RRSIG associated to the RRsets.  This may not be
   due to a key roll over, but to an incompatibility between the keys
   (KSK or ZSK) and the signatures.

   When such situation occurs, there is only a choice between not
   validating the RRsets or invalidating their signature.  This is a
   policy design that needs to be taken by the network administrator.
   In other ways, flushing the RRset are not expected to address this
   issue.  Such KSK/ZSK are known as Negative Trust Anchors [RFC7646].

   With Negative Trust Anchor, the zone for a given time will be known
   as "known insecure".  The DNSSEC Validator is not expected to perform
   signature validation for this zone.  It is expected that this
   information is associated to a Time To Live (TTL).

   Note that, this information may be used as an attack vector to
   impersonate a zone, and must be provided in a trusted way, by a
   trusted party.

   If a zone has been badly signed, the administrator of the
   authoritative DNS server may resign the zone with the same keys or
   proceed to an emergency key rollover.  If the signature is performed
   with the same keys, the DNSSEC Validator may notice by itself that
   RRSIG can be validated.  On the other hand if a key rollover is
   performed, the newly received RRSIG will carry a new key id.  Upon
   receiving a new key id in the RRSIG, the DNSSEC Validator is expected
   to retrieve the new ZSK/KSK.  If the RRSIG can be validated, the
   DNSSEC Validator is expected to remove the "known insecure" flag.

   However, if the KSK/ZSK are rolled over and RRSIG cannot be
   validated, it remains hard for the DNSSEC Validator to determine
   whether the RRSIG cannot be validated or that RRSIG are invalid.  As
   a result:

Migault, et al.         Expires December 29, 2017               [Page 8]
Internet-Draft        DNSSEC Validator Requirements            June 2017

   REQ14: A trusted party MUST be able to indicate a DNSSEC validator
          that a KSK or a ZSK as Negative Trust Anchor.  Such Trust
          Anchors MUST NOT be used for RRSIG validation and MUST be
          moved to the Trust Anchor Database, so the information become
          resilient to reboot.

   REQ15: A trusted party MUST be able to indicate a DNSSEC validator
          that a KSK/ZSK is known "back to secure".

8.3.  Interactions with cached RRsets

   In order to refresh a KSK/ZSK, a trusted third party may simply flush
   the corresponding KSK/ZSK from the cache.

   In order to avoid inconsistency between KSK/ZSK and cached RRsets, a
   trusted third party may willing to remove all cached RRsets that have
   been validated by the KSK/ZSK upon some specific states (revoked, or
   Removed for example), of after some time after the state is noticed.
   In this later case, only the RRset whose TTL has not expired yet
   would be flushed.

   Finally, when a KSK/ZSK is known to be corrupted, the DNSSEC
   validator may removed all cached RRsets associated to the KSK/ZSK.

   As a result, the following requirements are expected:

   REQ16: A DNSSEC validator MUST be able to flush the cached KSK/ZSK.

   REQ17: A DNSSEC validator MUST be able to flush the cached RRsets
          associated to a KSK/ZSK.

9.  DS

   The DS RRset is stored in the parent zone to build a chain of trust
   with the child zone.  This DS RRset can be invalid because its RDATA
   (KSK) is not anymore used in the child zone or because the DS is
   badly signed and cannot be validated by the DNSSEC Validator.

   In both cases the child zone is considered as bogus and the valid
   child zone's KSK should become a Trust Anchor KSK.  This requirements
   is fulfilled by the requirement to add a Trust Anchor in Section 5.

10.  Cryptography Deprecation

   As mentioned in [I-D.ietf-ipsecme-rfc4307bis] and
   [I-D.ietf-ipsecme-rfc7321bis] cryptography used one day is expected
   over the time to be replaced by new and more robust cryptographic
   mechanisms.  In the case of DNSSEC signature protocols are likely to

Migault, et al.         Expires December 29, 2017               [Page 9]
Internet-Draft        DNSSEC Validator Requirements            June 2017

   be updated over time.  In order to anticipate the sunset of one of
   the signature scheme, a DNSSEC validator may willing to estimate the
   impact of deprecating one signature scheme.

   Currently [RFC6975] provides the ability for a DNSSEC validator to
   announce an authoritative server the supported signature schemes.
   However, a DNSSEC validator is not able to determine other than by
   trying whether a signature scheme is supported by the authoritative
   server.

   In order for a DNSSEC validator to safely deprecate one signature
   scheme the following requirement should be fulfilled.

   REQ18: A DNSSEC validator SHOULD be able to request the signature
          scheme supported by an authoritative server.

11.  IANA Considerations

   There are no IANA consideration for this document.

12.  Security Considerations

   The requirements listed in this document aim at providing the DNSSEC
   validator appropriated information so DNSSEC validation can be
   performed.  On the other hand, providing inappropriate information
   can lead to misconfiguring the DNSSEC validator, and thus disrupting
   the DNSSEC resolution service.  As a result, enabling the setting of
   configuration parameters by a third party may open a wide surface of
   attacks.

   As an appropriate time value is necessary to perform signature check
   (cf.  Section 4), an attacker may provide rogue time value to prevent
   the DNSSEC validator to check signatures.

   An attacker may also affect the resolution service by regularly
   asking the DNSSEC Validator to flush the KSK/ZSK from its cache (cf.
   Section 8).  All associated data will also be flushed.  This
   generates additional DNSSEC resolution and additional validations, as
   RRSet that were cached require a DNSSEC resolution over the Internet.
   This affects the resolution service by slowing down responses, and
   increases the load on the DNSSEC validator.

   An attacker may ask the DNSSEC validator to consider a rogue KSK/ZSK
   ( cf. Invalid DS in Section 9 or Private KSK in Section 5), thus
   hijacking the DNS zone.  Similarly, (cf.  Section 8) an attacker may
   inform the DNSSEC validator not to trust a given KSK in order to
   prevent DNSSEC validation to be performed.

Migault, et al.         Expires December 29, 2017              [Page 10]
Internet-Draft        DNSSEC Validator Requirements            June 2017

   An attacker (cf.  Section 8) can advertise a "known insecure" KSK or
   ZSK is "back to secure" to prevent signature check to be performed
   correctly.

   As a result, information considered by the DNSSEC validator should be
   from a trusted party.  This trust party should have been
   authenticated, and the channel used to exchange the information
   should also be protected and authenticated.

13.  Acknowledgment

   The need to address DNSSEC issues on the resolver side started in the
   Home Networks mailing list and during the IETF87 in Berlin.  Among
   others, people involved in the discussion were Ted Lemon, Ralph
   Weber, Normen Kowalewski, and Mikael Abrahamsson.  People involved in
   the email discussion initiated by Jim Gettys were, with among others,
   Paul Wouters, Joe Abley and Michael Richardson.

   The current document has been initiated after a discussion with Paul
   Wouter and Evan Hunt.

14.  References

14.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <http://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <http://www.rfc-editor.org/info/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <http://www.rfc-editor.org/info/rfc4033>.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <http://www.rfc-editor.org/info/rfc4034>.

Migault, et al.         Expires December 29, 2017              [Page 11]
Internet-Draft        DNSSEC Validator Requirements            June 2017

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
              <http://www.rfc-editor.org/info/rfc4035>.

   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
              Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
              September 2007, <http://www.rfc-editor.org/info/rfc5011>.

   [RFC6975]  Crocker, S. and S. Rose, "Signaling Cryptographic
              Algorithm Understanding in DNS Security Extensions
              (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013,
              <http://www.rfc-editor.org/info/rfc6975>.

14.2.  Informational References

   [I-D.ietf-dnsop-rfc5011-security-considerations]
              Hardaker, W. and W. Kumari, "Security Considerations for
              RFC5011 Publishers", draft-ietf-dnsop-rfc5011-security-
              considerations-02 (work in progress), June 2017.

   [I-D.ietf-ipsecme-rfc4307bis]
              Nir, Y., Kivinen, T., Wouters, P., and D. Migault,
              "Algorithm Implementation Requirements and Usage Guidance
              for IKEv2", draft-ietf-ipsecme-rfc4307bis-18 (work in
              progress), March 2017.

   [I-D.ietf-ipsecme-rfc7321bis]
              Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T.
              Kivinen, "Cryptographic Algorithm Implementation
              Requirements and Usage Guidance for Encapsulating Security
              Payload (ESP) and Authentication Header (AH)", draft-ietf-
              ipsecme-rfc7321bis-06 (work in progress), June 2017.

   [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
              Operational Practices, Version 2", RFC 6781,
              DOI 10.17487/RFC6781, December 2012,
              <http://www.rfc-editor.org/info/rfc6781>.

   [RFC7583]  Morris, S., Ihren, J., Dickinson, J., and W. Mekking,
              "DNSSEC Key Rollover Timing Considerations", RFC 7583,
              DOI 10.17487/RFC7583, October 2015,
              <http://www.rfc-editor.org/info/rfc7583>.

   [RFC7646]  Ebersman, P., Kumari, W., Griffiths, C., Livingood, J.,
              and R. Weber, "Definition and Use of DNSSEC Negative Trust
              Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015,
              <http://www.rfc-editor.org/info/rfc7646>.

Migault, et al.         Expires December 29, 2017              [Page 12]
Internet-Draft        DNSSEC Validator Requirements            June 2017

   [RFC7958]  Abley, J., Schlyter, J., Bailey, G., and P. Hoffman,
              "DNSSEC Trust Anchor Publication for the Root Zone",
              RFC 7958, DOI 10.17487/RFC7958, August 2016,
              <http://www.rfc-editor.org/info/rfc7958>.

   [UNBOUND-ANCHOR]
              "unbound-anchor.c File Reference",
              <https://www.unbound.net/documentation/doxygen/unbound-
              anchor_8c.html#details>.

Authors' Addresses

   Daniel Migault
   Ericsson

   Email: daniel.migault@ericsson.com

   Dan York
   Internet Society

   Email: york@isoc.org

   Edward Lewis
   ICANN

   Email: edward.lewis@icann.org

Migault, et al.         Expires December 29, 2017              [Page 13]