idnits 2.17.1 draft-dempsky-dnscurve-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (February 26, 2010) is 5174 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: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Dempsky 3 Internet-Draft OpenDNS, Inc. 4 Intended status: Standards Track February 26, 2010 5 Expires: August 30, 2010 7 DNSCurve: Link-Level Security for the Domain Name System 8 draft-dempsky-dnscurve-01 10 Abstract 12 This document describes DNSCurve, a protocol extension that adds 13 link-level security to the Domain Name System (DNS). 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 30, 2010. 38 Copyright Notice 40 Copyright (c) 2010 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 BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Base-32 Encoding . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Encoding Public Keys in Name Server Names . . . . . . . . . . 5 61 5. Nonce Generation . . . . . . . . . . . . . . . . . . . . . . . 5 62 6. DNSCurve Expanded Formats . . . . . . . . . . . . . . . . . . 6 63 6.1. Streamlined Format . . . . . . . . . . . . . . . . . . . . 6 64 6.2. TXT Format . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7. UDP and TCP . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 71 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 DNSCurve adds link-level security to the Domain Name System (DNS). 77 It includes a key distribution mechanism compatible with today's name 78 server software and registry services, and two packet formats: a 79 simple streamlined format requiring minimal space and processing 80 overhead and a mostly backwards-compatible format intended for use 81 with strict firewalls and DNS proxies. 83 DNSCurve packets include a cryptographic MAC (aka authenticator) to 84 provide integrity and availability. Clients can be confident that 85 verified responses came from the appropriate server and were not 86 forged by a blind or even sniffing attacker, while servers can be 87 confident that responses will not be replayed against other 88 unintended clients. Additionally, DNSCurve packets are encrypted to 89 provide some confidentiality. 91 1.1. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 2. Overview 99 DNSCurve uses Curve25519XSalsa20Poly1305, a particular combination of 100 the Curve25519, Salsa20, and Poly1305 primitives as described in 101 [naclcrypto]. In particular, it is a cryptosystem featuring 256-bit 102 public and secret keys, 192-bit nonces, and 128-bit authenticators. 104 Each DNSCurve client and server has a secret key and a corresponding 105 public key. DNSCurve servers distribute their public keys by 106 encoding them in name server names embedded in standard DNS NS 107 records (as described in Section 4), while DNSCurve clients 108 distribute their public keys by including them in their query 109 packets. (Additional mechanisms for key distribution like DNSSEC's 110 trust anchors and DLV are possible, but not defined by this 111 document.) 113 When a DNSCurve client is about to send a DNS query to a name server, 114 if the client knows a DNSCurve public key for that name server, it 115 MAY instead use that public key along with its own DNSCurve secret 116 key and a nonce to protect its query in a "cryptographic box" as 117 described in [naclcrypto]. The client then encodes this 118 cryptographic box along with the nonce and its own public key as an 119 expanded DNSCurve query packet, which it sends to the DNSCurve server 120 instead of the original DNS query. 122 Upon receiving a DNS query packet, a DNSCurve name server should 123 first treat the packet as a DNSCurve query packet by extracting the 124 client's DNSCurve public key, nonce, and boxed query and trying to 125 open the box using the extracted public key and its own secret key. 126 However, if this fails (i.e., the packet is not formatted as an 127 expanded DNSCurve query packet or the box's authenticator is 128 invalid), then the server responds to the packet as a normal DNS 129 packet. 131 Assuming the unboxing succeeds, then the server discovers the 132 client's original query packet. To send a response, the server 133 chooses a nonce extension to append to the client-chosen nonce, and 134 protects its response packet in a cryptographic box using the extend 135 nonce and same keys used to unbox the client's DNS query. The server 136 then encodes this cryptographic box as an expanded DNSCurve response 137 packet, which it sends to the DNSCurve client instead of the original 138 DNS response. 140 Meanwhile, the DNSCurve client waits for an expanded DNSCurve 141 response packet. If it receives a non-DNSCurve response packet, an 142 expanded DNSCurve response packet with an invalid nonce (i.e., not an 143 extension of its original nonce) or an invalid cryptographic box 144 (i.e., cannot be opened using the same keys and the extended nonce), 145 then it discards the packet and continues waiting. Once it receives 146 a valid expanded DNSCurve response packet, it opens the cryptographic 147 box to discover the server's original DNS response. 149 3. Base-32 Encoding 151 Sometimes DNSCurve communicates arbitrary byte strings inside domain 152 names. While the DNS protocol is 8-bit safe for names and labels 153 (except for case-insensitive handling of ASCII alphabetic 154 characters), many tools have trouble with arbitrary characters in 155 domain names, in particular domain registrar software. To cope with 156 this limitation, DNSCurve encodes byte strings using a set of safe 157 alphanumeric characters. 159 In DNSCurve's base-32 encoding, a byte string is interpreted as a 160 number in little-endian form. Each 5-bit sequence of this number, 161 from least significant to most significant, is encoded as one of the 162 standard "digits" "0123456789bcdfghjklmnpqrstuvwxyz". A final 163 sequence of fewer than 5 bits is zero-extended before encoding. 164 Decoders MUST accept "BCDFGHJKLMNPQRSTUVWXYZ" as synonyms for 165 "bcdfghjklmnpqrstuvwxyz". 167 For example, the two-byte string with bytes {0x64,0x88} (i.e., 168 {100,136} decimal) is interpreted as the integer 0x8864 (i.e., 169 34916). The bits 1000100001100100 of this integer are divided into 170 5-bit parts 00100, 00011, 00010, 00001, which in turn are encoded as 171 "4", "3", "2", "1". The original string is therefore encoded as the 172 string "4321". 174 N.B., this is not the same encoding as defined in [RFC4648]. In 175 particular, the byte string is chunked into 5-bit sequences 176 differently, and a different alphabet is used. The first allows 177 DNSCurve public keys to be encoded slightly more compactly (see 178 Section 4), and the second helps to further prevent false positives 179 when searching for base-32 encoded strings in domain names. 181 3.1. Examples 183 +-------------------------------------------+------------------+ 184 | Byte string | Base-32 encoding | 185 +-------------------------------------------+------------------+ 186 | {} | "" | 187 | {0x88} | "84" | 188 | {0x9f,0x0b} | "zw20" | 189 | {0x17,0xa3,0xd4} | "rs89f" | 190 | {0x2a,0xa9,0x13,0x7e} | "b9b71z1" | 191 | {0x7e,0x69,0xa3,0xef,0xac} | "ycu6urmp" | 192 | {0xe5,0x3b,0x60,0xe8,0x15,0x62} | "5zg06nr223" | 193 | {0x72,0x3c,0xef,0x3a,0x43,0x2c,0x8f} | "l3hygxd8dt31" | 194 | {0x17,0xf7,0x35,0x09,0x41,0xe4,0xdc,0x01} | "rsxcm44847r30" | 195 +-------------------------------------------+------------------+ 197 4. Encoding Public Keys in Name Server Names 199 DNSCurve public keys are encoded in name server names as a 54-byte 200 label consisting of the magic string "uz5" followed by the first 51 201 bytes of the base-32 encoding of the public key. (Curve25519 public 202 keys are actually 255-bit integers in little-endian, so the 52nd byte 203 of the base-32 encoding will always be "0".) 205 When a DNSCurve client is searching a name server name for a DNSCurve 206 public key, it MUST check every label for an encoded public key. If 207 multiple public keys are found, the left-most label MUST be chosen. 208 String comparison with "uz5" MUST be performed case-insensitively. 210 5. Nonce Generation 212 For every request, DNSCurve clients generate a 96-bit nonce, and for 213 every response, DNSCurve servers generate a 96-bit nonce extension. 214 Nonces MUST be unique for distinct packets for the same client-server 215 key pair. A simple way to achieve this is to choose a unique nonce 216 for each packet and for each retransmission. Additionally, servers 217 MUST use a non-zero nonce extension (because nonces are zero extended 218 in query packets). However, subject to these constraints, clients 219 and servers may generate nonces however they choose. 221 Two recommended ways to generate a 96-bit nonce or nonce extension 222 are 224 1. a 64-bit counter (starting at 1) followed by a 32-bit random 225 number and 227 2. a 64-bit timestamp (e.g., nanoseconds since 1970) followed by a 228 32-bit random number. 230 In either case the 64-bit value MUST NOT decrease even if the 231 software restarts or the system clock jumps backwards. 233 If multiple clients or multiple servers share a DNSCurve secret key, 234 then they MUST make sure no two separate clients or servers generate 235 the same nonce. A simple way to achieve this is to use nonce 236 separation; e.g., if two servers share a DNSCurve key pair, one 237 server could use only even nonces and the other could use only odd 238 nonces. 240 6. DNSCurve Expanded Formats 242 DNSCurve defines two expanded formats: "streamlined" and "TXT". Each 243 includes a format for expanded queries and a format for expanded 244 responses. DNSCurve clients may send DNSCurve expanded queries using 245 whichever format it chooses, but they are encouraged to use the 246 streamlined format when possible. A DNSCurve server MUST support 247 DNSCurve expanded queries in either format and MUST send expanded 248 responses using the corresponding format. 250 6.1. Streamlined Format 252 An expanded query packet in streamlined format has the following 253 bytes: 255 o 8 bytes: the magic string "Q6fnvWj8". 257 o 32 bytes: the client's DNSCurve public key. 259 o 12 bytes: a client-selected nonce for this packet. 261 o A cryptographic box containing the original DNS query packet. 263 An expanded response packet in streamlined format has the following 264 bytes: 266 o 8 bytes: the magic string "R6fnvWJ8". 268 o 12 bytes: the client's nonce. 270 o 12 bytes: a server-selected nonce extension. 272 o A cryptographic box containing the original DNS response packet. 274 Note that this streamlined response format does not repeat the 275 client's query name, and in particular does not repeat the client's 276 public key. However, it does repeat the client's nonce. 278 6.2. TXT Format 280 The "TXT" format receives its name from the fact that expanded query 281 and response packets in this format appear to casual inspection to be 282 standard DNS packets with two possible exceptions: 1) the query name 283 may exceed 255 bytes and 2) the total packet may exceed 512 bytes. 285 When encoding an expanded query packet in TXT format, a DNSCurve 286 client MUST create a DNS standard query packet with the AA, TC, RD, 287 RA, Z, and RCODE bits cleared, a single entry in the question 288 section, and no records in the answer, authority, or additional 289 records sections. The one question MUST ask for Internet-class TXT 290 records for the query name constructed from the concatenation of the 291 following labels: 293 o One or more labels, each label except the last being exactly 50 294 bytes, with the last label being at most 50 bytes. The 295 concatenation of these labels is the base-32 encoding of a 96-bit 296 client-selected nonce for this packet followed by a cryptographic 297 box containing the original DNS query packet. 299 o One 54-byte label: the client's DNSCurve public key, encoded as 300 described in Section 4, except with the magic string "x1a" instead 301 of "uz5". 303 o Zero or more additional labels specifying the name of the zone 304 served by this server; i.e., the owner name of the relevant NS 305 record. 307 A DNSCurve server SHOULD be lenient in decoding expanded query 308 packets in TXT format. In particular, it MUST allow the RD bit to 309 either be set or clear, MUST allow records in the answer, authority 310 records, and additional records sections, and MUST allow any labels 311 to follow the DNSCurve public key in the query name. However, it 312 MUST discard packets with the QR bit set. 314 When encoding an expanded response packet in TXT format, a DNSCurve 315 server MUST create a DNS standard response packet copying the ID, RD 316 bit, and questions section from the expanded query packet, setting 317 the AA bit, leaving the TC and RA bits cleared and Z and RCODE values 318 set to 0, containing one record in the answer section, and no records 319 in the authority records or additional records section. The record 320 in the answer section MUST be an Internet-class TXT record for the 321 query name from the questions section with a TTL of 0. The RDATA of 322 this record is the 96-bit server-selected nonce extension followed by 323 a cryptographic box containing the original DNS response packet, 324 encoded as a sequence of one or more strings of at most 255 bytes in 325 standard DNS TXT RDATA format. 327 Similarly, a DNSCurve client SHOULD be lenient in decoding expanded 328 response packets in TXT format. In particular, it MUST allow the 329 server to alter the case of the query name when repeating it in the 330 questions section. 332 7. UDP and TCP 334 If a normal DNS response packet is larger than 512 bytes then the 335 server replaces it by an explicitly truncated packet. The client 336 then tries again through TCP. Servers are not required to support 337 TCP if no responses are above 512 bytes; clients are permitted to try 338 TCP only if the server has explicitly indicated truncation. 340 DNSCurve does not require TCP support from servers that were not 341 already supporting TCP. If the original DNS response packet is at 342 most 512 bytes then the server is permitted to send the expanded 343 response packet as a UDP packet. DNSCurve clients are required to 344 set aside a 4096-byte buffer for receiving a UDP response packet. 346 If the original DNS response packet is larger than 512 bytes then it 347 is replaced by an explicitly truncated packet and the truncated 348 packet is protected by DNSCurve. In this case the client tries again 349 by TCP, sending its DNSCurve query packet through TCP and receiving 350 the DNSCurve response through TCP. 352 TCP is considerably more expensive for clients and servers than UDP 353 is, and TCP has no protection against denial of service, so server 354 administrators are advised to stay below 512 bytes if possible. 355 DNSCurve adds some denial-of-service protection for UDP but cannot do 356 anything to help TCP. 358 If a protected DNS query includes an EDNS0 OPT record, then the 359 payload size field refers to how large the original DNS response 360 packet can be before encoding as a DNSCurve response packet. Clients 361 MUST reduce the payload size they advertise to account for overhead 362 from encoding the response as an expanded response packet. If a 363 server builds a response within the payload size limit, but then 364 cannot fit the encoded response in 4096 bytes, it MAY silently 365 discard the response. 367 Even when DNSCurve transactions take place over UDP, they may still 368 be vulnerable to denial-of-service attacks due to spoofed IP 369 fragments if response packets are large enough to require IP 370 fragmentation. Therefore, servers SHOULD try to keep response 371 packets within the path's MTU limits. 373 8. Security Considerations 375 The security of the Curve25519XSalsa20Poly1305 cryptosystem and its 376 underlying cryptographic primitives is discussed in [naclcrypto]. In 377 summary, it is designed to meet the standard notions of privacy and 378 third-party unforgeability for a public-key authenticated-encryption 379 scheme using nonces. 381 DNSCurve only provides link-level security between a client-server 382 pair. It does not attempt to ensure end-to-end security for queries 383 and responses relayed by untrusted DNS proxies and caches. 385 DNSCurve clients are free to choose whether or not to use DNSCurve on 386 a per query basis; e.g., a client may decide to fallback to standard 387 DNS after a few failed DNSCurve queries. Of course, DNSCurve cannot 388 make any security guarantees for transactions that do not use 389 DNSCurve, so clients are encouraged to use DNSCurve if possible. 391 DNSCurve adds some confidentiality by encrypting DNS packet contents 392 but does not attempt to hide the length of the original DNS packet 393 nor the source or destination of the packet. Additionally, the TXT 394 format requires clients to reveal the zone they are querying. 396 9. IANA Considerations 398 This document has no actions for IANA. 400 10. Acknowledgements 402 The DNSCurve protocol was first introduced by Dan Berstein. Thanks 403 also to Adam Langley and George Barwood for their contributions to 404 early DNSCurve implementations. 406 Much thanks for feedback regarding this draft from George Barwood, 407 Sjoerd Langkemper and Nikos Mavrogiannopoulos. 409 11. References 411 11.1. Normative References 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, March 1997. 416 [naclcrypto] 417 Bernstein, D., "Cryptography in NaCl", March 2009. 419 11.2. Informative References 421 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 422 Encodings", RFC 4648, October 2006. 424 Author's Address 426 Matthew Dempsky 427 OpenDNS, Inc. 428 410 Townsend St, Suite 250 429 San Francisco, CA 94107 430 US 432 Phone: +1 415 680 3742 433 Email: matthew@dempsky.org