One document matched: draft-hallambaker-privatedns-00.xml
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<rfc ipr="trust200902" docName="draft-hallambaker-privatedns-00">
<front>
<title abbrev="Private DNS">Private-DNS</title>
<author fullname="Phillip Hallam-Baker" initials="P. M." surname="Hallam-Baker">
<organization>Comodo Group Inc.</organization>
<address>
<email>philliph@comodo.com</email>
</address>
</author>
<date day="9" month="May" year="2014"/>
<area>General</area>
<workgroup/>
<keyword>Cryptography</keyword>
<keyword>PKI</keyword>
<keyword>PKIX</keyword>
<abstract>
<t>This document describes Private DNS, a transport security mechanism for the DNS protocol. The mechanism may be employed to secure communication between a client and its resolver or between a resolver and an authoritative server.</t>
<t>Service binding including key exchange is effected using the JSON Service Connect (JCX) Protocol. DNS protocol messages are wrapped in a new framing protocol.</t>
</abstract>
</front>
<middle>
<section title="Introduction." anchor="Section_1">
<t>Recent events have required urgent consideration of privacy concerns in Internet protocols. In particular the lack of confidentiality controls in the DNS [RFC1035] protocol is of considerable concern.</t>
<t>This document describes Private-DNS, a security enhancement for the DNS protocol that meets the principal use cases and requirements set out in [I-D.hallambaker-dnse]. This enhancement provides for encryption and authentication of the DNS protocol messages. </t>
<t>Private-DNS makes use of the JSON Service Connect (JCX) Protocol [I-D.hallambaker-wsconnect] and introduces a new framing protocol.</t>
<section title="Related Work" anchor="Section_1_1">
<t>The proposal approach compliments the integrity controls provided by DNSSEC [RFC4033]. While both provide integrity controls, the controls provided by DNSSEC are based on digital signatures while this proposal provides controls based on a Message Authentica Code technique.</t>
<t>Like the Omnibroker protocol [I-D.hallambaker-omnibroker], this proposal is built on JCX [I-D.hallambaker-wsconnect] but offers a low level interface to the DNS protocol alone as opposed to a high level interface to generalized discovery services. A client would use the DNSE-JX interface in cases where retrieval of specific DNS resource records is required. The OmniBroker protocol would be used in cases where the client delegates the choice of discovery strategy to the OmniBroker service.</t>
</section>
<section title="Terminology" anchor="Section_1_2">
<t>The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]</t>
</section>
<section title="Defined Terms" anchor="Section_1_3">
<t>[[These terms are deliberately left blank here or else we will spend time wordsmithing the defined term definitions rather than looking at the protocol.]</t>
<t><list style="hanging">
<t hangText="Authoritative DNS Server"> </t>
<t hangText="Caching Recursive Resolver"> </t>
<t hangText="DNS"> </t>
<t hangText="DNS Client"> </t>
<t hangText="Recursive Resolver"> </t>
<t hangText="Stub Resolver"> </t>
</list></t>
</section>
</section>
<section title="Architecture" anchor="Section_2">
<t>PRIVATE-DNS has two parts</t>
<t><list style="symbols">
<t>Service Connection</t>
<t>DNS message encapsulation</t>
</list></t>
<t>In PRIVATE-DNS, the service connection is provided by the existing [I-D.hallambaker-wsconnect] proposal. The DNS message encapsulation is new and supports encryption and authentication of the DNS protocol messages. </t>
<t>To make use of PRIVATE-DNS a client first establishes a connection to a DNS server (resolver or authoritative) using the connection protocol. Once a client has established a connection it MAY use it to make as many queries as desired until either the connection context expires or is cancelled by the service.</t>
<t>The Service Connection and Query Service MAY be operated on the same host or on separate hosts. </t>
<section title="Service Connection" anchor="Section_2_1">
<t>The service connection mechanism is responsible for establishing a connection context between a client and a service. The connection context comprises:</t>
<t><list style="symbols">
<t>A security context (opaque identifier, key, algorithm choice) between the client and the connection service</t>
<t>One or more query host connection contexts, each comprisingNetwork connection description (IP address, Port, Protocol, transport)Security Context (opaque identifier, key, algorithm choice) between the client and the query host</t>
</list></t>
<t> The PRIVATE-DNS proposal is designed on the assumption that Service Connection transactions are relatively infrequent and thus the efficiency of the Service Connection protocol is not a major concern. Accordingly the Service Connection protocol is implemented as a JSON/REST Web Service over HTTP. While of an efficient encoding (e.g. [I-D.hallambaker-jsonbcd] would permit a more efficient implementation of the protocol using UDP, such an approach would be vulnerable to Denial of Service attacks against the service unless appropriate countermeasures were taken. For example use of a 'cookie' approach to prove the validity of the purported request source address.</t>
<t>A service connection MAY return a host connection set that includes multiple protocol and/or transport options. This has the important consequence that it allows new message formats or a transition to an entirely new protocol to be effected by simply defining a new identifier.</t>
<t>A distinction is drawn between a connection to a service and a connection to a host. A connection to a host is a relationship to a specific instance of a service with a distinct IP address. A connection to a service is a relationship to a set of hosts. This distinction is an important one for Denial of Service mitigation. A DNS service need not publish the same network connection description to every client. This permits a service to mitigate DoS attacks by filtering query requests by IP address, a strategy that is greatly enhanced by the large address space of IPv6.</t>
<t>Different configurations of the Service Connection service allow a DNS service to meet different combinations of security requirements. For example the Public Resolver described in [U-PUBLIC] would not require authentication of the client to the service but this would be required for the Subscriber, Private and Hybrid Resolvers described in [U-SUBSCRIBER], [U-PRIVATE] and [U-HYBRID].].</t>
<section title="Example: Public Resolver" anchor="Section_2_1_1">
<t>Following the use case [[U-PUBLIC] described in [I-D.hallambaker-dnse], Alice buys a laptop for her personal use at home. To ensure the privacy of her DNS connection she selects example.com, a public resolver that provides DNS service without requiring any form of subscription or registration.</t>
<t>During the initial configuration process, the machine uses the local DNS advertised in the DCHP configuration for the first and last time for discovery of the Service Connection Service of example.com.</t>
<t>Having discovered a Service Connection Service, the client requests a service provider for the PRIVATE-DNS service by establishing a TLS connection to indicated server. The server returns a TLS Certificate that meets the authentication criteria of the client. Once the TLS connection is established, an anonymous client connection is established.</t>
<figure>
<artwork>
<![CDATA[POST /.well-known/sxs-connect/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Host: localhost:8080
Content-Length: 226
Expect: 100-continue
{
"BindRequest": {
"Service": ["private-dns-resolver"],
"Encryption": ["A128CBC",
"A256CBC",
"A128GCM",
"A256GCM"],
"Authentication": ["HS256",
"HS384",
"HS512",
"HS256T128"]}}
]]></artwork>
</figure>
<t>Since the example.com service does not require authentication, the request is granted immediately and the necessary host connection parameters returned immediately:</t>
<figure>
<artwork>
<![CDATA[HTTP/1.1 OK Success
Content-Length: 578
Date: Fri, 09 May 2014 20:58:44 GMT
Server: Microsoft-HTTPAPI/2.0
{
"TicketResponse": {
"Status": 200,
"StatusDescription": "Success",
"Cryptographic": [],
"Service": [{
"Service": "private-dns-resolver",
"Name": "localhost",
"Port": 9090,
"Priority": 100,
"Weight": 100,
"Transport": "UDP",
"Cryptographic": {
"Secret": "
SwVyt3p_tkMeneeYtqnw5g",
"Encryption": "A128CBC",
"Authentication": "HS256T128",
"Ticket": "
bH0q4n8XQOWbjStHsVCzAzS3fbkV2mbx-HUC8Bxw7r31HXcXRvPp4xWORxSo98N4
M6uklYZEEC5OvlYBQ0kETabpBz7-dYo7nYCD6yCFlvE"}}]}}
]]></artwork>
</figure>
</section>
<section title="Example: Hybrid Resolver" anchor="Section_2_1_2">
<t>Following the use case [U-HYBRID], Alice decides to use her personal computer for work under her employer's 'Bring Your Own Device' program. Alice needs access to multiple services within her employer's intranet. </t>
<t>Her system administrator issues her an account name [TBS], a one time use PIN [TBS] and the DNS address of the service connection service byod.example.net. Having established a TLS connection as before, the client makes an initial request:</t>
<figure>
<artwork>
<![CDATA[POST /.well-known/sxs-connect/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Host: localhost:8080
Content-Length: 352
Expect: 100-continue
{
"OpenPINRequest": {
"Encryption": ["A128CBC",
"A256CBC",
"A128GCM",
"A256GCM"],
"Authentication": ["HS256",
"HS384",
"HS512",
"HS256T128"],
"Account": "alice",
"Service": ["private-dns-resolver"],
"Domain": "example.com",
"HaveDisplay": false,
"Challenge": "
YBr17dBu_lSDm4vY66rNBQ"}}
]]></artwork>
</figure>
<t>The server provides a challenge for verifying the one time use PIN.</t>
<figure>
<artwork>
<![CDATA[HTTP/1.1 OK Success
Content-Length: 501
Date: Fri, 09 May 2014 20:58:44 GMT
Server: Microsoft-HTTPAPI/2.0
{
"OpenPINResponse": {
"Status": 200,
"StatusDescription": "Success",
"Challenge": "
_eIhopTZAfkQR-mW6Y1IPg",
"ChallengeResponse": "
qRNgrSFhP3g6j-h8vlsIXN8rB5zn8qxgrqRcSFAiT_Q",
"Cryptographic": {
"Secret": "
3RWt4aRqQUA2o82GCz8BXA",
"Encryption": "A128CBC",
"Authentication": "HS256",
"Ticket": "
QZnH_9rlynU2SorpMeVwuJ8CDVnMhye4lmCXVGKGBedFCApDByEtvYMiOYB5Cseh
ApY9xc7uFOrVPi9zyrMIrcbFFUCRU6HRPxfPxWgvcmZpVZJli_GKg9eHiyy5osEU
AAPKUwJEGY1TXGf0xDYdaw"}}}
]]></artwork>
</figure>
<t>Having obtained the challenge value from the service, the client resends the initial request, having authenticated it this time under the challenge and one time PIN:</t>
<figure>
<artwork>
<![CDATA[POST /.well-known/sxs-connect/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Session: Value=bqbwaF3dLBxEvMeGiYeatBCtZLmdIRGleGhEYmmnkaw;
Id=QZnH_9rlynU2SorpMeVwuJ8CDVnMhye4lmCXVGKGBedFCApDByEtvYMiOYB5
CsehApY9xc7uFOrVPi9zyrMIrcbFFUCRU6HRPxfPxWgvcmZpVZJli_GKg9eHiyy
5osEUAAPKUwJEGY1TXGf0xDYdaw
Host: localhost:8080
Content-Length: 137
Expect: 100-continue
{
"TicketRequest": {
"Service": ["private-dns-resolver"],
"ChallengeResponse": "
mIr09oenHdiMji5i-sTX66KKzP_eXQAd6WXIgF3Y4uc"}}
]]></artwork>
</figure>
<t>The server returns a set of host connections for the requested services. The scope of the PRIVATE-DNS service is limited to the domain tree *.example.net:</t>
<figure>
<artwork>
<![CDATA[HTTP/1.1 OK Success
Content-Length: 858
Date: Fri, 09 May 2014 20:58:44 GMT
Server: Microsoft-HTTPAPI/2.0
{
"TicketResponse": {
"Status": 200,
"StatusDescription": "Success",
"Cryptographic": [{
"Protocol": "sxs-connect",
"Secret": "
fIRiC7by_MNNyuam0f8yDQ",
"Encryption": "A128CBC",
"Authentication": "HS256",
"Ticket": "
W76CJuIWZVig0OQVT6eldIl02d4e-Zgv9YrYnTAPgNNIbdeN_2FY30KUwiRPjh2i
r-NWiZ2FICQ4ATi2r9oktpMSEeyPRFppvHE6tnPFe9U"}],
"Service": [{
"Service": "private-dns-resolver",
"Name": "localhost",
"Port": 9090,
"Priority": 100,
"Weight": 100,
"Transport": "UDP",
"Cryptographic": {
"Secret": "
Y1klIDYuNfyCIMiqWbQi2w",
"Encryption": "A128CBC",
"Authentication": "HS256T128",
"Ticket": "
w_aLDzTjGjHiEDeOFDypBlGfY8a9xdTOnIdAgr2SjyFA3A2T8nVOwwacB9NW4qh9
xmLLgDYNyFvNIwTxxJH2ER0HU95VyjNMyrSAAj1zfM8"}}]}}
]]></artwork>
</figure>
</section>
</section>
<section title="Query Protocol Binding" anchor="Section_2_2">
<t>The Query Protocol Binding is designed to efficiently support the following features:</t>
<t><list style="symbols">
<t>Encryption</t>
<t>Prevent use in an Denial of Service attack.</t>
<t>Authentication</t>
<t>Multiple DNS queries and responses per PRIVATE-DNS Query [[*]</t>
<t>Multiple packet responses [[*]</t>
</list></t>
<t>The features marked [[*] are not essential for the purpose of meeting the privacy requirements but considerably improve the efficiency and flexibility of the DNS protocol. In particular the ability to make multiple DNS queries in a single transaction over UDP transport enables the use of novel discovery techniques without impact on performance.</t>
<t>While the privacy requirements may be met through use of encryption alone, any encoding that does not provide authentication of requests allows a service to be used as an attack vector in a denial of service attack on third parties. </t>
<t>The Query Protocol Binding wraps the [RFC1035] message structure rather than eliminating parts that are redundant. For example, the Query Protocol Binding Transaction ID which has a minimum length of 128 bits supplements rather than replaces the DNS message transaction ID of 16 bytes. </t>
<section title="Message Binding." anchor="Section_2_2_1">
<t>To ensure access to the DNS service in any network circumstance where the protocol is intentionally blocked, two message transports are specified:</t>
<t><list style="hanging">
<t hangText="UDP transport">The prefered transport providing low latency service.</t>
<t hangText="HTTP Web Service"> </t>
</list></t>
<t>In a typical network environment where a MTU of at least 1280 bytes is supported, the UDP transport supports DNS request messages of at least 1100 bytes and responses of at least 18000 bytes. </t>
<t>Both transport bindings are specified in [I-D.hallambaker-wsconnect].</t>
</section>
<section title="Query Protocol Example" anchor="Section_2_2_2">
<t>Having established a connection to a Private-DNS service, the client from the first example performs a DNS query:</t>
<figure>
<artwork>
<![CDATA[
www.example.com ? A
]]></artwork>
</figure>
<section title="Key Derrivation" anchor="Section_2_2_2_1">
<t>[TBS at the moment there is no key derrivation function specified and the same key is used for encryption and authentication. This is a weak approach architecturally as a compromise of one algorithm puts the other at risk and should be fixed. Rather than use k as the key we should use MAC ("encrypt", k) and MAC ("decrypt", k) or something similar. However doing that right requires consulting past RFCs to find the right derrivation function.]</t>
<t>Ticket value is:</t>
<figure>
<artwork>
<![CDATA[6c 7d 2a e2 7f 17 40 e5 9b 8d 2b 47 b1 50 b3 03
34 b7 7d b9 15 da 66 f1 f8 75 02 f0 1c 70 ee bd
f5 1d 77 17 46 f3 e9 e3 15 8e 47 14 a8 f7 c3 78
33 ab a4 95 86 44 10 2e 4e be 56 01 43 49 04 4d
a6 e9 07 3e fe 75 8a 3b 9d 80 83 eb 20 85 96 f1
]]></artwork>
</figure>
<t>Master key is:</t>
<figure>
<artwork>
<![CDATA[4b 05 72 b7 7a 7f b6 43 1e 9d e7 98 b6 a9 f0 e6
]]></artwork>
</figure>
<t>Authentication key is TBS (Master)</t>
<figure>
<artwork>
<![CDATA[4b 05 72 b7 7a 7f b6 43 1e 9d e7 98 b6 a9 f0 e6
]]></artwork>
</figure>
<t>Encryption key is TBS (Master)</t>
<figure>
<artwork>
<![CDATA[4b 05 72 b7 7a 7f b6 43 1e 9d e7 98 b6 a9 f0 e6
]]></artwork>
</figure>
</section>
<section title="Request" anchor="Section_2_2_2_2">
<t>The DNS Request is: [TBS this is a placeholder]</t>
<figure>
<artwork>
<![CDATA[;; QUESTION SECTION:
example.com. IN A]]></artwork>
</figure>
<t>In hex:</t>
<figure>
<artwork>
<![CDATA[24 1a 01 00 00 01 00 00 00 00 00 00 03 77 77 77
07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
01
]]></artwork>
</figure>
<t>The plaintext payload is</t>
<figure>
<artwork>
<![CDATA[
Segment(0)
Type code: 12
Segment length: 00 21
Data:
24 1a 01 00 00 01 00 00 00 00 00 00 03 77 77 77
07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
01
]]></artwork>
</figure>
<t>Note that in a real world example, the request SHOULD be padded to a fixed value (e.g. 1100 bytes) to prevent traffic analysis disclosing the message contents. for illustrative purposes, a mimimal padding is applied:</t>
<t>The request has the transaction ID which doubles as the initialization vector of the encryption algorithm and ticket identifier prepended and the MAC value appended:</t>
<figure>
<artwork>
<![CDATA[
Transaction ID: 10 (= 16 bytes)
23 bd d7 5e c0 eb a7 4d 85 92 fd 94 e0 05 85 a7
Ticket: 50 (= 80 bytes)
6c 7d 2a e2 7f 17 40 e5 9b 8d 2b 47 b1 50 b3 03
34 b7 7d b9 15 da 66 f1 f8 75 02 f0 1c 70 ee bd
f5 1d 77 17 46 f3 e9 e3 15 8e 47 14 a8 f7 c3 78
33 ab a4 95 86 44 10 2e 4e be 56 01 43 49 04 4d
a6 e9 07 3e fe 75 8a 3b 9d 80 83 eb 20 85 96 f1
Encrypted Data: 00 30 (= 48 bytes)
4c 16 ae b8 e1 8d f7 cf ab f1 d6 e7 d0 07 52 bc
96 ec a0 df f1 a9 bf fd e2 5c 7c 13 88 31 62 13
fc c3 a4 12 44 25 6a a2 6a fa 97 f7 57 97 fd ce
MAC: 10 (= 16 bytes)
a7 25 0b df 5a 10 bf ac 39 99 b7 6c 19 d2 1d e8
]]></artwork>
</figure>
</section>
<section title="Response" anchor="Section_2_2_2_3">
<t>The recursive resolver locates the records and returns the response.</t>
<t>The DNS Response is [TBS this is a placeholder]</t>
<figure>
<artwork>
<![CDATA[;; ANSWER SECTION:
example.com. 38400 IN A 192.168.1.20
;; AUTHORITY SECTION:
example.com. 38400 IN NS ns1.example.com.
;; ADDITIONAL SECTION:
ns1.example.com. 38400 IN A 192.168.1.28]]></artwork>
</figure>
<t>In hex:</t>
<figure>
<artwork>
<![CDATA[24 1a 81 80 00 01 00 03 00 00 00 00 03 77 77 77
06 67 6f 6f 67 6c 65 03 63 6f 6d 00 00 01 00 01
c0 0c 00 05 00 01 00 05 28 39 00 12 03 77 77 77
01 6c 06 67 6f 6f 67 6c 65 03 63 6f 6d 00 c0 2c
00 01 00 01 00 00 00 e3 00 04 42 f9 59 63 c0 2c
00 01 00 01 00 00 00 e3 00 04 42 f9 59 68
]]></artwork>
</figure>
<t>The plaintext payload is the DNS response plus the MAC value of the request. This response is small enough to fit into a single packet.</t>
<figure>
<artwork>
<![CDATA[
Segment(0)
Type code: 04
Segment length: 00 20
Data:
a7 25 0b df 5a 10 bf ac 39 99 b7 6c 19 d2 1d e8
24 93 b5 09 df 3d 91 27 98 23 10 99 25 b1 45 9e
Segment(1)
Type code: 12
Segment length: 00 5e
Data:
24 1a 81 80 00 01 00 03 00 00 00 00 03 77 77 77
06 67 6f 6f 67 6c 65 03 63 6f 6d 00 00 01 00 01
c0 0c 00 05 00 01 00 05 28 39 00 12 03 77 77 77
01 6c 06 67 6f 6f 67 6c 65 03 63 6f 6d 00 c0 2c
00 01 00 01 00 00 00 e3 00 04 42 f9 59 63 c0 2c
00 01 00 01 00 00 00 e3 00 04 42 f9 59 68
]]></artwork>
</figure>
<t>The plaintext is encrypted and the transaction identifier and MAC values added. Note that in a multiple packet response, each response has its own MAC value:</t>
<figure>
<artwork>
<![CDATA[
Transaction ID: 10 (= 16 bytes)
cd 36 4b 64 e0 c2 e7 52 90 a4 75 60 a2 af dc 13
Index: 01
Max Index: 01
Clear Response: 00 c8 (= 200)
Encrypted Data: 00 90 (= 144 bytes)
59 9a a7 57 56 df 19 28 fe ea c2 e2 60 36 0c aa
fb 43 dd d0 94 02 9a f8 d9 d8 75 d4 13 11 d5 18
08 05 02 e4 43 10 3f 92 63 ec b7 8c 81 9e 70 40
b4 00 e6 26 39 45 67 d4 1e 1b 87 11 e9 70 83 ee
7e ac 43 02 8e 54 b5 b7 5a 07 44 6f 5f 31 9d 6a
bf 8f d8 22 ba 12 06 8a 36 3a 72 71 3e a7 f2 21
bb 0c c6 44 57 c3 4a 56 0f 1e ec e5 68 c6 08 ff
21 b1 4a 07 04 5c 12 62 2b 3b 14 34 83 56 55 72
03 d9 af 1e 7d 0b be ad 40 4f 98 32 ae 65 3c 43
MAC: 10 (= 16 bytes)
e6 52 62 72 55 4b 95 be da a5 11 5a cd 2e a8 9b
]]></artwork>
</figure>
</section>
</section>
<section title="Authentication Conformance" anchor="Section_2_2_3">
<t>A Private-DNS server MUST authenticate queries. In the case that the UDP binding is used, a server MUST NOT make any response should the verification step fail. This requirement ensures that a Private-DNS service cannot be used to attack other systems in a Denial of Service attack through use of packets with forged source addresses.</t>
<t>A service MAY provide an error response in the case that a request using the Web Service binding fails as the TCP/IP connection startup provides an adequate protection against source address forgery.</t>
</section>
<section title="Handling Multiple Requests" anchor="Section_2_2_4">
<t>A Private-DNS service MUST accept requests that contain multiple requests. Where multiple requests are presented, each request in the transaction MUST have a unique DNS Transaction ID. </t>
<t>A Private-DNS service MAY limit the number of responses provided. Responses to requests MAY be returned in any order.</t>
</section>
</section>
</section>
<section title="Service Connection and Key Exchangee" anchor="Section_3">
<t>The Service Connection is established using [I-D.hallambaker-wsconnect]. The service identifiers for PRIVATE-DNS are as follows:</t>
<t><list style="hanging">
<t hangText="Service Identifier">PRIVATE-DNS</t>
</list></t>
<t>Two host connection bindings are defined:</t>
<t><list style="hanging">
<t hangText="UDP Binding">The UDP binding described in [!I-D.hallambaker-wsconnect] is the preferred host binding. The UDP binding allows most queries to be completed in a single round trip with no mandatory delays. </t>
<t hangText="HTTP Binding">A HTTP binding is specified for use as a last resort in situations where the UDP transport is not available.</t>
</list></t>
<section title="UDP Binding" anchor="Section_3_1">
<t>The prefered host connection type is to use the message encapsulation format</t>
<t><list style="hanging">
<t hangText="Protocol">DNS</t>
<t hangText="Presentation">PRIVATE-DNS-P</t>
<t hangText="Transport">UDP</t>
</list></t>
<t>Note that the omission of version numbers in the on-the-wire data structures is intentional. Use of the message encapsulation requires that the parties have previously established a host connection comprising the network and security parameters required to communicate. The choice of message encapsulation including the protocol version is defined in the host connection.</t>
<t>In the DNS protocol requests and responses use the same message structure. The encapsulation uses different structures for requests and responses but the payload of each structure is a sequence of [RFC1035] messages.</t>
</section>
<section title="HTTP Binding" anchor="Section_3_2">
<t>Under certain network conditions attempts to reach the PRIVATE-DNS service may fail due to constraints imposed by firewalls or through attempted censorship. Under these conditions, HTTP [RFC2616] MAY be used as an alternative transport as follows:</t>
<t><list style="hanging">
<t hangText="Protocol">DNS</t>
<t hangText="Presentation">POST</t>
<t hangText="Content-Type">application/private-dns-p</t>
<t hangText="Transport">HTTP</t>
</list></t>
<t>A PRIVATE-DNS service offered in this fashion MUST support HTTP/1.1 or higher. The transaction is performed as a POST request with the MIME content type application/private-dns-p.p.</t>
</section>
</section>
<section title="Security Considerationsns" anchor="Section_4">
<t>The broad security requirements for Private-DNS are set out in [I-D.hallambaker-dnse]. </t>
<t>In due course this section will explain which of the security requirements is met and under which circumstances. </t>
<section title="Confidentialityty" anchor="Section_4_1">
</section>
<section title="Integrity" anchor="Section_4_2">
</section>
<section title="Access" anchor="Section_4_3">
</section>
</section>
<section title="IANA Considerations" anchor="Section_5">
<t> </t>
</section>
<section title="Acnowledgements" anchor="Section_6">
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
</address>
</author>
<date month="March" year="1997"/>
<keyword>keyword</keyword>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format type="TXT" target="http://www.rfc-editor.org/rfc/rfc2119.txt" octets="4723"/>
<format type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2119.html" octets="17970"/>
<format type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml" octets="5777"/>
</reference>
<reference anchor="I-D.hallambaker-omnibroker">
<front>
<title>OmniBroker Protocol</title>
<author fullname="Phillip Hallam-Baker" initials="P" surname="Hallam-Baker">
<organization/>
<address>
</address>
</author>
<date day="21" month="January" year="2014"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-hallambaker-omnibroker-07"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-hallambaker-omnibroker-07.txt"/>
<format type="PDF" target="http://www.ietf.org/internet-drafts/draft-hallambaker-omnibroker-07.pdf"/>
</reference>
<reference anchor="RFC2616">
<front>
<title>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author fullname="Roy T. Fielding" initials="R." surname="Fielding">
<organization>Department of Information and Computer Science</organization>
<address>
</address>
</author>
<author fullname="James Gettys" initials="J." surname="Gettys">
<organization>World Wide Web Consortium</organization>
<address>
</address>
</author>
<author fullname="Jeffrey C. Mogul" initials="J." surname="Mogul">
<organization>Compaq Computer Corporation</organization>
<address>
</address>
</author>
<author fullname="Henrik Frystyk Nielsen" initials="H." surname="Frystyk">
<organization>World Wide Web Consortium</organization>
<address>
</address>
</author>
<author fullname="Larry Masinter" initials="L." surname="Masinter">
<organization>Xerox Corporation</organization>
<address>
</address>
</author>
<author fullname="Paul J. Leach" initials="P." surname="Leach">
<organization>Microsoft Corporation</organization>
<address>
</address>
</author>
<author fullname="Tim Berners-Lee" initials="T." surname="Berners-Lee">
<organization>World Wide Web Consortium</organization>
<address>
</address>
</author>
<date month="June" year="1999"/>
</front>
<seriesInfo name="RFC" value="2616"/>
<format type="TXT" target="http://www.rfc-editor.org/rfc/rfc2616.txt" octets="422317"/>
<format type="PS" target="http://www.rfc-editor.org/rfc/rfc2616.ps" octets="5529857"/>
<format type="PDF" target="http://www.rfc-editor.org/rfc/rfc2616.pdf" octets="550558"/>
<format type="HTML" target="http://xml.resource.org/public/rfc/html/rfc2616.html" octets="637302"/>
<format type="XML" target="http://xml.resource.org/public/rfc/xml/rfc2616.xml" octets="493420"/>
</reference>
<reference anchor="I-D.hallambaker-jsonbcd">
<front>
<title>Binary Encodings for JavaScript Object Notation: JSON-B, JSON-C, JSON-D</title>
<author fullname="Phillip Hallam-Baker" initials="P" surname="Hallam-Baker">
<organization/>
<address>
</address>
</author>
<date day="21" month="January" year="2014"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-hallambaker-jsonbcd-01"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-hallambaker-jsonbcd-01.txt"/>
<format type="PDF" target="http://www.ietf.org/internet-drafts/draft-hallambaker-jsonbcd-01.pdf"/>
</reference>
<reference anchor="I-D.hallambaker-dnse">
<front>
<title>Private-DNS</title>
<author fullname="Phillip Hallam-Baker" initials="P" surname="Hallam-Baker">
<organization/>
<address>
</address>
</author>
<date day="21" month="March" year="2014"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-hallambaker-dnse-00"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-hallambaker-dnse-00.txt"/>
</reference>
<reference anchor="RFC1035">
<front>
<title>Domain names - implementation and specification</title>
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris">
<organization>USC/ISI</organization>
<address>
</address>
</author>
<date day="1" month="November" year="1987"/>
</front>
<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1035"/>
<format type="TXT" target="http://www.rfc-editor.org/rfc/rfc1035.txt" octets="125626"/>
</reference>
<reference anchor="RFC4033">
<front>
<title>DNS Security Introduction and Requirements</title>
<author fullname="R. Arends" initials="R." surname="Arends">
<organization/>
<address>
</address>
</author>
<author fullname="R. Austein" initials="R." surname="Austein">
<organization/>
<address>
</address>
</author>
<author fullname="M. Larson" initials="M." surname="Larson">
<organization/>
<address>
</address>
</author>
<author fullname="D. Massey" initials="D." surname="Massey">
<organization/>
<address>
</address>
</author>
<author fullname="S. Rose" initials="S." surname="Rose">
<organization/>
<address>
</address>
</author>
<date month="March" year="2005"/>
</front>
<seriesInfo name="RFC" value="4033"/>
<format type="TXT" target="http://www.rfc-editor.org/rfc/rfc4033.txt" octets="52445"/>
</reference>
<reference anchor="I-D.hallambaker-wsconnect">
<front>
<title>JSON Service Connect (JCX) Protocol</title>
<author fullname="Phillip Hallam-Baker" initials="P" surname="Hallam-Baker">
<organization/>
<address>
</address>
</author>
<date day="21" month="January" year="2014"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-hallambaker-wsconnect-05"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-hallambaker-wsconnect-05.txt"/>
<format type="PDF" target="http://www.ietf.org/internet-drafts/draft-hallambaker-wsconnect-05.pdf"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:22:20 |