draft-ietf-dprive-dns-over-tls-08.txt   draft-ietf-dprive-dns-over-tls-09.txt 
Network Working Group Z. Hu Network Working Group Z. Hu
Internet-Draft L. Zhu Internet-Draft L. Zhu
Intended status: Standards Track J. Heidemann Intended status: Standards Track J. Heidemann
Expires: September 16, 2016 USC/Information Sciences Expires: September 18, 2016 USC/Information Sciences Institute
Institute
A. Mankin A. Mankin
D. Wessels D. Wessels
Verisign Labs Verisign Labs
P. Hoffman P. Hoffman
ICANN ICANN
March 15, 2016 March 17, 2016
Specification for DNS over TLS Specification for DNS over TLS
draft-ietf-dprive-dns-over-tls-08 draft-ietf-dprive-dns-over-tls-09
Abstract Abstract
This document describes the use of TLS to provide privacy for DNS. This document describes the use of TLS to provide privacy for DNS.
Encryption provided by TLS eliminates opportunities for eavesdropping Encryption provided by TLS eliminates opportunities for eavesdropping
and on-path tampering with DNS queries in the network, such as and on-path tampering with DNS queries in the network, such as
discussed in RFC 7626. In addition, this document specifies two discussed in RFC 7626. In addition, this document specifies two
usage profiles for DNS-over-TLS and provides advice on performance usage profiles for DNS-over-TLS and provides advice on performance
considerations to minimize overhead from using TCP and TLS with DNS. considerations to minimize overhead from using TCP and TLS with DNS.
This document focuses on securing stub-to-recursive traffic, as per This document focuses on securing stub-to-recursive traffic, as per
the charter of the DPRIVE working group. It does not prevent future the charter of the DPRIVE working group. It does not prevent future
applications of the protocol to recursive-to-authoritative traffic. applications of the protocol to recursive-to-authoritative traffic.
Note: this document was formerly named Note: this document was formerly named draft-ietf-dprive-start-tls-
draft-ietf-dprive-start-tls-for-dns. Its name has been changed to for-dns. Its name has been changed to better describe the mechanism
better describe the mechanism now used. Please refer to working now used. Please refer to working group archives under the former
group archives under the former name for history and previous name for history and previous discussion. [RFC Editor: please remove
discussion. [RFC Editor: please remove this paragraph prior to this paragraph prior to publication]
publication]
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 16, 2016. This Internet-Draft will expire on September 18, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4
3. Establishing and Managing DNS-over-TLS Sessions . . . . . . . 5 3. Establishing and Managing DNS-over-TLS Sessions . . . . . . . 4
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 5 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 4
3.2. TLS Handshake and Authentication . . . . . . . . . . . . . 6 3.2. TLS Handshake and Authentication . . . . . . . . . . . . 5
3.3. Transmitting and Receiving Messages . . . . . . . . . . . 6 3.3. Transmitting and Receiving Messages . . . . . . . . . . . 5
3.4. Connection Reuse, Close and Reestablishment . . . . . . . 7 3.4. Connection Reuse, Close and Reestablishment . . . . . . . 6
4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 8 4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 7
4.2. Out-of-band Key-pinned Privacy Profile . . . . . . . . . . 8 4.2. Out-of-band Key-pinned Privacy Profile . . . . . . . . . 7
5. Performance Considerations . . . . . . . . . . . . . . . . . . 10 5. Performance Considerations . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . . 11 7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . 10
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 11
8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 14 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 13
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Out-of-band Key-pinned Privacy Profile Example . . . 19 Appendix A. Out-of-band Key-pinned Privacy Profile Example . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Today, nearly all DNS queries [RFC1034], [RFC1035] are sent Today, nearly all DNS queries [RFC1034], [RFC1035] are sent
unencrypted, which makes them vulnerable to eavesdropping by an unencrypted, which makes them vulnerable to eavesdropping by an
attacker that has access to the network channel, reducing the privacy attacker that has access to the network channel, reducing the privacy
of the querier. Recent news reports have elevated these concerns, of the querier. Recent news reports have elevated these concerns,
and recent IETF work has specified privacy considerations for DNS and recent IETF work has specified privacy considerations for DNS
[RFC7626]. [RFC7626].
skipping to change at page 5, line 28 skipping to change at page 4, line 28
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Establishing and Managing DNS-over-TLS Sessions 3. Establishing and Managing DNS-over-TLS Sessions
3.1. Session Initiation 3.1. Session Initiation
A DNS server that supports DNS-over-TLS MUST by default listen for A DNS server that supports DNS-over-TLS MUST by default listen for
and accept TCP connections on port 853. By mutual agreement with its and accept TCP connections on port 853, unless it has mutual
clients, the server MAY, instead, use a port other than 853 for DNS- agreement with its clients to use a port other than 853 for DNS-over-
over-TLS. In order to use a port other than 853, both clients and TLS. In order to use a port other than 853, both clients and servers
servers would need a configuration option in their software. would need a configuration option in their software.
DNS clients desiring privacy from DNS-over-TLS from a particular DNS clients desiring privacy from DNS-over-TLS from a particular
server MUST by default establish a TCP connection to port 853 on the server MUST by default establish a TCP connection to port 853 on the
server. By mutual agreement with its server, the client MAY, server, unless it has mutual agreement with its server to use a port
instead, use a port other than port 853 for DNS-over-TLS. Such an other than port 853 for DNS-over-TLS. Such an other port MUST NOT be
other port MUST NOT be port 53, but MAY be from the "first-come, port 53, but MAY be from the "first-come, first-served" port range.
first-served" port range. This recommendation against use of port 53 This recommendation against use of port 53 for DNS-over-TLS is to
for DNS-over-TLS is to avoid complication in selecting use or non-use avoid complication in selecting use or non-use of TLS, and to reduce
of TLS, and to reduce risk of downgrade attacks. The first data risk of downgrade attacks. The first data exchange on this TCP
exchange on this TCP connection MUST be the client and server connection MUST be the client and server initiating a TLS handshake
initiating a TLS handshake using the procedure described in using the procedure described in [RFC5246].
[RFC5246].
DNS clients and servers MUST NOT use port 853 to transport clear text DNS clients and servers MUST NOT use port 853 to transport clear text
DNS messages. DNS clients MUST NOT send and DNS servers MUST NOT DNS messages. DNS clients MUST NOT send and DNS servers MUST NOT
respond to clear text DNS messages on any port used for DNS-over-TLS respond to clear text DNS messages on any port used for DNS-over-TLS
(including, for example, after a failed TLS handshake). There are (including, for example, after a failed TLS handshake). There are
significant security issues in mixing protected and unprotected data significant security issues in mixing protected and unprotected data
and for this reason TCP connections on a port designated by a given and for this reason TCP connections on a port designated by a given
server for DNS-over-TLS are reserved purely for encrypted server for DNS-over-TLS are reserved purely for encrypted
communications. communications.
skipping to change at page 6, line 23 skipping to change at page 5, line 20
be more aggressive about retrying DNS-over-TLS connection failures. be more aggressive about retrying DNS-over-TLS connection failures.
3.2. TLS Handshake and Authentication 3.2. TLS Handshake and Authentication
Once the DNS client succeeds in connecting via TCP on the well-known Once the DNS client succeeds in connecting via TCP on the well-known
port for DNS-over-TLS, it proceeds with the TLS handshake [RFC5246], port for DNS-over-TLS, it proceeds with the TLS handshake [RFC5246],
following the best practices specified in [BCP195]. following the best practices specified in [BCP195].
The client will then authenticate the server, if required. This The client will then authenticate the server, if required. This
document does not propose new ideas for authentication. Depending on document does not propose new ideas for authentication. Depending on
the privacy profile in use Section 4, the DNS client may choose not the privacy profile in use (Section 4), the DNS client may choose not
to require authentication of the server, or it may make use of a to require authentication of the server, or it may make use of a
trusted Subject Public Key Info (SPKI) Fingerprint pinset. trusted Subject Public Key Info (SPKI) Fingerprint pinset.
After TLS negotiation completes, the connection will be encrypted and After TLS negotiation completes, the connection will be encrypted and
is now protected from eavesdropping. is now protected from eavesdropping.
3.3. Transmitting and Receiving Messages 3.3. Transmitting and Receiving Messages
All messages (requests and responses) in the established TLS session All messages (requests and responses) in the established TLS session
MUST use the two-octet length field described in Section 4.2.2 of MUST use the two-octet length field described in Section 4.2.2 of
skipping to change at page 7, line 9 skipping to change at page 6, line 9
responses to outstanding queries on the same TLS connection using the responses to outstanding queries on the same TLS connection using the
Message ID. If the response contains a question section, the client Message ID. If the response contains a question section, the client
MUST match the QNAME, QCLASS, and QTYPE fields. Failure by clients MUST match the QNAME, QCLASS, and QTYPE fields. Failure by clients
to properly match responses to outstanding queries can have serious to properly match responses to outstanding queries can have serious
consequences for interoperability ([RFC7766], Section 7). consequences for interoperability ([RFC7766], Section 7).
3.4. Connection Reuse, Close and Reestablishment 3.4. Connection Reuse, Close and Reestablishment
For DNS clients that use library functions such as "getaddrinfo()" For DNS clients that use library functions such as "getaddrinfo()"
and "gethostbyname()", current implementations are known to open and and "gethostbyname()", current implementations are known to open and
close TCP connections each DNS call. To avoid excess TCP close TCP connections for each DNS query. To avoid excess TCP
connections, each with a single query, clients SHOULD reuse a single connections, each with a single query, clients SHOULD reuse a single
TCP connection to the recursive resolver. Alternatively they may TCP connection to the recursive resolver. Alternatively they may
prefer to use UDP to a DNS-over-TLS enabled caching resolver on the prefer to use UDP to a DNS-over-TLS enabled caching resolver on the
same machine that then uses a system-wide TCP connection to the same machine that then uses a system-wide TCP connection to the
recursive resolver. recursive resolver.
In order to amortize TCP and TLS connection setup costs, clients and In order to amortize TCP and TLS connection setup costs, clients and
servers SHOULD NOT immediately close a connection after each servers SHOULD NOT immediately close a connection after each
response. Instead, clients and servers SHOULD reuse existing response. Instead, clients and servers SHOULD reuse existing
connections for subsequent queries as long as they have sufficient connections for subsequent queries as long as they have sufficient
skipping to change at page 8, line 39 skipping to change at page 7, line 39
4.1. Opportunistic Privacy Profile 4.1. Opportunistic Privacy Profile
For opportunistic privacy, analogous to SMTP opportunistic security For opportunistic privacy, analogous to SMTP opportunistic security
[RFC7435], one does not require privacy, but one desires privacy when [RFC7435], one does not require privacy, but one desires privacy when
possible. possible.
With opportunistic privacy, a client might learn of a TLS-enabled With opportunistic privacy, a client might learn of a TLS-enabled
recursive DNS resolver from an untrusted source (such as DHCP's DNS recursive DNS resolver from an untrusted source (such as DHCP's DNS
server option [RFC3646] to discover the IP address followed by server option [RFC3646] to discover the IP address followed by
attemting the DNS-over-TLS on port 853, or with a future DHCP option attemting the DNS-over-TLS on port 853, or with a future DHCP option
that specifics DNS port). With such an discovered DNS server, the that specifies DNS port). With such a discovered DNS server, the
client might or might not validate the resolver. These choices client might or might not validate the resolver. These choices
maximize availability and performance, but they leave the client maximize availability and performance, but they leave the client
vulnerable to on-path attacks that remove privacy. vulnerable to on-path attacks that remove privacy.
Opportunistic privacy can be used by any current client, but it only Opportunistic privacy can be used by any current client, but it only
provides privacy when there are no on-path active attackers. provides privacy when there are no on-path active attackers.
4.2. Out-of-band Key-pinned Privacy Profile 4.2. Out-of-band Key-pinned Privacy Profile
The out-of-band key-pinned privacy profile can be used in The out-of-band key-pinned privacy profile can be used in
skipping to change at page 11, line 43 skipping to change at page 10, line 43
The TEMPORARY assignment expires 2016-10-08. IANA is requested to The TEMPORARY assignment expires 2016-10-08. IANA is requested to
make the assigmnent permanent upon publication of this document as an make the assigmnent permanent upon publication of this document as an
RFC. RFC.
7. Design Evolution 7. Design Evolution
[Note to RFC Editor: please do not remove this section as it may be [Note to RFC Editor: please do not remove this section as it may be
useful to future Foo-over-TLS efforts] useful to future Foo-over-TLS efforts]
Earlier versions of this document proposed an upgrade-based approach Earlier versions of this document proposed an upgrade-based approach
to establishing a TLS session. The client would signal its interest to establish a TLS session. The client would signal its interest in
in TLS by setting a "TLS OK" bit in the EDNS0 flags field. A server TLS by setting a "TLS OK" bit in the EDNS0 flags field. A server
would signal its acceptance by responding with the TLS OK bit set. would signal its acceptance by responding with the TLS OK bit set.
Since we assume the client doesn't want to reveal (leak) any Since we assume the client doesn't want to reveal (leak) any
information prior to securing the channel, we proposed the use of a information prior to securing the channel, we proposed the use of a
"dummy query" that clients could send for this purpose. The proposed "dummy query" that clients could send for this purpose. The proposed
query name was STARTTLS, query type TXT, and query class CH. query name was STARTTLS, query type TXT, and query class CH.
The TLS OK signaling approach has both advantages and disadvantages. The TLS OK signaling approach has both advantages and disadvantages.
One important advantage is that clients and servers could negotiate One important advantage is that clients and servers could negotiate
TLS. If the server is too busy, or doesn't want to provide TLS TLS. If the server is too busy, or doesn't want to provide TLS
skipping to change at page 13, line 22 skipping to change at page 12, line 21
The Unbound recursive name server software added support for DNS- The Unbound recursive name server software added support for DNS-
over-TLS in version 1.4.14. The unbound.conf configuration file has over-TLS in version 1.4.14. The unbound.conf configuration file has
the following configuration directives: ssl-port, ssl-service-key, the following configuration directives: ssl-port, ssl-service-key,
ssl-service-pem, ssl-upstream. See ssl-service-pem, ssl-upstream. See
https://unbound.net/documentation/unbound.conf.html. https://unbound.net/documentation/unbound.conf.html.
8.2. ldns 8.2. ldns
Sinodun Internet Technologies has implemented DNS-over-TLS in the Sinodun Internet Technologies has implemented DNS-over-TLS in the
ldns library from NLnetLabs. This also gives DNS-over-TLS support to ldns library from NLnetLabs. This also gives DNS-over-TLS support to
the drill DNS client program. Patches available at https:// the drill DNS client program. Patches available at
portal.sinodun.com/stash/projects/TDNS/repos/dns-over-tls_patches/ https://portal.sinodun.com/stash/projects/TDNS/repos/dns-over-
browse. tls_patches/browse.
8.3. digit 8.3. digit
The digit DNS client from USC/ISI supports DNS-over-TLS. Source code The digit DNS client from USC/ISI supports DNS-over-TLS. Source code
available at http://www.isi.edu/ant/software/tdns/index.html. available at http://www.isi.edu/ant/software/tdns/index.html.
8.4. getdns 8.4. getdns
The getdns API implementation supports DNS-over-TLS. Source code The getdns API implementation supports DNS-over-TLS. Source code
available at https://getdnsapi.net. available at https://getdnsapi.net.
skipping to change at page 15, line 30 skipping to change at page 14, line 30
11. Acknowledgments 11. Acknowledgments
The authors would like to thank Stephane Bortzmeyer, John Dickinson, The authors would like to thank Stephane Bortzmeyer, John Dickinson,
Brian Haberman, Christian Huitema, Shumon Huque, Kim-Minh Kaplan, Brian Haberman, Christian Huitema, Shumon Huque, Kim-Minh Kaplan,
Simon Joseffson, Simon Kelley, Warren Kumari, John Levine, Ilari Simon Joseffson, Simon Kelley, Warren Kumari, John Levine, Ilari
Liusvaara, Bill Manning, George Michaelson, Eric Osterweil, Jinmei Liusvaara, Bill Manning, George Michaelson, Eric Osterweil, Jinmei
Tatuya, Tim Wicinski, and Glen Wiley for reviewing this Internet- Tatuya, Tim Wicinski, and Glen Wiley for reviewing this Internet-
draft. They also thank Nikita Somaiya for early work on this idea. draft. They also thank Nikita Somaiya for early work on this idea.
Work by Zi Hu, Liang Zhu, and John Heidemann on this document is Work by Zi Hu, Liang Zhu, and John Heidemann on this document is
partially sponsored by the U.S. Dept. of Homeland Security (DHS) partially sponsored by the U.S. Dept. of Homeland Security (DHS)
Science and Technology Directorate, HSARPA, Cyber Security Division, Science and Technology Directorate, HSARPA, Cyber Security Division,
BAA 11-01-RIKA and Air Force Research Laboratory, Information BAA 11-01-RIKA and Air Force Research Laboratory, Information
Directorate under agreement number FA8750-12-2-0344, and contract Directorate under agreement number FA8750-12-2-0344, and contract
number D08PC75599. number D08PC75599.
12. References 12. References
12.1. Normative References 12.1. Normative References
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, [BCP195] 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, DOI 10.17487/RFC7525, (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
May 2015. 2015.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>. <http://www.rfc-editor.org/info/rfc4648>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <http://www.rfc-editor.org/info/rfc5077>. January 2008, <http://www.rfc-editor.org/info/rfc5077>.
[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, DOI 10.17487/ (TLS) Protocol Version 1.2", RFC 5246,
RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<http://www.rfc-editor.org/info/rfc6234>. <http://www.rfc-editor.org/info/rfc6234>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>. <http://www.rfc-editor.org/info/rfc6335>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
January 2014, <http://www.rfc-editor.org/info/rfc7120>. 2014, <http://www.rfc-editor.org/info/rfc7120>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
April 2015, <http://www.rfc-editor.org/info/rfc7469>. 2015, <http://www.rfc-editor.org/info/rfc7469>.
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<http://www.rfc-editor.org/info/rfc7766>. <http://www.rfc-editor.org/info/rfc7766>.
12.2. Informative References 12.2. Informative References
[dempsky-dnscurve]
Dempsky, M., "DNSCurve", draft-dempsky-dnscurve-01 (work
in progress), August 2010,
<http://tools.ietf.org/html/draft-dempsky-dnscurve-01>.
[dgr-dprive-dtls-and-tls-profiles]
Dickinson, S., Gillmor, D., and T. Reddy, "Authentication
and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS",
draft-dgr-dprive-dtls-and-tls-profiles-00 (work in
progress), December 2015, <https://tools.ietf.org/html/
draft-dgr-dprive-dtls-and-tls-profiles-00>.
[dnscrypt-website]
Denis, F., "DNSCrypt", December 2015,
<https://www.dnscrypt.org/>.
[dnssec-trigger]
NLnet Labs, "Dnssec-Trigger", May 2014,
<https://www.nlnetlabs.nl/projects/dnssec-trigger/>.
[draft-ietf-dprive-dnsodtls]
Reddy, T., Wing, D., and P. Patil, "DNS over DTLS
(DNSoD)", draft-ietf-dprive-dnsodtls-01 (work in
progress), June 2015, <https://tools.ietf.org/html/draft-
ietf-dprive-dnsodtls-01>.
[draft-ietf-tls-falsestart]
Moeller, B., Langley, A., and N. Modadugu, "Transport
Layer Security (TLS) False Start", draft-ietf-tls-
falsestart-01 (work in progress), November 2015,
<http://tools.ietf.org/html/draft-ietf-tls-falsestart-01>.
[I-D.confidentialdns] [I-D.confidentialdns]
Wijngaards, W., "Confidential DNS", Wijngaards, W., "Confidential DNS", draft-wijngaards-
draft-wijngaards-dnsop-confidentialdns-03 (work in dnsop-confidentialdns-03 (work in progress), March 2015,
progress), March 2015, <http://tools.ietf.org/html/ <http://tools.ietf.org/html/
draft-wijngaards-dnsop-confidentialdns-03>. draft-wijngaards-dnsop-confidentialdns-03>.
[I-D.edns-tcp-keepalive] [I-D.edns-tcp-keepalive]
Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
edns-tcp-keepalive EDNS0 Option", edns-tcp-keepalive EDNS0 Option", draft-ietf-dnsop-edns-
draft-ietf-dnsop-edns-tcp-keepalive-02 (work in progress), tcp-keepalive-02 (work in progress), July 2015,
July 2015, <http://tools.ietf.org/html/ <http://tools.ietf.org/html/
draft-ietf-dnsop-edns-tcp-keepalive-02>. draft-ietf-dnsop-edns-tcp-keepalive-02>.
[I-D.edns0-padding] [I-D.edns0-padding]
Mayrhofer, A., "The EDNS(0) Padding Option", Mayrhofer, A., "The EDNS(0) Padding Option", draft-
draft-mayrhofer-edns0-padding-01 (work in progress), mayrhofer-edns0-padding-01 (work in progress), August
August 2015, <http://tools.ietf.org/html/ 2015, <http://tools.ietf.org/html/
draft-mayrhofer-edns0-padding-01>. draft-mayrhofer-edns0-padding-01>.
[I-D.ipseca] [I-D.ipseca]
Osterweil, E., Wiley, G., Okubo, T., Lavu, R., and A. Osterweil, E., Wiley, G., Okubo, T., Lavu, R., and A.
Mohaisen, "Opportunistic Encryption with DANE Semantics Mohaisen, "Opportunistic Encryption with DANE Semantics
and IPsec: IPSECA", draft-osterweil-dane-ipsec-03 (work in and IPsec: IPSECA", draft-osterweil-dane-ipsec-03 (work in
progress), July 2015, progress), July 2015, <http://tools.ietf.org/html/
<http://tools.ietf.org/html/
draft-osterweil-dane-ipsec-03>. draft-osterweil-dane-ipsec-03>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>. <http://www.rfc-editor.org/info/rfc2818>.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
<http://www.rfc-editor.org/info/rfc3234>. <http://www.rfc-editor.org/info/rfc3234>.
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic
Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
DOI 10.17487/RFC3646, December 2003, DOI 10.17487/RFC3646, December 2003,
<http://www.rfc-editor.org/info/rfc3646>. <http://www.rfc-editor.org/info/rfc3646>.
skipping to change at page 18, line 11 skipping to change at page 17, line 44
<http://www.rfc-editor.org/info/rfc4033>. <http://www.rfc-editor.org/info/rfc4033>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <http://www.rfc-editor.org/info/rfc5280>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
August 2012, <http://www.rfc-editor.org/info/rfc6698>. 2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
May 2014, <http://www.rfc-editor.org/info/rfc7258>. 2014, <http://www.rfc-editor.org/info/rfc7258>.
[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, DOI 10.17487/RFC7413, December 2014, Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<http://www.rfc-editor.org/info/rfc7413>. <http://www.rfc-editor.org/info/rfc7413>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <http://www.rfc-editor.org/info/rfc7435>. December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015, DOI 10.17487/RFC7626, August 2015,
<http://www.rfc-editor.org/info/rfc7626>. <http://www.rfc-editor.org/info/rfc7626>.
[dempsky-dnscurve]
Dempsky, M., "DNSCurve", draft-dempsky-dnscurve-01 (work
in progress), August 2010,
<http://tools.ietf.org/html/draft-dempsky-dnscurve-01>.
[dgr-dprive-dtls-and-tls-profiles]
Dickinson, S., Gillmor, D., and T. Reddy,
"Authentication and (D)TLS Profile for DNS-over-TLS and
DNS-over-DTLS", draft-dgr-dprive-dtls-and-tls-profiles-00
(work in progress), December 2015, <https://
tools.ietf.org/html/
draft-dgr-dprive-dtls-and-tls-profiles-00>.
[dnscrypt-website]
Denis, F., "DNSCrypt", December 2015,
<https://www.dnscrypt.org/>.
[dnssec-trigger]
NLnet Labs, "Dnssec-Trigger", May 2014,
<https://www.nlnetlabs.nl/projects/dnssec-trigger/>.
[draft-ietf-dprive-dnsodtls]
Reddy, T., Wing, D., and P. Patil, "DNS over DTLS
(DNSoD)", draft-ietf-dprive-dnsodtls-01 (work in
progress), June 2015, <https://tools.ietf.org/html/
draft-ietf-dprive-dnsodtls-01>.
[draft-ietf-tls-falsestart]
Moeller, B., Langley, A., and N. Modadugu, "Transport
Layer Security (TLS) False Start",
draft-ietf-tls-falsestart-01 (work in progress),
November 2015,
<http://tools.ietf.org/html/draft-ietf-tls-falsestart-01>.
[tdns] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A., [tdns] Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A.,
and N. Somaiya, "T-DNS: Connection-Oriented DNS to Improve and N. Somaiya, "T-DNS: Connection-Oriented DNS to Improve
Privacy and Security", Technical report ISI-TR-688, Privacy and Security", Technical report ISI-TR-688,
February 2014, <Technical report, ISI-TR-688, February 2014, <Technical report, ISI-TR-688,
ftp://ftp.isi.edu/isi-pubs/tr-688.pdf>. ftp://ftp.isi.edu/isi-pubs/tr-688.pdf>.
Appendix A. Out-of-band Key-pinned Privacy Profile Example Appendix A. Out-of-band Key-pinned Privacy Profile Example
This section presents an example of how the out-of-band key-pinned This section presents an example of how the out-of-band key-pinned
privacy profile could work in practice based on a minimal pinset (two privacy profile could work in practice based on a minimal pinset (two
skipping to change at page 20, line 4 skipping to change at page 18, line 52
The server sends a Certificate message with a list of three The server sends a Certificate message with a list of three
certificates (A, B, and C), and signs the ServerKeyExchange message certificates (A, B, and C), and signs the ServerKeyExchange message
correctly with the public key found certificate A. correctly with the public key found certificate A.
The client now takes the SHA-256 digest of the SPKI in cert A, and The client now takes the SHA-256 digest of the SPKI in cert A, and
compares it against both pins in the pinset. If either pin matches, compares it against both pins in the pinset. If either pin matches,
the verification is successful; the client continues with the TLS the verification is successful; the client continues with the TLS
connection and can make its first DNS query. connection and can make its first DNS query.
If neither pin matches the SPKI of cert A, the client verifies that If neither pin matches the SPKI of cert A, the client verifies that
cert A is actually issued by cert B. If it is, it takes the SHA-256 cert A is actually issued by cert B. If it is, it takes the SHA-256
digest of the SPKI in cert B and compares it against both pins in the digest of the SPKI in cert B and compares it against both pins in the
pinset. If either pin matches, the verification is successful. pinset. If either pin matches, the verification is successful.
Otherwise, it verifes that B was issued by C, and then compares the Otherwise, it verifes that B was issued by C, and then compares the
pins against the digest of C's SPKI. pins against the digest of C's SPKI.
If none of the SPKIs in the cryptographically-valid chain of certs If none of the SPKIs in the cryptographically-valid chain of certs
match any pin in the pinset, the client closes the connection with an match any pin in the pinset, the client closes the connection with an
error, and marks the IP address as failed. error, and marks the IP address as failed.
Authors' Addresses Authors' Addresses
Zi Hu Zi Hu
USC/Information Sciences Institute USC/Information Sciences Institute
4676 Admiralty Way, Suite 1133 4676 Admiralty Way, Suite 1133
Marina del Rey, CA 90292 Marina del Rey, CA 90292
United States United States
Phone: +1 213 587 1057 Phone: +1 213 587 1057
Email: zihu@usc.edu Email: zihu@outlook.com
Liang Zhu Liang Zhu
USC/Information Sciences Institute USC/Information Sciences Institute
4676 Admiralty Way, Suite 1133 4676 Admiralty Way, Suite 1133
Marina del Rey, CA 90292 Marina del Rey, CA 90292
United States United States
Phone: +1 310 448 8323 Phone: +1 310 448 8323
Email: liangzhu@usc.edu Email: liangzhu@usc.edu
 End of changes. 31 change blocks. 
123 lines changed or deleted 117 lines changed or added

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