Simplified Updates of DNS Security (DNSSEC) Trust Anchors
draft-wkumari-dnsop-trust-management-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Warren "Ace" Kumari | ||
| Last updated | 2015-06-29 | ||
| Stream | (None) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wkumari-dnsop-trust-management-00
template W. Kumari
Internet-Draft Google
Intended status: Informational June 29, 2015
Expires: December 31, 2015
Simplified Updates of DNS Security (DNSSEC) Trust Anchors
draft-wkumari-dnsop-trust-management-00
Abstract
This document describes a simple means for automated updating of
DNSSEC trust anchors. This mechanism allows the trust anchor
maintainer to monitor the progress of the migration to the 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. A
secondary problem is that the response sizes suddenly increase,
potentially blowing the MTU limit. This document describes a method
that is basically CDS, but for the root key (or any other trust
anchor). Unlike the CDS record though, this record lives at a
special name - by querying for this name, the recursive exposes its
list of TAs to the auth server (signalling upstream) . This allows
the TA maintainer to predict how many, and who all will break. It
also allows the pre-publication of a key before using it, and so
avoids the need to double response sizes...]
[ 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 ]
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Kumari Expires December 31, 2015 [Page 1]
Internet-Draft draft-wkumari-dnsop-trust-management June 2015
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 31, 2015.
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. TDS Record Format . . . . . . . . . . . . . . . . . . . . . . 3
2.1. TDS Owner Name . . . . . . . . . . . . . . . . . . . . . 3
3. TDS Record Processing . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 6
Appendix B. Worked example . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
Kumari Expires December 31, 2015 [Page 2]
Internet-Draft draft-wkumari-dnsop-trust-management June 2015
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 recent effort to roll the IANA DNSSEC "root key", it has
become clear that, in order to predict (and minimize) outages caused
by rolling the key, one needs to know who does not have the new key.
In addition, RFC5011 style key rolls require "double signing", which
significantly increases the size of the responses.
This document defines a new record type, Trust DS (TDS), which
provides a mechanism very similar to the Child DS (CDS) [RFC7344]
record, and some practices for using it. Readers of this document
are expected to be familiar with the contents of [RFC7344].
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. TDS Record Format
The wire and presentation format of the Trust DS (TDS) resource
record is identical to the DS record [RFC4034].
IANA has allocated RR code TBD for the TDS resource record via Expert
Review [DNS-TRANSPORT]. The TDS RR uses the same registries as DS
for its fields. No special processing is performed by authoritative
servers or by resolvers, when serving or resolving.
For all practical purposes, TDS is a regular RR type.
2.1. TDS Owner Name
Much of the purpose of the mechanism described in this document is to
provide a mechanism to allow the trust anchor maintainer to determine
how widely deployed the trust anchor is, and who is using an outdated
trust anchor. This information is signalled from the validating
Kumari Expires December 31, 2015 [Page 3]
Internet-Draft draft-wkumari-dnsop-trust-management June 2015
resolver to the authoritative server serving the zone in which the
Trust Anchor lives.
This information is available from looking at queries to DNS servers
serving the DNSKEY for the zone; each resolver using this mechanism
will periodically query the zone for a name encoding the list of
trust anchors it is using for that zone.
This name is computed as follows:
1. Take the Key Tags of all of the DS records corresponding to the
TA(s) that the resolver knows / is using.
2. Sort this list in numerically ascending order
3. Concatenate the list, separating each Key Tag with a hyphen
('-'), then append this to an underscore ('_')
As an example, if the resolver has a single Trust Anchor with a Key
Tag of 4217, it would generate an owner name of _4217. If it has two
Trust Anchors, with Key Tags 1985 and 1776 it would generate an owner
name of _1776-1985.
NOTE: The generation of the TDS Name means 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 "_123." - which 123 key was that?!
RFC4034 Appendix B admonition: "Implementations MUST NOT assume that
the key tag uniquely identifies a DNSKEY RR" - I think that is for
validators though.]
3. TDS Record Processing
A compliant recursive resolver will periodically (every 'Active
Refresh' interval ([RFC5011] Section 2.3)) query the trust point
domain for the TDS Owner Name. It will receive back either an error
(e.g NoError / NoData), or a TDS RRSet. It will validate the TDS
record, using standard DNSSEC logic.
Assuming a TDS RRSet is received and validates, the resolver will
parse the RRSet. The RRSet will contain one or more TDS records,
listing the DS records that correspond to DNSKEYs that may sign the
zone. The resolver SHOULD store this list to its configuration /
persistent storage.
Kumari Expires December 31, 2015 [Page 4]
Internet-Draft draft-wkumari-dnsop-trust-management June 2015
[Ed note: See Appendix B for a worked example of performing a keyroll
using this mechanism. It's much less complex than this all makes it
sound...]
[Ed note - Corner cases. I didn't want to spend too long writing out
all of the handling for these until I've gotten some feedback on the
concept:]
1. The TDS doesn't validate. This is the same as in a non-TDS /
RFC5011 world. You entered the TA incorrectly, you are under
attack, or similar.
2. There is no TDS record (you get NoError / NoData). You have
somehow become out of sync with the system, or someone has
bungled the keyroll in an odd way. Panicking is a good option
here.
4. IANA Considerations
[ Ed note: This is largely a place holder. The real IANA
considerations section will require updating things like the DPS,
etc. ]
The generation of the TDS Name means 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.
In addition, the IANA is instructed to publish a TDS record
containing all trust anchors that are to be considered "trusted" for
the root key, with owner names as described above.
5. Security Considerations
[ Ed note: a placeholder as well ]
This mechanism can be used to roll from one trusted (whatever that
means) to a new key. It cannot, and should not be used to recover
from a (suspected) compromised key (this is true for RFC5011 as
well).
This relies upon the strength of the hashing algorithm in the DS.
Kumari Expires December 31, 2015 [Page 5]
Internet-Draft draft-wkumari-dnsop-trust-management June 2015
6. Contributors
A number of people contributed significantly to this document,
including Joe Abley, Paul Wouters, Paul Hoffman. Wes Hardaker and
David Conrad.
7. Acknowledgements
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", STD 74, RFC 5011, September 2007.
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344, September
2014.
8.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.1 to -00 (published):
Integrated comments and feedback from DRC and Paul Hoffman.
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.
Kumari Expires December 31, 2015 [Page 6]
Internet-Draft draft-wkumari-dnsop-trust-management June 2015
Appendix B. Worked example
This section provides an example of rolling the root trust anchor
from a DNSKEY with Key Tag 17 to one with Key Tag 42. It is written
informally, and will be tidied up / made more formal before
publication. To keep this readable, I've made key tags and hashes
and such be short.
The root trust anchor is RSA/SHA-1, generating a DS with SHA-1 the DS
works out to 17 5 1 111222 #(Tag RSA/SHA1 SHA1 Key). This DS is
installed into a root zone in a TDS record:
_17 IN TDS 17 5 1 111222
Compliant resolvers are configured with this information, by manually
placing this in thier config files (in the same way resolvers are
currently manually configred with the DNSKEY). The resolver will
periodically query the root for qname 17, type TDS. It will receive
(and validate!) this TDS record, will see that is has this key, and
will go back to sleep. The root TA maintainer can see that everyone
is using the key with ID 17.
Eventually the trust anchor maintainer withes to roll to a new RSA/
SHA-256 key, so they generate the new key. They compute the DS
(using SHA-256) and the computed DS is 42 (Tag) 8 (RSA/SHA-256) 2
(SHA-256) 333444. They now publish TDS records as follows:
_17 IN TDS 17 5 1 111222
IN TDS 42 8 2 333444
_17-42 IN TDS 17 5 1 111222
IN TDS 42 8 2 333444
A resolver who only knows about Key 17 queries for 17 and will now
start getting 2 TDS records and will see that this does not match
what is has configured, and so will add the 42 DS record to its
configured list of acceptable keys (now it has 17 and 42).
On its next scheduled check it will lookup _17-42 and see that it is
"in sync" and will go back to sleep. The trust anchor maintainer
will observe resolvers change from quering for 17 to querying for
_17-42. Hopefully everyone will end up querying for _17-42, but the
maintainer can observe who is still asking for 17 and trobleshoot
with them to see why they have not updated yet. At some point
(99.9%?), the maintainer will decide enough people have moved and can
now start using the new key, by adding it to the DNSKEY set (if they
are really brave / concerned about MTU they could just start using it
instead of the old key).
Kumari Expires December 31, 2015 [Page 7]
Internet-Draft draft-wkumari-dnsop-trust-management June 2015
The maintainer would now like to stop using the old key. They now
publish:
_17-42 IN TDS 42 8 2 333444
_42 IN TDS 42 8 2 333444
Resolvers will query for _17-42 and only receive the Key 42 record.
They will then remove the Key 17 record from thier config, leaving
only Key 42. They will then start querying just for 42, and see that
they are now in sync.
Remember: The DS records in the TDS RRSet define the entire set that
the trust anchor maintainer would like resolver operator to use for
that trust point.
Author's Address
Warren Kumari
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: warren@kumari.net
Kumari Expires December 31, 2015 [Page 8]