[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02

Internet Engineering Task Force (IETF)              Phillip Hallam-Baker
Internet-Draft                                         Comodo Group Inc.
Intended Status: Standards Track                          March 21, 2014
Expires: September 22, 2014


                              Private-DNS
                       draft-hallambaker-dnse-00

Abstract

   This document describes DNSE-JX, 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.

   Service binding including key exchange is effected using the JSON
   Service Connect (JCX) Protocol. DNS protocol messages are wrapped in
   a new framing protocol.

   Deployment of the new security mechanism compliments DNSSEC.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Hallam-Baker               September 22, 2014                   [Page 1]


Internet-Draft                Private-DNS                     March 2014

Table of Contents

   1.  Introduction.  . . . . . . . . . . . . . . . . . . . . . . . .  3
      1.1.  Related Work  . . . . . . . . . . . . . . . . . . . . . .  3
      1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .  3
      1.3.  Defined Terms . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Use Cases and Requirements . . . . . . . . . . . . . . . . . .  4
      2.1.  Core Use Cases  . . . . . . . . . . . . . . . . . . . . .  4
         2.1.1.  Client/Resolver Communications . . . . . . . . . . .  5
         2.1.2.  Resolver/Authoritative Communications  . . . . . . .  7
      2.2.  Constraints . . . . . . . . . . . . . . . . . . . . . . .  8
         2.2.1.  Legacy Deployment  . . . . . . . . . . . . . . . . .  8
         2.2.2.  Integrity Attacks  . . . . . . . . . . . . . . . . .  8
         2.2.3.  Limited message size . . . . . . . . . . . . . . . .  8
      2.3.  Requirements  . . . . . . . . . . . . . . . . . . . . . .  8
         2.3.1.  Confidentiality Requirements . . . . . . . . . . . .  9
         2.3.2.  Integrity Requirements . . . . . . . . . . . . . . .  9
         2.3.3.  Access Requirements  . . . . . . . . . . . . . . . .  9
   3.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 10
      3.1.  Service Connection  . . . . . . . . . . . . . . . . . . . 10
      3.2.  DNS Message Encapsulation . . . . . . . . . . . . . . . . 11
      3.3.  Satisfaction of Requirements  . . . . . . . . . . . . . . 12
   4.  Service Connection and Key Exchange  . . . . . . . . . . . . . 12
   5.  DNS Message Encapsulation  . . . . . . . . . . . . . . . . . . 13
      5.1.  Request . . . . . . . . . . . . . . . . . . . . . . . . . 13
      5.2.  Response  . . . . . . . . . . . . . . . . . . . . . . . . 14
      5.3.  Payload . . . . . . . . . . . . . . . . . . . . . . . . . 15
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
      6.1.  Service . . . . . . . . . . . . . . . . . . . . . . . . . 16
      6.2.  Confidentialityty . . . . . . . . . . . . . . . . . . . . 16
      6.3.  Integrity . . . . . . . . . . . . . . . . . . . . . . . . 16
      6.4.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 16
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   8.  Acnowledgementsts  . . . . . . . . . . . . . . . . . . . . . . 16
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
      9.1.  Normative References  . . . . . . . . . . . . . . . . . . 16
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17

















Hallam-Baker               September 22, 2014                   [Page 2]


Internet-Draft                Private-DNS                     March 2014

1. Introduction.

   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.

   This document illustrates the privacy and related concerns raised
   with a set of use cases which in turn give rise to a set of
   requirements. Private-DNS, a security enhancement for the DNS
   protocol is then proposed to meet the stated set of requirements.
   This enhancement provides for encryption and authentication of the
   DNS protocol messages.

   Private-DNS makes use of the JSON Service Connect (JCX) Protocol [I-
   D.hallambaker-wsconnect] and introduces a new framing protocol.

1.1. Related Work

   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.

   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.

1.2. Terminology

   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]

