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 algorithm TBD to that list. This document was inspired by, and borrows heavily from, [I-D.bretelle-dprive-dot-for-insecure-delegations]. 2. Document work This document lives on GitHub (https://github.com/PowerDNS/parent- signals-dot/blob/master/draft-vandijk-dprive-ds-dot-signal-and-pin/ draft-vandijk-dprive-ds-dot-signal-and-pin.md); proposed text and editorial changes are very much welcomed there, but any functional changes should always first be discussed on the IETF DPRIVE WG (dns- privacy) mailing list. 3. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. CDNSKEY record as defined in [RFC7344][RFC8078] DS record as defined in [RFC4034] DNSKEY record as defined in [RFC4034] 4. Summary To enable the signaling of DoT a new DNSKEY algorithm type TBD is added. If a resolver with support for TBD encounters a DS record with the DNSKEY algorithm type TBD it MUST connect to the authoritative servers for this domain via DoT. It MUST use the hashes attached to the DS records with DNSKEY algorithm type TBD to check whether the public key supplied by the authoritative nameserver is valid. If the DoT connection is unsuccessful or the public key supplied the server does not match one of the DS digests, the resolver MUST NOT fall back to unencrypted Do53. van Dijk, et al. Expires 20 November 2020 [Page 3] Internet-Draft ds-dot-signal-and-pin May 2020 The pseudo DNSKEY record MUST contain Base64 encoded ([RFC4648] 4.) DER SubjectPublicKeyInfo as defined in [RFC5280] 4.1.2.7. Since the cert provided by the TLS server over the wire is already DER encoded this makes for easy validation. The pseudo DNSKEY algorithm type TBD is algorithm agnostic, like the TLSA record, since the DER encoded data already contains information about the used algorithm. Algorithm support SHOULD be handled at the TLS handshake level, which means a DNS application SHOULD NOT need to be aware of the algorithm used by its TLS library. The pseudo DNSKEY record MUST NOT be present in the zone. The procedure for hashing the pseudo DNSKEY record is the same as for a normal DNSKEY as defined in RFC4034. The pseudo DNSKEY type can be used in CDNSKEY and CDS (as defined in [RFC7344]) records. These records MAY be present in the zone. For those familiar with TLSA ([RFC6698]), key matching for this protocol is identical to that provided by "TLSA 3 1 0" for (C)DNSKEY. For the DS case, key matching is similar to "TLSA 3 1 x" where x is not zero, except that the rest of the (C)DNSKEY, including the owner name, gets prepended before hashing. 5. Example This section will take you through the various parts of this specification, by example. We assume that we are working with a domain "example.com." with one name server, "ns.example.com.". 5.1. Generating and placing the (C)DNSKEY/DS records We will walk you through the CDNSKEY/DS generation, demonstrating it in terms of basic shell scripting and some common tools. First, we extract the SubjectPublicKeyInfo: openssl s_client -connect ns.example.com:853 < /dev/null \ | openssl x509 -noout -pubkey > pubkey.pem This gives us a file "pubkey.pem" that looks like this (abridged): -----BEGIN PUBLIC KEY----- MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxH2a6NxIcw5527b04kKy ... 71AWASNoX2GQh7eaQPDD9i8CAwEAAQ== -----END PUBLIC KEY----- To turns this into a CDNSKEY: van Dijk, et al. Expires 20 November 2020 [Page 4] Internet-Draft ds-dot-signal-and-pin May 2020 1. remove the header and footer 2. remove all newlines In other words: openssl s_client -connect ns.example.com:853 . [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from the Parent via CDS/CDNSKEY", RFC 8078, DOI 10.17487/RFC8078, March 2017, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [I-D.bretelle-dprive-dot-for-insecure-delegations] Bretelle, E., "DNS-over-TLS for insecure delegations", Work in Progress, Internet-Draft, draft-bretelle-dprive- dot-for-insecure-delegations-01, 11 March 2019, . van Dijk, et al. Expires 20 November 2020 [Page 8] Internet-Draft ds-dot-signal-and-pin May 2020 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 10.17487/RFC7344, September 2014, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . 12. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, . [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . Authors' Addresses Peter van Dijk PowerDNS Den Haag Netherlands Email: peter.van.dijk@powerdns.com Robin Geuze TransIP Delft Netherlands Email: robing@transip.nl van Dijk, et al. Expires 20 November 2020 [Page 9] Internet-Draft ds-dot-signal-and-pin May 2020 Emmanuel Bretelle Facebook Email: chantra@fb.com van Dijk, et al. Expires 20 November 2020 [Page 10]