idnits 2.17.1 draft-wijngaards-dnsop-confidentialdns-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 28, 2013) is 3800 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group W. Wijngaards 3 Internet-Draft NLnet Labs 4 Intended status: Standards Track November 28, 2013 5 Expires: June 1, 2014 7 Confidential DNS 8 draft-wijngaards-dnsop-confidentialdns-00 10 Abstract 12 This document offers opportunistic encryption to provide privacy for 13 DNS queries and responses. 15 Requirements Language 17 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 18 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 19 document are to be interpreted as described in RFC 2119 [RFC2119]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 1, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. ENCRYPT RR Type . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Server and Client Algorithm . . . . . . . . . . . . . . . . . . 4 58 4. Authenticated Operation . . . . . . . . . . . . . . . . . . . . 6 59 5. Comparison with TLS and DTLS . . . . . . . . . . . . . . . . . 6 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 62 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 63 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 The privacy of the Question, Answer, Authority and Additional 68 sections in DNS queries and responses is protected by the 69 confidential DNS protocol by encrypting the contents of each section. 70 The goal of this change to the DNS protocol is to make large scale 71 monitoring more expensive, see [draft-bortzmeyer-dnsop-dns-privacy] 72 and [draft-koch-perpass-dns-confidentiality]. Authenticity and 73 integrity may be provided by DNSSEC, this protocol does not change 74 DNSSEC and does not offer the means to authenticate responses. 76 Confidential communication between any pair of DNS servers is 77 supported, both between iterative resolvers and authoritative servers 78 and between stub resolvers and recursive resolvers. 80 The confidential DNS protocol has minimal impact on the number of 81 packets involved in a typical DNS query/response exchange by 82 leveraging a cacheable ENCRYPT Resource Record and an optionally 83 cacheable shared secret. The protocol supports selectable 84 cryptographic suites and parameters (such as key sizes). 86 The client fetches an ENCRYPT RR from the server that it wants to 87 contact. The public key retrieved in the ENCRYPT RR is used to 88 encrypt a shared secret or public key that the client uses to encrypt 89 the sections in the DNS query and which the name server uses to 90 encrypt the DNS response. Note that an ENCRYPT RR must be fetched 91 for each name server in order for the entire session to be 92 confidential. 94 As this is opportunistic encryption, the key is (re-)fetched when the 95 exchange fails. If the key fetch fails or the encrypted query fails, 96 communication in the clear may be performed. 98 The server advertises which crypto suites and key lengths may be used 99 in the ENCRYPT RR, the client then chooses a crypto suite from this 100 list and includes that selection in subsequent DNS queries. 102 The key from the server can be cached by the client, using the TTL 103 specified in the ENCRYPT RR, the IP address of the server 104 distinguishes keys in the cache. The server may also cache shared 105 secrets and keys from clients. 107 2. ENCRYPT RR Type 109 The RR type for confidential DNS is ENCRYPT TBD (decimal). The 110 presentation format is: 112 . ENCRYPT [flags] [algo] [id] [data] 113 The flags, algo and id are unsigned numbers in decimal and the data 114 is in base-64. The wireformat is: one octet flags, one octet algo, 115 one octet id and the remainder of the rdata is for the data. The 116 type is class independent and it is a hop-by-hop transaction RR type. 117 The domain name of the ENCRYPT record is '.' (the root label) for 118 hop-by-hop exchanges. 120 In the flags the least two bits are used as usage value. The other 121 flag bits MUST be ignored by receivers and sent as zeroes. 123 o PAD (value=0): the ENCRYPT contains padding material. Algo and id 124 are set to 0. Its data length is random (say 1-63 octets), and 125 has some random values. It is a resource record that may be 126 appended to resource records that are encrypted so that identical 127 queries encrypt to different encrypted data of different lengths. 129 o KEY (value=1): the ENCRYPT contains a public or symmetric key. 130 The algo field gives the algorithm. The id identifies the key, 131 this id is copied to ENCRYPT type RRS to identify which key to use 132 to decrypt the data. The data contains the key bits. 134 o RRS (value=2): encrypted data. The data contains encrypted 135 resource records. The data is encrypted with the selected 136 algorithm and key id. The data contains resource records in DNS 137 wireformat [RFC1034], with a domain name, type, class, ttl, 138 rdatalength and rdata. 140 o SYM (value=3): the ENCRYPT contains an encrypted symmetric key. 141 The contained, encrypted data is rdata of an ENCRYPT of type KEY 142 and has the symmetric key. The data is encrypted with the 143 algorithm and id indicated. The encrypted data encompasses the 144 flags, algo, id, data for the symmetric key. 146 The ENCRYPT RR type can contain keys. It uses the same format as the 147 DNSKEY record [RFC4034] for public keys. algo=0 is reserved for 148 future expansion of the algorithm number above 255. algo=1 is RSA, 149 the rdata determines the key size, such as 512 and 768 bits. algo=2 150 is AES, aes-cbc, size of the rdata determines the size of the key, 151 such as 128 and 192 bits. 153 3. Server and Client Algorithm 155 If a clients wants to fetch the keys for the server from the server, 156 it performs a query with query type ENCRYPT and query name '.' (root 157 label). The reply contains the ENCRYPT (or multiple if a choice is 158 offered) in the answer section. These ENCRYPTs have the KEY flag 159 set. 161 If a client wants to perform an encrypted query, it sends an 162 unencrypted outer packet, with query type ENCRYPT and query name '.' 163 (root label). In the additional section it includes an ENCRYPT 164 record of type RRS. This encrypts a number of records, the first is 165 a query-section style query record, and then zero or more ENCRYPTs of 166 type KEY that the server uses to encrypt the reply. If the client 167 wants to use a symmetric key, there are no ENCRYPTs of type KEY 168 inside the encrypted ENCRYPT data, instead an ENCRYPT of type SYM is 169 positioned in the outer packet, before the ENCRYPT of type RRS and 170 the ENCRYPT of type RRS is encrypted with the symmetric key. 172 If a server wants to encrypt a reply, it also uses the ENCRYPT type. 173 The reply looks like a normal DNS packet, i.e. it has a normal 174 unencrypted outer DNS packet. Because the query name and query type 175 have been encrypted, the outer packet has a query name of '.' and 176 query type of ENCRYPT and the reply has an ENCRYPT record in the 177 answer section with flag RRS. The reply RRs have been encrypted into 178 the data of the ENCRYPT record. The RR counts for every section are 179 stored in the outer (unencrypted) header. Thus, the combination of 180 the original header and the decrypted data from this record results 181 in the decrypted packet. 183 The client may lookup keys whenever it wants to. It may cache the 184 keys for the server, using the TTL of those ENCRYPT records. It 185 should also cache failures to lookup the ENCRYPT record for some time 186 (eg. the negative TTL if the reply contained one). Errors and also 187 timeouts should also be taken as an indication that the ENCRYPT 188 cannot be looked up, and the client MUST fall back to unencrypted 189 communication (this is the opportunistic encryption case). The 190 result of an encrypted query may also be timeouts, errors or replies 191 with mangled contents, in that case the client MUST fall back to 192 unencrypted communication (this is the opportunistic encryption 193 case). Note that if some middlebox removes the ENCRYPT from the 194 additional section of an encrypted query, likely a reply with 195 ENCRYPTs of type KEY is returned instead of the encrypted reply with 196 an ENCRYPT of type RRS, and again the client does the unencrypted 197 fallback. If the server has changed its keys and does not recognize 198 the keys in an encrypted query, it should return FORMERR, and include 199 its current ENCRYPTs of type KEY in that FORMERR reply. A server may 200 decide it does not (any longer) have the resources for encryption and 201 reply with SERVFAIL to encrypted queries, forcing unencrypted 202 fallback. Keys for unknown algorithms should be ignored by the 203 client, if no usable keys remain, fallback to insecure. 205 The client may cache the ENCRYPT of type SYM for a server together 206 with the symmetric secret, this is better for performance, as public- 207 key operations can be avoided for repeated queries. The server may 208 also cache the ENCRYPTs of type SYM with the decoded secret, 209 associating a lookup for the rdata of the SYM record with the decoded 210 secret, avoiding public-key operations for repeated queries. 212 Key rollover is possible, use different key ids and support the old 213 key for its TTL, while advertising the new key, for the servers. For 214 clients, generate a new public or symmetric key and use it. 216 4. Authenticated Operation 218 The previous documented the opportunistic operation, where deployment 219 is easier, but security is weaker. This documents options for 220 authenticated operation. [[ is this out of scope? ]]. The client 221 selects if encryption is authenticated, opportunistic, or disabled. 223 The ENCRYPT KEYs for authority servers can be signed with DNSSEC. 224 The domain name of the nameserver is used to store the ENCRYPTs of 225 type KEY. [[ Could also be in the reverse tree for the IP address ]]. 227 For authenticated operation, fallback to insecure should not be 228 performed. However, this will significantly harm deployment as 229 unclean lookup paths result in lookup failure. Keys with unsupported 230 crypto algorithms MUST still be ignored and if no keys are left, 231 fallback to insecure MUST still be performed, also for authenticated 232 operation. 234 The key for recursive resolvers can be configured into the stub 235 machines, or a domain name can be configured where the keys are 236 looked up and they are signed with DNSSEC. 238 5. Comparison with TLS and DTLS 240 An alternative method of accomplishing confidential DNS would be to 241 leverage one of the existing means for establishing a secure 242 transport layer. For example a secure TCP session could be 243 established to the name server over which DNS queries could be sent 244 with no changes to the DNS protocol. The most significant down side 245 to this approach is the burden that it places on high volume name 246 servers. Very large scale DNS operators expect to answer hundreds of 247 thousands of queries per second (possibly even more than a million 248 qps) for each host in their name server footprint. The use of 249 technologies such as IPSec or TLS may have such a severe impact on 250 the largest name server operators as to impede adoption of 251 confidential DNS. 253 DTLS (RFC 6347) offers a more interesting approach to securing the 254 connection to a name server that may be implemented in a way that is 255 less abusive to the large scale name servers. It looks as though the 256 overhead imposed by DTLS would probably be significantly higher than 257 the protocol described in this draft, however if the session 258 established via DTLS is used over a large number of queries then the 259 cost of the handshake could be amortized over the total number of 260 queries. 262 6. IANA Considerations 264 An RR type registration for type ENCRYPT with number TBD and it 265 references this document [[to be done when this becomes RFC]]. 267 7. Security Considerations 269 Opportunistic encryption is the main mode here. Opportunistic 270 encryption has many drawbacks, against active intrusion, but works 271 against passives. The pervasive passive surveillance problem 272 statement and also its security considerations are applicable to this 273 document. Hence the suggested short key sizes and opportunistic 274 encryption. 276 This technique does not provide perfect forward secrecy. 277 Additionally, timing, traffic analysis (what IP address is 278 contacted), packet size, RR count, header flags and header RCODE can 279 be observed. These could provide almost all the information that was 280 encrypted. Such as: query to IP address for example.com nameservers, 281 size of the packet is similar to a www.example.com lookup and is 282 followed by http packets to www.example.com's IP address. 284 8. Acknowledgments 286 Acknowledgements here 288 9. Normative References 290 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 291 STD 13, RFC 1034, November 1987. 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, March 1997. 296 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 297 Rose, "Resource Records for the DNS Security Extensions", 298 RFC 4034, March 2005. 300 Author's Address 302 Wouter Wijngaards 303 NLnet Labs 304 Science Park 140 305 Amsterdam 1098 XH 306 The Netherlands 308 EMail: wouter@nlnetlabs.nl