| 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
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.
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 (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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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:
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.
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].
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).
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.
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.
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:
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 |
+-----------------------------------------+
and sent to server. The response encryption key is stored on client along its identifier for decryption.
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.
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 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.
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
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 |
+-----------------------------------------+
and sent back to client.
TODO
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.
The NSK RR has following format:
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:
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
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
)
The security of this protocol is based deeply on DNSSEC [RFC4033]. Protection against downgrade attack requires wide adoption of DNSSEC.
TODO - need a registry for encryption schemes.
| [RFC1033] | Lottor, M., "Domain Administrators Operations Guide", RFC 1033, DOI 10.17487/RFC1033, November 1987. |
| [RFC1034] | Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987. |
| [RFC1035] | Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC2317] | Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/RFC2317, March 1998. |
| [RFC3152] | Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, DOI 10.17487/RFC3152, August 2001. |
| [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. |
| [RFC5625] | Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009. |
| [RFC6891] | Damas, J., Graff, M. and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013. |
| [RFC7626] | Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015. |