idnits 2.17.1 draft-levine-dprive-signal-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 17, 2019) is 1622 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Levine 3 Internet-Draft Taughannock Networks 4 Intended status: Informational November 17, 2019 5 Expires: May 20, 2020 7 Signaling That an Authoritative DNS server offers DoT 8 draft-levine-dprive-signal-02 10 Abstract 12 DNS resolvers that wish to use DNS over TLS to authoritative servers 13 (ADoT) need some way to tell whether server offers DoT. This 14 document describes some ways that a server might signal that it uses 15 DoT. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 20, 2020. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. General observations . . . . . . . . . . . . . . . . . . . . 2 53 3. Signaling methods . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. EDNS0 option . . . . . . . . . . . . . . . . . . . . . . 3 55 3.2. DNSKEY flags . . . . . . . . . . . . . . . . . . . . . . 3 56 3.3. Other DNS records . . . . . . . . . . . . . . . . . . . . 3 57 3.4. SRV records . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.5. DANE TLSA . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.6. Special server names . . . . . . . . . . . . . . . . . . 4 60 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. References - Normative . . . . . . . . . . . . . . . . . 5 62 4.2. References - Informative . . . . . . . . . . . . . . . . 5 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 The Domain Name System[RFC1034] [RFC1035] uses a directed presumably 68 acyclic graph of servers to provide authoritative answers to queries. 69 The link from one server to the next is provided by an NS record in 70 the zone on the upper server that points to the lower server. For 71 zones signed with DNSSEC, the upper server zone contains DS records 72 that contain hashes of signing keys in DNSKEY records in the zone on 73 the lower server. 75 2. General observations 77 Depending on your threat model it may be a problem if an intermediate 78 party can intercept the signal and force a DoT client to use 79 unencrypted DNS. 81 The probe query would generally use query minimization to limit 82 leakage of the requested name. Even so, if a server handles many 83 zones, this leaks the name of the zone being probed. 85 Some zones have servers run by multiple operators. (The DNS root is 86 a well known example.) It is possible that some of the servers will 87 offer ADoT and some will not. Some of the schemes below handle per- 88 server signals, some don't. 90 In several of the following schemes, the client probes the server to 91 see whether it offers ADoT. In those cases, the client presumably 92 remembers what servers it's probed so there's only one probe per 93 server. 95 3. Signaling methods 97 This is a working list of possible signaling methods. Just because 98 they're in the list doesn't mean that anyone thinks they're a good 99 idea. 101 3.1. EDNS0 option 103 We define a new EDNS0 option edns-adot. The client sends an edns- 104 adot option in its request, and the server responds with a value of 0 105 or 1 to say whether it supports ADoT. The option could be served by 106 the upper level server along with the NS records, which avoids the 107 extra probe, or by the lower level server. 109 This is easy to implement, but since the OPT isn't signed, it's 110 subject to downgrade attacks. If served by the upper level server, 111 there's no per-server indication, but also no extra round trip. 113 3.2. DNSKEY flags 115 A DNSKEY [RFC4034] at the apex of the zone signals that ADoT is 116 available. The simplest approach would be to use one of the 117 unassigned DNSKEY flags to indicate that the zone is expected to be 118 served over ADoT. This is resistant to downgrade, since the DNSKEY 119 is signed, but there's no per-server indication. DNSSEC clients have 120 to fetch the DNSKEY records anyway so there's no extra round trip. 121 Since nobody has ever used DNSKEY records with flag values other than 122 0, 256, and 257, some software may fail if it sees other flag values. 124 3.3. Other DNS records 126 A variation of the previous approach is to put some other kind of 127 DNSSEC signed record at the zone apex that lists nameservers expected 128 to support ADoT, either yet another overloaded TXT record or a new 129 RRTYPE. The list of names would presumably have to be names already 130 listed in NS records (but see the next section.) This provides per- 131 server indication, and is backward compatible, but it makes the DNS 132 Camel sad. 134 The signal record could also be a signed record in the parent next to 135 the NS records, such as the DSPKI record in [DOTINSECURE]. 137 Another variation puts the signal record at the rDNS name for a 138 nameserver's IP address. 140 3.4. SRV records 142 Servers could publish SRV records for ADoT service discovery. ADoT 143 cleints would use the servers identified by SRV instead of the NS 144 servers. 146 This is downgrade resistant, backward compatible, and allows per- 147 server signalling, even allowing non-standard port numbers. There is 148 potentially an extra round trip for the SRV lookup and more if the 149 name of the servers aren't the same as the NS servers. The number of 150 round trips could be limited if servers provide the SRV and related 151 A/AAAA records as additional data in responses to DNSKEY lookups. It 152 might lead to unpleasant resolution loops if if SRV records use out 153 of bailiwick nameservers. 155 _domain-s._tcp.blah1.example. IN SRV 10 0 853 ns.blah2.example. 156 . . . 157 _domain-s._tcp.blah2.example. IN SRV 10 0 4242 ns.blah1.example. 159 3.5. DANE TLSA 161 If ADoT servers all have DANE secured TLS certificates, the TLSA 162 record can be the ADoT signal. 164 Publishing a TLSA record is straightforward if a zone is already 165 DNSSEC signed. It's downgrade-resistant, allows per-server signals, 166 and there's no extra round trip beyond what's needed to do the DANE 167 validation. 169 _853._tcp.ns1.blah.example IN TLSA . . ." 171 3.6. Special server names 173 Any server that supports ADoT has a name starting with the four 174 characters "XS--". All names starting with two letters other than 175 "XN" and two dashes were reserved when IDNs were invented, so these 176 names are unlikely to collide with any existing names. These are not 177 IDNs, they're just funny looking ASCII names, and you can't do "XN-- 178 XS--blah" or anything like that. 180 This is backward compatible, downgrade resistant, needs no extra 181 round trip, and allows per-server signals. It doesn't allow server 182 names to be IDNs which should not be a big problem since DNS server 183 names are not generally shown to users, although it may confuse 184 people who believe that anything with two dashes must be an IDN. 186 The Camel is also not crazy about it. 188 4. References 190 4.1. References - Normative 192 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 193 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 194 . 196 [RFC1035] Mockapetris, P., "Domain names - implementation and 197 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 198 November 1987, . 200 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 201 Rose, "Resource Records for the DNS Security Extensions", 202 RFC 4034, DOI 10.17487/RFC4034, March 2005, 203 . 205 4.2. References - Informative 207 [DOTINSECURE] 208 Bretelle, M., "DNS-over-TLS for insecure delegations", 209 March 2019, . 212 Author's Address 214 John Levine 215 Taughannock Networks 216 PO Box 727 217 Trumansburg, NY 14886 219 Email: standards@taugh.com 220 URI: http://jl.ly