idnits 2.17.1 draft-wijngaards-dnsop-confidentialdns-03.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 (March 6, 2015) is 3337 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 G. Wiley 5 Expires: September 7, 2015 VeriSign, Inc. 6 March 6, 2015 8 Confidential DNS 9 draft-wijngaards-dnsop-confidentialdns-03 11 Abstract 13 This document offers opportunistic encryption to provide privacy for 14 DNS queries and responses. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in RFC 2119 [RFC2119]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 7, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 1. Introduction 56 The privacy of the Question, Answer, Authority and Additional 57 sections in DNS queries and responses is protected by the 58 confidential DNS protocol by encrypting the contents of each section. 59 The goal of this change to the DNS protocol is to make large scale 60 monitoring more expensive, see [draft-bortzmeyer-dnsop-dns-privacy] 61 and [draft-koch-perpass-dns-confidentiality]. Authenticity and 62 integrity may be provided by DNSSEC, this protocol does not change 63 DNSSEC and does not offer the means to authenticate responses. 65 Confidential communication between any pair of DNS servers is 66 supported, both between iterative resolvers and authoritative servers 67 and between stub resolvers and recursive resolvers. 69 The confidential DNS protocol has minimal impact on the number of 70 packets involved in a typical DNS query/response exchange by 71 leveraging a cacheable ENCRYPT Resource Record and an optionally 72 cacheable shared secret. The protocol supports selectable 73 cryptographic suites and parameters (such as key sizes). 75 The client fetches an ENCRYPT RR from the server that it wants to 76 contact. The public key retrieved in the ENCRYPT RR is used to 77 encrypt a shared secret or public key that the client uses to encrypt 78 the sections in the DNS query and which the name server uses to 79 encrypt the DNS response. 81 As this is opportunistic encryption, the key is (re-)fetched when the 82 exchange fails or after the TTL expires. If the key fetch fails or 83 the encrypted query fails, communication in the clear is performed. 85 The server advertises which crypto suites and key lengths may be used 86 in the ENCRYPT RR, the client then chooses a crypto suite from this 87 list and includes that selection in subsequent DNS queries. 89 The key from the server can be cached by the client, using the TTL 90 specified in the ENCRYPT RR, the IP address of the server 91 distinguishes keys in the cache. The server may also cache shared 92 secrets and keys from clients. 94 The optional authenticated mode of operation uses two mechanisms, one 95 for authoritative and one for recursive servers, that fetch the 96 public key for the server and sign it with DNSSEC. For authoritative 97 servers, the key is included in an extra DS record in the parent's 98 delegation. For recursive servers the key is at the reverse IP 99 address location. 101 2. ENCRYPT RR Type 103 The RR type for confidential DNS is ENCRYPT, type TBD (decimal). The 104 presentation format is: 106 . ENCRYPT [flags] [algo] [id] [data] 108 The flags, algo and id are unsigned numbers in decimal and the data 109 is in base-64. The wireformat is: one octet flags, one octet algo, 110 one octet id and the remainder of the rdata is for the data. The 111 type is class independent. The domain name of the ENCRYPT record is 112 '.' (the root label) for hop-by-hop exchanges. 114 In the flags the least two bits are the usage value. The other flag 115 bits MUST be sent as zeroes, and the receiver MUST ignore RRs that 116 have other flag bits set. 118 o PAD (usage=0): the ENCRYPT contains padding material. Algo and id 119 are set to 0. Its data length varies (0-63 octets), and may 120 contain any value. It is used to pad packets to obscure the 121 packet length. Append such records to make the DNS message for 122 queries and answers a whole multiple of 64 bytes. 124 o KEY (usage=1): the ENCRYPT contains a public or symmetric key. 125 The algo field gives the algorithm. The id identifies the key, 126 this id is copied to ENCRYPT type RRS to identify which key to use 127 to decrypt the data. The data contains the key bits. 129 o RRS (usage=2): encrypted data. The data contains encrypted 130 resource records. The data is encrypted with the selected 131 algorithm and key id. The data contains resource records in DNS 132 wireformat [RFC1034], with a domain name, type, class, ttl, 133 rdatalength and rdata. 135 o SYM (usage=3): the ENCRYPT contains an encrypted symmetric key. 136 The contained, encrypted data is rdata of an ENCRYPT of type KEY 137 and has the symmetric key. The data is encrypted with the 138 algorithm and id indicated. The encrypted data encompasses the 139 flags, algo, id, data for the symmetric key. 141 The ENCRYPT RR type can contain keys. It uses the same format as the 142 DNSKEY record [RFC4034] for public keys. algo=0 is reserved for 143 future expansion of the algorithm number above 255. algo=1 is RSA, 144 the rdata determines the key size. algo=2 is AES, aes-cbc, size of 145 the rdata determines the size of the key. 147 3. Server and Client Algorithm 149 If a clients wants to fetch the keys for the server from the server, 150 it performs a query with query type ENCRYPT and query name '.' (root 151 label). The reply contains the ENCRYPT (or multiple if a choice is 152 offered) in the answer section. These ENCRYPTs have the KEY usage. 154 If a client wants to perform an encrypted query, it sends an 155 unencrypted outer packet, with query type ENCRYPT and query name '.' 156 (root label). In the authority section it includes an ENCRYPT record 157 of type RRS. This encrypts a number of records, the first is a 158 query-section style query record, and then zero or more ENCRYPTs of 159 type KEY that the server uses to encrypt the reply. If the client 160 wants to use a symmetric key, it omits the KEYs, and instead includes 161 an ENCRYPT of type SYM in the authority section. The ENCRYPT of type 162 RRs then follows after the SYM and can be encrypted with the key from 163 that SYM. 165 If a server wants to encrypt a reply, it also uses the ENCRYPT type. 166 The reply looks like a normal DNS packet, i.e. it has a normal 167 unencrypted outer DNS packet. Because the query name and query type 168 have been encrypted, the outer packet has a query name of '.' and 169 query type of ENCRYPT and the reply has an ENCRYPT type RRS in the 170 answer section. The reply RRs have been encrypted into the data of 171 the ENCRYPT record. The RRS data starts with 10 bytes of header; the 172 flags and section counts. 174 The client may lookup keys whenever it wants to. It may cache the 175 keys for the server, using the TTL of those ENCRYPT records. It 176 should also cache failures to lookup the ENCRYPT record for some 177 time. If the client fails to look up the ENCRYPT records it MUST 178 fall back to unencrypted communication (this is the opportunistic 179 encryption case). The result of an encrypted query may also be 180 timeouts, errors or replies with mangled contents, in that case the 181 client MUST fall back to unencrypted communication (this is the 182 opportunistic encryption case). 184 If some middlebox removes the ENCRYPT from the authority section of 185 an encrypted query, the query looks like a . ENCRYPT lookup and 186 likely a reply with ENCRYPTs of type KEY is returned instead of the 187 encrypted reply with an ENCRYPT of type RRS, and again the client 188 does the unencrypted fallback (this is the opportunistic encryption 189 case). If the server has changed its keys and does not recognize the 190 keys in an encrypted query, it should return an ENCRYPT record of 191 type PAD with no data. A server may decide it does not (any longer) 192 have the resources for encryption and reply with SERVFAIL to 193 encrypted queries, forcing unencrypted fallback (this is the 194 opportunistic encryption case). Keys for unknown algorithms should 195 be ignored by the client, if no usable keys remain, fallback to 196 insecure (this is for both opportunistic and authenticated). 198 The client may cache the ENCRYPT of type SYM for a server together 199 with the symmetric secret, this is better for performance, as public- 200 key operations can be avoided for repeated queries. The server may 201 also cache the ENCRYPTs of type SYM with the decoded secret, 202 associating a lookup for the rdata of the SYM record with the decoded 203 secret, avoiding public-key operations for repeated queries. This is 204 why the SYM record is sent separately in the authority section in 205 queries (it is identical and can be used for cache lookups). 207 Key rollover is possible, support the old key for its TTL, while 208 advertising the new key, for the servers. For clients, generate a 209 new public or symmetric key and use it. 211 4. Authenticated Operation 213 The previous documented the opportunistic operation, where deployment 214 is easier, but security is weaker. This documents options for 215 authenticated operation. The client selects if encryption is 216 authenticated, opportunistic, or disabled in its local policy 217 (configuration). 219 The authentication happens with a DNSSEC signed DS record that 220 carries the key for confidential DNS. This removes a full roundtrip 221 from the connection setup cost. The DS has hash type TBDhashtype, 222 that is specific for confidential DNS. The DS record carries a flag 223 byte and the public key (in DNSKEY's wireformat) in its rdata. This 224 means that the confidential DNS keys are acquired with a referral to 225 the zone and are secured with DNSSEC. 227 Because the key itself is carried, the probe sequence can be omitted 228 and an encrypted query can be sent to the delegated server straight 229 away. The nameservers for that zone then MUST support using that key 230 for encrypting packets. The servers have the same key with 231 authenticated mode, where with the opportunistic mode, every server 232 could have its own key. 234 Validators do not know or support the DS with ENCRYPT hash type, 235 those validators ignore them and continue to DNSSEC validate the 236 zone. Validators that support the new hash type should use them to 237 encrypt messages and use the remaining DS records to DNSSEC validate 238 the zone. 240 This changes the opportunistic encryption to authenticated 241 encryption. The fallback to insecure is still possible and this may 242 make deployment easier. The one byte at the start of the base64 243 data, in its least significant bit, signals if fallback to insecure 244 is allowed (value 0x01). That gives the zone owner the option to 245 enable fallback to insecure or if it should be disabled. The 246 remainder of the DS base64 data contains a public key in the same 247 format as when sent in the rdata of ENCRYPT KEY. The type of the key 248 is in the key type field of this DS record. With fallback to 249 insecure disabled and the keys authenticated the confidential DNS 250 query and response should be fully secure (i.e. not 251 'Opportunistically' secure). 253 With fallback to insecure disabled, queries fail instead of falling 254 back to insecure. This means no answer is acquired, and DNS lookups 255 for that zone fail because the security failed. 257 The DS method works for authority servers. Recursors need another 258 method. The client looks up reverse-of-recursors-IP.arpa ENCRYPT and 259 gets the keys signed with DNSSEC from there (type ENCRYPT KEY 260 lookup). If there is no dnssec secure answer with a key, the 261 opportunistic key exchange is attempted. Do this for DNSSEC-insecure 262 answers, if there is no trust anchor, or when no such name and 263 ENCRYPT are present. If it is dnssec bogus, then authentication 264 failed and it is not possible to communicate with the server (with 265 the authenticated communication mode selected by the client). 267 5. IANA Considerations 269 An RR type registration for type ENCRYPT with number TBD and it 270 references this document [[to be done when this becomes RFC]]. 272 A DS record hash type is registered TBDhashtype that references this 273 document. It is for the confidential DNS public key, acronym 274 ENCRYPT. 276 6. Security Considerations 278 Opportunistic encryption can be configured. Opportunistic encryption 279 has many drawbacks against active intrusion, but it works against 280 pervasive passive surveillance, and thus it improves privacy. 282 With authentication (if selected by the client) the key is secured 283 with DNSSEC. 285 This technique encrypts DNS queries and answers, but other data 286 sources, such as timing, IP addresses, and the packet size can be 287 observed. These could provide almost all the information that was 288 encrypted. 290 7. Acknowledgments 292 Roy Arends 294 8. Normative References 296 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 297 STD 13, RFC 1034, November 1987. 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, March 1997. 302 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 303 Rose, "Resource Records for the DNS Security Extensions", 304 RFC 4034, March 2005. 306 Authors' Addresses 308 Wouter Wijngaards 309 NLnet Labs 310 Science Park 140 311 Amsterdam 1098 XH 312 The Netherlands 314 EMail: wouter@nlnetlabs.nl 316 Glen Wiley 317 VeriSign, Inc. 318 Reston, VA 319 USA 321 EMail: gwiley@verisign.com