idnits 2.17.00 (12 Aug 2021) /tmp/idnits1508/draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 112 has weird spacing: '... record as de...' == Line 114 has weird spacing: '... record as de...' == Line 116 has weird spacing: '... record as de...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: If a resolver succesfully uses DoT with a nameserver as specified in this document, it MAY assume DoT is always available for that nameserver. However, it MAY NOT assume that the connection is properly pinned unless there is a DS record available for the domain it is currently resolving. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Checks for child DNSKEY records based on parent DS records algorithms, and checks for zone RRSIG algorithms based on DNSKEY algorithms, MUST not be applied to algorithm TBD. [NOTE: rephrase this in terms of the Zone Signing column at https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml (https://www.iana.org/assignments/dns-sec-alg-numbers/ dns-sec-alg-numbers.xhtml) ?] -- The document date (19 May 2020) is 731 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 6982 (Obsoleted by RFC 7942) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dprive P. van Dijk 3 Internet-Draft PowerDNS 4 Intended status: Standards Track R. Geuze 5 Expires: 20 November 2020 TransIP 6 E. Bretelle 7 Facebook 8 19 May 2020 10 Signalling Authoritative DoT support in DS records, with key pinning 11 draft-vandijk-dprive-ds-dot-signal-and-pin-00 13 Abstract 15 This document specifies a way to signal the usage of DoT, and the 16 pinned keys for that DoT usage, in authoritative servers. This 17 signal lives on the parent side of delegations, in DS records. To 18 ensure easy deployment, the signal is defined in terms of (C)DNSKEY. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 20 November 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Document work . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 56 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5.1. Generating and placing the (C)DNSKEY/DS records . . . . . 4 59 6. Implementation . . . . . . . . . . . . . . . . . . . . . . . 5 60 6.1. Authoritative server changes . . . . . . . . . . . . . . 5 61 6.2. Validating resolver changes . . . . . . . . . . . . . . . 6 62 6.3. Stub resolver changes . . . . . . . . . . . . . . . . . . 6 63 6.4. Zone validator changes . . . . . . . . . . . . . . . . . 6 64 6.5. Domain registry changes . . . . . . . . . . . . . . . . . 6 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 67 8.1. PoC . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 70 11. Normative References . . . . . . . . . . . . . . . . . . . . 8 71 12. Informative References . . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 Even quite recently, DNS was a completely unencrypted protocol, with 77 no protection against snooping. In the past few years, this 78 landscape has shifted. The connections between stubs and resolvers 79 are now often protected by DoT, DoH, or other protocols that provide 80 privacy. 82 This document introduces a way to signal, from the parent side of a 83 delegation, that the name servers hosting the delegated zone support 84 DoT, and with which TLS/X.509 keys. This proposal does not require 85 any changes in authoritative name servers, other than (possibly 86 through an external process) actually offering DoT on port 853 87 [RFC7858]. DNS registry operators (such as TLD operators) also need 88 to make no changes, unless they filter uploaded DNSKEY/DS records on 89 acceptable DNSKEY algorithms, in which case they would need to add 90 algorithm TBD to that list. 92 This document was inspired by, and borrows heavily from, 93 [I-D.bretelle-dprive-dot-for-insecure-delegations]. 95 2. Document work 97 This document lives on GitHub (https://github.com/PowerDNS/parent- 98 signals-dot/blob/master/draft-vandijk-dprive-ds-dot-signal-and-pin/ 99 draft-vandijk-dprive-ds-dot-signal-and-pin.md); proposed text and 100 editorial changes are very much welcomed there, but any functional 101 changes should always first be discussed on the IETF DPRIVE WG (dns- 102 privacy) mailing list. 104 3. Conventions and Definitions 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in BCP 109 14 [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 CDNSKEY record as defined in [RFC7344][RFC8078] 114 DS record as defined in [RFC4034] 116 DNSKEY record as defined in [RFC4034] 118 4. Summary 120 To enable the signaling of DoT a new DNSKEY algorithm type TBD is 121 added. If a resolver with support for TBD encounters a DS record 122 with the DNSKEY algorithm type TBD it MUST connect to the 123 authoritative servers for this domain via DoT. It MUST use the 124 hashes attached to the DS records with DNSKEY algorithm type TBD to 125 check whether the public key supplied by the authoritative nameserver 126 is valid. If the DoT connection is unsuccessful or the public key 127 supplied the server does not match one of the DS digests, the 128 resolver MUST NOT fall back to unencrypted Do53. 130 The pseudo DNSKEY record MUST contain Base64 encoded ([RFC4648] 4.) 131 DER SubjectPublicKeyInfo as defined in [RFC5280] 4.1.2.7. Since the 132 cert provided by the TLS server over the wire is already DER encoded 133 this makes for easy validation. The pseudo DNSKEY algorithm type TBD 134 is algorithm agnostic, like the TLSA record, since the DER encoded 135 data already contains information about the used algorithm. 136 Algorithm support SHOULD be handled at the TLS handshake level, which 137 means a DNS application SHOULD NOT need to be aware of the algorithm 138 used by its TLS library. The pseudo DNSKEY record MUST NOT be 139 present in the zone. The procedure for hashing the pseudo DNSKEY 140 record is the same as for a normal DNSKEY as defined in RFC4034. 142 The pseudo DNSKEY type can be used in CDNSKEY and CDS (as defined in 143 [RFC7344]) records. These records MAY be present in the zone. 145 For those familiar with TLSA ([RFC6698]), key matching for this 146 protocol is identical to that provided by "TLSA 3 1 0" for (C)DNSKEY. 147 For the DS case, key matching is similar to "TLSA 3 1 x" where x is 148 not zero, except that the rest of the (C)DNSKEY, including the owner 149 name, gets prepended before hashing. 151 5. Example 153 This section will take you through the various parts of this 154 specification, by example. 156 We assume that we are working with a domain "example.com." with one 157 name server, "ns.example.com.". 159 5.1. Generating and placing the (C)DNSKEY/DS records 161 We will walk you through the CDNSKEY/DS generation, demonstrating it 162 in terms of basic shell scripting and some common tools. 164 First, we extract the SubjectPublicKeyInfo: 166 openssl s_client -connect ns.example.com:853 < /dev/null \ 167 | openssl x509 -noout -pubkey > pubkey.pem 169 This gives us a file "pubkey.pem" that looks like this (abridged): 171 -----BEGIN PUBLIC KEY----- 172 MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxH2a6NxIcw5527b04kKy 173 ... 174 71AWASNoX2GQh7eaQPDD9i8CAwEAAQ== 175 -----END PUBLIC KEY----- 177 To turns this into a CDNSKEY: 179 1. remove the header and footer 181 2. remove all newlines 183 In other words: 185 openssl s_client -connect ns.example.com:853 . 345 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 346 and P. Hoffman, "Specification for DNS over Transport 347 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 348 2016, . 350 [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from 351 the Parent via CDS/CDNSKEY", RFC 8078, 352 DOI 10.17487/RFC8078, March 2017, 353 . 355 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 356 Rose, "Resource Records for the DNS Security Extensions", 357 RFC 4034, DOI 10.17487/RFC4034, March 2005, 358 . 360 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 361 Housley, R., and W. Polk, "Internet X.509 Public Key 362 Infrastructure Certificate and Certificate Revocation List 363 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 364 . 366 [I-D.bretelle-dprive-dot-for-insecure-delegations] 367 Bretelle, E., "DNS-over-TLS for insecure delegations", 368 Work in Progress, Internet-Draft, draft-bretelle-dprive- 369 dot-for-insecure-delegations-01, 11 March 2019, 370 . 373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels", BCP 14, RFC 2119, 375 DOI 10.17487/RFC2119, March 1997, 376 . 378 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 379 DNSSEC Delegation Trust Maintenance", RFC 7344, 380 DOI 10.17487/RFC7344, September 2014, 381 . 383 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 384 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 385 . 387 12. Informative References 389 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 390 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 391 May 2017, . 393 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 394 of Named Entities (DANE) Transport Layer Security (TLS) 395 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 396 2012, . 398 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 399 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 400 January 2019, . 402 Authors' Addresses 404 Peter van Dijk 405 PowerDNS 406 Den Haag 407 Netherlands 409 Email: peter.van.dijk@powerdns.com 411 Robin Geuze 412 TransIP 413 Delft 414 Netherlands 416 Email: robing@transip.nl 417 Emmanuel Bretelle 418 Facebook 420 Email: chantra@fb.com