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

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01

dprive                                                       P. van Dijk
Internet-Draft                                                  PowerDNS
Intended status: Standards Track                                R. Geuze
Expires: 20 November 2020                                        TransIP
                                                             E. Bretelle
                                                                Facebook
                                                             19 May 2020

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

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 20 November 2020.

Copyright Notice

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

van Dijk, et al.        Expires 20 November 2020                [Page 1]
Internet-Draft            ds-dot-signal-and-pin                 May 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 . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  Generating and placing the (C)DNSKEY/DS records . . . . .   4
   6.  Implementation  . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Authoritative server changes  . . . . . . . . . . . . . .   5
     6.2.  Validating resolver changes . . . . . . . . . . . . . . .   6
     6.3.  Stub resolver changes . . . . . . . . . . . . . . . . . .   6
     6.4.  Zone validator changes  . . . . . . . . . . . . . . . . .   6
     6.5.  Domain registry changes . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  Implementation Status . . . . . . . . . . . . . . . . . . . .   7
     8.1.  PoC . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   11. Normative References  . . . . . . . . . . . . . . . . . . . .   8
   12. Informative References  . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

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.

van Dijk, et al.        Expires 20 November 2020                [Page 2]
Internet-Draft            ds-dot-signal-and-pin                 May 2020

   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
   [RFC7858].  DNS registry operators (such as TLD operators) also need
   to make no changes, unless they filter uploaded DNSKEY/DS records on
   acceptable DNSKEY algorithms, in which case they would need to add