One document matched: draft-ietf-dnsop-maintain-ds-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>
<rfc ipr="trust200902" category="info" docName="draft-ietf-dnsop-maintain-ds-01">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc private=""?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<front>
<title abbrev="DS-maintain-ds">Managing DS records from parent via CDS/CDNSKEY</title>

<author initials="O." surname="Gudmundsson" fullname="Olafur Gudmundsson">
<organization>CloudFlare</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
<region></region>
</postal>
<phone></phone>
<email>olafur+ietf@cloudflare.com</email>
<uri></uri>
</address>
</author>
<author initials="P." surname="Wouters" fullname="Paul Wouters">
<organization>Red Hat</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
<region></region>
</postal>
<phone></phone>
<email>pwouters@redhat.com</email>
<uri></uri>
</address>
</author>
<date year="2016" month="March" day="20"/>

<area>Operations</area>
<workgroup>dnsop</workgroup>
<keyword>dnssec</keyword>
<keyword>trust maintenance</keyword>


<abstract>
<t>RFC7344 specifies how DNS trust can be partially maintained in-band between parent
and child. There are two features missing in that specification:
initial trust setup and removal of trust anchor. This document
addresses both these omissions.
</t>
<t>Changing a domain's DNSSEC status can be a complicated matter involving
multiple unrelated parties. Some of these parties, such as the DNS operator, might
not even be known by all organizations involved. The inability to
disable DNSSEC via in-band signalling is seen as a problem
or liability that prevents some DNSSEC adoption at large scale. This
document adds a method for in-band signalling of this DNSSEC status changes.
</t>
<t>Initial trust is considered a much harder problem, this document will
seek to clarify and simplify the initial acceptance policy.
</t>
</abstract>

</front>

<middle>

<section anchor="introduction" title="Introduction">
<t>CDS/CDNSKEY <xref target="RFC7344"/> records are used to signal changes in trust
anchors, this is one method to maintain delegations that can be used when
the DNS operator has no other way to inform the parent that changes are
needed. RFC7344 contains no "delete" signal for the child to tell the parent
that it wants to remove the DNSSEC security for its domain.
</t>
<t><xref target="RFC7344"/> did not include a method for the Initial Trust establishment and
left it to each parent to come up with an acceptance policy.
</t>

<section anchor="removing-a-ds-record" title="Removing a DS Record">
<t>This document introduces the delete option for both CDS and CDNSKEY,
allowing a child to signal to the parent to turn off DNSSEC.
When a domain is moved from one DNS operator to another one, sometimes
it is necessary to turn off DNSSEC to facilitate the change of DNS
operator. Common scenarios include:

</t>
<t>
<list style="format %d">
<t>alternative to doing a proper DNSSEC algorithm rollover due to operational
limitations such as software limitations.</t>
<t>moving from a DNSSEC operator to a non-DNSSEC capable operator.</t>
<t>moving to an operator that cannot/does-not-want to do a proper DNSSEC rollover.</t>
<t>when moving between two DNS operators that use disjoint sets of algorithms
to sign the zone, thus an algorithm rollover can not be performed.</t>
<t>the domain holder no longer wants DNSSEC enabled.</t>
</list>
</t>
<t>The lack of a "remove my DNSSEC" option is cited as a reason why
some operators cannot deploy DNSSEC, as this is seen as an operational risk.
</t>
<t>Turning off DNSSEC reduces the security of the domain and thus should
only be done carefully, and that decision should be fully under the
child domain's control.
</t>
</section>

<section anchor="introducing-a-ds-record" title="Introducing a DS record">
<t>The converse issue is how a child domain instructs the parent that it
wants to have a DS record added. This problem can be solved using a
few simplifying assumptions. This document makes the assumption that
there are reasonable policies that can be applied and will allow automation
of trust introduction.
</t>
<t>Not being able to enable trust via an easily automated mechanism is
hindering DNSSEC at scale for DNS hosters that do not have automated
access to the "registry" of the child zone's parent.
</t>
</section>

