template W. Kumari
Internet-Draft Google
Intended status: Informational O. Gudmundsson
Expires: August 22, 2013 Shinkuro Inc.
G. Barwood
February 18, 2013
Easy DNSSEC Key Publish
draft-kumari-ogud-dnsop-cds-00
Abstract
This document describes a method to allow DNS operators to more
easily publish updated DNSSEC Key Signing Keys. This document does
not address the initial configuration of trust anchors for a domain.
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 August 22, 2013.
Copyright Notice
Copyright (c) 2013 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.
Kumari, et al. Expires August 22, 2013 [Page 1]
Internet-Draft ezkeyroll February 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. CDS Resource Record Format . . . . . . . . . . . . . . . . . . 4
4. CDS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Periodic check by parental agent . . . . . . . . . . . . . 5
5. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Going unsigned . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Kumari, et al. Expires August 22, 2013 [Page 2]
Internet-Draft ezkeyroll February 2013
1. Introduction
When a DNS operator first signs their zone they need to communicate
their DS record(s) (or DNSKEY(s)) to their parent through some out of
band method. In many cases this is a fairly annoying and manual
process. Unfortunately, every time the child rolls their KSK (Key
Signing Key) key they have to repeat the process, possibly multiple
times. As this is a manual process DNS operators often avoid rolling
their keys, as they don't want to have to do go through the annoyance
of publishing the new keys.
This document describes a method to automate publication of
subsequent DS records, after the initial one has been published.
Readers are expected to be familiar with DNSSEC, including [RFC4033],
[RFC4034], [RFC4035] and [RFC6781].
This document is a compilation of two earlier drafts,
draft-barwood-dnsop-ds-publish and draft-wkumari-dnsop-ezkeyroll
This document outlines a technique in which the parent (often
registrar / registry) periodically polls its signed children and
automatically publish new DS records. To a large extent the
procedures this document follows are in [RFC6781] section 4.1.2
This technique is in some ways similar to RFC 5011 style rollovers,
but for subdomains instead of trust anchors
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. Background
For ease of explanation, we will mainly describe the "standard" case
where a DNS operator registers a domain though a registrar, who then
publishes the information in a registry, but this same technique can
be used anywhere where a child needs to update their DS resource
record. We will also assume that the registrar provides a web
interface for adding DS resource record information; in a
distressingly large number of cases the registrar doesn't (yet) have
this functionality, and so the operator has to communicate their DS
to the registrar through email or a telephone call, but the actual
mechanism doesn't matter. We will further assume that the registrant
is also the DNS operator - this technique is expandable to any
Kumari, et al. Expires August 22, 2013 [Page 3]
Internet-Draft ezkeyroll February 2013
relationship, but the background explanation gets more tricky.
After an DNS operator first signs its zone, they login to the
registrar's web interface and then paste in the zone's DS
information. The registrar then communicates the DS record to the
registry who publishes it. The action of logging in through the web
interface authenticates that the user is authorized to publish in the
zone.
Eventually the registrant may want to publish a new DS record in the
parent, either because they are rolling their keys, or because they
want to publish a stand-by key DS record. This involves performing
the same process -- logging into a web interfaces, selecting the
domain, finding the link to change DNSSEC information, pasting (or
typing) their DS record (often in a non-standard format) and clicking
submit (in a real world test, this took 12 steps and approximately 3
minutes). As humans (especially DNS operators :-)) dislike tedious,
repetitive steps they often avoid rolling their DNSSEC keys to avoid
having to perform this.
3. CDS Resource Record Format
The wire and presentation format of the CDS ("Child DS") record is
identical to the DS record. IANA has allocated RR code 59 for the
CDS record.
However no special processing is performed by authoritative servers
or by resolvers, when serving or resolving. CDS unlike a DS resides
in the child zone.
The CDS record MUST be signed with a key that has the Secure Entry
Point flag set, just like the DNSKEY record.
4. CDS Behavior
The CDS RRset MAY be used by the parent (or a parental
representative) to update the DS RRset in the parent zone we call
this entity "parental agent".
In many environments (for example, gTLDs) the parent will be a
registry, and is expected to not have direct contact with the child
(registrant). In these cases, the registrar (or a contractor for the
registrar) will be the one that queries the child zone for the CDS
record, and if found, will publish it in the parent (probably using
[RFC5734]). It is conceivable that this could be a "value added"
service.
Kumari, et al. Expires August 22, 2013 [Page 4]
Internet-Draft ezkeyroll February 2013
Transfer of the contents of the CDS record can be accomplished in a
number of ways. A parental agent MAY periodically check the child
zone to see if the CDS RRset has changed. The child MAY request that
the parent check the CDS set via registration interface, or via some
other automated mechanism.
The child MUST make sure that the CDS RRset is at all times
validatable using a DNSKEY that is referenced from the current DS set
in the parent. This can be accomplished by making sure that at all
times during a KEY rollover there are either two DS records or two
DNSKEY records with SEP bit published in the DNS.
When using CDS to publish its key rollover information it is the
child's responsibility to monitor the parent for changes to the DS
RRset before performing the next action in the key rollover sequence.
What this implies is that the child MUST NOT follow a strict timeline
but rather strict sequence of steps with time checks.
4.1. Periodic check by parental agent
In this case the parental agent will query each child zone that has a
DS RRset, looking for CDS RRset
If present the parental agent MUST validate [[RFC4035]] the CDS
RRset. If the validation succeeds with a DNSKEY that is represented
in the current DS RRset in parent. The parenteral agent should
submit a request to the registry to publish the contents of the CDS
RR(s) as the new a DS record(s) for that zone. The parental agent
SHOULD log the date and time when of this action including the
signature initiation time on the CDS record. The registry should log
if possible the source of the update, user interface/CDS etc.
5. Usage
The parent zone SHOULD ensure that old versions of the CDS RRset do
not overwrite newer versions, which can occur the parent performs the
checks too frequently. In that case when there is a delay updating
secondary name servers for the child zone. This MAY be accomplished
by checking that the signature inception in the RRSIG for CDS is
newer
If the CDS RRset does not exist, the parent MUST take no action.
Specifically it MUST NOT delete the existing DS RRset.
If the child zone loses the secret key(s) for the zone, and needs to
reset the parent DS RRset, this must be accomplished by an out-of-
band mechanism not defined here.
Kumari, et al. Expires August 22, 2013 [Page 5]
Internet-Draft ezkeyroll February 2013
To mitigate situations where a key signing key has been compromised,
the parent zone MAY take extra security measures, for example
informing ( by email or other methods ) the zone administrator of the
change, and delaying the acceptance of the new DS RRset for some
period of time. However the precise out-of-band measures that a
parent zone SHOULD take are outside the scope of this document.
5.1. Going unsigned
In theory the child can use the CDS to reflect the parent to remove
the DS records. This can be accomplished by publishing CDS record
with the following contents:
@ IN CDS 0 0 0
This is an suggestion and its security implications have not been
fully examined but an RFC5011 like process should be used before this
is accepted.
If a child zone has gone unsigned, i.e. no DNSKEY and no RRsigs in
the zone, the parental representative MAY treat that as intent to go
unsigned. (NEEDS DISCUSSION).
6. IANA Considerations
IANA has assigned RR Type code 59 for CDS. This was done for an
earlier version of this document (draft-barwood-dnsop-ds-publish).
7. Security Considerations
[ This needs a more work, suggestions welcome.]
In the event of a compromise of the server generating signatures for
a zone, attacker may be able to generate and publish new CDS records.
These will be picked up by this technique and so may allow the
attacker to extend the effective time of his attack. This can be
dealt with by contacting the parent (potentially though a registrar
web interface) and removing any compromised DS keys.
A compromise of the registrar, will not be mitigated by this
technique
While it may be tempting, this should NOT be used for initial
enrolment of keys since there is no way to ensure that the initial
key is the correct one.
Kumari, et al. Expires August 22, 2013 [Page 6]
Internet-Draft ezkeyroll February 2013
The CDS RRtype should allow for enhanced security by simplifying
process. Since rollover is automated, updating a DS RRset by other
means may be regarded as unusual and subject to extra security
checks.
8. Acknowledgements
This is by no means the invention of the authors. This idea has been
floating around for a long time. This simply documents it for
discussion.
We would like to thank: Joe Abley, Roy Arends, Jim Galvin, Cricket
Liu, Matt Larson, Olaf Kolkman, Suzanne Woolfe.
There were a large number of other folk with whom we discussed this,
apologies for not remembering everyone.
9. References
9.1. Normative References
[IANA.AS_Numbers]
IANA, "Autonomous System (AS) Numbers",
<http://www.iana.org/assignments/as-numbers>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
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.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
Kumari, et al. Expires August 22, 2013 [Page 7]
Internet-Draft ezkeyroll February 2013
[RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Transport over TCP", STD 69, RFC 5734, August 2009.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781,
December 2012.
Appendix A. Changes / Author Notes.
[RFC Editor: Please remove this section before publication ]
From -00 to -01.
o Nothing changed in the template!
Authors' Addresses
Warren Kumari
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: warren@kumari.net
Olafur Gudmundsson
Shinkuro Inc.
4922 Fairmont Av, Suite 250
Bethsda, MD 20814
USA
Email: ogud@ogud.com
George Barwood
33 Sandpiper Close
Gloucester GL2 4LZ
United Kingdom
Email: warren@kumari.net
Kumari, et al. Expires August 22, 2013 [Page 8]