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 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
    1.1.  Requirements Language
2.  Purpose
    2.1.  Use Scenarios
        2.1.1.  Trusted Resolver
        2.1.2.  Split Horizon DNS
        2.1.3.  Curated DNS
    2.2.  Security Requirements
        2.2.1.  Confidential DNS Data
        2.2.2.  Integrity of requests
        2.2.3.  Integrity of responses
        2.2.4.  Confidentiality of requests
        2.2.5.  Confidentiality of responses
        2.2.6.  Service
    2.3.  Constraints
        2.3.1.  Server
        2.3.2.  Client
        2.3.3.  Network
    2.4.  Engineering Requirements
3.  Discovery
4.  Key Exchange
    4.1.  TLS
5.  Transport
    5.1.  Field Encoding
    5.2.  Message Format
        5.2.1.  Version
        5.2.2.  Flags
        5.2.3.  Request Identifier
        5.2.4.  Initialization Vector
        5.2.5.  Request Data
            5.2.5.1.  Server ticket
            5.2.5.2.  MTU
        5.2.6.  Authenticated Data
            5.2.6.1.  MAC
            5.2.6.2.  Authentication Only Data
            5.2.6.3.  Authentication and Encryption Data
    5.3.  Continuation Packet
        5.3.1.  Flags
        5.3.2.  Request Identifier
        5.3.3.  Data
6.  Security Considerations
    6.1.  Trusted Resolver
    6.2.  Resolver Substitution
7.  IANA Considerations
8.  References
    8.1.  Normative References
    8.2.  Non-Normative References
§  Authors' Addresses

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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 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.

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.

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]

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 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)

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

8.2. Non-Normative References

Authors' Addresses