<section anchor="notation" title="Notation">
<t>When this document uses the word CDS it implies that the same applies
to CDNSKEY and vice versa. The only difference between the two
records is how information is represented.
</t>
<t>We use RRR to mean Registry Registrar Registrant in the context of DNS
domain markets.
</t>
<t>When the document uses the word "parent" it implies an entity that is
authorized to insert DS records into the parent zone on behalf of the child
domain. Which entity this exactly is does not matter. It could be
the Registrar or Reseller that the child domain was purchased from. It
could be the Registry that the domain is registered in when
allowed. It could be some other entity when the RRR framework is not
used.
</t>
</section>

<section anchor="terminology" title="Terminology">
<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 anchor="the-three-uses-of-cds" title="The Three Uses of CDS">
<t>In general there are three operations that a domain wants to influence
on its parent:

</t>
<t>
<list style="format %d">
<t>Roll over KSK, this means updating the DS records in the parent to
reflect the new set of KSK's at the child. This could be an ADD
operation, a DELETE operation on one or more records while keeping at
least one DS RR, or a full REPLACE operation.</t>
<t>Turn off DNSSEC validation, i.e. delete all the DS records.</t>
<t>Enable DNSSEC validation, i.e. place an initial DS RRset in the parent.</t>
</list>
</t>
<t>Operation 1 is covered in <xref target="RFC7344"/>, operations 2 and 3 are defined in this
document. In many people's minds, those two later operations carry more
risk than the first one. This document argues that 2 is identical to 1
and the third one is different (but not that different).
</t>

<section anchor="the-meaning-of-the-cds-rrset" title="The meaning of the CDS RRset">
<t>The semantic meaning of publishing a CDS RRset is interpreted to mean:
</t>
<t>"Publishing a CDS or CDNSKEY record signals to the parent that the
child desires that the corresponding DS records be synchronized. Every
parent or parental agent should have an acceptance policy of these
records for the three different use cases involved:
Initial DS publication, Key rollover, and Returning to Insecure."
</t>
<t>In short, the CDS RRset is an instruction to the parent to modify DS RRset if
the CDS and DS RRsets differ. The acceptance policy for CDS in the rollover
case is "seeing" according to <xref target="RFC7344"/>. The acceptance policy in the Delete
case is seeing a (validly signed) CDS RRset with the delete operation
specified in this document.
</t>
</section>
</section>

<section anchor="enabling-dnssec-via-cdscdnskey" title="Enabling DNSSEC via CDS/CDNSKEY">
<t>There are number of different models for managing initial trust, but in
the general case, the child wants to enable global validation for the future.
Thus during the period from the time the child publishes the CDS until the
corresponding DS is published at the parent is the period that DNS answers for the
child could be forged. The goal is to keep this period as short as
possible.
</t>
<t>One important case is how a third party DNS operator can upload
its DNSSEC information to the parent, so the parent can publish
a DS record for the child.  In this case there is a possibility of setting
up some kind of authentication mechanism and submission mechanism that
is outside the scope of this document.
</t>
<t>Below are some policies that parents can use. These policies assume that
the notifications can be verified or authenticated.
</t>

<section anchor="accept-policy-via-authenticated-channel" title="Accept policy via authenticated channel">
<t>In this case the parent is notified via UI/API that a CDS RRset
exists. The parent retrieves the CDS and inserts the corresponding DS
RRset as requested, provided that the request comes over an authenticated
channel.
</t>
</section>

<section anchor="accept-with-extra-checks" title="Accept with extra checks">
<t>In this case the parent checks that the source of the notification is
allowed to request the DS insertion. The checks could include whether this is
a trusted entity, whether the nameservers correspond to the requestor, whether
there have been any changes in registration in the last few days, etc.
The parent can also send a notification requesting a confirmation.
</t>
<t>The end result is that the CDS RRset is accepted at the end of the checks
or when the out-of-band confirmation is received.
</t>
</section>

<section anchor="accept-after-delay" title="Accept after delay">
<t>In this case, if the parent deems the request valid, it starts monitoring
the CDS RRset at the child nameservers over period of time to make sure
nothing changes. After some time or after a number of checks, preferably
from different vantage points in the network, the parent accepts the
CDS RRset as a valid signal to update its DS RRset for this child.
</t>
</section>

