Internet Engineering Task Force W. Krecicki
Internet-Draft Internet Systems Consortium
Intended status: Standards Track October 17, 2015
Expires: April 19, 2016
Stateless DNS Encryption
draft-krecicki-dprive-dnsenc-00
Abstract
The DNS is the last common Internet protocol that has no encryption
scheme and therefore provides no privacy to the users. This document
proposes an extensible mechanism providing encryption of DNS queries
and responses with method for secure retrieval and verification of
validity of encryption keys. It is independent of the underlying
transport protocol.
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."
This Internet-Draft will expire on April 19, 2016.
Copyright Notice
Copyright (c) 2015 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
Krecicki Expires April 19, 2016 [Page 1]
Internet-Draft Stateless DNS Encryption October 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Communication process . . . . . . . . . . . . . . . . . . . . 3
2.1. Key retrieval . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Query creation . . . . . . . . . . . . . . . . . . . . . 4
2.2.1. Method 1 . . . . . . . . . . . . . . . . . . . . . . 4
2.2.2. Method 2 . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Query processing . . . . . . . . . . . . . . . . . . . . 5
2.4. Response creation . . . . . . . . . . . . . . . . . . . . 6
2.5. Response processing . . . . . . . . . . . . . . . . . . . 7
3. Data types . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. NSK record . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Wire format . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Presentation format . . . . . . . . . . . . . . . . . 9
3.2. DNSENC OPT pseudo-record . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Normative References . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
The Domain Name System protocol is specified in [RFC1034] and
[RFC1035]. DNS messages are unencrypted and therefore prone to
eavesdropping. Although it's considered only metadata, the are a lot
of data that can be leaked - as explained by [RFC7626].
The DNS protocol is very lightweight - the queries are usually less
than 100 bytes long, the responses are usually less than 1000 bytes
(with DNSSEC). Existing transport encryption schemes such as TLS for
TCP or DTLS for UDP give huge and unnecessary overhead both in amount
of data sent and retrieved and in number of packets exchanged between
client and server.
In DNSENC the query is encrypted using asymmetric cryptography with a
securely retrieved key, the response is encrypted using symmetric
encryption using one-time key provided with query. DNSENC protocol
is confined within DNS and does not requires any additional external
mechanisms such as PKI/CA system.
The DNSENC communication can be split into three phases:
Krecicki Expires April 19, 2016 [Page 2]
Internet-Draft Stateless DNS Encryption October 2015
o first the client retrieves public key for server that is stored in
DNS and DNSSEC signed (this key can be cached)
o client creates the query, adds a random response encryption key
and encrypts the query with servers public key
o server decrypts the message, prepares the response and encrypts it
with the key provided by client
It has to be noted that to bootstrap a resolver it has to perform a
clear text query to retrieve keys for DNSENC encryption, but as this
can be a query for root domain there is no leak of information here.
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. Communication process
2.1. Key retrieval
To communicate securely with server, client first needs to retrieve
servers public key for asymmetric encryption, this key is stored in
NSK RR described in Section 3.1. The NSK RRset might contain
multiple records. Key retrieval process is different for
authoritative servers and for recursive servers.
For authoritative servers a NSK RRset SHOULD be present at a
delegation point. All NSK RRsets MUST be signed with DNSSEC, and NSK
RRsets MUST NOT appear at a zone's apex.
example.com. 86400 IN NS a.iana-servers.net.
example.com. 86400 IN NS b.iana-servers.net.
example.com. 86400 IN NSK (...)
For recursive servers and in case it is not possible to put the NSK
RRset at a delegation point, the NSK RRset SHOULD be present in
reverse DNS record of servers' IP address, as described in [RFC3152],
[RFC1033] and [RFC2317]. This RRset MUST be DNSSEC signed. For
authoritative servers this method is only a fallback and client MUST
try to retrieve the key at a delegation point first.
5.2.0.192.in-addr.arpa. 86400 IN NSK (...)
If the record is not signed the client MUST NOT use the key provided.
(TODO enforce encryption, protection against downgrade attack).
Krecicki Expires April 19, 2016 [Page 3]
Internet-Draft Stateless DNS Encryption October 2015
As there might be multiple NSK RRs in RRSet it's client
responsibility to choose a RR that has query and response encryption
schemes supported by client and has highest priority.
2.2. Query creation
NOTE: two alternatives are currently under discussion. Both are
fully compatible with DNS protocol, the first one is a kludge but has
better chances to be compatible with not-fully-protocol-compliant
forwarders (although it still requires support for EDNS). The second
solution is cleaner but might not work with some forwarders as the
packet is not a regular DNS QUERY.
2.2.1. Method 1
After choosing encryption scheme client generates a random response
encryption key (symmetrical, eg. AES), prepares a regular DNS query
with NSK record containing the response encryption scheme and key in
ADDITIONAL section.
This message is encrypted using query encryption key and packed,
along with encryption key ID, in a DNSENC OPT RR, as described in
Section 3.2. A new query is created with:
o query id copied from the encrypted message
o <nonce>.dnsenc.arpa. TXT? query in QUERY section, where <nonce>
is a random label that guarantees that in the case the response is
cached by a forwarder it will not be reused for any other client.
o empty ANSWER and AUTHORITY sections
o DNSENC OPT RR in ADDITIONAL section
eg.:
+-----------------------------------------+
Header | OPCODE=QUERY, ID=997, QR=QUERY |
+-----------------------------------------+
Question | QTYPE=TXT, QCLASS=IN, |
| QNAME=<nonce>.dnsenc.arpa |
+-----------------------------------------+
Answer | <empty> |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | EDNS0 OPT OPTION-CODE=DNSENC |
+-----------------------------------------+
Krecicki Expires April 19, 2016 [Page 4]
Internet-Draft Stateless DNS Encryption October 2015
and sent to server. The response encryption key is stored on client
along its identifier for decryption.
2.2.2. Method 2
After choosing encryption scheme client generates a random response
encryption key (symmetrical, eg. AES), prepares a regular DNS query
with NSK record containing the response encryption scheme and key in
ADDITIONAL section.
This message is encrypted using query encryption key and packed
inside a query with OPCODE set to ENCRYPT:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| ENCRYPT | Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ENCRYPTED PAYLOAD LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RESERVED |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RESERVED |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RESERVED |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ENCRYPTION KEY ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ ENCRYPTED PAYLOAD /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
and sent to server. The response encryption key is stored on client
along its identifier for decryption.
2.3. Query processing
When a server supporting DNSENC receives a query for anything in
"dnsenc.arpa." domain it MUST immediately look in ADDITIONAL section
for DNSENC OPT RR. If DNSENC OPT RR is missing the server MUST
respond with REFUSED result. The DNSENC OPT RR is then decoded. If
the server does not have a key with identifier provided in query or
the decryption failed the server MUST respond with BADCRYPT response.
If the data contained in the decrypted packet is invalid or the query
Krecicki Expires April 19, 2016 [Page 5]
Internet-Draft Stateless DNS Encryption October 2015
ID is not the same as the encapsulating packet query ID the server
MUST respond with FORMERR response.
A server that does not support DNSENC should respond with REFUSED
response code, although old implementations not supporting [RFC6891]
might return FORMERR.
A forwarder/proxy MUST pass the message untouched (along with DNSENC
OPT RR in ADDITIONAL section) - as described in [RFC5625]. A
forwarder/proxy MUST NOT cache a result for anything within "dnsenc."
pseudo-TLD nor with DNSENC OPT RR in ADDITIONAL section.
2.4. Response creation
NOTE: the alternate form is the method with OPCODE sent to ENCRYPT,
as with query.
After decryption the query section from encapsulating packet is saved
along the NSK record from query for response encryption and the query
is processed normally. When response is ready a regular DNS response
packet is created, it is encrypted using previously saved response
encryption key sent by client and stored along with response
encryption key ID in DNSENC OPT RR. New response packet is created
with
o query ID same as in encrypted packet
o QUESTION section copied from original query
o empty ANSWER and AUTHORITY sections
o DNSENC OPT RR in ADDITIONAL section
eg.
+-----------------------------------------+
Header | OPCODE=QUERY, ID=997, QR=RESPONSE |
+-----------------------------------------+
Question | QTYPE=TXT, QCLASS=IN, |
| QNAME=<nonce>.dnsenc.arpa |
+-----------------------------------------+
Answer | <empty> |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | EDNS0 OPT OPTION-CODE=DNSENC |
+-----------------------------------------+
Krecicki Expires April 19, 2016 [Page 6]
Internet-Draft Stateless DNS Encryption October 2015
and sent back to client.
2.5. Response processing
TODO
3. Data types
3.1. NSK record
The NSK RR consist of priority field, key identifier, server names
for which the key can be used (wildcard '*' is supported, single '*'
means all servers), query encryption scheme (asymmetrical, eg. rsaes-
oaep-2048), query key data and possible response encryption schemes.
The server might provide multiple RR records, it's client
responsibility to choose a RR that has query and response encryption
schemes supported by client and has highest priority.
3.1.1. Wire format
The NSK RR has following format:
Krecicki Expires April 19, 2016 [Page 7]
Internet-Draft Stateless DNS Encryption October 2015
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| KEY IDENTIFIER |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PRIORITY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| APPLICABLE NS NAME LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ APPLICABLE NS NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QUERY ENCRYPTION SCHEME |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QUERY KEY LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ QUERY KEY DATA /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NUMBER OF RESPONSE ENCRYPTION SCHEMES |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RESPONSE ENCRYPTION SCHEME 1 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RESPONSE ENCRYPTION SCHEME 2 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ ... +
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RESPONSE ENCRYPTION SCHEME N |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
Krecicki Expires April 19, 2016 [Page 8]
Internet-Draft Stateless DNS Encryption October 2015
KEY IDENTIFIER 32-bit key identifier, unique for server
PRIORITY 16-bit key priority as preferred by
server
APPLICABLE NS NAME name of NSes for which this key is
valid, might contain wildcard symbol '*',
single '*' means any
QUERY ENCRYPTION SCHEME 16-bit identifier of query encryption
scheme, as defined in [TBD IANA REGISTRY]
QUERY KEY DATA query encryption key - raw binary data
RESPONSE ENCRYPTION SCHEMES list of 16-bit identifiers of response
encryption schemes, as defined in
[TBD IANA REGISTRY], in order of server
preference
3.1.2. Presentation format
All numerical fields are presented in decimal form, query key data is
base64 encoded, fields are in the same order as in wire format, eg:
example.com. 86400 IN NSK (896417428 ; identifier
10 ; priority
ns*.example.com ; applicable NS name
1 ; query encryption
; scheme, rsaes-2048-eoap
"bnJfZnJlZV9wYWdlcyAyMTU2NjgKbnJf
YWxsb2NfYmF0Y2ggNDE1OQpucl9pbmFj
dGl2ZV9hbm9uIDM1NzczNwpucl9hY3Rp
IDQ4OTAwMQpucl9kaXJ0eSAxMTUKbnJf
ZCAwCg==" ; query key, b64 encoded
32769 32770 ; response encryption
; schemes: aes256, aes512
)
3.2. DNSENC OPT pseudo-record
4. Security Considerations
The security of this protocol is based deeply on DNSSEC [RFC4033].
Protection against downgrade attack requires wide adoption of DNSSEC.
Krecicki Expires April 19, 2016 [Page 9]
Internet-Draft Stateless DNS Encryption October 2015
5. IANA Considerations
TODO - need a registry for encryption schemes.
6. Normative References
[RFC1033] Lottor, M., "Domain Administrators Operations Guide", RFC
1033, DOI 10.17487/RFC1033, November 1987,
<http://www.rfc-editor.org/info/rfc1033>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/
RFC2317, March 1998,
<http://www.rfc-editor.org/info/rfc2317>.
[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, DOI
10.17487/RFC3152, August 2001,
<http://www.rfc-editor.org/info/rfc3152>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP
152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
<http://www.rfc-editor.org/info/rfc5625>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/
RFC6891, April 2013,
<http://www.rfc-editor.org/info/rfc6891>.
Krecicki Expires April 19, 2016 [Page 10]
Internet-Draft Stateless DNS Encryption October 2015
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015,
<http://www.rfc-editor.org/info/rfc7626>.
Author's Address
Witold Krecicki
Internet Systems Consortium
Warsaw
PL
Phone: +48 502117580
Email: wpk@isc.org
Krecicki Expires April 19, 2016 [Page 11]