Network Working Group W. Kumari Internet-Draft Google Intended status: Informational G. Huston Expires: April 7, 2016 APNIC E. Hunt Internet Systems Consortium R. Arends ICANN October 5, 2015 Signalling of DNS Security (DNSSEC) Trust Anchors draft-wkumari-dnsop-trust-management-01 Abstract [ 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. ] 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. It is primarily aimed at the root DNSSEC trust anchor, but should be applicable to trust anchors elsewhere in the DNS as well. [ 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.] [ Ed note: Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, etc. They will be removed before publication.] [ 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 ] Kumari, et al. Expires April 7, 2016 [Page 1] Internet-Draft draft-wkumari-dnsop-trust-management October 2015 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 April 7, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 2. Trust Anchor Telemetry . . . . . . . . . . . . . . . . . . . 3 2.1. TAT Name Format . . . . . . . . . . . . . . . . . . . . . 4 3. Sending the Trust Anchor Telemetry Query . . . . . . . . . . 5 4. Known issues and limitations . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 7 Kumari, et al. Expires April 7, 2016 [Page 2] Internet-Draft draft-wkumari-dnsop-trust-management October 2015 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction 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.). [RFC5011] provides a secure mechanism to do this, but operational experience has demonstrated a need for some additional functionality that was not foreseen. 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. 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 [RFC7344] and [RFC5011]. 1.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. Trust Anchor Telemetry 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 Name, a format which encodes the list of the trust anchors for that zone that are currently in use by the validating resolver, along with status information about each key. Telemetry information can be retrieved by the trust anchor maintainer by examining logged queries that match the TAT Name format. Kumari, et al. Expires April 7, 2016 [Page 3] Internet-Draft draft-wkumari-dnsop-trust-management October 2015 2.1. TAT Name Format The TAT Name is generated as follows: 1. 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.] 2. Follow each string with a character indicating the status of the key from the resolver's point of view: S Static trust anchor, not subject to [RFC5011] A Accepted trust anchor P Pending trust anchor, not yet accepted R Revoked trust anchor 3. Sort the list in numerically ascending order of Algorithm and Key Tag. 4. Concatenate the list, with each string used as a label in a domain name. 5. Append _tat. Assuming no more than two digits for the Algorithm and five for the Key Tag, a TAT Name for the root zone can encode up to 24 trust anchors. [ Someone should probably check my math. QUESTION: Do we need to specify what will happen in the crazy case of a resolver having configured more than 24 trust anchors? -each ] Examples: o 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. o If the resolver were configured to use [RFC5011] trust anchor management, it would send 8_19036A._tat. o 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 Kumari, et al. Expires April 7, 2016 [Page 4] Internet-Draft draft-wkumari-dnsop-trust-management October 2015 for 8_1999P.8_19036A._tat. After the hold-down timer ([RFC5011] Section 2.2) had expired, the resolver would send a query for 8_1999A.8_19036A._tat. o 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. 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.] 3. Sending the Trust Anchor Telemetry Query When a compliant validating resolver performs the "Active Refresh" query as part of its RFC5011 ([RFC5011] Section 2.3)) processing it will also send a query for the TAT Name. This SHOULD be the default for compliant resolvers. 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. 4. Known issues and limitations 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 achievable. In particular: 1. Only compliant resolvers will send telemetry queries; no information is provided from legacy resolvers, or from those who choose to disable this functionality. 2. 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 Kumari, et al. Expires April 7, 2016 [Page 5] Internet-Draft draft-wkumari-dnsop-trust-management October 2015 the _TAT subdomain; subsequent client queries would be answered from the cache rather than forwarded to the trust anchor zone.) 3. 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. [ Open Questions: 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...) 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. 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.) 5. IANA Considerations [ Ed note: This is largely a place holder. The real IANA considerations section will require updating things like the DPS, etc. ] 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. There will need to be some text added to the DNSSEC Ceremony to handle this. 6. Security Considerations [ Ed note: a placeholder as well ] 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 / Kumari, et al. Expires April 7, 2016 [Page 6] Internet-Draft draft-wkumari-dnsop-trust-management October 2015 revoked trust anchor and perform a MitM attack. This would also require the attacker to have factored the private key. This seems farfetched.... 7. Contributors A number of people contributed significantly to this document, including Joe Abley, Paul Wouters, Paul Hoffman. Wes Hardaker and David Conrad. 8. Acknowledgements 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [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, . [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, September 2007, . [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 10.17487/RFC7344, September 2014, . 9.2. Informative References [I-D.ietf-sidr-iana-objects] Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects issued by IANA", draft-ietf-sidr-iana-objects-03 (work in progress), May 2011. Appendix A. Changes / Author Notes. [RFC Editor: Please remove this section before publication ] From -00 to -01.1: Kumari, et al. Expires April 7, 2016 [Page 7] Internet-Draft draft-wkumari-dnsop-trust-management October 2015 o Ripped all the actual keyroll logic out. o Added Geoff, Evan and Roy as authors. o Added some limitations and known issues. o Renamed to TAT, added tag describing the state of the TA. From -00.1 to -00 (published): o Integrated comments and feedback from DRC and Paul Hoffman. o Use _ as a prefix to make clear it is meta-type (drc) From -00.0 to -00.1 o Initial draft, written in an airport lounge. Authors' Addresses Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 US Email: warren@kumari.net Geoff Huston APNIC 6 Cordelia St South Brisbane QLD 4001 AUS Email: gih@apnic.net Evan Hunt Internet Systems Consortium 950 Charter St Redwood City, CA 94063 US Email: each@isc.org Kumari, et al. Expires April 7, 2016 [Page 8] Internet-Draft draft-wkumari-dnsop-trust-management October 2015 Roy Arends ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 US Email: roy.arends@icann.org Kumari, et al. Expires April 7, 2016 [Page 9]