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

Versions: 00

Internet Engineering Task Force                          P. Hallam-Baker
Internet-Draft                                               Comodo Inc.
Intended status: Informational                                  B. Smith
Expires: April 21, 2011                                          DNS.com
                                                        October 18, 2010


                       DNS Packet Layer Security
                       draft-hallambaker-dpls-00

Abstract

   A mechanism for encrypting and authenticating communication between a
   DNS Client and server is presented.  The mechanism is designed to
   compliment use of DNSSEC in the case where DNSSEC validation is
   performed at the resolver and it is not desirable to repeat
   validation at the server.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, except to format it
   for publication as an RFC or to translate it into languages other
   than English.

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

   This Internet-Draft will expire on April 21, 2011.

Copyright Notice

   Copyright (c) 2010 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



Hallam-Baker & Smith     Expires April 21, 2011                 [Page 1]

Internet-Draft          DNS Packet Layer Security           October 2010


   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.


Table of Contents

   1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  Purpose  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Use Scenarios  . . . . . . . . . . . . . . . . . . . . . .  5
       2.1.1.  Trusted Resolver . . . . . . . . . . . . . . . . . . .  5
       2.1.2.  Split Horizon DNS  . . . . . . . . . . . . . . . . . .  5
       2.1.3.  Curated DNS  . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Security Requirements  . . . . . . . . . . . . . . . . . .  6
       2.2.1.  Confidential DNS Data  . . . . . . . . . . . . . . . .  6
       2.2.2.  Integrity of requests  . . . . . . . . . . . . . . . .  6
       2.2.3.  Integrity of responses . . . . . . . . . . . . . . . .  6
       2.2.4.  Confidentiality of requests  . . . . . . . . . . . . .  7
       2.2.5.  Confidentiality of responses . . . . . . . . . . . . .  7
       2.2.6.  Service  . . . . . . . . . . . . . . . . . . . . . . .  7
     2.3.  Constraints  . . . . . . . . . . . . . . . . . . . . . . .  7
       2.3.1.  Server . . . . . . . . . . . . . . . . . . . . . . . .  7
       2.3.2.  Client . . . . . . . . . . . . . . . . . . . . . . . .  7
       2.3.3.  Network  . . . . . . . . . . . . . . . . . . . . . . .  7
     2.4.  Engineering Requirements . . . . . . . . . . . . . . . . .  8
   3.  Discovery  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  TLS  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Transport  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Field Encoding . . . . . . . . . . . . . . . . . . . . . .  9
     5.2.  Message Format . . . . . . . . . . . . . . . . . . . . . .  9
       5.2.1.  Version  . . . . . . . . . . . . . . . . . . . . . . . 10
       5.2.2.  Flags  . . . . . . . . . . . . . . . . . . . . . . . . 10
       5.2.3.  Request Identifier . . . . . . . . . . . . . . . . . . 10
       5.2.4.  Initialization Vector  . . . . . . . . . . . . . . . . 11
       5.2.5.  Request Data . . . . . . . . . . . . . . . . . . . . . 11
         5.2.5.1.  Server ticket  . . . . . . . . . . . . . . . . . . 11
         5.2.5.2.  MTU  . . . . . . . . . . . . . . . . . . . . . . . 11
       5.2.6.  Authenticated Data . . . . . . . . . . . . . . . . . . 12
         5.2.6.1.  MAC  . . . . . . . . . . . . . . . . . . . . . . . 12
         5.2.6.2.  Authentication Only Data . . . . . . . . . . . . . 12
         5.2.6.3.  Authentication and Encryption Data . . . . . . . . 12
     5.3.  Continuation Packet  . . . . . . . . . . . . . . . . . . . 12
       5.3.1.  Flags  . . . . . . . . . . . . . . . . . . . . . . . . 13
       5.3.2.  Request Identifier . . . . . . . . . . . . . . . . . . 13
       5.3.3.  Data . . . . . . . . . . . . . . . . . . . . . . . . . 13



