Internet DRAFT - draft-schwartz-dns-sni
draft-schwartz-dns-sni
Network Working Group B. Schwartz
Internet-Draft Google
Intended status: Standards Track February 17, 2017
Expires: August 21, 2017
A DNS Resource Record for TLS Server Name Indication (DNS SNI)
draft-schwartz-dns-sni-02
Abstract
The SNI record type allows a domain owner to specify the "server
name" to indicate in TLS connections, if it is different from the
domain name. This allows domains that use shared hosting and
wildcard or multi-domain (UCC) certificates to change the only domain
name shown in cleartext, to prevent a passive adversary from
identifying exactly which domain a user is accessing.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 21, 2017.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Schwartz Expires August 21, 2017 [Page 1]
Internet-Draft DNSSNI February 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Threat example: shared hosting service . . . . . . . . . 3
2. Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Need for a new record type . . . . . . . . . . . . . . . 4
2.1.1. Using SRV . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. Using TLSA . . . . . . . . . . . . . . . . . . . . . 5
2.1.3. Using TXT . . . . . . . . . . . . . . . . . . . . . . 5
3. Client Requirements . . . . . . . . . . . . . . . . . . . . . 5
4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 6
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Performance Considerations . . . . . . . . . . . . . . . . . 7
8. Considerations for optimizing privacy . . . . . . . . . . . . 9
9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Modern Internet standards are designed to avoid unnecessarily
revealing sensitive information about a user's behavior to a passive
adversary. One key piece of sensitive information is the name of the
domain that a user is visiting. Most commonly, this is the DNS name
of a website, so the sensitive information indicates browsing history
at domain granularity.
Several protocol standards contain elements that protect the user's
browsing history from a passive adversary. The DNS over TLS standard
[RFC7858] allows clients to perform DNS queries without revealing the
request or response to an attacker. This allows clients to access
DNS-named services without publicly revealing the name of the
services that they are about to access.
After a DNS lookup, the HTTPS standard [RFC2818] allows clients to
perform HTTP requests to a server without revealing the contents of
the HTTP request or response, using TLS. This hides the website's
host name from being observed by a passive adversary. Previous
versions of TLS transferred the server's certificate in cleartext,
revealing some information about the identity of the destination, but
Schwartz Expires August 21, 2017 [Page 2]
Internet-Draft DNSSNI February 2017
TLS 1.3 [I-D.ietf-tls-tls13] enables encrypting the certificate as
well.
However, modern use of HTTPS requires providing a TLS Server Name
Indication (SNI, [RFC6066]), which conveys the website's DNS name in
cleartext. Sending the Server Name Indication in cleartext reveals
the user's sensitive information to a passive adversary, defeating
the desired privacy benefit.
DNS Server Client HTTP Server
| | |
1. |<==example.com AAAA?==| |
2. |===2001:db8::1=======>| |
3. | |--TLS ClientHello SNI:example.com--->|
4. | |<------TLS ServerHello---------------|
5. | |<==TLS EncryptedExt SNI:example.com==|
6. | |<==TLS Certificate, CN:example.com===|
7. | |==HTTP GET :authority:example.com===>|
==== encrypted ---- cleartext
Figure 1: HTTP request with DPRIVE, HTTP/2, and TLS-1.3
This document describes a new DNS record that allows a domain owner
to tell clients precisely what Server Name Indication to send. For
domains that use wildcard or multi-domain (UCC) certificates, this
name may differ from the website's DNS name, preventing the passive
adversary from learning which domain the user is accessing with high
confidence. Instead, the adversary learns only the IP addresses with
confidence, so all services that share an IP address and certificate
can become part of a single anonymity set that is larger than any
single service. Clients can make use of this record without adding
delay to their connection process, and clients who do not make use of
this record are not negatively impacted.
1.1. Threat example: shared hosting service
Consider a shared hosting service, example.com, that offers each user
their own website, hosted at a unique subdomain like
alicesphotos.example.com. For confidentiality and access control,
example.com provides its users with service over HTTPS, using a
wildcard certificate for *.example.com. All users' subdomains are
hosted by the same set of servers.
Prior to the introduction of TLS Server Name Indication, this
arrangement was sufficient to prevent a passive adversary who
monitors example.com's incoming traffic from determining which user
is visiting which subdomain. However, modern TLS clients publish the
Schwartz Expires August 21, 2017 [Page 3]
Internet-Draft DNSSNI February 2017
Fully Qualified Domain Name in the TLS ClientHello as the Server Name
Indication, so the adversary can easily identify which client IP
address is accessing which subdomain. Mapping IP addresses to
individual users is often straightforward for an adversary with
access to ISP records or a popular website's logs.
The user's choice of which subdomain to visit may be sensitive.
Subdomains of shared hosting services often contain controversial
material, and users may reasonably wish not to make public the names
of the subdomains that they read.
The user's identity as the author of a particular subdomain is
typically even more sensitive. Authors of controversial sites on
shared hosting often choose not to reveal their true identity or
location, to protect their physical safety. However, the author of a
domain is typically the only visitor who is likely to upload a large
amount of data. By combining the TLS SNI with a simple upload
threshold, the adversary can determine the author's client IP address
with high confidence.
2. Concept
We define a new RRTYPE: "SNI". To control the TLS Server Name
Indication that clients set, a TLS endpoint operator MAY publish one
or more SNI records for their domain name (the "base domain").
Each SNI record MUST contain a prefix of the form
_(port)._(transport), the same prefix used for a TLSA record
[RFC6698]. The SNI record's RDATA MUST contain the intended Server
Name. For example, if the operator of subdomain1.example.com wishes
to inform HTTPS visitors to set a Server Name Indication of
"subdomain2.example.com", they would publish a record of the form
_443._tcp.subdomain1.example.com. IN SNI "subdomain2.example.com"
The RDATA of an SNI record consists of UTF-8 octets for use as a
HostName in the TLS Server Name Indication field, in conformance with
Section 3 of [RFC6066]. DNS resolvers SHOULD treat SNI records as
resource records of unknown type [RFC3597].
2.1. Need for a new record type
Instead of defining a new record type, we could convey this
information using an existing record type. However, using any
existing record type has some significant drawbacks.
Schwartz Expires August 21, 2017 [Page 4]
Internet-Draft DNSSNI February 2017
2.1.1. Using SRV
We could achieve an equivalent effect using SRV records [RFC2782],
with a new protocol type.
This would function very similarly to an SNI record, but it would be
a violation of the SRV specification, which requires the client to
redirect to the domain in the RDATA and perform additional DNS
queries. SRV records also include a port, which is not meaningful in
this context. Using SRV records in this way might also make future
extensions (e.g. to other forms of RDATA) somewhat less appealing.
2.1.2. Using TLSA
We could use the existing TLSA record type [RFC6698]. Clients could
extract the server's supported names from a "full certificate
association" Section 4.1 [RFC6698] TLSA response.
This approach doesn't work well for wildcard certificates, because
the client cannot tell what SNI to set. Using TLSA in this way would
also create problems for servers that use SNI for more than
certificate selection, and for servers that have multiple overlapping
certificates. It might also be very inefficient: transferring an
entire certificate just to learn its names is wasteful, and TLSA
records that contain hashes would have to be discarded.
2.1.3. Using TXT
We could encode this information in a TXT record, but that would
violate the intended purpose of TXT records: to convey information to
human readers.
3. Client Requirements
When initiating a TLS connection to a domain and port, a client
application SHOULD query the SNI record for the prefixed domain at
the same time as the A or AAAA query. The application MUST discard
or ignore any SNI record whose RDATA is not a valid TLS HostName or
an empty string. If an application's query returns multiple valid
SNI records, the application SHOULD choose one at random.
The client application SHOULD use the RDATA of the selected SNI
record as the Server Name Indication in the TLS ClientHello. If the
selected SNI record is present with an empty RDATA (RDLEN = 0), then
the client SHOULD omit the Server Name Indication.
Client applications MUST NOT allow the contents of the SNI record to
influence their certificate validation behavior. The client's
Schwartz Expires August 21, 2017 [Page 5]
Internet-Draft DNSSNI February 2017
certificate validation MUST be based on the user's specified
destination, not the RDATA of the SNI DNS record. If the server's
certificate is not valid for the user's specified destination, the
client application MUST terminate the TCP connection and SHOULD retry
the TLS connection without the SNI RDATA, using the client's default
Server Name Indication behavior.
4. Server Requirements
Domain owners that publish an SNI record MUST ensure that all
relevant servers, when receiving this SNI value, reply with a
certificate whose set of valid domains includes the base domain. The
servers MUST satisfy this criterion for all SNI records that have
been published and not yet expired. Relevant servers are those whose
IP addresses are in the correct family and are listed in a non-
expired address record for this domain.
Domain owners that publish an SNI record MUST ensure that their
servers do not depend on the TLS Server Name Indication to select
which service to provide to the user. Instead, participating servers
SHOULD select the service using the tunneled protocol's service
identifier, e.g. the :authority pseudo-header in HTTP/2, bearing in
mind that this identifier is controlled by the client and may be
untrusted.
5. Use Cases
A host that serves many subdomains with a single wildcard certificate
could set the SNI of all subdomains to the same fixed subdomain, in
order to prevent a passive adversary from learning which subdomain a
user is accessing.
A host that uses multiple-domain (UCC) certificates, and which
controls the DNS entries for domains that it hosts, could set several
SNI records on the domains that share one certificate, with each
record indicating a different domain name that is also provided in
that certificate. This would prevent a passive adversary from
learning with confidence which of those domains a client is
accessing.
A TLS service operator who does not use shared hosting could set an
empty SNI record, to tell the client not to use SNI.
6. Security Considerations
The SNI record is provided over DNS, and MAY be used with or without
DNSSEC. The SNI record is therefore untrusted, and clients MUST NOT
rely on its presence or correctness.
Schwartz Expires August 21, 2017 [Page 6]
Internet-Draft DNSSNI February 2017
A passive adversary who monitors the client's DNS queries could learn
which domain the client is accessing, defeating the confidentiality
benefits of this record type. Therefore, clients wishing to conceal
browsing history from a passive adversary SHOULD also use DNS over
TLS [RFC7858]. However, clients MAY use SNI records with standard
DNS, in order to provide protection against a weak passive adversary
who can monitor only the link between the client and the TLS server,
not the link between the client and the DNS server.
An active adversary who controls the DNS could remove the SNI record,
or add a malicious record. Removing the record would cause the
client to revert to its default behavior in the absence of an SNI
record. Adding a malicious record could cause the client to set an
incorrect or nonexistent Server Name. This will likely cause the
initial connection attempt to fail, but does not cause any additional
loss of confidentiality, because the client will still perform
standard TLS certificate verification. (Like the previous adversary,
this active adversary can also monitor DNS queries, so they can still
learn which domain the client is attempting to access.)
7. Performance Considerations
Client applications that intend to make use of the SNI record SHOULD
issue a DNS query for the SNI record immediately following the A or
AAAA record query. The client SHOULD NOT wait for an A or AAAA
response before issuing the SNI query, as this would introduce an
extra round-trip delay to the DNS server. A client application
SHOULD NOT delay initiating a TCP connection while waiting for the
SNI DNS response.
DNS Server Client TLS Server
| | |
|(Client wants to connect to example.com, but doesn't know the IP)|
1. |<===example.com AAAA?==========| |
|<==_443._tcp.example.com SNI?==| |
2. |===AAAA 2001:db8::1===========>| |
|(As soon as the client gets the IP they can start TCP connection)|
| |--------------TCP SYN----------->|
|(The DNS SNI response should arrive soon after the AAAA response)|
3. |======SNI example2.com========>| |
4. | |<------------TCP SYN+ACK---------|
| |--------------TCP ACK----------->|
|(When starting TLS, the client uses the SNI RDATA as the TLS SNI)|
| |--ClientHello SNI:example2.com-->|
Figure 2: TLS connection with SNI record, typical case
Schwartz Expires August 21, 2017 [Page 7]
Internet-Draft DNSSNI February 2017
If the client can begin sending data to the server (e.g. SYN-ACK is
received) before the SNI RDATA has been received, the client MAY
issue a ClientHello using its default behavior (i.e. without using
the SNI RDATA). Note that if the client's DNS resolver has similar
performance for SNI and A/AAAA queries, the client will generally
receive the SNI response before the destination server receives the
TCP SYN packet, thus avoiding this situation.
DNS Server Client TLS Server
| | |
1. |<===example.com AAAA?==========| |
|<==_443._tcp.example.com SNI?==| |
2. |===AAAA 2001:db8::1===========>| |
| |--------------TCP SYN---------->|
3. | |<------------TCP SYN+ACK--------|
| |--------------TCP ACK---------->|
| |--ClientHello SNI:example.com-->|
4. |======SNI example2.com========>| |
Figure 3: TLS connection with SNI record, slow case (OPTIONAL)
If the client is using TCP Fast Open [RFC7413], and the destination
IP address is known (e.g. AAAA record is in cache) but the SNI RDATA
is not known, the client MAY send a TLS ClientHello using its default
behavior. However, the client SHOULD also issue a DNS query for the
SNI record, in order to populate the local cache for subsequent
connection attempts.
DNS Server Client TLS Server
| | |
1. | |----------TCP Fast Open-------->|
| |--ClientHello SNI:example.com-->|
2. |<==_443._tcp.example.com SNI?==| |
3. |======SNI example2.com========>| |
Figure 4: TCP Fast Open, AAAA cached but not SNI (OPTIONAL)
If the client is using TCP Fast Open and the destination IP address
is not known, the client SHOULD issue A/AAAA and SNI requests
simultaneously. If the A or AAAA response is received before the
corresponding SNI response, the client SHOULD wait briefly (e.g. 1
millisecond) to allow receipt of the SNI response before issuing a
TLS ClientHello.
Schwartz Expires August 21, 2017 [Page 8]
Internet-Draft DNSSNI February 2017
DNS Server Client TLS Server
| | |
1. |<===example.com AAAA?==========| |
|<==_443._tcp.example.com SNI?==| |
2. |===AAAA 2001:db8::1===========>| |
| (client waits briefly for the SNI response to arrive) |
3. |======SNI example2.com========>| |
4. | |----------TCP Fast Open--------->|
| |--ClientHello SNI:example2.com-->|
Figure 5: TCP Fast Open, nothing cached (delay is RECOMMENDED)
TODO: Check if 1ms is a reasonable delay to receive an immediately
subsequent packet on current hardware.
8. Considerations for optimizing privacy
By publishing an SNI record, a service operator can reduce the
ability of a passive network adversary to determine with certainty
which domain each user is accessing. Reducing leakage of information
to this adversary, and reducing this adversary's confidence in the
information they do collect, improves user privacy.
Regardless of SNI, a passive adversary still learns the client's and
destination's IP addresses. The adversary may have foreknowledge of
which domains are hosted at that address. An active adversary could
attempt a similar connection in order to learn more about the
services hosted at the destination. The purpose of this proposal is
to ensure that if there is more than one service hosted at the
destination IP, a passive network adversary does not directly learn
which service the client is using. Services that share an IP address
and TLS certificate with a wider range of other services can benefit
more from the use of an SNI record.
An adversary may be able to distinguish different encrypted services
on the same IP address by the size, frequency, and timing of
encrypted packets. Use of the SNI record does not prevent attacks of
this kind.
If the adversary has full knowledge of the contents of the global DNS
(a strong adversary), then users of a domain only experience a
privacy benefit if another domain at the same IP address uses the
same SNI RDATA. The privacy benefit increases as more domains share
the same SNI RDATA and the same IP addresses.
If all clients will use the SNI record, then the greatest privacy
benefit is achieved by configuring all services that share a
certificate to use the same SNI. However, a service operator may
Schwartz Expires August 21, 2017 [Page 9]
Internet-Draft DNSSNI February 2017
also choose to publish multiple SNI records for a domain, listing
several other services that share the same certificate. The client
will then choose from among these Server Name Indications at random.
This approach maintains protection of clients that are aware of the
SNI record, but also benefits users who are not using the SNI record:
if the adversary cannot distinguish these two groups of users, then
it cannot tell with certainty which domain any user is accessing.
Note that due to response latency issues, some clients might not be
using the SNI record contents, even if they have issued an SNI DNS
query (see Performance Considerations).
Use of the SNI record does not prevent an active adversary from
learning which certificate the server is using. A simple active
adversary can reuse the client's observed Server Name Indication, to
learn which certificate is sent by the server in reply. Therefore,
domain owners seeking to protect users against an active adversary
MUST ensure that the server's certificate includes a sufficiently
large and diverse set of domains to achieve their privacy goals.
In TLS 1.2 [RFC5246], the server sends its certificate in cleartext,
visible to a passive adversary. A passive adversary can also observe
the certificate ID if the client performs an OCSP lookup [RFC6960].
Therefore, servers wishing to hide the certificate MUST implement TLS
1.3 and OCSP Stapling [RFC6961]. Note that this precaution does not
protect against even a simple active adversary.
9. Extensibility
The SNI record as described here contains two main mechanisms for
extensibility. First, future extensions may describe records whose
RDATA is not structured as a valid domain name (e.g. containing
whitespace or "=" characters). Clients conformant to this
specification MUST ignore such records.
Second, clients that connect to a server and experience a negotiation
failure SHOULD retry the connection without making use of the SNI
record. This allows future changes to the semantics of SNI records
with RDATA that are valid domain names, without causing a serious
problem for clients conformant to this version of the specification.
10. IANA Considerations
This document uses a new DNS RR type, SNI, which will require a value
assignment from IANA.
Schwartz Expires August 21, 2017 [Page 10]
Internet-Draft DNSSNI February 2017
11. Acknowledgements
Thanks to Ben Vitale, Warren Kumari, and Vinicius Fortuna for their
constructive feedback.
12. References
12.1. Normative References
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
2003, <http://www.rfc-editor.org/info/rfc3597>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<http://www.rfc-editor.org/info/rfc6960>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013,
<http://www.rfc-editor.org/info/rfc6961>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<http://www.rfc-editor.org/info/rfc7413>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <http://www.rfc-editor.org/info/rfc7858>.
Schwartz Expires August 21, 2017 [Page 11]
Internet-Draft DNSSNI February 2017
12.2. Informative References
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-18 (work in progress),
October 2016.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
<http://www.rfc-editor.org/info/rfc2782>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
Author's Address
Benjamin M. Schwartz
Google, Inc.
111 8th Ave
New York, NY 10011
USA
Email: bemasc@google.com
Schwartz Expires August 21, 2017 [Page 12]