A Sentinel for Detecting Trusted Keys in DNSSEC
draft-huston-kskroll-sentinel-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2017-10-02
Replaced by rfc8509, draft-ietf-dnsop-kskroll-sentinel
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
DNSOP                                                          G. Huston
Internet-Draft                                                  J. Damas
Intended status: Standards Track                                   APNIC
Expires: April 5, 2018                                   October 2, 2017

            A Sentinel for Detecting Trusted Keys in DNSSEC
                  draft-huston-kskroll-sentinel-00.txt

Abstract

   The DNS Security Extensions (DNSSEC) were developed to provide origin
   authentication and integrity protection for DNS data by using digital
   signatures.  These digital signatures can be verified by building a
   chain of trust starting from a trust anchor and proceeding down to a
   particular node in the DNS.  This document specifies a mechanism that
   will allow an end user to establish the trusted key state of the
   resolvers that handle the user's DNS queries.  This allows users to
   discover the trusted key state used by their DNS resolution service.

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 https://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 5, 2018.

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
   (https://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

Huston & Damas            Expires April 5, 2018                 [Page 1]
Internet-Draft         DNSSEC Trusted Key Sentinel          October 2017

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Sentinel Mechanism  . . . . . . . . . . . . . . . . . . . . .   3
   3.  Sentinel Processing . . . . . . . . . . . . . . . . . . . . .   3
   4.  Sentinel Considerations . . . . . . . . . . . . . . . . . . .   3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   The DNS Security Extensions (DNSSEC) [RFC4033]", [RFC4034] and
   [RFC4035] were developed to provide origin authentication and
   integrity protection for DNS data by using digital signatures.
   DNSSEC uses Key Tags to efficiently match signatures to the keys from
   which they are generated.  The Key Tag is a 16-bit value computed
   from the RDATA portion of a DNSKEY RR using a formula not unlike a
   ones-complement checksum.  RRSIG RRs contain a Key Tag field whose
   value is equal to the Key Tag of the DNSKEY RR that validates the
   signature.

   This document specifies how validating resolvers should respond to
   certain queries so that a user can deduce whether a key has been
   loaded into a resolver's trusted key store.  This mechanism can be
   used to determine whether a certain Root Zone KSK is ready to be used
   as a trusted key within the context of a key roll.

   This new mechanism is OPTIONAL to implement and use, although for
   reasons of supporting broad based measurement techniques, it is
   strongly preferred if configurations of DNSSEC-vbalidating resolvers
   enabled this mechanism by default, allowing for configuration
   directives to disable this mechanism if desired.

1.1.  Terminology

   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 RFC 2119.

Huston & Damas            Expires April 5, 2018                 [Page 2]
Show full document text