< draft-ietf-dprive-dnsodtls-00.txt   draft-ietf-dprive-dnsodtls-01.txt >
DPRIVE T. Reddy DPRIVE T. Reddy
Internet-Draft D. Wing Internet-Draft D. Wing
Intended status: Standards Track P. Patil Intended status: Standards Track P. Patil
Expires: December 5, 2015 Cisco Expires: December 6, 2015 Cisco
June 3, 2015 June 4, 2015
DNS over DTLS (DNSoD) DNS over DTLS (DNSoD)
draft-ietf-dprive-dnsodtls-00 draft-ietf-dprive-dnsodtls-01
Abstract Abstract
DNS queries and responses are visible to network elements on the path DNS queries and responses are visible to network elements on the path
between the DNS client and its server. These queries and responses between the DNS client and its server. These queries and responses
can contain privacy-sensitive information which is valuable to can contain privacy-sensitive information which is valuable to
protect. An active attacker can send bogus responses causing protect. An active attacker can send bogus responses causing
misdirection of the subsequent connection. misdirection of the subsequent connection.
To counter passive listening and active attacks, this document To counter passive listening and active attacks, this document
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 5, 2015. This Internet-Draft will expire on December 6, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Relationship to TCP Queries and to DNSSEC . . . . . . . . . . 3 2. Relationship to TCP Queries and to DNSSEC . . . . . . . . . . 3
3. Common problems with DNS Privacy . . . . . . . . . . . . . . 3 3. Common problems with DNS Privacy . . . . . . . . . . . . . . 3
3.1. Firewall Blocking Ports or DNS Privacy Protocol . . . . . 3 3.1. Firewall Blocking Ports or DNS Privacy Protocol . . . . . 3
3.2. Authenticating the DNS Privacy Server . . . . . . . . . . 4 3.2. Authenticating the DNS Privacy Server . . . . . . . . . . 4
3.3. Downgrade attacks . . . . . . . . . . . . . . . . . . . . 5 3.3. Downgrade attacks . . . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Incremental Deployment . . . . . . . . . . . . . . . . . . . 5 5. Incremental Deployment . . . . . . . . . . . . . . . . . . . 6
6. Demultiplexing, Polling, Port Usage, and Discovery . . . . . 6 6. Demultiplexing, Polling, Port Usage, and Discovery . . . . . 6
7. Performance Considerations . . . . . . . . . . . . . . . . . 7 7. Performance Considerations . . . . . . . . . . . . . . . . . 7
8. Established sessions . . . . . . . . . . . . . . . . . . . . 8 8. Established sessions . . . . . . . . . . . . . . . . . . . . 8
9. DTLS Features and Cipher Suites . . . . . . . . . . . . . . . 9 9. DTLS Features and Cipher Suites . . . . . . . . . . . . . . . 9
10. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
14.1. Normative References . . . . . . . . . . . . . . . . . . 11 14.1. Normative References . . . . . . . . . . . . . . . . . . 11
14.2. Informative References . . . . . . . . . . . . . . . . . 11 14.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Domain Name System is specified in [RFC1034] and [RFC1035]. DNS The Domain Name System is specified in [RFC1034] and [RFC1035]. DNS
queries and responses are normally exchanged unencrypted and are thus queries and responses are normally exchanged unencrypted and are thus
vulnerable to eavesdropping. Such eavesdropping can result in an vulnerable to eavesdropping. Such eavesdropping can result in an
undesired entity learning domains that a host wishes to access, thus undesired entity learning domains that a host wishes to access, thus
resulting in privacy leakage. DNS privacy problem is further resulting in privacy leakage. DNS privacy problem is further
discussed in [I-D.bortzmeyer-dnsop-dns-privacy]. discussed in [I-D.bortzmeyer-dnsop-dns-privacy].
skipping to change at page 4, line 41 skipping to change at page 4, line 41
We imagine this could be implemented by adding the certificate name We imagine this could be implemented by adding the certificate name
to the /etc/resolv.conf file, such as below: to the /etc/resolv.conf file, such as below:
nameserver 8.8.8.8 nameserver 8.8.8.8
certificate google-public-dns.google.com certificate google-public-dns.google.com
nameserver 208.67.220.220 nameserver 208.67.220.220
certificate resolver.opendns.com certificate resolver.opendns.com
For DNS privacy servers that don't have a certificate trust chain For DNS privacy servers that don't have a certificate trust chain
(e.g., because they are on a home network or a corporate network), (e.g., because they are on a home network or a corporate network),
the configured list of DNS privacy servers can contain the the configured list of DNS privacy servers can contain the Subject
certificate fingerprint of the DNS privacy server (i.e., a simple Public Key Info (SPKI) fingerprint of the DNS privacy server (i.e., a
whitelist of name and certificate fingerprint). simple whitelist of name and SPKI fingerprint). The public key is
used for the same reasons HTTP pinning [RFC7469] uses the public key.
We imagine this could be implemented by adding the certificate We imagine this could be implemented by adding the certificate
fingerprint to the /etc/resolv.conf file, such as below (line split fingerprint to the /etc/resolv.conf file, such as below (line split
for Internet Draft formatting): for Internet Draft formatting):
nameserver 192.168.1.1 nameserver 192.168.1.1
certificate-fingerprint SPKI-fingerprint
01:56:D3:AC:CF:5B:3F:B8:8F:0F:B4:30:88:2D:F6:72:4E:8C:F2:EE 01:56:D3:AC:CF:5B:3F:B8:8F:0F:B4:30:88:2D:F6:72:4E:8C:F2:EE
3.3. Downgrade attacks 3.3. Downgrade attacks
Using DNS privacy with an authenticated server is most preferred, DNS Using DNS privacy with an authenticated server is most preferred, DNS
privacy with an unauthenticated server is next preferred, and plain privacy with an unauthenticated server is next preferred, and plain
DNS is least preferred. An implementation will attempt to obtain DNS DNS is least preferred. This section gives a non-normative
privacy by contacting DNS servers on the local network (provided by discussion on common behaviors and choices.
DHCP) and on the Internet, and will make those attempts in parallel
to reduce user impact. If DNS privacy cannot be successfully An implementation will attempt to obtain DNS privacy by contacting
negotiated for whatever reason, client can do three things: DNS servers on the local network (provided by DHCP) and on the
Internet, and will make those attempts in parallel to reduce user
impact. If DNS privacy cannot be successfully negotiated for
whatever reason, client can do three things:
1. refuse to send DNS queries on this network, which means the 1. refuse to send DNS queries on this network, which means the
client can not make effective use of this network, as modern client can not make effective use of this network, as modern
networks require DNS; or, networks require DNS; or,
2. use DNS privacy with an un-authorized server, which means an 2. use DNS privacy with an un-authorized server, which means an
attacker could be spoofing the handshake with the DNS privacy attacker could be spoofing the handshake with the DNS privacy
server; or, server; or,
3. send plain DNS queries on this network, which means no DNS 3. send plain DNS queries on this network, which means no DNS
skipping to change at page 6, line 36 skipping to change at page 6, line 49
packet will contain 253 in the third octet, whereas a DNS packet will packet will contain 253 in the third octet, whereas a DNS packet will
never contain 253 in the third octet. never contain 253 in the third octet.
There has been some concern with sending DNSoD traffic over the same There has been some concern with sending DNSoD traffic over the same
port as normal, un-encrypted DNS traffic. The intent of this section port as normal, un-encrypted DNS traffic. The intent of this section
is to show that DNSoD could successfully be sent over port 53. is to show that DNSoD could successfully be sent over port 53.
Further analysis and testing on the Internet may be valuable to Further analysis and testing on the Internet may be valuable to
determine if multiplexing on port 53, using a separate port, or some determine if multiplexing on port 53, using a separate port, or some
fallback between a separate port and port 53 brings the most success. fallback between a separate port and port 53 brings the most success.
After performing the above steps, the host should determine if the The host should determine if the DNS server supports DNSoD by sending
DNS server supports DNSoD by sending a DTLS ClientHello message. A a DTLS ClientHello message. A DNS server that does not support DNSoD
DNS server that does not support DNSoD will not respond to will not respond to ClientHello messages sent by the client, because
ClientHello messages sent by the client, because they are not valid they are not valid DNS requests (specifically, the DNS Opcode is
DNS requests (specifically, the DNS Opcode is invalid). The client invalid). The client MUST use timer values defined in
MUST use timer values defined in Section 4.2.4.1 of [RFC6347] for Section 4.2.4.1 of [RFC6347] for retransmission of ClientHello
retransmission of ClientHello message and if no response is received message and if no response is received from the DNS server. After 15
from the DNS server. After 15 seconds, it MUST cease attempts to re- seconds, it MUST cease attempts to re-transmit its ClientHello.
transmit its ClientHello. Thereafter, the client MAY repeat that Thereafter, the client MAY repeat that procedure in the event the DNS
procedure in the event the DNS server has been upgraded to support server has been upgraded to support DNSoD, but such probing SHOULD
DNSoD, but such probing SHOULD NOT be done more frequently than every NOT be done more frequently than every 24 hours and MUST NOT be done
24 hours and MUST NOT be done more frequently than every 15 minutes. more frequently than every 15 minutes. This mechanism requires no
This mechanism requires no additional signaling between the client additional signaling between the client and server.
and server.
7. Performance Considerations 7. Performance Considerations
To reduce number of octets of the DTLS handshake, especially the size To reduce number of octets of the DTLS handshake, especially the size
of the certificate in the ServerHello (which can be several of the certificate in the ServerHello (which can be several
kilobytes), we should consider using plain public keys kilobytes), we should consider using plain public keys
[I-D.ietf-tls-oob-pubkey]. Considering that to authorize a certain [I-D.ietf-tls-oob-pubkey]. Considering that to authorize a certain
DNS server the client already needs explicit configuration of the DNS DNS server the client already needs explicit configuration of the DNS
servers it trusts, maybe the public key configuration problem is servers it trusts, maybe the public key configuration problem is
really no worse than the configuration problem of those whitelisted really no worse than the configuration problem of those whitelisted
skipping to change at page 8, line 9 skipping to change at page 8, line 19
additional chattiness. additional chattiness.
o To avoid IP fragmentation, DTLS handshake messages incorporate o To avoid IP fragmentation, DTLS handshake messages incorporate
their own fragment offset and fragment length. We might utilize a their own fragment offset and fragment length. We might utilize a
similar mechanism in a shim layer between DTLS and DNS, so that similar mechanism in a shim layer between DTLS and DNS, so that
large DNS messages could be carried without causing IP large DNS messages could be carried without causing IP
fragmentation. fragmentation.
DNSoD puts an additional computational load on servers. The largest DNSoD puts an additional computational load on servers. The largest
gain for privacy is to protect the communication between the DNS gain for privacy is to protect the communication between the DNS
client (the end user's machine) and its caching resolver. Because of client (the end user's machine) and its caching resolver.
the load imposed, and because of the infrequency of queries to root Implementing DNSoD on root servers is outside the scope of this
servers means the DTLS overhead is unlikely to be amoritized over the document.
DNS queries sent over that DTLS connection, implementing DNSoD on
root servers is NOT RECOMMENDED.
8. Established sessions 8. Established sessions
In DTLS, all data is protected using the same record encoding and In DTLS, all data is protected using the same record encoding and
mechanisms. When the mechanism described in this document is in mechanisms. When the mechanism described in this document is in
effect, DNS messages are encrypted using the standard DTLS record effect, DNS messages are encrypted using the standard DTLS record
encoding. When a user of DTLS wishes to send an DNS message, it encoding. When a user of DTLS wishes to send an DNS message, it
delivers it to the DTLS implementation as an ordinary application delivers it to the DTLS implementation as an ordinary application
data write (e.g., SSL_write()). A single DTLS session can be used to data write (e.g., SSL_write()). A single DTLS session can be used to
receive multiple DNS requests and generate DNS multiple responses. receive multiple DNS requests and generate DNS multiple responses.
skipping to change at page 10, line 46 skipping to change at page 10, line 46
Measures for Making DNS More Resilient against Forged Answers Measures for Making DNS More Resilient against Forged Answers
[RFC5452]. [RFC5452].
Security considerations discussed in DTLS [RFC6347] also apply to Security considerations discussed in DTLS [RFC6347] also apply to
this document. this document.
13. Acknowledgements 13. Acknowledgements
Thanks to Phil Hedrick for his review comments on TCP and to Josh Thanks to Phil Hedrick for his review comments on TCP and to Josh
Littlefield for pointing out DNSoD load on busy servers (most notably Littlefield for pointing out DNSoD load on busy servers (most notably
root servers). The authors would like to thank Simon Josefsson for root servers). The authors would like to thank Simon Josefsson,
discussions and comments on the design of DNSoD. Daniel Kahn Gillmor and Bob Harold for discussions and comments on
the design of DNSoD.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
skipping to change at page 11, line 40 skipping to change at page 11, line 40
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
August 2008. August 2008.
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
Resilient against Forged Answers", RFC 5452, January 2009. Resilient against Forged Answers", RFC 5452, January 2009.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, April 2015.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, May 2015. (DTLS)", BCP 195, RFC 7525, May 2015.
14.2. Informative References 14.2. Informative References
[I-D.bortzmeyer-dnsop-dns-privacy] [I-D.bortzmeyer-dnsop-dns-privacy]
Bortzmeyer, S., "DNS privacy considerations", draft- Bortzmeyer, S., "DNS privacy considerations", draft-
bortzmeyer-dnsop-dns-privacy-02 (work in progress), April bortzmeyer-dnsop-dns-privacy-02 (work in progress), April
skipping to change at page 12, line 28 skipping to change at page 12, line 35
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", draft-ietf-tls-oob-pubkey-11 (work in progress), (DTLS)", draft-ietf-tls-oob-pubkey-11 (work in progress),
January 2014. January 2014.
[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
Compression Methods", RFC 3749, May 2004. Compression Methods", RFC 3749, May 2004.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007. Discovery", RFC 4821, March 2007.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, December 2014. Fast Open", RFC 7413, December 2014.
Authors' Addresses Authors' Addresses
Tirumaleswar Reddy Tirumaleswar Reddy
Cisco Systems, Inc. Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103 Bangalore, Karnataka 560103
 End of changes. 14 change blocks. 
42 lines changed or deleted 47 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/