<section anchor="accept-with-challenge" title="Accept with challenge">
<t>In this case the parent instructs the requestor to insert some record
into the child domain to prove it has the ability to do so (i.e., it is
the operator of the zone).
</t>
</section>
</section>

<section anchor="dnssec-delete-algorithm" title="DNSSEC Delete Algorithm">
<t>The DNSKEY algorithm registry contains two reserved values: 0 and 255<xref target="RFC4034"/>.
The CERT record <xref target="RFC4398"/> defines the value 0 to mean the algorithm
in the CERT record is not defined in DNSSEC.
</t>
<t>[rfc-editor remove before publication]
For this reason, using the value 0 in CDS/CDNSKEY delete operations is
potentially problematic, but we propose it here anyway as the risk
is minimal. The alternative is to reserve a DNSSEC algorithm number
for this purpose.
[rfc-editor end remove]
</t>
<t>Right now, no DNSSEC validator understands algorithm 0 as a valid
signature algorithm. If a validator sees a DNSKEY or DS record
with this algorithm value, it MUST treat it as unknown. Accordingly, the zone is
treated as unsigned unless there are other algorithms present.
</t>
<t>In the context of CDS and CDNSKEY records, DNSSEC algorithm 0 is defined
to mean that the entire DS RRset MUST be removed. The contents of the
CDS or CDNSKEY RRset MUST contain one RR and only contain the fixed
fields as shown below.

</t>
<t>
<list style="format %d">
<t>CDS 0 0 0</t>
<t>CDNSKEY 0 3 0</t>
</list>
</t>
<t>The keying material payload is represented by a single 0. This record
is signed in the same way as regular CDS/CDNSKEY RRsets are signed.
</t>
<t>Strictly speaking the CDS record could be "CDS X 0 X" as only the
DNSKEY algorithm is what signals the DELETE operation, but for clarity
the "0 0 0" notation is mandated - this is not a definition of DS
Digest algorithm 0. The same argument applies to "CDNSKEY 0 3 0",
the value 3 in second field is mandated by RFC4034 section 2.1.2.
</t>
<t>Once the parent has verified the CDS/CDNSKEY RRset and it has passed
other acceptance tests, the parent MUST remove the DS RRset. After waiting
a sufficient amount of time - depending the the parental TTL's - the child
can start the process of turning off DNSSEC.
</t>
</section>

<section anchor="security-considerations" title="Security considerations">
<t>This document's main goal is to avoid validation failures when a domain moves from
one DNS operator to another. Turning off DNSSEC reduces the security of the
domain and thus should only be done as a last resort.
</t>
<t>In most cases it is preferable that operators collaborate on the
rollover by doing a KSK+ZSK rollover as part of the hand-off, but that
is not always possible. This document addresses the case where
unsigned state is needed to complete a rollover.
</t>
<t>Users SHOULD keep in mind that re-establishing trust in delegation can
be hard and takes a long time. Before deciding to complete the rollover
via an unsigned state, all options SHOULD be considered.
</t>
<t>A parent SHOULD ensure that when it is allowing a child to become
securely delegated, that it has a reasonable assurance that the
CDS/CDNSKEY RRset that is used to bootstrap the security is visible
from a geographically and network topology diverse view. It SHOULD
also ensure the the zone validates correctly if the parent publishes the
DS record. A parent zone might also consider sending an email to
its contact addresses to give the child zone a warning that security
will be enabled after a certain about of wait time - thus allowing
a child administrator to cancel the request.
</t>
</section>

<section anchor="iana-considerations" title="IANA considerations">
<t>This document updates the following IANA registries: "DNS Security
Algorithm Numbers"
</t>
<t>Algorithm 0 adds a reference to this document.
</t>
</section>

</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7344.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4398.xml"?>
</references>

<section anchor="acknowledgements" title="Acknowledgements">
<t>This document is generated using the mmark tool that Miek Gieben has developed.
</t>
</section>

</back>
</rfc>