Internet DRAFT - draft-hallambaker-dpls
draft-hallambaker-dpls
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]