Hallam-Baker & Smith     Expires April 21, 2011                 [Page 2]

Internet-Draft          DNS Packet Layer Security           October 2010


   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
     6.1.  Trusted Resolver . . . . . . . . . . . . . . . . . . . . . 13
     6.2.  Resolver Substitution  . . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     8.2.  Non-Normative References . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14











































Hallam-Baker & Smith     Expires April 21, 2011                 [Page 3]

Internet-Draft          DNS Packet Layer Security           October 2010


1.  Definitions

   The following definitions are used in this document:

   DNS Resource Record  A DNS Resource Record as defined in [TBS]

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


2.  Purpose

   DNS Packet Layer Security (DPLS) enables efficient encryption and
   authentication of DNS protocol messages.  In particular, DPLS is
   optimized for use in cases in which a DNS client expects to exchange
   a large number of messages with a particular DNS server as is typical
   of a DNS client that makes us of a DNS resolver.

   In the prefered DNS deployment scenario, all DNS traffic is
   intermediated by a DNS caching resolver in order to minimize load on
   the authoritative name servers.

   DPLS is complimentary to use of DNSSEC.  DNSSEC is designed to permit
   authoritative name servers to perform all necessary public key
   operations offline.  The DNS zone is signed before it is handed toi
   the authoritative name server for publication.  This approach
   minimizes impact on the publishers of DNS data but maximizes impact
   on relying parties which may be required to perform multiple public
   key verification operations for each DNS lookup.  In particular the
   DNS Client that originates a DNS request is required to perform
   multiple signature validations per new request with little chance of
   being able to mitigate performance impact through caching.

   DPLS allows for more efficient secure DNS resolution by enabling a
   trusted resolver to efficiently authenticate communiction with a
   client.  Instead of re-verifying the record chain, the client relies
   on the verification performed at the resolver.

   A secondary advantage of using DPLS is that it enables traffic
   between the DNS client and resolver to be encrypted, thus reducing
   exposure to confidentiality attacks.

   In both cases, the advantage of DPLS is enhanced when deployed at a
   caching resolver that caches the result of DNSSEC validation
   operations and performs pre-fetches on frequently used DNS RRs before



Hallam-Baker & Smith     Expires April 21, 2011                 [Page 4]

Internet-Draft          DNS Packet Layer Security           October 2010


   expiry.  This approach minimizes response latency and correlation
   between encrypted traffic between the DNS resolver and the client and
   external DNS traffic exchanged en-clair

   When deployed at a caching resolver with a very high percentage of
   cache hits, the performance of a DNSSEC/DPLS server approaches the
   performance of the same system without using DNSSEC or DPLS.

2.1.  Use Scenarios

   Use scenarios for DPLS are drawn from observed patterns of using DNS.

   In particular note is taken of the fact that accepted practice at
   enterprise Internet deployment differs in significant respects from
   the traditional DNS deployment scenario in which confidentiality is
   not a concern and in particular adversaried are deemed to be capable
   of performing unrestricted traffic analysis.

2.1.1.  Trusted Resolver

   In the traditional model of DNS, client access to the DNS is always
   mediated through a resolver.  Although the DNS resolver is performing
   a trusted role, the use of unauthenticated requests and responses
   mean that the resolver is not trustworthy.

2.1.2.  Split Horizon DNS

   [many enterprises deploy a split horizon DNS in which internal DNS
   entries are not visible to unauthorized parties.  This is typically
   implemented today using very coarse level access control schemes in
   which a party has either full access to a domain node or does not.]

   [A fine grained access control model in which individual hosts and/or
   end users access can be controlled is highly desirable]

