< draft-ietf-dprive-dns-over-tls-07.txt   draft-ietf-dprive-dns-over-tls-08.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 2, 2016 USC/Information Sciences Expires: September 16, 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 1, 2016 March 15, 2016
Specification for DNS over TLS Specification for DNS over TLS
draft-ietf-dprive-dns-over-tls-07 draft-ietf-dprive-dns-over-tls-08
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 [RFC7258]. 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-for-dns. Its name has been changed to draft-ietf-dprive-start-tls-for-dns. Its name has been changed to
better describe the mechanism now used. Please refer to working better describe the mechanism now used. Please refer to working
skipping to change at page 2, line 8 skipping to change at page 2, line 8
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 2, 2016. This Internet-Draft will expire on September 16, 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
skipping to change at page 3, line 17 skipping to change at page 3, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Establishing and Managing DNS-over-TLS Sessions . . . . . . . 5 3. Establishing and Managing DNS-over-TLS Sessions . . . . . . . 5
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 5 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 5
3.2. TLS Handshake and Authentication . . . . . . . . . . . . . 6 3.2. TLS Handshake and Authentication . . . . . . . . . . . . . 6
3.3. Transmitting and Receiving Messages . . . . . . . . . . . 6 3.3. Transmitting and Receiving Messages . . . . . . . . . . . 6
3.4. Connection Reuse, Close and Reestablishment . . . . . . . 7 3.4. Connection Reuse, Close and Reestablishment . . . . . . . 7
4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 8 4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 8
4.2. Out-of-band Key-pinned Privacy Profile . . . . . . . . . . 8 4.2. Out-of-band Key-pinned Privacy Profile . . . . . . . . . . 8
5. Performance Considerations . . . . . . . . . . . . . . . . . . 9 5. Performance Considerations . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . . 11 7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . . 11
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 12
8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 14 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Out-of-band Key-pinned Privacy Profile Example . . . 18 Appendix A. Out-of-band Key-pinned Privacy Profile Example . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
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 4, line 29 skipping to change at page 4, line 29
replies are correct. By intention, DNSSEC does not protect request replies are correct. By intention, DNSSEC does not protect request
and response privacy. Traditionally, either privacy was not and response privacy. Traditionally, either privacy was not
considered a requirement for DNS traffic, or it was assumed that considered a requirement for DNS traffic, or it was assumed that
network traffic was sufficiently private, however these perceptions network traffic was sufficiently private, however these perceptions
are evolving due to recent events [RFC7258]. are evolving due to recent events [RFC7258].
Other work that has offered the potential to encrypt between DNS Other work that has offered the potential to encrypt between DNS
clients and servers includes DNSCurve [dempsky-dnscurve], DNSCrypt clients and servers includes DNSCurve [dempsky-dnscurve], DNSCrypt
[dnscrypt-website], ConfidentialDNS [I-D.confidentialdns] and IPSECA [dnscrypt-website], ConfidentialDNS [I-D.confidentialdns] and IPSECA
[I-D.ipseca]. In addition to the present draft, the DPRIVE working [I-D.ipseca]. In addition to the present draft, the DPRIVE working
group has recently adopted a DNS-over-DTLS group has also adopted a DNS-over-DTLS [draft-ietf-dprive-dnsodtls]
[draft-ietf-dprive-dnsodtls] proposal. proposal.
This document describes using DNS-over-TLS on a well-known port and This document describes using DNS-over-TLS on a well-known port and
also offers advice on performance considerations to minimize also offers advice on performance considerations to minimize
overheads from using TCP and TLS with DNS. overheads from using TCP and TLS with DNS.
Initiation of DNS-over-TLS is very straightforward. By establishing Initiation of DNS-over-TLS is very straightforward. By establishing
a connection over a well-known port, clients and servers expect and a connection over a well-known port, clients and servers expect and
agree to negotiate a TLS session to secure the channel. Deployment agree to negotiate a TLS session to secure the channel. Deployment
will be gradual. Not all servers will support DNS-over-TLS and the will be gradual. Not all servers will support DNS-over-TLS and the
well-known port might be blocked by some firewalls. Clients will be well-known port might be blocked by some firewalls. Clients will be
expected to keep track of servers that support TLS and those that expected to keep track of servers that support TLS and those that
don't. Clients and servers will adhere to the TLS implementation don't. Clients and servers will adhere to the TLS implementation
recommendations and security considerations of [RFC7525] or its recommendations and security considerations of [BCP195].
successor.
The protocol described here works for queries and responses between The protocol described here works for queries and responses between
stub clients and recursive servers. It might work equally between stub clients and recursive servers. It might work equally between
recursive clients and authoritative servers, but this application of recursive clients and authoritative servers, but this application of
the protocol is out of scope for the DNS PRIVate Exchange (DPRIVE) the protocol is out of scope for the DNS PRIVate Exchange (DPRIVE)
Working Group per its current charter. Working Group per its current charter.
This document describes two profiles in Section 4 providing different This document describes two profiles in Section 4 providing different
levels of assurance of privacy: an opportunistic privacy profile and levels of assurance of privacy: an opportunistic privacy profile and
an out-of-band key-pinned privacy profile. It is expected that a an out-of-band key-pinned privacy profile. It is expected that a
skipping to change at page 5, line 28 skipping to change at page 5, line 27
2. Reserved Words 2. Reserved Words
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 listen for and accept A DNS server that supports DNS-over-TLS MUST by default listen for
TCP connections on port 853. By mutual agreement with its clients, and accept TCP connections on port 853. By mutual agreement with its
the server MAY, instead, use a port other than 853 for DNS-over-TLS. clients, the server MAY, instead, use a port other than 853 for DNS-
over-TLS. In order to use a port other than 853, both clients and
servers 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 establish a TCP connection to port 853 on the server. By server MUST by default establish a TCP connection to port 853 on the
mutual agreement with its server, the client MAY, instead, use a port server. By mutual agreement with its server, the client MAY,
other than port 853 for DNS-over-TLS. Such an other port MUST NOT be instead, use a port other than port 853 for DNS-over-TLS. Such an
port 53, but MAY be from the "first-come, first-served" port range. other port MUST NOT be port 53, but MAY be from the "first-come,
The first data exchange on this TCP connection MUST be the client and first-served" port range. This recommendation against use of port 53
server initiating a TLS handshake using the procedure described in for DNS-over-TLS is to avoid complication in selecting use or non-use
of TLS, and to reduce risk of downgrade attacks. The first data
exchange on this TCP connection MUST be the client and server
initiating a TLS handshake 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 16 skipping to change at page 6, line 19
DNS-over-TLS, including timeouts, connection refusals, and TLS DNS-over-TLS, including timeouts, connection refusals, and TLS
handshake failures, and not request DNS-over-TLS from them for a handshake failures, and not request DNS-over-TLS from them for a
reasonable period (such as one hour per server). DNS clients reasonable period (such as one hour per server). DNS clients
following an out-of-band key-pinned privacy profile (Section 4.2) MAY following an out-of-band key-pinned privacy profile (Section 4.2) MAY
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 [RFC7525] or its successor. 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 to require authentication of the server, or it may make use of a
trusted a 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. At this point, normal DNS is now protected from eavesdropping.
queries SHOULD take place.
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
[RFC1035]. For reasons of efficiency, DNS clients and servers SHOULD [RFC1035]. For reasons of efficiency, DNS clients and servers SHOULD
pass the two-octet length field, and the message described by that pass the two-octet length field, and the message described by that
length field, to the TCP layer at the same time (e.g., in a single length field, to the TCP layer at the same time (e.g., in a single
"write" system call) to make it more likely that all the data will be "write" system call) to make it more likely that all the data will be
transmitted in a single TCP segment ([I-D.ietf-dnsop-5966bis], transmitted in a single TCP segment ([RFC7766], Section 8).
Section 8).
In order to minimize latency, clients SHOULD pipeline multiple In order to minimize latency, clients SHOULD pipeline multiple
queries over a TLS session. When a DNS client sends multiple queries queries over a TLS session. When a DNS client sends multiple queries
to a server, it should not wait for an outstanding reply before to a server, it should not wait for an outstanding reply before
sending the next query ([I-D.ietf-dnsop-5966bis], Section 6.2.1.1). sending the next query ([RFC7766], Section 6.2.1.1).
Since pipelined responses can arrive out-of-order, clients MUST match Since pipelined responses can arrive out of order, clients MUST match
responses to outstanding queries using the ID field, query name, responses to outstanding queries on the same TLS connection using the
type, and class. Failure by clients to properly match responses to Message ID. If the response contains a question section, the client
outstanding queries can have serious consequences for MUST match the QNAME, QCLASS, and QTYPE fields. Failure by clients
interoperability ([I-D.ietf-dnsop-5966bis], Section 7). to properly match responses to outstanding queries can have serious
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 each DNS call. 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
skipping to change at page 7, line 26 skipping to change at page 7, line 26
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
resources. In some cases, this means that clients and servers may resources. In some cases, this means that clients and servers may
need to keep idle connections open for some amount of time. need to keep idle connections open for some amount of time.
Proper management of established and idle connections is important to Proper management of established and idle connections is important to
the healthy operation of a DNS server. An implementor of DNS-over- the healthy operation of a DNS server. An implementor of DNS-over-
TLS SHOULD follow best practices for DNS-over-TCP, as described in TLS SHOULD follow best practices for DNS-over-TCP, as described in
[I-D.ietf-dnsop-5966bis]. Failure to do so may lead to resource [RFC7766]. Failure to do so may lead to resource exhaustion and
exhaustion and denial-of-service. denial-of-service.
Whereas client and server implementations from the [RFC1035] era are Whereas client and server implementations from the [RFC1035] era are
known to have poor TCP connection management, this document known to have poor TCP connection management, this document
stipulates that successful negotiation of TLS indicates the stipulates that successful negotiation of TLS indicates the
willingness of both parties to keep idle DNS connections open, willingness of both parties to keep idle DNS connections open,
independent of timeouts or other recommendations for DNS-over-TCP independent of timeouts or other recommendations for DNS-over-TCP
without TLS. In other words, software implementing this protocol is without TLS. In other words, software implementing this protocol is
assumed to support idle, persistent connections and be prepared to assumed to support idle, persistent connections and be prepared to
manage multiple, potentially long-lived TCP connections. manage multiple, potentially long-lived TCP connections.
skipping to change at page 8, line 6 skipping to change at page 8, line 6
values [I-D.edns-tcp-keepalive] [tdns]. values [I-D.edns-tcp-keepalive] [tdns].
Clients and servers that keep idle connections open MUST be robust to Clients and servers that keep idle connections open MUST be robust to
termination of idle connection by either party. As with current DNS- termination of idle connection by either party. As with current DNS-
over-TCP, DNS servers MAY close the connection at any time (perhaps over-TCP, DNS servers MAY close the connection at any time (perhaps
due to resource constraints). As with current DNS-over-TCP, clients due to resource constraints). As with current DNS-over-TCP, clients
MUST handle abrupt closes and be prepared to reestablish connections MUST handle abrupt closes and be prepared to reestablish connections
and/or retry queries. and/or retry queries.
When reestablishing a DNS-over-TCP connection that was terminated, as When reestablishing a DNS-over-TCP connection that was terminated, as
discussed in [I-D.ietf-dnsop-5966bis], TCP Fast Open [RFC7413] is of discussed in [RFC7766], TCP Fast Open [RFC7413] is of benefit.
benefit. Underlining the requirement for sending only encrypted DNS Underlining the requirement for sending only encrypted DNS data on a
data on a DNS-over-TLS port (Section 3.2), when using TCP Fast Open DNS-over-TLS port (Section 3.2), when using TCP Fast Open the client
the client and server MUST immediately initiate or resume a TLS and server MUST immediately initiate or resume a TLS handshake (clear
handshake (clear text DNS MUST NOT be exchanged). DNS servers SHOULD text DNS MUST NOT be exchanged). DNS servers SHOULD enable fast TLS
enable fast TLS session resumption [RFC5077] and this SHOULD be used session resumption [RFC5077] and this SHOULD be used when
when reestablishing connections. reestablishing connections.
When closing a connection, DNS servers SHOULD use the TLS close- When closing a connection, DNS servers SHOULD use the TLS close-
notify request to shift TCP TIME-WAIT state to the clients. notify request to shift TCP TIME-WAIT state to the clients.
Additional requirements and guidance for optimizing DNS-over-TCP are Additional requirements and guidance for optimizing DNS-over-TCP are
provided by [RFC5966], [I-D.ietf-dnsop-5966bis]. provided by [RFC7766].
4. Usage Profiles 4. Usage Profiles
This protocol provides flexibility to accommodate several different This protocol provides flexibility to accommodate several different
use cases. This document defines two usage profiles: (1) use cases. This document defines two usage profiles: (1)
opportunistic privacy, and (2) out-of-band key-pinned authentication opportunistic privacy, and (2) out-of-band key-pinned authentication
that can be used to obtain stronger privacy guarantees if the client that can be used to obtain stronger privacy guarantees if the client
has a trusted relationship with a DNS server supporting TLS. has a trusted relationship with a DNS server supporting TLS.
Additional methods of authentication will be defined in a forthcoming Additional methods of authentication will be defined in a forthcoming
draft [dgr-dprive-dtls-and-tls-profiles]. draft [dgr-dprive-dtls-and-tls-profiles].
4.1. Opportunistic Privacy Profile 4.1. Opportunistic Privacy Profile
For opportunistic privacy, analogous to SMTP opportunistic encryption 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 while recursive DNS resolver from an untrusted source (such as DHCP's DNS
roaming), it might or might not validate the resolver. These choices server option [RFC3646] to discover the IP address followed by
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
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 guaranteed privacy when there are no on-path active provides privacy when there are no on-path active attackers.
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
environments where an established trust relationship already exists environments where an established trust relationship already exists
between DNS clients and servers (e.g., stub-to-recursive in between DNS clients and servers (e.g., stub-to-recursive in
enterprise networks, actively-maintained contractual service enterprise networks, actively-maintained contractual service
relationships, or a client using a public DNS resolver). The result relationships, or a client using a public DNS resolver). The result
of this profile is that the client has strong guarantees about the of this profile is that the client has strong guarantees about the
privacy of its DNS data by connecting only to servers it can privacy of its DNS data by connecting only to servers it can
authenticate. authenticate. Operators of a DNS-over-TLS service in this profile
are expected to provide pins that are specific to the service being
pinned (i.e., public keys belonging directly to the end-entity or to
a service-specific private CA) and not to public key(s) of a generic
public CA.
In this profile, clients authenticate servers by matching a set of In this profile, clients authenticate servers by matching a set of
Subject Public Key Info (SPKI) Fingerprints in an analogous manner to Subject Public Key Info (SPKI) Fingerprints in an analogous manner to
that described in [RFC7469]. With this out-of-band key-pinned that described in [RFC7469]. With this out-of-band key-pinned
privacy profile, client administrators SHOULD deploy a backup pin privacy profile, client administrators SHOULD deploy a backup pin
along with the primary pin, for the reasons explained in [RFC7469]. along with the primary pin, for the reasons explained in [RFC7469].
A backup pin is especially helpful in the event of a key rollover, so A backup pin is especially helpful in the event of a key rollover, so
that a server operator does not have to coordinate key transitions that a server operator does not have to coordinate key transitions
with all its clients simultaneously. After a change of keys on the with all its clients simultaneously. After a change of keys on the
server, an updated pinset SHOULD be distributed to all clients in server, an updated pinset SHOULD be distributed to all clients in
skipping to change at page 9, line 32 skipping to change at page 9, line 38
pinset has been provided. The possession of trusted pre-deployed pinset has been provided. The possession of trusted pre-deployed
pinset allows the client to detect and prevent person-in-the-middle pinset allows the client to detect and prevent person-in-the-middle
and downgrade attacks. and downgrade attacks.
However, a configured DNS server may be temporarily unavailable when However, a configured DNS server may be temporarily unavailable when
configuring a network. For example, for clients on networks that configuring a network. For example, for clients on networks that
require authentication through web-based login, such authentication require authentication through web-based login, such authentication
may rely on DNS interception and spoofing. Techniques such as those may rely on DNS interception and spoofing. Techniques such as those
used by DNSSEC-trigger [dnssec-trigger] MAY be used during network used by DNSSEC-trigger [dnssec-trigger] MAY be used during network
configuration, with the intent to transition to the designated DNS configuration, with the intent to transition to the designated DNS
provider after authentication. The user MUST be alerted that the DNS provider after authentication. The user MUST be alerted whenever
is not private during such bootstrap. possible that the DNS is not private during such bootstrap.
Upon successful TLS connection and handshake, the client computes the Upon successful TLS connection and handshake, the client computes the
SPKI Fingerprints for the public keys found in the validated server's SPKI Fingerprints for the public keys found in the validated server's
certificate chain (or in the raw public key, if the server provides certificate chain (or in the raw public key, if the server provides
that instead). If a computed fingerprint exactly matches one of the that instead). If a computed fingerprint exactly matches one of the
configured pins the client continues with the connection as normal. configured pins the client continues with the connection as normal.
Otherwise, the client MUST treat the SPKI validation failure as a Otherwise, the client MUST treat the SPKI validation failure as a
non-recoverable error. Appendix A provides a detailed example of how non-recoverable error. Appendix A provides a detailed example of how
this authentication could be performed in practice. this authentication could be performed in practice.
Implementations of this privacy profile MUST support the calculation
of a fingerprint as the SHA-256 [RFC6234] hash of the DER-encoded
ASN.1 representation of the Subject Public Key Info (SPKI) of an
X.509 certificate. Implementations MUST support the representation
of a SHA-256 fingerprint as a base 64 encoded character string
[RFC4648]. Additional fingerprint types MAY also be supported.
5. Performance Considerations 5. Performance Considerations
DNS-over-TLS incurs additional latency at session startup. It also DNS-over-TLS incurs additional latency at session startup. It also
requires additional state (memory) and increased processing (CPU). requires additional state (memory) and increased processing (CPU).
1. Latency: Compared to UDP, DNS-over-TCP requires an additional Latency: Compared to UDP, DNS-over-TCP requires an additional round-
round-trip-time (RTT) of latency to establish a TCP connection. trip-time (RTT) of latency to establish a TCP connection. TCP
Fast Open [RFC7413] can eliminate that RTT when information exists
from prior connections. The TLS handshake adds another two RTTs
of latency. Clients and servers should support connection
keepalive (reuse) and out of order processing to amortize
connection setup costs. Fast TLS connection resumption [RFC5077]
further reduces the setup delay and avoids the DNS server keeping
per-client session state.
TCP Fast Open [RFC7413] can eliminate that RTT when information TLS False Start [draft-ietf-tls-falsestart] can also lead to a
exists from prior connections. The TLS handshake adds another latency reduction in certain situations. Implementations
two RTTs of latency. Clients and servers should support supporting TLS false start need to be aware that it imposes
connection keepalive (reuse) and out-of-order processing to additional constraints on how one uses TLS, over and above those
amortize connection setup costs. Fast TLS connection resumption stated in [BCP195]. It is unsafe to use false start if your
[RFC5077] further reduces the setup delay and avoids the DNS implementation and deployment does not adhere to these specific
server keeping per-client session state. TLS False Start requirements. See [draft-ietf-tls-falsestart] for the details of
[draft-ietf-tls-falsestart] can also lead to a latency reduction these additional constraints.
in certain situations.
2. State: The use of connection-oriented TCP requires keeping State: The use of connection-oriented TCP requires keeping
additional state at the server in both the kernel and additional state at the server in both the kernel and application.
application. The state requirements are of particular concern on The state requirements are of particular concern on servers with
servers with many clients, although memory-optimized TLS can add many clients, although memory-optimized TLS can add only modest
only modest state over TCP. Smaller timeout values will reduce state over TCP. Smaller timeout values will reduce the number of
the number of concurrent connections, and servers can concurrent connections, and servers can preemptively close
preemptively close connections when resource limits are exceeded. connections when resource limits are exceeded.
3. Processing: Use of TLS encryption algorithms results in slightly Processing: Use of TLS encryption algorithms results in slightly
higher CPU usage. Servers can choose to refuse new DNS-over-TLS higher CPU usage. Servers can choose to refuse new DNS-over-TLS
clients if processing limits are exceeded. clients if processing limits are exceeded.
4. Number of connections: To minimize state on DNS servers and Number of connections: To minimize state on DNS servers and
connection startup time, clients SHOULD minimize creation of new connection startup time, clients SHOULD minimize creation of new
TCP connections. Use of a local DNS request aggregator (a TCP connections. Use of a local DNS request aggregator (a
particular type of forwarder) allows a single active DNS-over-TLS particular type of forwarder) allows a single active DNS-over-TLS
connection from any given client computer to its server. connection from any given client computer to its server.
Additional guidance can be found in [I-D.ietf-dnsop-5966bis]. Additional guidance can be found in [RFC7766].
A full performance evaluation is outside the scope of this A full performance evaluation is outside the scope of this
specification. A more detailed analysis of the performance specification. A more detailed analysis of the performance
implications of DNS-over-TLS (and DNS-over-TCP) is discussed in implications of DNS-over-TLS (and DNS-over-TCP) is discussed in
[tdns] and [I-D.ietf-dnsop-5966bis]. [tdns] and [RFC7766].
6. IANA Considerations 6. IANA Considerations
IANA is requested to add the following value to the "Service Name and IANA is requested to add the following value to the "Service Name and
Transport Protocol Port Number Registry" registry in the System Transport Protocol Port Number Registry" registry in the System
Range. The registry for that range requires IETF Review or IESG Range. The registry for that range requires IETF Review or IESG
Approval [RFC6335] and such a review was requested using the Early Approval [RFC6335] and such a review was requested using the Early
Allocation process [RFC7120] for the well-known TCP port in this Allocation process [RFC7120] for the well-known TCP port in this
document. document.
skipping to change at page 11, line 20 skipping to change at page 11, line 39
Contact Paul Hoffman Contact Paul Hoffman
Description DNS query-response protocol run over TLS/DTLS Description DNS query-response protocol run over TLS/DTLS
Reference This document Reference This document
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 prior to [Note to RFC Editor: please do not remove this section as it may be
publication 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 establishing a TLS session. The client would signal its interest
in TLS by setting a "TLS OK" bit in the EDNS0 flags field. A server in 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.
skipping to change at page 13, line 29 skipping to change at page 13, line 48
Use of DNS-over-TLS is designed to address the privacy risks that Use of DNS-over-TLS is designed to address the privacy risks that
arise out of the ability to eavesdrop on DNS messages. It does not arise out of the ability to eavesdrop on DNS messages. It does not
address other security issues in DNS, and there are a number of address other security issues in DNS, and there are a number of
residual risks that may affect its success at protecting privacy: residual risks that may affect its success at protecting privacy:
1. There are known attacks on TLS, such as person-in-the-middle and 1. There are known attacks on TLS, such as person-in-the-middle and
protocol downgrade. These are general attacks on TLS and not protocol downgrade. These are general attacks on TLS and not
specific to DNS-over-TLS; please refer to the TLS RFCs for specific to DNS-over-TLS; please refer to the TLS RFCs for
discussion of these security issues. Clients and servers MUST discussion of these security issues. Clients and servers MUST
adhere to the TLS implementation recommendations and security adhere to the TLS implementation recommendations and security
considerations of [RFC7525] or its successor. DNS clients considerations of [BCP195]. DNS clients keeping track of servers
keeping track of servers known to support TLS enables clients to known to support TLS enables clients to detect downgrade attacks.
detect downgrade attacks. For servers with no connection history For servers with no connection history and no apparent support
and no apparent support for TLS, depending on their Privacy for TLS, depending on their Privacy Profile and privacy
Profile and privacy requirements, clients may choose to (a) try requirements, clients may choose to (a) try another server when
another server when available, (b) continue without TLS, or (c) available, (b) continue without TLS, or (c) refuse to forward the
refuse to forward the query. query.
2. Middleboxes [RFC3234] are present in some networks and have been 2. Middleboxes [RFC3234] are present in some networks and have been
known to interfere with normal DNS resolution. Use of a known to interfere with normal DNS resolution. Use of a
designated port for DNS-over-TLS should avoid such interference. designated port for DNS-over-TLS should avoid such interference.
In general, clients that attempt TLS and fail can either fall In general, clients that attempt TLS and fail can either fall
back on unencrypted DNS, or wait and retry later, depending on back on unencrypted DNS, or wait and retry later, depending on
their Privacy Profile and privacy requirements. their Privacy Profile and privacy requirements.
3. Any DNS protocol interactions performed in the clear can be 3. Any DNS protocol interactions performed in the clear can be
modified by a person-in-the-middle attacker. For example, modified by a person-in-the-middle attacker. For example,
unencrypted queries and responses might take place over port 53 unencrypted queries and responses might take place over port 53
between a client and server. For this reason, clients MAY between a client and server. For this reason, clients MAY
discard cached information about server capabilities advertised discard cached information about server capabilities advertised
in clear text. in clear text.
4. This document does not itself specify ideas to resist known 4. This document does not itself specify ideas to resist known
traffic analysis or side channel leaks. Even with encrypted traffic analysis or side channel leaks. Even with encrypted
messages, a well-positioned party may be able to glean certain messages, a well-positioned party may be able to glean certain
details from an analysis of message timings and sizes. Clients details from an analysis of message timings and sizes. Clients
and servers may consider the use of a padding method to address and servers may consider the use of a padding method to address
privacy leakage due to message sizes [I-D.edns0-padding] privacy leakage due to message sizes [I-D.edns0-padding]. Since
traffic analysis can be based on many kinds of patterns and many
kinds of classifiers, simple padding schemes alone might not be
sufficient to mitigate such an attack. Padding will, however,
form a part of more complex mitigations for traffic analysis
attacks that are likely to be developed over time. Implementers
who can offer flexibility in terms of how padding can be used may
be in a better position to enable such mitigations to be deployed
in future.
As noted earlier, DNSSEC and DNS-over-TLS are independent and fully
compatible protocols, each solving different problems. The use of
one does not diminish the need nor the usefulness of the other.
10. Contributing Authors 10. Contributing Authors
The below individuals contributed significantly to the draft. The The below individuals contributed significantly to the draft, and so
RFC Editor prefers a maximum of 5 names on the front page, and so we we have listed additional authors in this section.
have listed additional authors in this section.
Sara Dickinson Sara Dickinson
Sinodun Internet Technologies Sinodun Internet Technologies
Magdalen Centre Magdalen Centre
Oxford Science Park Oxford Science Park
Oxford OX4 4GA Oxford OX4 4GA
United Kingdom United Kingdom
Email: sara@sinodun.com Email: sara@sinodun.com
URI: http://sinodun.com URI: http://sinodun.com
skipping to change at page 15, line 4 skipping to change at page 15, line 37
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
[I-D.ietf-dnsop-5966bis] [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and "Recommendations for Secure Use of Transport Layer
D. Wessels, "DNS Transport over TCP - Implementation Security (TLS) and Datagram Transport Layer Security
Requirements", draft-ietf-dnsop-5966bis-02 (work in (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525,
progress), July 2015. May 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, DOI 10.17487/
RFC2119, March 1997, 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
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<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, DOI 10.17487/
RFC5246, August 2008, 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
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<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 2014, <http://www.rfc-editor.org/info/rfc7120>. January 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 2015, <http://www.rfc-editor.org/info/rfc7469>. April 2015, <http://www.rfc-editor.org/info/rfc7469>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
"Recommendations for Secure Use of Transport Layer D. Wessels, "DNS Transport over TCP - Implementation
Security (TLS) and Datagram Transport Layer Security Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, <http://www.rfc-editor.org/info/rfc7766>.
May 2015, <http://www.rfc-editor.org/info/rfc7525>.
12.2. Informative References 12.2. Informative References
[I-D.confidentialdns] [I-D.confidentialdns]
Wijngaards, W., "Confidential DNS", Wijngaards, W., "Confidential DNS",
draft-wijngaards-dnsop-confidentialdns-03 (work in draft-wijngaards-dnsop-confidentialdns-03 (work in
progress), March 2015, <http://tools.ietf.org/html/ progress), March 2015, <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]
skipping to change at page 16, line 45 skipping to change at page 17, line 42
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, DOI 10.17487/
RFC2818, May 2000, 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
Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
DOI 10.17487/RFC3646, December 2003,
<http://www.rfc-editor.org/info/rfc3646>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<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>.
[RFC5966] Bellis, R., "DNS Transport over TCP - Implementation
Requirements", RFC 5966, DOI 10.17487/RFC5966,
August 2010, <http://www.rfc-editor.org/info/rfc5966>.
[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 2012, <http://www.rfc-editor.org/info/rfc6698>. August 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 2014, <http://www.rfc-editor.org/info/rfc7258>. May 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
skipping to change at page 18, line 13 skipping to change at page 19, line 10
NLnet Labs, "Dnssec-Trigger", May 2014, NLnet Labs, "Dnssec-Trigger", May 2014,
<https://www.nlnetlabs.nl/projects/dnssec-trigger/>. <https://www.nlnetlabs.nl/projects/dnssec-trigger/>.
[draft-ietf-dprive-dnsodtls] [draft-ietf-dprive-dnsodtls]
Reddy, T., Wing, D., and P. Patil, "DNS over DTLS Reddy, T., Wing, D., and P. Patil, "DNS over DTLS
(DNSoD)", draft-ietf-dprive-dnsodtls-01 (work in (DNSoD)", draft-ietf-dprive-dnsodtls-01 (work in
progress), June 2015, <https://tools.ietf.org/html/ progress), June 2015, <https://tools.ietf.org/html/
draft-ietf-dprive-dnsodtls-01>. draft-ietf-dprive-dnsodtls-01>.
[draft-ietf-tls-falsestart] [draft-ietf-tls-falsestart]
Moeller, B. and A. Langley, "Transport Layer Security Moeller, B., Langley, A., and N. Modadugu, "Transport
(TLS) False Start", draft-ietf-tls-falsestart-00 (work in Layer Security (TLS) False Start",
progress), November 2014, draft-ietf-tls-falsestart-01 (work in progress),
<http://tools.ietf.org/html/draft-ietf-tls-falsestart-00>. 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
pins). Operators of a DNS-over-TLS service in this profile are pins).
expected to provide pins that are specific to the service being
pinned (i.e., public keys belonging directly to the end-entity or to
a service-specific private CA) and not to public key(s) of a generic
public CA.
A DNS client system is configured with an out-of-band key-pinned A DNS client system is configured with an out-of-band key-pinned
privacy profile from a network service, using a pinset containing two privacy profile from a network service, using a pinset containing two
pins. Represented in HPKP [RFC7469] style, the pins are: pins. Represented in HPKP [RFC7469] style, the pins are:
o pin-sha256="FHkyLhvI0n70E47cJlRTamTrnYVcsYdjUGbr79CfAVI=" o pin-sha256="FHkyLhvI0n70E47cJlRTamTrnYVcsYdjUGbr79CfAVI="
o pin-sha256="dFSY3wdPU8L0u/8qECuz5wtlSgnorYV2f66L6GNQg6w=" o pin-sha256="dFSY3wdPU8L0u/8qECuz5wtlSgnorYV2f66L6GNQg6w="
The client also configures the IP addresses of its expected DNS The client also configures the IP addresses of its expected DNS
 End of changes. 47 change blocks. 
122 lines changed or deleted 162 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/