draft-wkumari-dnsop-trust-management.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" ".//reference.RFC.2119.xml">
]>
<!-- WK: Set category, IPR, docName -->
<!-- WK: Testing edit in github itself... -->
<rfc category="info" docName="draft-wkumari-dnsop-trust-management-01"
     ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes"?>

  <?rfc compact="yes" ?>

  <front>
    <!-- WK: Set long title. -->

    <title abbrev="draft-wkumari-dnsop-trust-management">Signalling of DNS
    Security (DNSSEC) Trust Anchors</title>

    <author fullname="Warren Kumari" initials="W." surname="Kumari">
      <organization>Google</organization>

      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>

          <city>Mountain View, CA</city>

          <code>94043</code>

          <country>US</country>
        </postal>

        <email>warren@kumari.net</email>
      </address>
    </author>

    <author fullname="Geoff Huston" initials="G." surname="Huston">
      <organization>APNIC</organization>

      <address>
        <postal>
          <street>6 Cordelia St</street>

          <city>South Brisbane QLD</city>

          <code>4001</code>

          <country>AUS</country>
        </postal>

        <email>gih@apnic.net</email>
      </address>
    </author>

    <author fullname="Evan Hunt" initials="E." surname="Hunt">
      <organization>Internet Systems Consortium</organization>

      <address>
        <postal>
          <street>950 Charter St</street>

          <city>Redwood City, CA</city>

          <code>94063</code>

          <country>US</country>
        </postal>

        <email>each@isc.org</email>
      </address>
    </author>

    <author fullname="Roy Arends" initials="R." surname="Arends">
      <organization>ICANN</organization>

      <address>
        <postal>
          <street>12025 Waterfront Drive, Suite 300</street>

          <city>Los Angeles, CA</city>

          <code>90094-2536</code>

          <country>US</country>
        </postal>

        <email>roy.arends@icann.org</email>
      </address>
    </author>

    <date day="25" month="September" year="2015"/>

    <area>template</area>

    <workgroup>template</workgroup>

    <abstract>
      <t>[ Editor note: This originally included a mechanism to actually roll
      the keys (like RFC5011 does), but feedback from the Prague meeting
      indicated a strong preference for signalling only. ]</t>

      <t>This document describes a simple method for validating recursive
      resolvers to signal their configured list of DNSSEC trust anchors. This
      mechanism allows the trust anchor maintainer to monitor the progress of
      the migration to a new trust anchor, and so predict the effect before
      decommissioning the existing trust anchor.</t>

      <t>It is primarily aimed at the root DNSSEC trust anchor, but should be
      applicable to trust anchors elsewhere in the DNS as well.</t>

      <t>[ Ed note - informal summary: One of the big issues with rolling the
      root key is that it is unclear who all is using RFC5011, who all has
      successfully fetched and installed the new key, and, most importantly,
      who all will die when the old key is revoked. By having resolvers query
      for a special QNAME, comprised of the list of TAs that it knows about,
      we effectively signal "up stream" to the authoritative server. By
      querying for this name, the recursive exposes its list of TAs to this
      authoritative server. This allows the TA maintainer to gather
      information relating to the state of TAs on resolvers.]</t>

      <t>[ Ed note: Text inside square brackets ([]) is additional background
      information, answers to frequently asked questions, general musings,
      etc. They will be removed before publication.]</t>

      <t>[ This document is being collaborated on in Github at:
      https://github.com/wkumari/draft-wkumari-dnsop-trust-management. The
      most recent version of the document, open issues, etc should all be
      available here. The authors (gratefully) accept pull requests ]</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>When a DNSSEC-aware resolver performs validation, it requires a trust
      anchor to validate the DNSSEC chain. An example of a trust anchor is the
      so called DNSSEC "root key". For a variety of reasons, this trust anchor
      may need to be replaced or "rolled", to a new key (potentially with a
      different algorithm, different key length, etc.).</t>

      <t><xref target="RFC5011"/> provides a secure mechanism to do this, but
      operational experience has demonstrated a need for some additional
      functionality that was not foreseen.</t>

      <t>During the current efforts to roll the IANA DNSSEC "root key", it has
      become clear that, in order to predict (and minimize) outages caused by
      rolling the key, real-time information about the uptake of the new key
      will be needed.</t>

      <t>This document defines a mechanism ("trust anchor telemetry") by which
      validating resolvers can provide information about their configured
      trust anchors. Readers of this document are expected to be familiar with
      the contents of <xref target="RFC7344"/> and <xref
      target="RFC5011"/>.</t>

      <section title="Requirements notation">
        <t>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 <xref
        target="RFC2119"/>.</t>
      </section>
    </section>

    <section title="Trust Anchor Telemetry Query">
      <t>The purpose of the mechanism described in this document is to allow
      the trust anchor maintainer to determine how widely deployed a given
      trust anchor is. This information is signaled from the validating
      resolver to the authoritative servers serving the zone in which the
      trust anchor lives by sending a periodic query to that zone. The query
      type of the TAT Query is NULL. The query name is a TAT Owner Name, a
      format which encodes the list of the trust anchors for that zone that
      are currently in use by the validating resolver, and optional metadata
      about each key. Telemetry information can be retrieved by the trust
      anchor maintainer by examining logged queries that match the TAT Name
      format.</t>

      <section title="TAT Name Format">
        <t>The TAT Name is generated as follows:<list style="numbers">
            <t>For each trust anchor that the resolver knows and/or is using,
            generate a string consisting of the key's Algorithm in decimal
            format, followed by an underscore ('_'), followed by the derived
            Key Tag in decimal format. [NOTE: If we used hex, this could just
            be AAKKKK, no need for a punctuation mark, but it would be less
            human-readable.]</t>

            <t>Follow each string with a character indicating the status of
            the key from the resolver's point of view: <list style="hanging">
                <t hangText="S">Static trust anchor, not subject to <xref
                target="RFC5011"/></t>

                <t hangText="A">Accepted trust anchor</t>

                <t hangText="P">Pending trust anchor, not yet accepted</t>

                <t hangText="R">Revoked trust anchor</t>
              </list></t>

            <t>Sort the list in numerically ascending order of Algorithm and
            Key Tag.</t>

            <t>Concatenate the list, with each string used as a label in a
            domain name.</t>

            <t>Append _tat.&lt;domain&gt;</t>
          </list></t>

        <t>Examples: <list style="symbols">
            <t>If the resolver has a single trust anchor statically configured
            for the root zone, with an algorithm of RSASHA256 and a Key Tag of
            19036, it would emit a query for 8_19036S._tat.</t>

            <t>If the resolver were configured to use <xref target="RFC5011"/>
            trust anchor management, it would send 8_19036A._tat.</t>

            <t>If a new key with Key Tag 1999 was added to the root zone and
            had been seen by the resolver, but was too recent to have been
            accepted as a trust anchor, then the resolver would send a query
            for 8_1999P.8_19036A._tat. After the hold-down timer (<xref
            target="RFC5011"/> Section 2.2) had expired, the resolver would
            send a query for 8_1999A.8_19036A._tat.</t>

            <t>If there is a separate static trust anchor configured for
            example.com with an algorithm of RSASHA1 and a Key Tag of 1234,
            the resolver would send a query for 5_1234S._tat.example.com.</t>
          </list></t>

        <t>NOTE: The format of the TAT Name requires that Key Tags MUST be
        unique, at least within "recent" history. If (e.g during a Key
        Ceremony) a new DNSKEY is generated whose derived Key Tag collides
        with an exiting one (statistically unlikely, but not impossible) this
        DNSKEY MUST NOT be used, and a new DNSKEY MUST be generated. [ Ed
        note: This is to prevent two successive keys having the same keytag
        (e.g: 123), and then seeing "8_123A." - which 123 key was that?!
        RFC4034 Appendix B admonition: "Implementations MUST NOT assume that
        the key tag uniquely identifies a DNSKEY RR", but this appears to be
        targeted at validating resolver implmentations.]</t>
      </section>
    </section>

    <section title="Sending the Trust Anchor Telemetry Query">
      <t>When a compliant validating resolver performs the "Active Refresh"
      query as part of its RFC5011 (<xref target="RFC5011"/> Section 2.3))
      processing it will also send a query for the TAT Name. This SHOULD be
      the default for compliant resolvers.</t>

      <t>It will receive back either a negative response (e.g. NXDOMAIN), or a
      (nonsensical) answer. As the entire purpose of this query is to send
      information from a recursive resolver to the nameservers that serve the
      zone containing a trust anchor, the response to the query contains no
      useful information and MUST be ignored.</t>
    </section>

    <section title="Known issues and limitations">
      <t>This solution is designed to provide a rough idea of the rate of
      uptake of a new key during a key rollover; perfect visibility is not an
      achievable. In particular: <list style="numbers">
          <t>Only compliant resolvers will send telemetry queries; no
          information is provided from legacy resolvers, or from those who
          choose to disable this functionality.</t>

          <t>The trust anchor maintainer has no way to differentiate a query
          that is emitted by the resolver itself from a query that is
          forwarded through the resolver. (Note, however, that forwarded
          queries are likely to be infrequent; responses to TAT queries will
          in most cases be negatively cached with an NXDOMAIN covering the
          _TAT subdomain; subsequent queries will be answered from the cache
          rather than forwarded to the trust anchor zone.)</t>

          <t>An attacker could forge TAT queries to trick the trust anchor
          maintainer into a false impression of the adoption rate of a new
          trust anchor, if there were a perceived advantage to doing so.</t>
        </list></t>

      <t>[ Open Questions:</t>

      <t>1: In order to disambiguate queries from resolvers versus those
      forwarded through resolvers (or being recursed because of users behind
      the resolver) we *could* add craziness like having resolvers include
      ephemeral UUIDs or something...). Is this worth doing? (Personally I
      think not...)</t>

      <t>2: We *could* also specify that compliant resolvers MUST NOT forward
      queries of type TDS to try limit this. Worth doing? This is some of the
      reason for having a defined type.</t>

      <t>3: The authorative server *could* return a record with a long TTL to
      stop queries (if it knows that it is not doing a rollover in the near
      future). This seems like a simple option, worth doing? (I think so).
      (each thinks not.)</t>
    </section>

    <section title="IANA Considerations">
      <t>[ Ed note: This is largely a place holder. The real IANA
      considerations section will require updating things like the DPS, etc.
      ]</t>

      <t>The format of the TAT query requires that Key Tags MUST be unique, at
      least within an interval. If, during a Key Ceremony, a new DNSKEY is
      generated whose derived Key Tag collides with an exiting one
      (statistically unlikely, but not impossible) this DNSKEY MUST NOT be
      used, and a new DNSKEY MUST be generated.</t>

      <t>There will need to be some text added to the DNSSEC Ceremony to
      handle this.</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>[ Ed note: a placeholder as well ]</t>

      <t>This mechanism causes a recursive resolver to disclose the list of
      trust anchors that it knows about to the authorative servers serving the
      zone containing the TA (or attackers able to monitor the path between
      these devices). It is conceviable that an attacker may be able to use
      this to determine that a resolver trusts an outdated / revoked trust
      anchor and perform a MitM attack. This would also require the attacker
      to have factored the private key. This seems farfetched....</t>
    </section>

    <section title="Contributors">
      <t>A number of people contributed significantly to this document,
      including Joe Abley, Paul Wouters, Paul Hoffman. Wes Hardaker and David
      Conrad.</t>
    </section>

    <section title="Acknowledgements">
      <t/>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.4034'?>

      <?rfc include='reference.RFC.5011'?>

      <?rfc include='reference.RFC.7344'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.draft-ietf-sidr-iana-objects-03.xml'?>
    </references>

    <section title="Changes / Author Notes.">
      <t>[RFC Editor: Please remove this section before publication ]</t>

      <t>From -00 to -01.1:<list style="symbols">
          <t>Ripped all the actual keyroll logic out.</t>

          <t>Added Geoff, Evan and Roy as authors.</t>

          <t>Added some limitations and known issues.</t>

          <t>Renamed to TAT, added tag describing the state of the TA.</t>
        </list></t>

      <t>From -00.1 to -00 (published):<list style="symbols">
          <t>Integrated comments and feedback from DRC and Paul Hoffman.</t>

          <t>Use _ as a prefix to make clear it is meta-type (drc)</t>
        </list></t>

      <t>From -00.0 to -00.1</t>

      <t><list style="symbols">
          <t>Initial draft, written in an airport lounge.</t>
        </list></t>
    </section>
  </back>
</rfc>