idnits 2.17.1 draft-bortzmeyer-dprive-step-2-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 abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 20, 2016) is 2838 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) -- Looks like a reference, but probably isn't: '1' on line 279 == Outdated reference: A later version (-11) exists of draft-ietf-dprive-dtls-and-tls-profiles-03 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) == Outdated reference: A later version (-07) exists of draft-ietf-tls-dnssec-chain-extension-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Privacy (dprive) Working Group S. Bortzmeyer 3 Internet-Draft AFNIC 4 Intended status: Standards Track July 20, 2016 5 Expires: January 21, 2017 7 Next step for DPRIVE: resolver-to-auth link 8 draft-bortzmeyer-dprive-step-2-01 10 Abstract 12 This document examines the possible future work for the DPRIVE (DNS 13 privacy) working group, specially in securing the resolver-to- 14 authoritative name server link with TLS under DNS. 16 It is not intended to be published as a RFC. 18 REMOVE BEFORE PUBLICATION: this document should be discussed in the 19 IETF DPRIVE group, through its mailing list. The source of the 20 document, as well as a list of open issues, is currently kept at 21 Github [1]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 21, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction and background . . . . . . . . . . . . . . . . . 2 58 2. Possible solutions . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Encode key in name . . . . . . . . . . . . . . . . . . . 3 60 2.2. Key in DNS . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.3. PKIX . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.4. Lax security . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 69 7.2. Informative References . . . . . . . . . . . . . . . . . 6 70 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction and background 75 To improve the privacy of the DNS user ([RFC7626]), the standard 76 solution is to encrypt the requests with TLS ([RFC7858]). Just 77 encrypting, without authenticating the remote server, leaves the 78 user's privacy vulnerable to active man-in-the-middle attacks. 79 [RFC7858] and [I-D.ietf-dprive-dtls-and-tls-profiles] describe how to 80 authenticate the DNS resolver, in the stub-to-resolver link. We have 81 currently no standard way to authenticate the authoritative name 82 server, in the resolver-to-auth link. 84 The two cases are quite different: a stub resolver has only a few 85 resolvers, and there is typically a pre-existing relationship. But a 86 resolver speaks to many authoritative name servers, without any prior 87 relationship. This means that, for instance, having a static key for 88 the resolver makes sense while it would be clearly unrealistic for 89 the authoritative server. 91 Another difference is that resolvers are typically known by IP 92 address (obtained by DHCP or manual configuration) while 93 authoritative name servers are known by name (obtained from zone 94 delegation). This makes things easier for techniques similar to 95 DANE: the manager of the ns1.example.net name server can always add a 96 TLSA record under example.net while she may have problems modifying 97 the zone under in-addr.arpa or ip6.arpa. 99 The original charter of the DPRIVE working group, in force at the 100 time of this draft, says "The primary focus of this Working Group is 101 to develop mechanisms that provide confidentiality between DNS 102 Clients and Iterative Resolvers" and adds "but it may also later 103 consider mechanisms that provide confidentiality between Iterative 104 Resolvers and Authoritative Servers". This document is here for this 105 second step, "between Iterative Resolvers and Authoritative Servers". 106 It will probably require a rechartering of the group. 108 2. Possible solutions 110 We can express the problem this way: if we want to use TLS-over-DNS 111 to secure the link between the resolver and the authoritative server, 112 it would be important to have a standard way to authenticate the 113 authoritative server. Basically, the client will get the public key 114 of the server in the TLS session, how will it know that this key is 115 the right one? 117 Here is a comprehensive list of the four possible solutions to this 118 problem. First, the two where the key (or a hash of it) is available 119 somewhere else than in the TLS session. 121 2.1. Encode key in name 123 We could encode the key in the authoritative server name (as in 124 DNScurve [dnscurve] [I-D.dempsky-dnscurve]). Here is an example of a 125 domain using DNScurve: the names of the authoritative name servers 126 are a Base-32 encoded form of the server's Curve25519 public key. 128 % dig +short NS yp.to 129 uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to. 130 uz5hjgptn63q5qlch6xlrw63tf6vhvvu6mjwn0s31buw1lhmlk14kd.ns.yp.to. 131 uz5uu2c7j228ujjccp3ustnfmr4pgcg5ylvt16kmd0qzw7bbjgd5xq.ns.yp.to. 133 Securely transmitting the key would therefore be a by-product of 134 delegation. Among the limits of this solution, the length of these 135 names limit the number of possible name servers, if we want to keep 136 the delegation short. Also, it requires a cryptographic algorithm 137 where keys are short (which means no RSA). 139 2.2. Key in DNS 141 We could publish keys in the DNS, secured with DNSSEC (as in DANE 142 [RFC6698]). This raises an interesting bootstrap problem: we need 143 the key to get information privately with the DNS but we need the DNS 144 to do so. A possible solution is to have an "unsecure" mode to 145 retrieve the initial key material. The algorithm could be: 147 (0)The resolver remembers the keys of the authoritative name 148 servers (in the same way it remembers the lowest RTT among a NS 149 RRset), 151 (1)When the resolver needs to talk to a server (say 152 ns1.example.net) for which it does not know the key, it does a 153 TLSA request for _853._tcp.ns1.example.net, 155 (2)If the resolution of this request requires to talk to the very 156 server we search the key for, the resolver connects to this server 157 with TLS to port 853, does not authenticate, and sends the query. 158 This step offers no authentication. 160 The real algorithm will need to be more complicated since there are 161 several servers per zone. A resolver may use the knowledge of TLS 162 authentication it has to choose an authoritative name server among a 163 NS RRset. 165 Another solution is for the authoritative name server to use 166 [I-D.ietf-tls-dnssec-chain-extension] to send all the necessary 167 DNSSEC records over TLS. 169 2.3. PKIX 171 We could use the X.509 security model [RFC5280]). The certificates 172 for authoritative name servers would be signed by regular CAs, with 173 the name of the server in the Subject Alternative Name. 175 One of the problems is that resolvers will probably have different 176 sets of trusted CA so an authoritative name server will not know in 177 advance what percentage of the resolvers may authenticate it. 179 Of course, this technique would not work if the server used raw 180 public keys ([RFC7250]. 182 2.4. Lax security 184 Finally, we could simply not check the keys at all, accepting 185 anything. This would break privacy promises, when there is an active 186 attacker, able to pose as the authoritative name server. But it is 187 still better, privacy-wise, than the current situation where DNS 188 requests are sent in clear text. 190 3. Miscellaneous 192 A resolver may use a combination of these solutions. For instance, 193 trying PKIX authentication (it does not require an extra lookup, 194 except may be OCSP), if it fails, search a TLSA record, if there is 195 none, depending on the resolver's policy, accept anyway. 197 All these solutions can be improved by things like automatic key 198 pinning ([RFC6797]). 200 An authoritative name server cannot know if the resolver authentified 201 it, and how. In the future, it may be interesting to have a EDNS 202 option to signal a successful authentication, or a failure, but this 203 is out of scope currently. 205 4. IANA Considerations 207 There is currently nothing to do for IANA. The future chosen 208 solution may require some IANA action, such as a registry. 210 5. Security Considerations 212 For the time being, refer to each subsection under Section 2 to have 213 an analysis of its security. 215 6. Acknowledgments 217 Nobody yet :-) 219 7. References 221 7.1. Normative References 223 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 224 and P. Hoffman, "Specification for DNS over Transport 225 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 226 2016, . 228 [I-D.ietf-dprive-dtls-and-tls-profiles] 229 Dickinson, S., Gillmor, D., and T. Reddy, "Authentication 230 and (D)TLS Profile for DNS-over-(D)TLS", draft-ietf- 231 dprive-dtls-and-tls-profiles-03 (work in progress), July 232 2016. 234 7.2. Informative References 236 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 237 Housley, R., and W. Polk, "Internet X.509 Public Key 238 Infrastructure Certificate and Certificate Revocation List 239 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 240 . 242 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 243 of Named Entities (DANE) Transport Layer Security (TLS) 244 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 245 2012, . 247 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 248 Transport Security (HSTS)", RFC 6797, 249 DOI 10.17487/RFC6797, November 2012, 250 . 252 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 253 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 254 Transport Layer Security (TLS) and Datagram Transport 255 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 256 June 2014, . 258 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 259 DOI 10.17487/RFC7626, August 2015, 260 . 262 [I-D.dempsky-dnscurve] 263 Dempsky, M., "DNSCurve: Link-Level Security for the Domain 264 Name System", draft-dempsky-dnscurve-01 (work in 265 progress), February 2010. 267 [I-D.ietf-tls-dnssec-chain-extension] 268 Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE 269 Record and DNSSEC Authentication Chain Extension for TLS", 270 draft-ietf-tls-dnssec-chain-extension-01 (work in 271 progress), July 2016. 273 [dnscurve] 274 Bernstein, D., "DNSCurve: Usable security for DNS", June 275 2009, . 277 7.3. URIs 279 [1] https://github.com/bortzmeyer/ietf-dprive-step-2 281 Author's Address 283 Stephane Bortzmeyer 284 AFNIC 285 1, rue Stephenson 286 Montigny-le-Bretonneux 78180 287 France 289 Phone: +33 1 39 30 83 46 290 Email: bortzmeyer+ietf@nic.fr 291 URI: http://www.afnic.fr/