Signalling Authoritative DoT support in DS records, with key pinning
draft-vandijk-dprive-ds-dot-signal-and-pin-01

Document Type Active Internet-Draft (individual)
Authors Peter van Dijk  , Robin Geuze  , Emmanuel Bretelle 
Last updated 2020-07-13
Stream (None)
Intended RFC status (None)
Formats plain text html xml pdf htmlized (tools) htmlized bibtex
Additional Resources
- GitHub Repository
- GitHub Repository
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)
dprive                                                       P. van Dijk
Internet-Draft                                                  PowerDNS
Intended status: Standards Track                                R. Geuze
Expires: 14 January 2021                                         TransIP
                                                             E. Bretelle
                                                                Facebook
                                                            13 July 2020

  Signalling Authoritative DoT support in DS records, with key pinning
             draft-vandijk-dprive-ds-dot-signal-and-pin-01

Abstract

   This document specifies a way to signal the usage of DoT, and the
   pinned keys for that DoT usage, in authoritative servers.  This
   signal lives on the parent side of delegations, in DS records.  To
   ensure easy deployment, the signal is defined in terms of (C)DNSKEY.

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 14 January 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

van Dijk, et al.         Expires 14 January 2021                [Page 1]
Internet-Draft            ds-dot-signal-and-pin                July 2020

   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 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
   2.  Document work . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   4.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Generating and placing the (C)DNSKEY/DS records . . . . .   5
   6.  Implementation  . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Authoritative server changes  . . . . . . . . . . . . . .   6
     6.2.  Validating resolver changes . . . . . . . . . . . . . . .   7
     6.3.  Stub resolver changes . . . . . . . . . . . . . . . . . .   8
     6.4.  Zone validator changes  . . . . . . . . . . . . . . . . .   8
     6.5.  Domain registry changes . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  Implementation Status . . . . . . . . . . . . . . . . . . . .   9
     8.1.  PoC . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  Design Considerations . . . . . . . . . . . . . . . . . . . .   9
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   12. Normative References  . . . . . . . . . . . . . . . . . . . .  11
   13. Informative References  . . . . . . . . . . . . . . . . . . .  12
   Appendix A.  Document history . . . . . . . . . . . . . . . . . .  13
     A.1.  Changes between -00 and -01 . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Even quite recently, DNS was a completely unencrypted protocol, with
   no protection against snooping.  In the past few years, this
   landscape has shifted.  The connections between stubs and resolvers
   are now often protected by DoT, DoH, or other protocols that provide
   privacy.

   This document introduces a way to signal, from the parent side of a
   delegation, that the name servers hosting the delegated zone support
   DoT, and with which TLS/X.509 keys.  This proposal does not require
   any changes in authoritative name servers, other than (possibly
   through an external process) actually offering DoT on port 853

van Dijk, et al.         Expires 14 January 2021                [Page 2]
Internet-Draft            ds-dot-signal-and-pin                July 2020
Show full document text