idnits 2.17.1 draft-hallambaker-privatedns-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 521 has weird spacing: '...e 6a bb b3 d4...' == Line 589 has weird spacing: '...a 74 ed a4 84...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 7, 2014) is 3456 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) == Missing Reference: 'U-PUBLIC' is mentioned on line 200, but not defined == Missing Reference: 'U-SUBSCRIBER' is mentioned on line 203, but not defined == Missing Reference: 'U-PRIVATE' is mentioned on line 203, but not defined == Missing Reference: 'U-HYBRID' is mentioned on line 275, but not defined == Missing Reference: 'TBS' is mentioned on line 281, but not defined == Outdated reference: A later version (-08) exists of draft-hallambaker-omnibroker-07 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-24) exists of draft-hallambaker-jsonbcd-01 -- Possible downref: Normative reference to a draft: ref. 'I-D.hallambaker-jsonbcd' == Outdated reference: A later version (-02) exists of draft-hallambaker-dnse-00 == Outdated reference: A later version (-08) exists of draft-hallambaker-wsconnect-05 Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force (IETF) Phillip Hallam-Baker 2 Internet-Draft Comodo Group Inc. 3 Intended Status: Standards Track November 7, 2014 4 Expires: May 11, 2015 6 Private-DNS 7 draft-hallambaker-privatedns-01 9 Abstract 11 This document describes Private DNS, a transport security mechanism 12 for the DNS protocol. The mechanism may be employed to secure 13 communication between a client and its resolver or between a resolver 14 and an authoritative server. 16 Service binding including key exchange is effected using the JSON 17 Service Connect (JCX) Protocol. DNS protocol messages are wrapped in 18 a new framing protocol. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.3. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Service Connection . . . . . . . . . . . . . . . . . . . 4 58 2.1.1. Example: Public Resolver . . . . . . . . . . . . . . 5 59 2.1.2. Example: Hybrid Resolver . . . . . . . . . . . . . . 6 60 2.2. Query Protocol Binding . . . . . . . . . . . . . . . . . 9 61 2.2.1. Message Binding. . . . . . . . . . . . . . . . . . . 10 62 2.2.2. Query Protocol Example . . . . . . . . . . . . . . . 10 63 2.2.3. Authentication Conformance . . . . . . . . . . . . . 13 64 2.2.4. Handling Multiple Requests . . . . . . . . . . . . . 14 65 3. Service Connection and Key Exchangee . . . . . . . . . . . . . 14 66 3.1. UDP Binding . . . . . . . . . . . . . . . . . . . . . . . 14 67 3.2. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . 15 68 4. Security Considerationsns . . . . . . . . . . . . . . . . . . 15 69 4.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 15 70 4.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 15 71 4.3. Access . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 73 6. Acnowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 1. Introduction. 80 Recent events have required urgent consideration of privacy concerns 81 in Internet protocols. In particular the lack of confidentiality 82 controls in the DNS [RFC1035] protocol is of considerable concern. 84 This document describes Private-DNS, a security enhancement for the 85 DNS protocol that meets the principal use cases and requirements set 86 out in [I-D.hallambaker-dnse]. This enhancement provides for 87 encryption and authentication of the DNS protocol messages. 89 Private-DNS makes use of the JSON Service Connect (JCX) Protocol [I- 90 D.hallambaker-wsconnect] and the UYFM framing protocol described in 91 that specification. 93 1.1. Related Work 95 The proposal approach compliments the integrity controls provided by 96 DNSSEC [RFC4033]. While both provide integrity controls, the controls 97 provided by DNSSEC are based on digital signatures while this 98 proposal provides controls based on a Message Authentica Code 99 technique. 101 Like the Omnibroker protocol [I-D.hallambaker-omnibroker], this 102 proposal is built on JCX [I-D.hallambaker-wsconnect] but offers a low 103 level interface to the DNS protocol alone as opposed to a high level 104 interface to generalized discovery services. A client would use the 105 DNSE-JX interface in cases where retrieval of specific DNS resource 106 records is required. The OmniBroker protocol would be used in cases 107 where the client delegates the choice of discovery strategy to the 108 OmniBroker service. 110 1.2. Terminology 112 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 113 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 114 document, are to be interpreted as described in [RFC2119] 116 1.3. Defined Terms 118 [[These terms are deliberately left blank here or else we will spend 119 time wordsmithing the defined term definitions rather than looking at 120 the protocol.] 121 Authoritative DNS Server 123 Caching Recursive Resolver 125 DNS 127 DNS Client 129 Recursive Resolver 131 Stub Resolver 133 2. Architecture 135 PRIVATE-DNS has two parts 137 * Service Connection 139 * DNS message encapsulation 141 In PRIVATE-DNS, the service connection is provided by the existing 142 [I-D.hallambaker-wsconnect] proposal. The DNS message encapsulation 143 is new and supports encryption and authentication of the DNS protocol 144 messages. 146 To make use of PRIVATE-DNS a client first establishes a connection to 147 a DNS server (resolver or authoritative) using the connection 148 protocol. Once a client has established a connection it MAY use it to 149 make as many queries as desired until either the connection context 150 expires or is cancelled by the service. 152 The Service Connection and Query Service MAY be operated on the same 153 host or on separate hosts. 155 2.1. Service Connection 157 The service connection mechanism is responsible for establishing a 158 connection context between a client and a service. The connection 159 context comprises: 161 * A security context (opaque identifier, key, algorithm choice) 162 between the client and the connection service 164 * One or more query host connection contexts, each 165 comprisingNetwork connection description (IP address, Port, 166 Protocol, transport)Security Context (opaque identifier, key, 167 algorithm choice) between the client and the query host 169 The PRIVATE-DNS proposal is designed on the assumption that Service 170 Connection transactions are relatively infrequent and thus the 171 efficiency of the Service Connection protocol is not a major concern. 173 Accordingly the Service Connection protocol is implemented as a 174 JSON/REST Web Service over HTTP. While of an efficient encoding (e.g. 175 [I-D.hallambaker-jsonbcd] would permit a more efficient 176 implementation of the protocol using UDP, such an approach would be 177 vulnerable to Denial of Service attacks against the service unless 178 appropriate countermeasures were taken. For example use of a 'cookie' 179 approach to prove the validity of the purported request source 180 address. 182 A service connection MAY return a host connection set that includes 183 multiple protocol and/or transport options. This has the important 184 consequence that it allows new message formats or a transition to an 185 entirely new protocol to be effected by simply defining a new 186 identifier. 188 A distinction is drawn between a connection to a service and a 189 connection to a host. A connection to a host is a relationship to a 190 specific instance of a service with a distinct IP address. A 191 connection to a service is a relationship to a set of hosts. This 192 distinction is an important one for Denial of Service mitigation. A 193 DNS service need not publish the same network connection description 194 to every client. This permits a service to mitigate DoS attacks by 195 filtering query requests by IP address, a strategy that is greatly 196 enhanced by the large address space of IPv6. 198 Different configurations of the Service Connection service allow a 199 DNS service to meet different combinations of security requirements. 200 For example the Public Resolver described in [U-PUBLIC] would not 201 require authentication of the client to the service but this would be 202 required for the Subscriber, Private and Hybrid Resolvers described 203 in [U-SUBSCRIBER], [U-PRIVATE] and [U-HYBRID].]. 205 2.1.1. Example: Public Resolver 207 Following the use case [[U-PUBLIC] described in [I-D.hallambaker- 208 dnse], Alice buys a laptop for her personal use at home. To ensure 209 the privacy of her DNS connection she selects example.com, a public 210 resolver that provides DNS service without requiring any form of 211 subscription or registration. 213 During the initial configuration process, the machine uses the local 214 DNS advertised in the DCHP configuration for the first and last time 215 for discovery of the Service Connection Service of example.com. 217 Having discovered a Service Connection Service, the client requests a 218 service provider for the PRIVATE-DNS service by establishing a TLS 219 connection to indicated server. The server returns a TLS Certificate 220 that meets the authentication criteria of the client. Once the TLS 221 connection is established, an anonymous client connection is 222 established. 224 POST /.well-known/sxs-connect/ HTTP/1.1 225 Content-Type: application/json;charset=UTF-8 226 Cache-Control: no-store 227 Host: localhost:8080 228 Content-Length: 226 229 Expect: 100-continue 231 { 232 "BindRequest": { 233 "Service": ["private-dns-resolver"], 234 "Encryption": ["A128CBC", 235 "A256CBC", 236 "A128GCM", 237 "A256GCM"], 238 "Authentication": ["HS256", 239 "HS384", 240 "HS512", 241 "HS256T128"]}} 243 Since the example.com service does not require authentication, the 244 request is granted immediately and the necessary host connection 245 parameters returned immediately: 247 HTTP/1.1 OK Success 248 Content-Length: 578 249 Date: Tue, 14 Oct 2014 19:34:07 GMT 250 Server: Microsoft-HTTPAPI/2.0 252 { 253 "TicketResponse": { 254 "Status": 200, 255 "StatusDescription": "Success", 256 "Cryptographic": [], 257 "Service": [{ 258 "Service": "private-dns-resolver", 259 "Name": "localhost", 260 "Port": 9090, 261 "Priority": 100, 262 "Weight": 100, 263 "Transport": "UDP", 264 "Cryptographic": { 265 "Secret": " 266 qJq11EcqrvWe2WfyDC2FLg", 267 "Encryption": "A128CBC", 268 "Authentication": "HS256T128", 269 "Ticket": " 270 Tpau1M6HuDjwuzwLhw9SWPi9Qx1zfkcQmaj0YRnKV-JCRv2kld06zyobptvuA2F6 271 JGXkM0JGnSVWOPtn235wnIljsg7pZg25vPiofgPuZNY"}}]}} 273 2.1.2. Example: Hybrid Resolver 275 Following the use case [U-HYBRID], Alice decides to use her personal 276 computer for work under her employer's 'Bring Your Own Device' 277 program. Alice needs access to multiple services within her 278 employer's intranet. 280 Her system administrator issues her an account name [TBS], a one time 281 use PIN [TBS] and the DNS address of the service connection service 282 byod.example.net. Having established a TLS connection as before, the 283 client makes an initial request: 285 POST /.well-known/sxs-connect/ HTTP/1.1 286 Content-Type: application/json;charset=UTF-8 287 Cache-Control: no-store 288 Host: localhost:8080 289 Content-Length: 352 290 Expect: 100-continue 292 { 293 "OpenPINRequest": { 294 "Service": ["private-dns-resolver"], 295 "Encryption": ["A128CBC", 296 "A256CBC", 297 "A128GCM", 298 "A256GCM"], 299 "Authentication": ["HS256", 300 "HS384", 301 "HS512", 302 "HS256T128"], 303 "Account": "alice", 304 "Domain": "example.com", 305 "HaveDisplay": false, 306 "Challenge": " 307 c1CfkTu5XVVLuT2gxaVFjA"}} 309 The server provides a challenge for verifying the one time use PIN. 311 HTTP/1.1 281 Pin code required 312 Content-Length: 511 313 Date: Tue, 14 Oct 2014 19:34:07 GMT 314 Server: Microsoft-HTTPAPI/2.0 316 { 317 "OpenPINResponse": { 318 "Status": 281, 319 "StatusDescription": "Pin code required", 320 "Challenge": " 321 9W8IxZw-bEQBbnWBWSM9Vw", 322 "ChallengeResponse": " 323 2FPG-xEBcYIo2137in1wxnhqUxmhygB6SsfvzhtYTXE", 324 "Cryptographic": { 325 "Secret": " 326 KATjv8Nkix4ITrexxyGBsQ", 327 "Encryption": "A128CBC", 328 "Authentication": "HS256", 329 "Ticket": " 330 vnBXaykCug2eeRVsH-CEqhR3qJvvRQEmm4a1Ldh-G-Zqj7acqA9NtLYVCnJflaWs 331 Sd2cMi8-mqdX-5VRVAMFfrxjdaQx4uq7mcr59OUFMRGSb11ZXcMkan9h142NUjmI 332 t1MnYRsXWNdFndPE19zMDA"}}} 334 Having obtained the challenge value from the service, the client 335 resends the initial request, having authenticated it this time under 336 the challenge and one time PIN: 338 POST /.well-known/sxs-connect/ HTTP/1.1 339 Content-Type: application/json;charset=UTF-8 340 Cache-Control: no-store 341 Session: Value=uuPiOYOP7kpM3xrYXMWa9JttlhR-VSf604UR6iFbPpY; 342 Id=vnBXaykCug2eeRVsH-CEqhR3qJvvRQEmm4a1Ldh-G-Zqj7acqA9NtLYVCnJf 343 laWsSd2cMi8-mqdX-5VRVAMFfrxjdaQx4uq7mcr59OUFMRGSb11ZXcMkan9h142 344 NUjmIt1MnYRsXWNdFndPE19zMDA 345 Host: localhost:8080 346 Content-Length: 137 347 Expect: 100-continue 349 { 350 "TicketRequest": { 351 "Service": ["private-dns-resolver"], 352 "ChallengeResponse": " 353 S_t81MumUqouGaxWQIT1nOJfkUaE1YcXNwQJXkXuqbM"}} 355 The server returns a set of host connections for the requested 356 services. The scope of the PRIVATE-DNS service is limited to the 357 domain tree *.example.net: 359 HTTP/1.1 OK Success 360 Content-Length: 858 361 Date: Tue, 14 Oct 2014 19:34:07 GMT 362 Server: Microsoft-HTTPAPI/2.0 364 { 365 "TicketResponse": { 366 "Status": 200, 367 "StatusDescription": "Success", 368 "Cryptographic": [{ 369 "Protocol": "sxs-connect", 370 "Secret": " 371 UDvvBM8fE42zCs4g2mVnjw", 372 "Encryption": "A128CBC", 373 "Authentication": "HS256", 374 "Ticket": " 376 WZDn4kOYJCrx6LnhuWwH3U00_aCJBcNRcUZyIV8L_hWVGjtvF8UEWTL1SgRXYcSE 377 zVBR9v_ER4HpSEwkYgKLX2crAo2fZMZlqyRW9kh5s88"}], 378 "Service": [{ 379 "Service": "private-dns-resolver", 380 "Name": "localhost", 381 "Port": 9090, 382 "Priority": 100, 383 "Weight": 100, 384 "Transport": "UDP", 385 "Cryptographic": { 386 "Secret": " 387 IdvuBOccKHwnPFIByHaU6w", 388 "Encryption": "A128CBC", 389 "Authentication": "HS256T128", 390 "Ticket": " 391 xMVgwd-i2nHjbmZDUowVx3yAUHl_gHuh7aNzxVArYepIBMHcpaaNGw4goUsZTMby 392 EOUinBXDXkmVE66ExnA4H4Mgd9GSu48ReM9lKtrff98"}}]}} 394 2.2. Query Protocol Binding 396 The Query Protocol Binding is designed to efficiently support the 397 following features: 399 * Encryption 401 * Prevent use in an Denial of Service attack. 403 * Authentication 405 * Multiple DNS queries and responses per PRIVATE-DNS Query [[*] 407 * Multiple packet responses [[*] 409 The features marked [[*] are not essential for the purpose of meeting 410 the privacy requirements but considerably improve the efficiency and 411 flexibility of the DNS protocol. In particular the ability to make 412 multiple DNS queries in a single transaction over UDP transport 413 enables the use of novel discovery techniques without impact on 414 performance. 416 While the privacy requirements may be met through use of encryption 417 alone, any encoding that does not provide authentication of requests 418 allows a service to be used as an attack vector in a denial of 419 service attack on third parties. 421 The Query Protocol Binding wraps the [RFC1035] message structure 422 rather than eliminating parts that are redundant. For example, the 423 Query Protocol Binding Transaction ID which has a minimum length of 424 128 bits supplements rather than replaces the DNS message transaction 425 ID of 16 bytes. 427 2.2.1. Message Binding. 429 To ensure access to the DNS service in any network circumstance where 430 the protocol is intentionally blocked, two message transports are 431 specified: 433 UDP transport 434 The prefered transport providing low latency service. 436 HTTP Web Service 438 In a typical network environment where a MTU of at least 1280 bytes 439 is supported, the UDP transport supports DNS request messages of at 440 least 1100 bytes and responses of at least 18000 bytes. 442 Both transport bindings are specified in [I-D.hallambaker-wsconnect]. 444 2.2.2. Query Protocol Example 446 Having established a connection to a Private-DNS service, the client 447 from the first example performs a DNS query: 449 www.example.com ? A 451 2.2.2.1. Key Derrivation 453 [TBS at the moment there is no key derrivation function specified and 454 the same key is used for encryption and authentication. This is a 455 weak approach architecturally as a compromise of one algorithm puts 456 the other at risk and should be fixed. Rather than use k as the key 457 we should use MAC ("encrypt", k) and MAC ("decrypt", k) or something 458 similar. However doing that right requires consulting past RFCs to 459 find the right derrivation function.] 461 Ticket value is: 463 4e 96 ae d4 ce 87 b8 38 f0 bb 3c 0b 87 0f 52 58 464 f8 bd 43 1d 73 7e 47 10 99 a8 f4 61 19 ca 57 e2 465 42 46 fd a4 95 dd 3a cf 2a 1b a6 db ee 03 61 7a 466 24 65 e4 33 42 46 9d 25 56 38 fb 67 db 7e 70 9c 467 89 63 b2 0e e9 66 0d b9 bc f8 a8 7e 03 ee 64 d6 468 Master key is: 470 a8 9a b5 d4 47 2a ae f5 9e d9 67 f2 0c 2d 85 2e 472 Authentication key is TBS (Master) 474 a8 9a b5 d4 47 2a ae f5 9e d9 67 f2 0c 2d 85 2e 476 Encryption key is TBS (Master) 478 a8 9a b5 d4 47 2a ae f5 9e d9 67 f2 0c 2d 85 2e 480 2.2.2.2. Request 482 The DNS Request is: [TBS this is a placeholder] 484 ;; QUESTION SECTION: 485 example.com. IN A 487 In hex: 489 24 1a 01 00 00 01 00 00 00 00 00 00 03 77 77 77 490 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 491 01 493 The plaintext payload is 495 Segment(0) 496 Type code: 12 497 Segment length: 00 21 498 Data: 499 24 1a 01 00 00 01 00 00 00 00 00 00 03 77 77 77 500 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 501 01 503 Note that in a real world example, the request SHOULD be padded to a 504 fixed value (e.g. 1100 bytes) to prevent traffic analysis disclosing 505 the message contents. for illustrative purposes, a mimimal padding is 506 applied: 508 The request has the transaction ID which doubles as the 509 initialization vector of the encryption algorithm and ticket 510 identifier prepended and the MAC value appended: 512 Transaction ID: 10 (= 16 bytes) 513 34 bf 46 58 50 6b 20 7a bb 57 71 04 94 c5 80 06 514 Ticket: 50 (= 80 bytes) 515 4e 96 ae d4 ce 87 b8 38 f0 bb 3c 0b 87 0f 52 58 516 f8 bd 43 1d 73 7e 47 10 99 a8 f4 61 19 ca 57 e2 517 42 46 fd a4 95 dd 3a cf 2a 1b a6 db ee 03 61 7a 518 24 65 e4 33 42 46 9d 25 56 38 fb 67 db 7e 70 9c 519 89 63 b2 0e e9 66 0d b9 bc f8 a8 7e 03 ee 64 d6 520 Encrypted Data: 00 30 (= 48 bytes) 521 fd e5 f6 48 69 ce 6a bb b3 d4 ef 86 06 e9 79 f7 522 82 3e 86 d2 ac c5 e9 f4 b6 f3 eb a5 02 5c bf 5d 523 07 eb 31 cb 2b 29 90 a9 c7 96 cd bd a9 71 a1 7a 524 MAC: 10 (= 16 bytes) 525 b9 1d e6 e4 63 93 04 d8 ff 26 8e 17 fa a9 84 aa 527 2.2.2.3. Response 529 The recursive resolver locates the records and returns the response. 531 The DNS Response is [TBS this is a placeholder] 533 ;; ANSWER SECTION: 534 example.com. 38400 IN A 192.168.1.20 536 ;; AUTHORITY SECTION: 537 example.com. 38400 IN NS ns1.example.com. 539 ;; ADDITIONAL SECTION: 540 ns1.example.com. 38400 IN A 192.168.1.28 542 In hex: 544 24 1a 81 80 00 01 00 03 00 00 00 00 03 77 77 77 545 06 67 6f 6f 67 6c 65 03 63 6f 6d 00 00 01 00 01 546 c0 0c 00 05 00 01 00 05 28 39 00 12 03 77 77 77 547 01 6c 06 67 6f 6f 67 6c 65 03 63 6f 6d 00 c0 2c 548 00 01 00 01 00 00 00 e3 00 04 42 f9 59 63 c0 2c 549 00 01 00 01 00 00 00 e3 00 04 42 f9 59 68 551 The plaintext payload is the DNS response plus the MAC value of the 552 request. This response is small enough to fit into a single packet. 554 Segment(0) 555 Type code: 04 556 Segment length: 00 20 557 Data: 558 b9 1d e6 e4 63 93 04 d8 ff 26 8e 17 fa a9 84 aa 559 7d ff 40 00 16 91 70 d1 0a 1a 19 a5 1f 3a dc cf 560 Segment(1) 561 Type code: 12 562 Segment length: 00 5e 563 Data: 564 24 1a 81 80 00 01 00 03 00 00 00 00 03 77 77 77 565 06 67 6f 6f 67 6c 65 03 63 6f 6d 00 00 01 00 01 566 c0 0c 00 05 00 01 00 05 28 39 00 12 03 77 77 77 567 01 6c 06 67 6f 6f 67 6c 65 03 63 6f 6d 00 c0 2c 568 00 01 00 01 00 00 00 e3 00 04 42 f9 59 63 c0 2c 569 00 01 00 01 00 00 00 e3 00 04 42 f9 59 68 571 The plaintext is encrypted and the transaction identifier and MAC 572 values added. Note that in a multiple packet response, each response 573 has its own MAC value: 575 Transaction ID: 10 (= 16 bytes) 576 8e dc 41 ba 32 9f ca 6c b4 83 43 34 88 10 7f ed 577 Index: 01 578 Max Index: 01 579 Clear Response: 00 c8 (= 200) 580 Encrypted Data: 00 90 (= 144 bytes) 581 ce e6 31 cd 2d 48 01 07 23 77 db 99 ac e1 57 2a 582 7c f1 9b 7c cd 9e 68 8d 76 97 de 99 eb d5 bb fc 583 4d 17 c6 3f 9b 69 a1 e5 3a 4e 61 36 59 c6 8c 89 584 5c 17 2e 8c 56 6c 49 71 0a 3a 07 3d d8 1a 18 f1 585 25 ad 92 fa ef 85 b2 31 78 25 35 b8 e7 c2 c0 92 586 d3 ad a9 75 1e 10 a2 4d 3d 81 99 19 43 86 3b 29 587 b5 49 45 49 00 59 6b 7b 80 47 e7 fb 36 99 4b 76 588 45 8d aa ba e4 04 65 0b 8f 41 2e 58 df 6a ca 41 589 dc 16 c7 f9 ac 2a 74 ed a4 84 80 1e e1 72 2d c9 590 MAC: 10 (= 16 bytes) 591 49 c2 0c 8b 93 df 7f 33 4e 97 52 9a 66 2b 4f 88 593 2.2.3. Authentication Conformance 595 A Private-DNS server MUST authenticate queries. In the case that the 596 UDP binding is used, a server MUST NOT make any response should the 597 verification step fail. This requirement ensures that a Private-DNS 598 service cannot be used to attack other systems in a Denial of Service 599 attack through use of packets with forged source addresses. 601 A service MAY provide an error response in the case that a request 602 using the Web Service binding fails as the TCP/IP connection startup 603 provides an adequate protection against source address forgery. 605 2.2.4. Handling Multiple Requests 607 A Private-DNS service MUST accept requests that contain multiple 608 requests. Where multiple requests are presented, each request in the 609 transaction MUST have a unique DNS Transaction ID. 611 A Private-DNS service MAY limit the number of responses provided. 612 Responses to requests MAY be returned in any order. 614 3. Service Connection and Key Exchangee 616 The Service Connection is established using [I-D.hallambaker- 617 wsconnect]. The service identifiers for PRIVATE-DNS are as follows: 619 Service Identifier 620 PRIVATE-DNS 622 Two host connection bindings are defined: 624 UDP Binding 625 The UDP binding described in [!I-D.hallambaker-wsconnect] is 626 the preferred host binding. The UDP binding allows most queries 627 to be completed in a single round trip with no mandatory 628 delays. 630 HTTP Binding 631 A HTTP binding is specified for use as a last resort in 632 situations where the UDP transport is not available. 634 3.1. UDP Binding 636 The prefered host connection type is to use the message encapsulation 637 format 639 Protocol 640 DNS 642 Presentation 643 PRIVATE-DNS-P 645 Transport 646 UDP 648 Note that the omission of version numbers in the on-the-wire data 649 structures is intentional. Use of the message encapsulation requires 650 that the parties have previously established a host connection 651 comprising the network and security parameters required to 652 communicate. The choice of message encapsulation including the 653 protocol version is defined in the host connection. 655 In the DNS protocol requests and responses use the same message 656 structure. The encapsulation uses different structures for requests 657 and responses but the payload of each structure is a sequence of 658 [RFC1035] messages. 660 3.2. HTTP Binding 662 Under certain network conditions attempts to reach the PRIVATE-DNS 663 service may fail due to constraints imposed by firewalls or through 664 attempted censorship. Under these conditions, HTTP [RFC2616] MAY be 665 used as an alternative transport as follows: 667 Protocol 668 DNS 670 Presentation 671 POST 673 Content-Type 674 application/private-dns-p 676 Transport 677 HTTP 679 A PRIVATE-DNS service offered in this fashion MUST support HTTP/1.1 680 or higher. The transaction is performed as a POST request with the 681 MIME content type application/private-dns-p.p. 683 4. Security Considerationsns 685 The broad security requirements for Private-DNS are set out in [I- 686 D.hallambaker-dnse]. 688 In due course this section will explain which of the security 689 requirements is met and under which circumstances. 691 4.1. Confidentiality 693 4.2. Integrity 695 4.3. Access 697 5. IANA Considerations 699 6. Acnowledgements 700 7. References 702 7.1. Normative References 704 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 705 Requirement Levels", BCP 14, RFC 2119, March 1997. 707 [I-D.hallambaker-omnibroker] Hallam-Baker, P, "OmniBroker Protocol", 708 Internet-Draft draft-hallambaker-omnibroker-07, 21 January 709 2014. 711 [RFC2616] Fielding, R.,Gettys, J.,Mogul, J.,Frystyk, H.,Masinter, 712 L.,Leach, P.,Berners-Lee, T., "Hypertext Transfer Protocol 713 -- HTTP/1.1", RFC 2616, June 1999. 715 [I-D.hallambaker-jsonbcd] Hallam-Baker, P, "Binary Encodings for 716 JavaScript Object Notation: JSON-B, JSON-C, JSON-D", 717 Internet-Draft draft-hallambaker-jsonbcd-01, 21 January 718 2014. 720 [I-D.hallambaker-dnse] Hallam-Baker, P, "Private-DNS", Internet- 721 Draft draft-hallambaker-dnse-00, 21 March 2014. 723 [RFC1035] Mockapetris, P., "Domain names - implementation and 724 specification", STD 13, RFC 1035, 1 November 1987. 726 [RFC4033] Arends, R.,Austein, R.,Larson, M.,Massey, D.,Rose, S., 727 "DNS Security Introduction and Requirements", RFC 4033, 728 March 2005. 730 [I-D.hallambaker-wsconnect] Hallam-Baker, P, "JSON Service Connect 731 (JCX) Protocol", Internet-Draft draft-hallambaker- 732 wsconnect-05, 21 January 2014. 734 Author's Address 736 Phillip Hallam-Baker 737 Comodo Group Inc. 739 philliph@comodo.com