idnits 2.17.1 draft-levine-dprive-signal-01.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 4, 2019) is 1628 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 4, 2019 5 Expires: May 7, 2020 7 Signaling That an Authoritative DNS server offers DoT 8 draft-levine-dprive-signal-01 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 7, 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 . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.5. DANE TLSA . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.6. Special server names . . . . . . . . . . . . . . . . . . 4 60 4. References - Normative . . . . . . . . . . . . . . . . . . . 4 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 The Domain Name System[RFC1034] [RFC1035] uses a directed presumably 66 acyclic graph of servers to provide authoritative answers to queries. 67 The link from one server to the next is provided by an NS record in 68 the zone on the upper server that points to the lower server. For 69 zones signed with DNSSEC, the upper server zone contains DS records 70 that contain hashes of signing keys in DNSKEY records in the zone on 71 the lower server. 73 2. General observations 75 Depending on your threat model it may be a problem if an intermediate 76 party can intercept the signal and force a DoT client to use 77 unencrypted DNS. 79 The probe query would generally use query minimization to limit 80 leakage of the requested name. Even so, if a server handles many 81 zones, this leaks the name of the zone being probed. 83 Some zones have servers run by multiple operators. (The DNS root is 84 a well known example.) It is possible that some of the servers will 85 offer ADoT and some will not. Some of the schemes below handle per- 86 server signals, some don't. 88 In several of the following schemes, the client probes the server to 89 see whether it offers ADoT. In those cases, the client presumably 90 remembers what servers it's probed so there's only one probe per 91 server. 93 3. Signaling methods 95 This is a working list of possible signaling methods. Just because 96 they're in the list doesn't mean that anyone thinks they're a good 97 idea. 99 3.1. EDNS0 option 101 We define a new EDNS0 option edns-adot. The client sends an edns- 102 adot option in its request, and the server responds with a value of 0 103 or 1 to say whether it supports ADoT. The option could be served by 104 the upper level server along with the NS records, which avoids the 105 extra probe, or by the lower level server. 107 This is easy to implement, but since the OPT isn't signed, it's 108 subject to downgrade attacks. If served by the upper level server, 109 there's no per-server indication, but also no extra round trip. 111 3.2. DNSKEY flags 113 A DNSKEY [RFC4034] at the apex of the zone signals that ADoT is 114 available. The simplest approach would be to use one of the 115 unassigned DNSKEY flags to indicate that the zone is expected to be 116 served over ADoT. This is resistant to downgrade, since the DNSKEY 117 is signed, but there's no per-server indication. DNSSEC clients have 118 to fetch the DNSKEY records anyway so there's no extra round trip. 119 Since nobody has ever used DNSKEY records with flag values other than 120 0, 256, and 257, some software may fail if it sees other flag values. 122 3.3. Other DNS records 124 A variation of the previous approach is to put some other kind of 125 DNSSEC signed record at the zone apex lists nameservers expected to 126 support ADoT, either yet another overloaded TXT record or a new 127 RRTYPE. The list of names would presumably have to be names already 128 listed in NS records (but see the next section.) This provides per- 129 server indication, and is backward compatible, but it makes the DNS 130 Camel sad. 132 Another variation puts the signal record at the rDNS name for a 133 nameserver's IP address. 135 3.4. SRV records 137 Servers could publish SRV records for ADoT service discovery. ADoT 138 cleints would use the servers identified by SRV instead of the NS 139 servers. 141 This is downgrade resistant, backward compatible, and allows per- 142 server signalling, even allowing non-standard port numbers. There is 143 potentially an extra round trip for the SRV lookup and more if the 144 name of the servers aren't the same as the NS servers. The number of 145 round trips could be limited if servers provide the SRV and related 146 A/AAAA records as additional data in responses to DNSKEY lookups. It 147 might lead to unpleasant resolution loops if if SRV records use out 148 of bailiwick nameservers. 150 _domain-s._tcp.blah1.example. IN SRV 10 0 853 ns.blah2.example. 151 . . . 152 _domain-s._tcp.blah2.example. IN SRV 10 0 4242 ns.blah1.example. 154 3.5. DANE TLSA 156 If ADoT servers all have DANE secured TLS certificates, the TLSA 157 record can be the ADoT signal. 159 Publishing a TLSA record is straightforward if a zone is already 160 DNSSEC signed. It's downgrade-resistant, allows per-server signals, 161 and there's no extra round trip beyond what's needed to do the DANE 162 validation. 164 _853._tcp.ns1.blah.example IN TLSA . . ." 166 3.6. Special server names 168 Any server that supports ADoT has a name starting with the four 169 characters "XS--". All names starting with two letters other than 170 "XN" and two dashes were reserved when IDNs were invented, so these 171 names are unlikely to collide with any existing names. These are not 172 IDNs, they're just funny looking ASCII names, and you can't do "XN-- 173 XS--blah" or anything like that. 175 This is backward compatible, downgrade resistant, needs no extra 176 round trip, and allows per-server signals. It doesn't allow server 177 names to be IDNs which should not be a big problem since DNS server 178 names are not generally shown to users, although it may confuse 179 people who believe that anything with two dashes must be an IDN. 181 The Camel is also not crazy about it. 183 4. References - Normative 185 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 186 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 187 . 189 [RFC1035] Mockapetris, P., "Domain names - implementation and 190 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 191 November 1987, . 193 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 194 Rose, "Resource Records for the DNS Security Extensions", 195 RFC 4034, DOI 10.17487/RFC4034, March 2005, 196 . 198 Author's Address 200 John Levine 201 Taughannock Networks 202 PO Box 727 203 Trumansburg, NY 14886 205 Email: standards@taugh.com 206 URI: http://jl.ly