2.1.3.  Curated DNS

   [In the traditional model of DNS, every Internet host has access to
   the public DNS records published by every DNS name owner regardless
   of the trustworthiness of the publisher.

   [In general a relying party wants to have unrestricted access to the
   parts of the Internet known to be safe and does not want to risk
   accessing domains known to be primarily used for criminal purposes
   such as distribution of malware and bank fraud.






Hallam-Baker & Smith     Expires April 21, 2011                 [Page 5]

Internet-Draft          DNS Packet Layer Security           October 2010


2.2.  Security Requirements

   Security model is that the trust relationship between the client and
   resolver is supreme and superceeds any trust relationship that the
   network operator might attempt to impose.

2.2.1.  Confidential DNS Data

   Some or all of the data in a DNS zone MAY be subject to
   confidentiality requirements.

   For example, in a split horizon DNS configuration a perimeter
   security model is employed.  The only DNS data accessible from the
   public network is data that corresponds to public Internet hosts.
   Access to DNS data for private hosts is only available within a
   security perimeter established by means of a firewall or VPN.

   Split horizon DNS has proved to be an essential enterprise security
   control since the deployment and naming of hosts can reveal a lot of
   security sensitive information.  A speculator noting the addition of
   new hosts named sales31, sales32... sales50 may draw one conclusion
   while the addition of a host named secaudit may draw another.

   In a default-deny security configuration access is only granted on a
   need to know basis.  Deployment of a default deny infrastructure
   requires access control at the level of individual users and hosts.

   Requirement: Confidentiality of DNS data.

2.2.2.  Integrity of requests

   The requirement for fine grained access control entails a requirement
   for identification of individual requestors at the host or user level
   and authentication of their requests.

   Requirement: Authentication of Requestors.

   Requirement: Authentication of Requests.

2.2.3.  Integrity of responses

   A DNS resolver performs a trusted role in the Internet architecture.
   Authenticity of responses is thus a primary security concern.

   Requirement: Authentication of Responder.

   Requirement: Authentication of Response.




Hallam-Baker & Smith     Expires April 21, 2011                 [Page 6]

Internet-Draft          DNS Packet Layer Security           October 2010


2.2.4.  Confidentiality of requests

   Request data may disclose confidential information.

   Requirement: Optional Encryption of Requests.

2.2.5.  Confidentiality of responses

   Response data may disclose confidential information.

   Requirement: Optional Encryption of Responses.

2.2.6.  Service

2.3.  Constraints

2.3.1.  Server

   [A DNS resolver is typically high throughput and must avoid the need
   to perform public key operations at time-critical moments. ]

   [Support for high volume resolvers is particularly important as the
   efficiency of the protocol rests on a high cache hit rate]

   [Server cannot support any per client state.  This rules out use of
   IPSEC and TKEY]

2.3.2.  Client

   [Avoid need for extensive state]

   [Allow for tunnelling an bypass.

   [Enable easy configuration and audit of trust configuration

2.3.3.  Network

   [Firewalls louse things up]

   [Allow for tunnelling and bypass to prevent unintentional blocking]

   [But traffic should be identifiable by DPLS aware firewall.

   [Response truncation issues, most DNS requests fit in one small
   packet, more efficient to allow for long responses and enable
   effective control of fragmentation]





Hallam-Baker & Smith     Expires April 21, 2011                 [Page 7]

Internet-Draft          DNS Packet Layer Security           October 2010


2.4.  Engineering Requirements

   [No server side state means a ticket approach]

   [Try to avoid need for new key exchange protocol]


3.  Discovery

   [A client discovers the existence of a DPLS service option by means
   of an ESRV query for the _dns._udp service.

   [The service option for DPLS is _dpls._ws]

                       _dns._udp.example.com   ESRV "prot=_dpls._ws"


4.  Key Exchange

   [Server specifies the key exchange mechanism(s) supported by means of
   the ESRV exch property.  Initially, only the TLS exchange mechanism
   is defined]

   [Although TKEY is defined as a key exchange mechanism in RFC2390, the
   description in that document falls far short of being implemented and
   the document has not been updated in ten years to keep pace with
   developments in cryptography since]

   [Description and implementation of a new version of TKEY that
   supported appropriate cryptographic algorithms and key exchange
   schemes requires considerably more effort than reuse of TLS that
   already has these features.

4.1.  TLS

   [Client uses HTTP/TLS with RFC4507 Session Resumption without Server-
   Side State options

   [Client sends a SessionTicket extension.]

   Server is responsible for delivering a ticket that will work with the
   DNS service.

   Server may employ TLS client auth to authenticate the request,
   alternatively HTTP authenticate option may be employed.

   At conclusion of the protocol, the server MAY specify an alternative
   set of IP addresses for the DNS service, plus control information



Hallam-Baker & Smith     Expires April 21, 2011                 [Page 8]

Internet-Draft          DNS Packet Layer Security           October 2010


   such as an expiry interval for the session parameters.

   It is envisaged that the expiry interval would typically be of the
   order months to years and that re-authentication should be automatic
   and not require new user authentication.


5.  Transport

   One of the principle motivations behind the proposal for a new
   cryptographic packet format is the unique nature of DNS responses and
   requests.

   In particular, a DNS request is typically very small, almost never
   exceeding the 500 byte limit specified for UDP transport in the
   original protocol.  DNS responses are usually smaller than 500 bytes
   but may exceed the 1400 byte limit set by the Ethernet MTU,
   particularly if DNSSEC is in employed but should not normally exceed
   4048 bits.

   The UPDP packet transport is designed to support the following
   criteria when used in conjunction with a network offering an MTU of
   at least 1500 bytes (i.e. ethernet)

      Requests of 500 bytes or less

      Responses of 32768 bytes or less

5.1.  Field Encoding

   Each field except for Version is encoded in length:data format as
   follows:

   If the first bit of the first byte in the length field is 0 then the
   length field is one byte long and the lower 7 bits specify the length
   of the following data field in octets.  Otherwise the lower 7 bits of
   the first byte specify the most significant byte and the following
   octet specifies the least significant byte of a two byte length field
   specifying the number of octets that follow.

5.2.  Message Format

      Header



         Version (MUST be 0)




Hallam-Baker & Smith     Expires April 21, 2011                 [Page 9]

Internet-Draft          DNS Packet Layer Security           October 2010


         Flags

         Request Identifier

         Initialization Vector

         Request Data (only for requests)

      Authenticated Data



         MAC

         Data or Encrypted Data

5.2.1.  Version

   The version field is the only fied length field used in the packet
   format and MUST be set to 0 for this version of the packet format.

5.2.2.  Flags

   The following flags values are specified

   4-0  Packet Count

   5  Not Encrypted (1) or Encrypted (0)

   6  Continuation (1) or Initial packet (0)

   7  Request (1) or Response (0)

   8  Error (1) or Success (0)

   In an initial packet, the packet count specifies the total number of
   packets across which the message is spread excluding the initial
   packet.  In continuation packets the packet count specifies the
   sequence number of the packet.

   Flag values that are unspecified are assumed to be 0. thus a
   successful, encrypted response that fits in a single packet will have
   all flags set to zero and a flag length specifier of 0x00.

5.2.3.  Request Identifier

   In a request the request identifier is value assigned by the client
   to differentiate requests and responses.  Since the request



Hallam-Baker & Smith     Expires April 21, 2011                [Page 10]

Internet-Draft          DNS Packet Layer Security           October 2010


   identifier is only used for this purpose and not as a weak form of
   authentication, the request identifier does not need to be any larger
   than is necessary to prevent ambiguity.

   [Note: the Request Identifier is only required if continuation
   packets are in use and could possibly be eliminated by combining it
   with the IV]

5.2.4.  Initialization Vector

   The Initialization Vector (IV) is generated by the client and serves
   as a nonce for use in the authentication mechanism and an
   Initialization Vector when encryption is in use.

   The IV specified in a response MUST match that specified in the
   corresponding request.

5.2.5.  Request Data

   Additional information is required in a request to enable the server
   to establish the cryptographic context.

      Server ticket

      MTU

5.2.5.1.  Server ticket

   The server ticket established during the key exchange phase.

   The server ticket carries all the state that the server considers
   necessary to locate the keys required for the necessary
   authentication, authorization and cryptographic operations.

5.2.5.2.  MTU

   The Maximum Transmission Unit for the network link.  If the value 00
   is specified, the MTU is unspecified.

   A client MUST NOT specify a value less than 512 bytes for the MTU.  A
   client SHOULD NOT specify an MTU value unless it is known that a
   larger packet is either certain to fail or very likely to fail.

   A server MUST NOT generate response packets larger than the specified
   MTU.

   In normal circumstances, specification of MTUs less than 1452 bytes
   (the Ethernet MTU minus the IPv6 header length minus the UDP header



Hallam-Baker & Smith     Expires April 21, 2011                [Page 11]

Internet-Draft          DNS Packet Layer Security           October 2010


   length) is not necessary.

   In the case that the MTU size is unspecified, servers SHOULD attempt
   to select an MTU size that balances the overhead of sending
   additional packets and the need to avoid UDP packet fragmentation.

5.2.6.  Authenticated Data

   The authernticated data section consists of the MAC field and the
   Data section.

5.2.6.1.  MAC

   The MAC value is only specified in the first packet and is calculated
   over the header of the initial packet concatenated to the data
   section.  Continuation header data is ignored in calculating the MAC
   value.

   The Message Authentication Code calculated according to the
   cryptographic algorithms agreed in the key negotiation phase.  The
   key used is the client_write_MAC_secret in the case of a request and
   the server_write_MAC_secret in the case of a response.

   There is no need to specify the cryptographic algorithm since a
   server that is capable of supporting multiple algorithms MAY encode
   the algorithm information in the ticket.

5.2.6.2.  Authentication Only Data

   The data section consists of the DNS request or response data.

   If the DNS data is too large to allow a single packet to be used, the
   data is partitioned into segments so that each segment is small
   enough to fit within the specified MTU.

5.2.6.3.  Authentication and Encryption Data

   The entire authenticated data section (MAC and data) is encrypted
   under the client_write_key in the case of a request or the
   server_write_key in the case of a response.

5.3.  Continuation Packet

   If the data section of a response is larger than the MTU specified in
   the request, the additional data is sent as continuation packets.

   DNS clients MUST NOT issue requests with continuation packets unless
   the server has stated that they will be accepted via means out of



Hallam-Baker & Smith     Expires April 21, 2011                [Page 12]

Internet-Draft          DNS Packet Layer Security           October 2010


   scope for this draft.

      Header



         Version (MUST be 0)

         Flags

         Request Identifier

      Data

5.3.1.  Flags

   The flags value set in a continuation packet enables the receiver to
   match requests and responses and re-assemble data segments in the
   correct sequence.

   4-0  Packet Number

   5  Ignored

   6  MUST be 1

   7  Request (1) or Response (0)

5.3.2.  Request Identifier

   Value must match that specified in the initial packet.

5.3.3.  Data

   The continuation data.


6.  Security Considerations

   [This will need considerable expansion]

6.1.  Trusted Resolver

   The DNS server performs a trusted role in the standard DNS model but
   is not required to be trusted in the end-to-end model of DNSSEC
   deployment.

   DPLS is designed to support a configuration where the DNS resolver is



Hallam-Baker & Smith     Expires April 21, 2011                [Page 13]

Internet-Draft          DNS Packet Layer Security           October 2010


   trusted to perform DNSSEC operations on behalf of the client.

6.2.  Resolver Substitution

   DPLS provides for server authentication in all cases and mutual
   authentication when client authentication is employed.


7.  IANA Considerations

   Will need to establish a registry for the flags values

   Will need to register DPLP as a protocol prefix.


8.  References

8.1.  Normative References

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

8.2.  Non-Normative References

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.


Authors' Addresses

   Phillip Hallam-Baker
   Comodo Inc.

   Email: philliph@comodo.com


   Brian Smith
   DNS.com

   Email: brian@dns.com










Hallam-Baker & Smith     Expires April 21, 2011                [Page 14]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/