Managing DS records from parent via CDS/CDNSKEY
draft-ietf-dnsop-maintain-ds-06

Document Type Active Internet-Draft (dnsop WG)
Last updated 2017-01-11 (latest revision 2017-01-10)
Replaces draft-ogud-dnsop-maintain-ds
Stream IETF
Intended RFC status Proposed Standard
Formats plain text xml pdf html bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Tim Wicinski
Shepherd write-up Show (last changed 2016-06-21)
IESG IESG state RFC Ed Queue
Consensus Boilerplate Yes
Telechat date
Responsible AD Joel Jaeggli
Send notices to "Tim Wicinski" <tjw.ietf@gmail.com>
IANA IANA review state Version Changed - Review Needed
IANA action state RFC-Ed-Ack
RFC Editor RFC Editor state EDIT
dnsop                                                     O. Gudmundsson
Internet-Draft                                                CloudFlare
Intended status: Standards Track                              P. Wouters
Expires: July 14, 2017                                           Red Hat
                                                        January 10, 2017

            Managing DS records from parent via CDS/CDNSKEY
                    draft-ietf-dnsop-maintain-ds-06

Abstract

   RFC7344 specifies how DNS trust can be maintained across key
   rollovers in-band between parent and child.  This document elevates
   RFC7344 from informational to standards track and adds a standard
   track method for initial trust setup and removal of secure entry
   point.

   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 the organizations
   involved.  The inability to disable DNSSEC via in-band signaling is
   seen as a problem or liability that prevents some DNSSEC adoption at
   large scale.  This document adds a method for in-band signaling of
   these DNSSEC status changes.

   This document describes reasonable policies to ease deployment of the
   initial acceptance of new secure entry points (DS records)

   It is preferable that operators collaborate on the transfer or move
   of a domain.  The best method is to perform a Key Signing Key ("KSK")
   plus Zone Signing Key ("ZSK") rollover.  If that is not possible, the
   method using an unsigned intermediate state described in this
   document can be used to move the domain between two parties.  This
   leaves the domain temporarily unsigned and vulnerable to DNS
   spoofing, but that is preferred over the alternative of validation
   failures due to a mismatched DS and DNSKEY record.

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/.

Gudmundsson & Wouters     Expires July 14, 2017                 [Page 1]
Internet-Draft               DS-maintain-ds                 January 2017

   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 July 14, 2017.

Copyright Notice

   Copyright (c) 2017 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.  Introducing a DS record . . . . . . . . . . . . . . . . .   3
     1.2.  Removing a DS Record  . . . . . . . . . . . . . . . . . .   3
     1.3.  Notation  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.4.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  The Three Uses of CDS . . . . . . . . . . . . . . . . . . . .   4
     2.1.  The meaning of the CDS RRset  . . . . . . . . . . . . . .   5
   3.  Enabling DNSSEC via CDS/CDNSKEY . . . . . . . . . . . . . . .   5
     3.1.  Accept policy via authenticated channel . . . . . . . . .   6
     3.2.  Accept with extra checks  . . . . . . . . . . . . . . . .   6
     3.3.  Accept after delay  . . . . . . . . . . . . . . . . . . .   6
     3.4.  Accept with challenge . . . . . . . . . . . . . . . . . .   6
     3.5.  Accept from inception . . . . . . . . . . . . . . . . . .   7
   4.  DNSSEC Delete Algorithm . . . . . . . . . . . . . . . . . . .   7
   5.  Security considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA considerations . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Promoting RFC7344 to standards track  . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
Show full document text