< draft-ietf-dprive-dns-over-tls-01.txt   draft-ietf-dprive-dns-over-tls-02.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: April 13, 2016 USC/Information Sciences Expires: June 9, 2016 USC/Information Sciences
Institute Institute
A. Mankin A. Mankin
D. Wessels D. Wessels
Verisign Labs Verisign Labs
P. Hoffman P. Hoffman
ICANN ICANN
October 11, 2015 December 7, 2015
DNS over TLS: Initiation and Performance Considerations DNS over TLS: Initiation and Performance Considerations
draft-ietf-dprive-dns-over-tls-01 draft-ietf-dprive-dns-over-tls-02
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 7258. In addition, this document specifies two discussed in RFC 7258. 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.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 April 13, 2016. This Internet-Draft will expire on June 9, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Establishing and Managing DNS-over-TLS Sessions . . . . . . . 4 3. Establishing and Managing DNS-over-TLS Sessions . . . . . . . 4
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 4 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 4
3.2. TLS Handshake and Authentication . . . . . . . . . . . . . 4 3.2. TLS Handshake and Authentication . . . . . . . . . . . . . 4
3.3. Transmitting and Receiving Messages . . . . . . . . . . . 5 3.3. Transmitting and Receiving Messages . . . . . . . . . . . 5
3.4. Connection Reuse, Close and Reestablishment . . . . . . . 5 3.4. Connection Reuse, Close and Reestablishment . . . . . . . 5
4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 7 4.1. Opportunistic Privacy Profile . . . . . . . . . . . . . . 7
4.2. Pre-Deployed Profile . . . . . . . . . . . . . . . . . . . 7 4.2. Out-of-band Key-pinned Privacy Profile . . . . . . . . . . 7
5. Performance Considerations . . . . . . . . . . . . . . . . . . 8 5. Performance Considerations . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . . 9 7. Design Evolution . . . . . . . . . . . . . . . . . . . . . . . 9
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 10
8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Unbound . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.2. ldns . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.3. digit . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.4. getdns . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 12 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Out-of-band Key-pinned Privacy Profile Example . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
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 3, line 42 skipping to change at page 3, line 42
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]. recommendations and security considerations of [RFC7525] or its
successor.
The protocol described here works for any DNS client to server The protocol described here works for any DNS client to server
communication using DNS-over-TCP. That is, it may be used for communication using DNS-over-TCP. That is, it may be used for
queries and responses between stub clients and recursive servers as queries and responses between stub clients and recursive servers as
well as between recursive clients and authoritative servers. well as between recursive clients and authoritative servers.
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
a pre-deployed profile. an out-of-band key-pinned privacy profile. It is expected that a
future document based on [TBD] will further describe additional
privacy profiles for DNS over both TLS and DTLS. [Note to RFC
Editor: informative reference for that document will be forthcoming]
An earlier version of this document described a technique for An earlier version of this document described a technique for
upgrading a DNS-over-TCP connection to a DNS-over-TLS session with, upgrading a DNS-over-TCP connection to a DNS-over-TLS session with,
essentially, "STARTTLS for DNS". To simplify the protocol, this essentially, "STARTTLS for DNS". To simplify the protocol, this
document now only uses a well-known port to specify TLS use, omitting document now only uses a well-known port to specify TLS use, omitting
the upgrade approach. The upgrade approach no longer appears in this the upgrade approach. The upgrade approach no longer appears in this
document, which now focuses exclusively on the use of a well-known document, which now focuses exclusively on the use of a well-known
port for DNS-over-TLS. port for DNS-over-TLS.
2. Reserved Words 2. Reserved Words
skipping to change at page 4, line 36 skipping to change at page 4, line 39
DNS clients desiring privacy from DNS-over-TLS from a particular DNS clients desiring privacy from DNS-over-TLS from a particular
server SHOULD establish a TCP connection to port 853 on the server. server SHOULD establish a TCP connection to port 853 on the server.
Upon successful establishment of the TCP connection, client and Upon successful establishment of the TCP connection, client and
server SHOULD immediately initiate a TLS handshake using the server SHOULD immediately initiate a TLS handshake using the
procedure described in [RFC5246]. procedure described in [RFC5246].
DNS clients SHOULD remember server IP addresses that don't support DNS clients SHOULD remember server IP addresses that don't support
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 a pre-deployed privacy profile MAY be more aggressive about following an out-of-band key-pinned privacy profile MAY be more
retrying DNS-over-TLS connection failures. 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]). following the best practices specified in [RFC7525] or its successor.
The client will then authenticate the certificate, if required. DNS-
over-TLS does not propose new ideas for certificate authentication.
Depending on the privacy profile in use Section 4, the DNS client may
choose not to require authentication of the certificate, or it may
make use of a certificate that is part of the Certificate Authority
infrastructure [RFC5280] authenticated in the manner of HTTP/TLS
[RFC2818]. DANE [RFC6698] provides mechanisms to root certificate The client will then authenticate the server, if required. This
trust with DNSSEC. The DNS queries in DANE authentication of the document does not propose new ideas for authentication. Depending on
certificate for DNS-over-TLS MAY be in the clear to avoid trust the privacy profile in use Section 4, the DNS client may choose not
recursion. to require authentication of the server, or it may make use of
trusted a 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. At this point, normal DNS
queries SHOULD take place. 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
skipping to change at page 6, line 48 skipping to change at page 6, line 48
[RFC5077] and this SHOULD be used when reestablishing connections. [RFC5077] and this SHOULD be used when 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 [RFC5966], [I-D.ietf-dnsop-5966bis].
4. Usage Profiles 4. Usage Profiles
This protocol provides flexibility to accommodate several different This protocol provides flexibility to accommodate several different
use cases. Two usage profiles are defined here to identify specific use cases. This document defines two usage profiles: (1)
design points in performance and privacy. Other profiles are opportunistic privacy, and (2) out-of-band key-pinned authentication
possible but are outside the scope of this document. that can be used to obtain stronger privacy guarantees if the client
has a trusted relationship with a DNS server supporting TLS.
Additional methods of authentication will be defined in a forthcoming
draft [TBD].
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 encryption
[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 while
roaming), it might or might not validate the TLS certificate. These roaming), it might or might not validate the resolver. These choices
choices maximize availability and performance, but they leave the maximize availability and performance, but they leave the client
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 guaranteed privacy when there are no on-path active
attackers. attackers.
4.2. Pre-Deployed Profile 4.2. Out-of-band Key-pinned Privacy Profile
For pre-deployed privacy, the DNS client has one or more trusted The out-of-band key-pinned privacy profile can be used in
recursive DNS providers. This profile provides strong privacy environments where an established trust relationship already exists
guarantees to the user. between DNS clients and servers (e.g., stub-to-recursive in
enterprise networks, actively-maintained contractual service
relationships, or a client using a public DNS resolver). The result
of this profile is that the client has strong guarantees about the
privacy of its DNS data by connecting only to servers it can
authenticate.
With pre-deployed privacy, a client retains a copy of the TLS In this profile, clients authenticate servers by matching a set of
certificate (and/or other authentication credentials as appropriate) Subject Public Key Info (SPKI) Fingerprints in an analogous manner to
and IP address of each provider. The client will only use DNS that described in [RFC7469]. With this out-of-band key-pinned
servers for which this information has been pre-configured. The privacy profile, client administrators MUST deploy a pinset
possession of a trusted, pre-deployed TLS certificate allows the containing two or more pins (specific to the service being pinned)
client to detect person-in-the-middle and downgrade attacks. using a secure out-of-band (i.e., non-DNS) mechanism. This minimum
pinset size is required for key rollover, so that a server operator
does not have to coordinate key transitions with all its clients
simultaneously. After a change of keys on the server, an updated
pinset should be distributed to all clients in some secure way in
preparation for future key rollover. The mechanism for out-of-band
pinset update is out of scope for this document.
With pre-deployed privacy, the DNS client MUST signal to the user Such a client will only use DNS servers for which an SPKI Fingerprint
when none of the designated DNS servers are available, and MUST NOT pinset has been provided. The possession of trusted pre-deployed
provide DNS service until at least one of the designated DNS servers pinset allows the client to detect and prevent person-in-the-middle
becomes available. and downgrade attacks.
The designated DNS provider 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 that the DNS
is not private during such bootstrap. is not private during such bootstrap.
Methods for pre-deployment of the designated DNS provider are outside Upon successful TLS connection and handshake, the client computes the
the scope of this document. In corporate settings, such information SPKI Fingerprints for the public keys found in the validated server's
may be provided at system installation. certificate chain (or in the raw public key, if the server provides
that instead). If a computed fingerprint exactly matches one of the
configured pins the client continues with the connection as normal.
Otherwise, the client MUST treat the SPKI validation failure as a
non-recoverable error. Appendix A provides a detailed example of how
this authentication could be performed in practice.
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 1. Latency: Compared to UDP, DNS-over-TCP requires an additional
round-trip-time (RTT) of latency to establish a TCP connection. round-trip-time (RTT) of latency to establish a TCP connection.
TCP Fast Open [RFC7413] can eliminate that RTT when information TCP Fast Open [RFC7413] can eliminate that RTT when information
exists from prior connections. The TLS handshake adds another exists from prior connections. The TLS handshake adds another
skipping to change at page 9, line 13 skipping to change at page 9, line 32
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.
We further recommend that IANA reserve the same port number over UDP We further recommend that IANA reserve the same port number over UDP
for the proposed DNS-over-DTLS protocol [draft-ietf-dprive-dnsodtls]. for the proposed DNS-over-DTLS protocol [draft-ietf-dprive-dnsodtls].
IANA responded to the early allocation request with the following IANA responded to the early allocation request with the following
TEMPORARY assignment: TEMPORARY assignment:
Service Name domain-s Service Name domain-s
Port Number 853 Port Number 853
Transport Protocol(s) TCP/UDP Transport Protocol(s) TCP/UDP
Assignee IETF DPRIVE Chairs Assignee IETF DPRIVE Chairs
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 prior to
publication as it may be useful to future Foo-over-TLS efforts] publication as it may be useful to future Foo-over-TLS efforts]
skipping to change at page 11, line 37 skipping to change at page 12, line 10
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]. DNS clients keeping track of considerations of [RFC7525] or its successor. DNS clients
servers known to support TLS enables clients to detect downgrade keeping track of servers known to support TLS enables clients to
attacks. For servers with no connection history and no apparent detect downgrade attacks. For servers with no connection history
support for TLS, clients depending on their Privacy Profile and and no apparent support for TLS, depending on their Privacy
privacy requirements may choose to (a) try another server when Profile and privacy requirements, clients may choose to (a) try
available, (b) continue without TLS, or (c) refuse to forward the another server when available, (b) continue without TLS, or (c)
query. refuse to forward the 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 prior to the TLS handshake that are 3. Any DNS protocol interactions prior to the TLS handshake that are
performed in the clear can be modified by a person-in-the-middle performed in the clear can be modified by a person-in-the-middle
skipping to change at page 12, line 35 skipping to change at page 13, line 14
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
UK UK
Email: sara@sinodun.com Email: sara@sinodun.com
URI: http://sinodun.com URI: http://sinodun.com
Daniel Kahn Gillmor
ACLU
125 Broad Street, 18th Floor
New York, NY 10004
USA
11. Acknowledgments 11. Acknowledgments
The authors would like to thank Stephane Bortzmeyer, John Dickinson, The authors would like to thank Stephane Bortzmeyer, John Dickinson,
Daniel Kahn Gillmor, Brian Haberman, Kim-Minh Kaplan, Bill Manning, Brian Haberman, Shumon Huque, Kim-Minh Kaplan, Simon Joseffson, Simon
George Michaelson, Eric Osterweil, and Glen Wiley for reviewing this Kelley, Warren Kumari, John Levine, Ilari Liusvaara, Bill Manning,
Internet-draft. They also thank Nikita Somaiya for early work on George Michaelson, Eric Osterweil, Jinmei Tatuya, Tim Wicinski, and
this idea. Glen Wiley for reviewing this Internet-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
skipping to change at page 13, line 49 skipping to change at page 14, line 33
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
Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469,
April 2015, <http://www.rfc-editor.org/info/rfc7469>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525,
May 2015, <http://www.rfc-editor.org/info/rfc7525>. 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",
skipping to change at page 16, line 11 skipping to change at page 16, line 48
(TLS) False Start", draft-ietf-tls-falsestart-00 (work in (TLS) False Start", draft-ietf-tls-falsestart-00 (work in
progress), November 2014, progress), November 2014,
<http://tools.ietf.org/html/draft-ietf-tls-falsestart-00>. <http://tools.ietf.org/html/draft-ietf-tls-falsestart-00>.
[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
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
pins). 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.
A DNS client system is configured with an out-of-band key-pinned
privacy profile from a network service, using a pinset containing two
pins. Represented in HPKP [RFC7469] style, the pins are:
o pin-sha256="FHkyLhvI0n70E47cJlRTamTrnYVcsYdjUGbr79CfAVI="
o pin-sha256="dFSY3wdPU8L0u/8qECuz5wtlSgnorYV2f66L6GNQg6w="
The client also configures the IP addresses of its expected DNS
server, 192.0.2.3 and 192.0.2.4.
The client connects to 192.0.2.3 on TCP port 853 and begins the TLS
handshake, negotiation TLS 1.2 with a diffie-hellman key exchange.
The server sends a Certificate message with a list of three
certificates (A, B, and C), and signs the ServerKeyExchange message
correctly with the public key found certificate A.
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,
the verification is successful; the client continues with the TLS
connection and can make its first DNS query.
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
digest of the SPKI in cert B and compares it against both pins in the
pinset. If either pin matches, the verification is successful.
Otherwise, it verifes that B was issued by C, and then compares the
pins against the digest of C's SPKI.
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
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
USA USA
Phone: +1 213 587-1057 Phone: +1 213 587-1057
Email: zihu@usc.edu Email: zihu@usc.edu
 End of changes. 28 change blocks. 
67 lines changed or deleted 140 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/