1.3. Defined Terms

   [[These terms are deliberately left blank here or else we will spend
   time wordsmithing the defined term definitions rather than looking at
   the protocol.]










Hallam-Baker               September 22, 2014                   [Page 3]


Internet-Draft                Private-DNS                     March 2014

      Authoritative DNS Server

      Caching Recursive Resolver

      DNS

      DNS Client

      Recursive Resolver

      Stub Resolver

2. Use Cases and Requirements

   The immediate motivation for considering a DNS transport layer
   security protocol is the desire to improve the privacy of Internet
   communications by allowing encryption of DNS requests and responses.
   Since any encryption protocol mustby its very nature require changes
   to both the sender and receiver of a message, any such change is
   necessarily backwards incompatible. Accordingly we consider two sets
   of use cases:

      *  Use cases that illustrate aspects of the immediate concern of
         protecting privacy of DNS protocol messages.

      *  Use cases that illustrate other concerns that might be usefully
         addressed in any major revision of the DNS protocol.

2.1. Core Use Cases

   The DNS is the Internet infrastructure that makes authoritative
   statements about DNS names. In particular the DNS is used to support
   discovery of Internet services by mapping DNS names onto IP
   addresses.

   In the conventional configuration, a client requiring information
   from the DNS does not access DNS authoritative servers directly and
   instead makes requests through a resolver. The resolver in turn
   determines which requests to make to answer the query and forwards
   the request to the authoritative server.


   +-------------+    +-------------+    +-------------+
   |   Client    |--->|  Resolver   |--->|Authoritative|
   +-------------+    +-------------+    +-------------+

   Due to the distributed and hierarchical nature of the DNS, answering
   a DNS query typically requires queries to multiple Authoritative
   servers. This process is known as Recursive Resolution of the DNS
   Query. In the typical configuration the Resolver is a 'Caching
   Recursive Resolver' capable of making Recursive Queries and caching



Hallam-Baker               September 22, 2014                   [Page 4]


Internet-Draft                Private-DNS                     March 2014

   the result to answer future queries. The client is typically a 'Stub
   Client' that is not capable of making recursive queries itself and
   must rely on a Recursive Resolver to do this for it.

   One of the major security weaknesses in the DNS infrastructure as
   currently deployed is that by default most Internet enabled devices
   accept DNS service from the servers offered to it by DHCP when a
   connection is established. Since the DNS is a naming service and thus
   a trusted service, DNS services SHOULD be trustworthy. The practice
   of relying on a the 'local' DNS resolver advertised in the DHCP
   connection is therefore highly unsatisfactory.

   In real world circumstances this configuration is further complicated
   by firewalls, NAT devices and other middleboxes. Many of which filter
   or in some cases modify DNS protocol packets whether or not they are
   addressed to that device.

   For the purposes of considering the privacy of the DNS protocol,
   there are two important protocol interactions to consider:

      *  Communications between a Client and a Resolver

      *  Communications between a Resolver and an Authoritative Server

   The DNS protocol supports both modes of interaction without special
   provision for either case. From a security point of view, the two
   interactions have different characteristics and give rise to
   different use cases.

2.1.1. Client/Resolver Communications

   Communications between the client and the resolver reveal a lot of
   privacy sensitive information about the user. A DNS query for the
   address of a controversial Web Site indicates with high probability
   that a user is viewing material from the site.

   In the typical configuration a DNS client makes use of the DNS
   resolution server(s) advertised by DHCP when a network configuration
   is established or server(s) that are configured manually by an
   administrator.

   In either case the relationship between the client and the resolver
   is at minimum persistent for the length of time the network
   association is active. In the case that the DNS service is selected
   and confinugred manually, the security relationship might last for
   years or the entire life of the device.








Hallam-Baker               September 22, 2014                   [Page 5]


Internet-Draft                Private-DNS                     March 2014

2.1.1.1. Local Resolver

   For the sake of completeness, we state the case in which a client
   obtains DNS service from a local DNS server advertised at the time
   the network connection is established as a use case. Note however
   that the privacy concerns that can be protected in such circumstances
   are necessarily limited as the user has no idea where the service is
   being provided from.

   [U-LOCAL]: User connects to untrusted local network and wishes to use
   the locally provided DNS service.

   While a user may not intend to use the local DNS service, there are
   many real world network configurations that attempt to impose this on
   the user for a variety of reasons. In particular hotels and other
   providers of local wireless Internet often make use of a 'captive DNS
   resolver' to direct users to a portal for a variety of business
   purposes that include limiting use of the wireless network to
   particular parties.

   While it is clearly impossible to provide robust privacy protections
   to users who accept core network functions from random untrustworthy
   sources, the ability to establish network connections in such
   circumstances is essential.

2.1.1.2. Selected Public Resolver

   A public resolver allows users to avoid the numerous security
   vulnerabilities inherent in the local resolver model. Instead of
   taking trusted services from random, anonymous providers, the user
   selects a particular DNS resolution provider to be used regardless of
   which network is in use.

   Many Public DNS resolution services are for-profit commercial
   ventures. The business models supporting such services include
   advertising and data-mining the DNS log file data.

   [[U-PUBLIC] The user takes DNS resolution service from a selected
   provider offering a public DNS resolution service.

2.1.1.3. Selected Subscriber Resolver

   In an alternative business model the DNS resolution service is
   visible to the public Internet but only answers requests from paying
   subscribers. While such a service might not be considered
   sufficiently attractive for it to be offered as a stand-alone
   service, an ISP or security provider might offer a privacy enhanced
   DNS as part of a more general offering.






Hallam-Baker               September 22, 2014                   [Page 6]


Internet-Draft                Private-DNS                     March 2014

   [[U-SUBSCRIBER] The user takes DNS resolution service from a selected
   provider offering the service on a subscription model of some form.

2.1.1.4. Selected Private Resolver

   Most medium to large enterprises run their own DNS services as part
   of their trusted network infrastructure.

   Although the DNS is conceptually a single uniform namespace, many
   Internet sites regard the DNS names of their internal network
   machines to be secret. Protecting the secrecy of such names being one
   of the principle attractions of a DNS privacy protocol to such
   enterprises. this leads to the widespread use of 'split-horizon' DNS
   in which different views of the DNS namespace are visible depending
   on whether a machine is inside or outside the enterprise.

   [U-PRIVATE] A device takes DNS resolution service from a private
   service restricted to authorized use.

2.1.1.5. Hybrid Resolver

   To reduce equipment costs and in response to employee demand, many
   enterprises now support a Bring Your Own Device (BYOD) model in which
   a device that is the property of the owner. Such a device requires
   access to a private DNS service to access enterprise resources within
   a hidden split-horizon DNS. But the owner might not wish their
   private use of the device to be visible to their employer.

   [U-HYBRID] A user makes use of different DNS resolution services for
   different portions of the DNS namespace.

2.1.2. Resolver/Authoritative Communications

   Communications between a Resolver and an Authoritative Server can
   also leak privacy sensitive data. Such leakage is mitigated at
   resolvers with a large number of users and a high traffic load.

   Unlike clients which typically direct DNS requests to a single
   resolver or a small number of resolvers, resolvers typically interact
   with a large number of authoritative servers. Some of which service a
   large number of DNS domains and others service are restricted to a
   publishing data for a specific enterprise.

   Although these use cases are not distinguished in the DNS protocol,
   the privacy implications and protocol constraints of interactions
   with the two types of server are very different. Any interaction
   between a resolver and an authoritative server that responds to
   requests for a single domain with a single host effectively discloses
   the nature of the request regardless of whether encryption is used.
   At the other extreme, traffic analysis of interactions with
   authoritative services serving a large number of domains revealls



Hallam-Baker               September 22, 2014                   [Page 7]


Internet-Draft                Private-DNS                     March 2014

   much less.

   [U-A-BULK] Interaction between a resolver and an authoritative server
   supporting a large number of domains.

   [U-A-TAIL] Interaction between a resolver and an authoritative server
   supporting a small number of domains such that the interaction is
   effectively disclosure of the nature of the communication.

2.2. Constraints

   Any proposal to address the use cases must operate within the
   constraints set by existing DNS infrastructure and administration
   practices.

2.2.1. Legacy Deployment

   The DNS protocol specification was first published in 1987 and has
   evolved significantly over time. While the vast majority of deployed
   DNS servers support modern features such as EDN(0) and DNSSEC, many
   do not. Likewise, most DNS clients and servers accept messages longer
   than the 500 byte minimum implementation requirement.

   Regretably, while most DNS clients and servers are capable of
   supporting features introduced since [RFC1035], many middle-box
   devices including firewalls and residential network gateway devices
   do not.

2.2.2. Integrity Attacks

   One of the core security vulnerabilities of the original DNS protocol
   is that responses are only weakly bound to requests, thus enabling an
   attack known as 'DNS-Spoofing'.

   While DNSSEC is intended to provide a long term solution to the
   problem of DNS spoofing, deployment of DNSSEC is currently the rare
   exception rather than the rule.

2.2.3. Limited message size

   One of the chief performance limitations of the DNS as currently
   deployed is that most DNS servers will only accept a single request
   per DNS message. Th despite support for multiple queries in a single
   request in the DNS protocol,










Hallam-Baker               September 22, 2014                   [Page 8]


Internet-Draft                Private-DNS                     March 2014

2.3. Requirements

   The use cases set out above give rise to the following requirements.

   the term 'requirement' is used to refer to protocol features that
   might be considered desirable without taking a position as to whether
   they are necessary or desirable in practice. A proposal that is
   simpler or more performant may be considered to be superior to one
   that satisfies every requirement.

2.3.1. Confidentiality Requirements

      [R-C-PASSIVE]
         Protect the confidentiality of request and response data
         against a passive attacker.

      [R-C-AFIRST]
         Protect the confidentiality of request and response data
         against an active attacker after first contact.

      [R-C-ACTIVE]
         Protect the confidentiality of request and response data
         against an active attacker on every contact.

      [R-C-TRAFFIC]
         Protect the contents of messages from being disclosed by an
         external attacker through traffic analysis.

      [R-C-LINKING]
         Protect the client against profiling by the resolver.

      [R-C-ATHOR]
         Protect the confidentiality of messages against profiling by
         authoritative servers.

2.3.2. Integrity Requirements

      [R-PSPOOF]
         Prevent spoofing of DNS responses by passive attack

      [R-ASPOOF]
         Prevent spoofing of DNS responses by active attack

2.3.3. Access Requirements

      [R-CANON]
         Support anonymous access to a DNS resolution service







Hallam-Baker               September 22, 2014                   [Page 9]


Internet-Draft                Private-DNS                     March 2014

      [R-CAUTH]
         Support authentication of the client requesting access to a DNS
         resolution service

      [R-AMP]
         Prevent Message amplification attack

      [R-DDOS]
         Prevent Denial of Service attack on the service

   Note that [[R-CANON] and [[RCAUTH] are mutually exclusive. While it
   is desirable for a solution to be capable of supporting both it is
   not possible for a request to be anonymous and authenticated at the
   same time by definition. The access requirement  [[RCAUTH] is also
   distinct from the spoofing countermeasure requirements [R-PSPOOF] and
   [R-ASPOOF]. The access requirement [[RCAUTH] requires that the
   service identify the source of a request. The anti-spoofing
   requirements require that responses be authenticated against the
   requests made.

3. Architecture

   PRIVATE-DNS has two parts

      *  Service Connection

      *  DNS message encapsulation

   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.

   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.

   The Service Connection and Query Service MAY be operated on the same
   host or on separate hosts.

3.1. Service Connection

   The service connection mechanism is responsible for establishing a
   connection context between a client and a service. The connection
   context comprises:

      *  A security context (opaque identifier, key, algorithm choice)
         between the client and the connection service




Hallam-Baker               September 22, 2014                  [Page 10]


Internet-Draft                Private-DNS                     March 2014

      *  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

   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.

   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.

   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.

   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].].

3.2. DNS Message Encapsulation

   The DNS Query Encapsulation is designed for efficiency and to support
   the following features

      *  Encryption

      *  Authentication

      *  Multiple DNS queries and responses per PRIVATE-DNS Query [[*]




Hallam-Baker               September 22, 2014                  [Page 11]


Internet-Draft                Private-DNS                     March 2014

      *  Multiple packet responses [[*]

   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 enables the use of novel
   discovery techniques without impact on performance.

   Choice of encoding scheme is notoriously open to differences without
   distinctions (aka bikeshedding). Fortunately this is a decision that
   the Service Connection service makes easy to revisit.

   Accordingly this specification only describes the information to be
   put in the massages rather than the messages themselves.

   The principle design choice to be made is between a tagged data
   format (e.g. JSON) and a position based format (e.g. the format used
   in TLS). A tagged format offers greater flexibility while a position
   based format is more efficient. At present the TLS position based
   approach is prefered since this is compatible with the traditional
   approach in DNS.

3.3. Satisfaction of Requirements

   [[TBS go through each requirement and show that it is satisfied or
   satisfiable by a particular configuration.]

4. Service Connection and Key Exchange

   The Service Connection is established using [I-D.hallambaker-
   wsconnect]. The protocol identifiers for PRIVATE-DNS are as follows:

      Service Identifier
         PRIVATE-DNS

      Protocol
         DNS

      Presentation
         PRIVATE-DNS-P

      Transport
         UDP

   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:






Hallam-Baker               September 22, 2014                  [Page 12]


Internet-Draft                Private-DNS                     March 2014

      Protocol
         DNS

      Presentation
         POST

      Transport
         HTTP

   A PRIVATE-DNS service offered in this fashion MUST support HTTP/1.1
   or higher.

5. DNS Message Encapsulation

   The DNS Message Encapsulation format is described using the format
   desribed in [RFC5246]. Note that in this notation the size of a
   length specifier is defined by the maximum number of octets permitted
   in the corresponding data field. For convenience these sizes are
   given as 255 or 65335 to specify 1 and 2 byte length specifiers
   respectively. The actual length of the data fields that can be used
   in practice will depend on the maximum size of UDP packet that can be
   reliably transmitted.

   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.

   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.

   opaque TransactionID<16..255>
   opaque SecurityContextID<1..255>

5.1. Request

   If the UDP transport is in use, a request consists of exactly one
   packet.












Hallam-Baker               September 22, 2014                  [Page 13]


Internet-Draft                Private-DNS                     March 2014

   A request has the following structure:

   struct {
       TransactionID       transactionID;
       SecurityContextID   securityContextID;
       opaque              encryptedPayload<1..65535>
       } Request;

   Where:

      transactionID
         Is a unquie identifier for the transaction and an input to the
         function used to derrive the initialization vector (IV) for the
         encryption algorithm

      securityContextID
         Is the opaque security context identifier returned by the
         Service Connect Service.

      encryptedPayload
         Is the encrypted message payload.

5.2. Response

   A response MAY consist of 1 or up to 16 packets, each formatted as
   follows:

   struct {
       TransactionID       transactionID;
       uint8               index;
       uint8               maxIndex;
       uint16              clearResponse;
       opaque              encryptedPayloadSegment<0..65535>
       } Response;

   Where:

      transactionID
         Is a unquie identifier for the transaction and an input to the
         function used to derrive the initialization vector (IV) for the
         encryption algorithm

      index
         Is the index number of this response packet.

      maxIndex
         Is the index number of the last packet. The value of maxIndex
         MUST be the same for every packet. Receivers MUST reject
         packets





Hallam-Baker               September 22, 2014                  [Page 14]


Internet-Draft                Private-DNS                     March 2014

      clearResponse
         Is a response code sent enclair. The value 0 indicates a
         successful response. Error codes TBS. It might be expedient to
         merge these with index and maxIndex to shave some bytes.

      encryptedPayloadSegment
         Is the encrypted message payload segment.

   To obtain the encryptedPayload of the response, the receiver:

      *   Waits for all the response packets to arrive

      *  Sorts the response packets by the value of index.

      *  Extracts the value of encryptedPayloadSegment from each
         response

      *  Concatenate the values of encryptedPayloadSegment to obtain the
         encryptedPayload value

   UDP packets MAY be sent out of order and the order in which they were
   received MAY not match the order in which they were sent. A receiver
   MUST accept response packets recieved in any order.

5.3. Payload

   The payload is a sequence of the following types of data::::

      DNS Message(s)
         The Payload MUST contain at least one DNS message

      Options
         The Payload may contain additional options (To be defined)

      Pading
         The Payload MAY contain padding

      Message Authentication Code
         The Payload MUST contain a MAC. this is calculated over the
         contents of the payload excluding the MAC. For this reason the
         MAC is always the last data in the payload.

   Placing the MAC inside the payload ensures that it is encrypted. this
   prevents a passive attacker determining the length of the MAC which
   might leak information..









Hallam-Baker               September 22, 2014                  [Page 15]


Internet-Draft                Private-DNS                     March 2014

6. Security Considerations

   [[TBS]

6.1. Service

6.2. Confidentialityty

6.3. Integrity

6.4. Privacy

7. IANA Considerations


8. Acnowledgementsts

9. References

9.1. Normative References

   [I-D.hallambaker-jsonbcd]  Hallam-Baker, P, "Binary Encodings for
              JavaScript Object Notation: JSON-B, JSON-C, JSON-D",
              Internet-Draft draft-hallambaker-jsonbcd-01, 21 January
              2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5246]  Dierks, T.,Rescorla, E., "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC2616]  Fielding, R.,Gettys, J.,Mogul, J.,Frystyk, H.,Masinter,
              L.,Leach, P.,Berners-Lee, T., "Hypertext Transfer Protocol
              -- HTTP/1.1", RFC 2616, June 1999.

   [I-D.hallambaker-wsconnect]  Hallam-Baker, P, "JSON Service Connect
              (JCX) Protocol", Internet-Draft draft-hallambaker-
              wsconnect-05, 21 January 2014.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, 1 November 1987.

   [I-D.hallambaker-omnibroker]  Hallam-Baker, P, "OmniBroker Protocol",
              Internet-Draft draft-hallambaker-omnibroker-07, 21 January
              2014.

   [RFC4033]  Arends, R.,Austein, R.,Larson, M.,Massey, D.,Rose, S.,
              "DNS Security Introduction and Requirements", RFC 4033,
              March 2005.




Hallam-Baker               September 22, 2014                  [Page 16]


Internet-Draft                Private-DNS                     March 2014

Author's Address

   Phillip Hallam-Baker
   Comodo Group Inc.

   philliph@comodo.com
















































Hallam-Baker               September 22, 2014                  [Page 17]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/