One document matched: draft-ietf-dprive-dns-over-tls-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC1034 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC1035 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC4033 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC6698 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6698.xml">
<!ENTITY RFC5246 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC2595 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2595.xml">
<!ENTITY RFC3501 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3501.xml">
<!ENTITY RFC3207 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3207.xml">
<!ENTITY RFC3234 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3234.xml">
<!ENTITY RFC1939 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1939.xml">
<!ENTITY RFC5280 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC2818 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY RFC2131 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2131.xml">
<!ENTITY RFC6891 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml">
<!ENTITY RFC4892 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4892.xml">
<!ENTITY RFC5077 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5077.xml">
<!ENTITY RFC6335 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6335.xml">
<!ENTITY RFC5966 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5966.xml">
<!ENTITY RFC7120 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7120.xml">
<!ENTITY RFC7258 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml">
<!ENTITY RFC7413 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7413.xml">
<!ENTITY RFC7435 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7435.xml">
<!ENTITY RFC7469 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7469.xml">
<!ENTITY RFC7525 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml">
<!ENTITY RFC7626 PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7626.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes"?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<?rfc toc="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-dprive-dns-over-tls-04" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="DNS over TLS">DNS over TLS: Initiation and Performance Considerations</title>
<author fullname="Zi Hu" initials="Z." surname="Hu">
<organization>USC/Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way, Suite 1133</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>USA</country>
</postal>
<phone>+1 213 587-1057</phone>
<email>zihu@usc.edu</email>
</address>
</author>
<author fullname="Liang Zhu" initials="L." surname="Zhu">
<organization>USC/Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way, Suite 1133</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>USA</country>
</postal>
<phone>+1 310 448-8323</phone>
<email>liangzhu@usc.edu</email>
</address>
</author>
<author fullname="John Heidemann" initials="J." surname="Heidemann">
<organization>USC/Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way, Suite 1001</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>USA</country>
</postal>
<phone>+1 310 822-1511</phone>
<email>johnh@isi.edu</email>
</address>
</author>
<author fullname="Allison Mankin" initials="A." surname="Mankin">
<organization>Verisign Labs</organization>
<address>
<postal>
<street>12061 Bluemont Way</street>
<city>Reston</city>
<region>VA</region>
<code>20190</code>
</postal>
<phone>+1 703 948-3200</phone>
<email>amankin@verisign.com</email>
</address>
</author>
<author fullname="Duane Wessels" initials="D." surname="Wessels">
<organization>Verisign Labs</organization>
<address>
<postal>
<street>12061 Bluemont Way</street>
<city>Reston</city>
<region>VA</region>
<code>20190</code>
</postal>
<phone>+1 703 948-3200</phone>
<email>dwessels@verisign.com</email>
</address>
</author>
<author fullname="Paul Hoffman" initials="P." surname="Hoffman">
<organization>ICANN</organization>
<address>
<email>paul.hoffman@icann.org</email>
</address>
</author>
<date year="2016" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Internet</area>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
This document describes the use of TLS to provide privacy
for DNS. Encryption provided by TLS eliminates opportunities
for eavesdropping and on-path tampering with DNS queries in the network, such as
discussed in RFC 7258.
In addition, this document specifies
two usage profiles for DNS-over-TLS and provides advice on
performance considerations to minimize overhead from using
TCP and TLS with DNS.
</t>
<t>
Note: this document was formerly named
draft-ietf-dprive-start-tls-for-dns. Its name has been
changed to better describe the mechanism now used. Please
refer to working group archives under the former name for
history and previous discussion. [RFC Editor: please remove
this paragraph prior to publication]
</t>
</abstract>
</front>
<middle>
<section anchor="Intro" title="Introduction">
<t>
Today, nearly all DNS queries <xref target="RFC1034"/>,
<xref target="RFC1035"/> are sent unencrypted, which makes
them vulnerable to eavesdropping by an attacker that has
access to the network channel, reducing the privacy of the
querier. Recent news reports have elevated these concerns,
and recent IETF work has specified privacy considerations
for DNS <xref target="RFC7626"/>.
</t>
<t>
Prior work has addressed some aspects of DNS security, but
until recently there has been little work on privacy between
a DNS client and server. DNS Security Extensions (DNSSEC),
<xref target="RFC4033"/> provide <spanx style="emph">response
integrity</spanx> by defining mechanisms to cryptographically
sign zones, allowing end-users (or their first-hop resolver)
to verify replies are correct. By intention, DNSSEC does not
protect request and response privacy. Traditionally, either
privacy was not considered a requirement for DNS traffic, or
it was assumed that network traffic was sufficiently private,
however these perceptions are evolving due to recent events
<xref target="RFC7258"/>.
</t>
<!-- XXX DW: I don't particularly like the following paragraph.
It seems wrong to mention these drafts in a standards track
RFC. If nothing else it needs to be rewritten (and given
a brief "related work" intro sentence)
XXX AJM: See replacment which is very minimal and
I think may be OK
XXX DW: yes, I like it.
-->
<!-- <t>
DNSCurve <xref target="draft-dempsky-dnscurve"/> defines a
method to add confidentiality to the link between DNS clients
and servers; however, it does so with a new cryptographic
protocol and does not take advantage of an existing standard
protocol such as TLS. ConfidentialDNS <xref
target="draft-wijngaards-confidentialdns"/> and IPSECA <xref
target="draft-osterweil-dane-ipsec"/> use opportunistic
encryption to offer privacy for DNS queries and responses.
Finally, others have suggested DNS-over-TLS. Unbound DNS
software <xref target="unbound"/> includes a DNS-over-TLS
implementation. The DNS-over-DTLS <xref
target="draft-ietf-dprive-dnsodtls"/> proposal describing how
to secure UDP-based DNS messages with DTLS. The present document
specifies how to encrypt DNS queries with DNS-over-TLS and
advice on performance considerations.
</t> -->
<t>
Other work that has offered the potential to encrypt
between DNS clients and servers includes
DNSCurve <xref target="dempsky-dnscurve"/>,
ConfidentialDNS <xref target="I-D.confidentialdns"/>
and IPSECA <xref target="I-D.ipseca"/>.
In addition to the present draft, the DPRIVE working group
has recently adopted a DNS-over-DTLS
<xref target="draft-ietf-dprive-dnsodtls"/> proposal.
</t>
<t>
This document describes using DNS-over-TLS on a well-known port and
also offers advice on performance considerations to minimize overheads from
using TCP and TLS with DNS.
</t>
<t>
Initiation of DNS-over-TLS is very straightforward. By
establishing a connection over a well-known port, clients and
servers expect and agree to negotiate a TLS session to secure
the channel. Deployment 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 expected to keep track
of servers that support TLS and those that don't. Clients and
servers will adhere to the TLS implementation recommendations
and security considerations of <xref target="RFC7525"/> or its successor.
</t>
<!-- XXX AJM: instead of addressing any security issues of
TLS, I think we need to refer all generic TLS items to the TLS BCP.
XXX AJM: Cited RFC 7525 but actually this should be BCP 195 -
for future-proofing - check later to make sure this works in the xml2rfc.
Deleted: Furthermore,
as is generally the case with TLS, it is subject to downgrade
attacks, as discussed in <xref target="Security"/>. -->
<t>
The protocol described here works for any DNS client to server
communication using DNS-over-TCP. That is, it may be used
for queries and responses between stub clients and recursive
servers as well as between recursive clients and authoritative
servers.
</t>
<t>
This document describes two profiles in <xref target="profiles"/>
providing different levels of assurance of privacy: an opportunistic
privacy profile and an out-of-band key-pinned privacy profile.
It is expected that a future document based on <xref target="dgr-dprive-dtls-and-tls-profiles"/> will further
describe additional privacy profiles for DNS over both TLS and DTLS.
</t>
<t>
An earlier version of this document described a technique for
upgrading a DNS-over-TCP connection to a DNS-over-TLS session
with, essentially, "STARTTLS for DNS".
To simplify the protocol, this document now
only uses a well-known port to specify TLS use,
omitting the upgrade approach.
The upgrade approach no longer
appears in this document, which now focuses exclusively on
the use of a well-known port for DNS-over-TLS.
</t>
</section>
<section title="Reserved Words">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in <xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
<section anchor="Establishment" title="Establishing and Managing DNS-over-TLS Sessions">
<section anchor="Initiation" title="Session Initiation">
<t>
A DNS server that supports DNS-over-TLS MUST listen for
and accept TCP connections on port 853.
</t>
<t>
DNS clients desiring privacy from DNS-over-TLS from a
particular server MUST establish a TCP connection which SHOULD be to
port 853 on the server. This is a SHOULD rather than a
MUST because a server MAY also offer DNS-over-TLS service
on another port by agreement with its client. Such an
additional port MUST NOT be port 53, but MAY be from the
FCFS port range. The first data exchange on this TCP
connection MUST be the client and server
initiating a TLS handshake using the procedure described
in <xref target="RFC5246"/>.
</t>
<t>
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 respond to clear text DNS messages
on any port used for DNS-over-TLS (including, for example,
after a failed TLS handshake). There are significant
security issues in mixing protected and unprotected data
and for this reason TCP connections on a port designated
by a given server for DNS-over-TLS are reserved purely
for encrypted communications.
</t>
<t>
DNS clients SHOULD remember server IP addresses that don't
support DNS-over-TLS, including timeouts, connection
refusals, and TLS handshake failures, and not request
DNS-over-TLS from them for a reasonable period (such as
one hour per server). DNS clients following an out-of-band key-pinned
privacy profile MAY be more aggressive about retrying
DNS-over-TLS connection failures.
</t>
</section>
<section anchor="handshake" title="TLS Handshake and Authentication">
<t>
Once the DNS client succeeds in connecting via TCP on the well-known port for
DNS-over-TLS, it proceeds with the TLS handshake <xref target="RFC5246"/>,
following
the best practices specified in <xref target="RFC7525"/> or its successor.
</t>
<t>
The client will then authenticate the server, if required.
This document does
not propose new ideas for authentication.
Depending on the privacy profile in use <xref target="profiles"/>, the DNS client may
choose not to require authentication of the server, or it may make use of
trusted a SPKI Fingerprint pinset.
</t>
<t>
After TLS negotiation completes, the connection will be encrypted
and is now protected from eavesdropping. At this point, normal DNS queries SHOULD take place.
</t>
</section>
<section anchor="transmitting" title="Transmitting and Receiving Messages">
<t>
All messages (requests and responses) in the established TLS session
MUST use the two-octet length field described in Section 4.2.2 of
<xref target="RFC1035"/>.
For reasons of efficiency, DNS clients and servers SHOULD
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 "write" system call) to make
it more likely that all the data will be transmitted in
a single TCP segment
(<xref target="I-D.ietf-dnsop-5966bis"/>, Section 8).
</t>
<t>
<!-- cut-n-paste with edits from rfc5966-bis sec 6.2.1.1 -->
In order to minimize latency, clients SHOULD pipeline
multiple queries over a TLS session. When a DNS client sends
multiple queries to a server, it should not wait for an
outstanding reply before sending the next query (<xref
target="I-D.ietf-dnsop-5966bis"/>, Section 6.2.1.1).
</t>
<t>
<!-- cut-n-paste from rfc5966-bis sec 7 -->
Since pipelined responses can arrive out-of-order, clients
MUST match responses to outstanding queries using the ID
field, query name, type, and class. Failure by clients to properly
match responses to outstanding queries can have serious
consequences for interoperability (<xref
target="I-D.ietf-dnsop-5966bis"/>, Section 7).
</t>
</section>
<section anchor="Connection" title="Connection Reuse, Close and Reestablishment">
<t>
For DNS clients that use library functions such as "getaddrinfo()" and "gethostbyname()",
current implementations are known to open and close TCP connections each DNS
call. To avoid excess TCP connections, each with a single query,
clients SHOULD reuse a single TCP connection to the
recursive resolver. Alternatively they may 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 recursive
resolver.
</t>
<t>
In order to amortize TCP and TLS connection setup costs, clients
and servers SHOULD NOT immediately close a connection after
each response. Instead, clients and servers SHOULD reuse
existing connections for subsequent queries as long as they
have sufficient resources. In some cases, this means that
clients and servers may need to keep idle connections open for
some amount of time.
</t>
<t>
Proper management of established and idle connections is important
to the healthy operation of a DNS server. An implementor of
DNS-over-TLS SHOULD follow best practices for DNS-over-TCP, as
described in <xref target="I-D.ietf-dnsop-5966bis"/>. Failure
to do so may lead to resource exhaustion and denial-of-service.
</t>
<t>
Whereas client and server implementations from the <xref
target="RFC1035"/> era are known to have poor TCP connection
management, this document stipulates that successful negotiation
of TLS indicates the willingness of both parties to keep idle
DNS connections open, independent of timeouts or other
recommendations for DNS-over-TCP without TLS. In other words,
software implementing this protocol is assumed to support idle,
persistent connections and be prepared to manage
multiple, potentially long-lived TCP connections.
</t>
<t>
This document does not make specific recommendations for timeout
values on idle connections. Clients and servers should reuse
and/or close connections depending on the level of available
resources. Timeouts may be longer during periods of low activity
and shorter during periods of high activity. Current work in
this area may also assist DNS-over-TLS clients and servers
select useful timeout values <xref
target="I-D.edns-tcp-keepalive"/> <xref target="tdns"/>.
</t>
<t>
Clients and servers that keep idle connections open MUST be
robust to termination of idle connection by either party. As
with current DNS-over-TCP, DNS servers MAY close the connection
at any time (perhaps due to resource constraints). As with current
DNS-over-TCP, clients MUST handle abrupt closes and be prepared
to reestablish connections and/or retry queries.
</t>
<t>
When reestablishing a DNS-over-TCP connection that was terminated,
as discussed in <xref target="I-D.ietf-dnsop-5966bis"/>, TCP Fast Open <xref
target="RFC7413"/> is of benefit.
Underlining the requirement for sending only encrypted
DNS data on a DNS-over-TLS port (Section 3.2), when
using TCP Fast Open the client and server MUST immediately
initiate or resume a TLS handshake (clear text DNS MUST
NOT be exchanged).
DNS servers SHOULD enable fast
TLS session resumption <xref target="RFC5077"/> and this SHOULD
be used when reestablishing connections.
</t>
<t>
When closing a connection, DNS servers SHOULD use the TLS
close-notify request to shift TCP TIME-WAIT state to the clients.
Additional requirements and guidance for optimizing DNS-over-TCP
are provided by <xref target="RFC5966"/>, <xref
target="I-D.ietf-dnsop-5966bis"/>.
</t>
</section>
</section>
<section anchor="profiles" title="Usage Profiles">
<t>
This protocol provides flexibility to accommodate several different use cases.
<!--
Two usage profiles are defined here to identify specific
design points in performance and privacy.
Other profiles are possible but are outside the scope of this document.
-->
This document defines two usage profiles: (1) opportunistic privacy, and
(2) out-of-band key-pinned authentication 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 <xref target="dgr-dprive-dtls-and-tls-profiles"/>.
</t>
<section title="Opportunistic Privacy Profile">
<t>
For opportunistic privacy, analogous to SMTP opportunistic
encryption <xref target="RFC7435"/> one does not require privacy,
but one desires privacy when
possible.
</t>
<t>
With opportunistic privacy, a client might learn of a TLS-enabled
recursive DNS resolver from an untrusted source (such as DHCP
while roaming), it might or might not validate the
resolver. These choices maximize availability and
performance, but they leave the client vulnerable to on-path attacks
that remove privacy.
</t>
<t>
Opportunistic privacy can be used by any current client, but
it only provides guaranteed privacy when there are no on-path
active attackers.
</t>
</section>
<!-- section title="Pre-Deployed Profile">
<t>
For pre-deployed privacy, the DNS client has one or more
trusted recursive DNS providers. This profile provides strong
privacy guarantees to the user.
</t>
<t>
With pre-deployed privacy, a client retains a copy of the TLS
certificate (and/or other authentication credentials as
appropriate) and IP address of each provider. The client
will only use DNS servers for which this information
has been pre-configured. The possession of a trusted,
pre-deployed TLS certificate allows the client to detect person-in-the-middle
and downgrade attacks.
</t>
<t>
With pre-deployed privacy, the DNS client MUST signal to the
user when none of the designated DNS servers are available,
and MUST NOT provide DNS service until at least one of the
designated DNS servers becomes available.
</t>
<t>
The designated DNS provider may be temporarily unavailable
when configuring a network. For example, for clients on
networks that require authentication through web-based login,
such authentication may rely on DNS interception and spoofing.
Techniques such as those used by DNSSEC-trigger <xref
target="dnssec-trigger"/> MAY be used during network
configuration, with the intent to transition to the designated
DNS provider after authentication. The user MUST be alerted
that the DNS is not private during such bootstrap.
</t>
<t>
Methods for pre-deployment of the designated DNS provider are
outside the scope of this document. In corporate settings,
such information may be provided at system installation.
</t>
</section -->
<section title="Out-of-band Key-pinned Privacy Profile">
<t>
The out-of-band key-pinned privacy profile can be used in
environments where an established trust relationship already
exists 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.
</t>
<t>
In this profile, clients authenticate servers by matching
a set of Subject Public Key Info (SPKI) Fingerprints in an analogous
manner to that described in <xref target="RFC7469"/>.
With this out-of-band key-pinned privacy profile, client administrators
SHOULD deploy a backup pin along with the primary pin, for the reasons explained in <xref target="RFC7469"/>.
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 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.
</t>
<t>
Such a client will only use DNS servers for which an SPKI
Fingerprint pinset has been provided.
The possession of trusted pre-deployed pinset
allows the client to detect and prevent person-in-the-middle and
downgrade attacks.
</t>
<t>
However, a configured DNS server may be temporarily unavailable
when configuring a network. For example, for clients on
networks that require authentication through web-based login,
such authentication may rely on DNS interception and spoofing.
Techniques such as those used by DNSSEC-trigger <xref
target="dnssec-trigger"/> MAY be used during network
configuration, with the intent to transition to the designated
DNS provider after authentication. The user MUST be alerted
that the DNS is not private during such bootstrap.
</t>
<!-- t>
DNS clients configured for out-of-band key-pinned privacy MUST
authenticate the SPKI from the server certificate as follows
(based on section 2.6 of <xref target="RFC7469"/>):
</t -->
<!-- t>
When a client connects to a server over TLS, if the TLS connection
has errors, the client MUST terminate the connection without
transmitting any queries to the server.
</t -->
<!-- t>
If the connection has no errors, the client MUST check the SPKI
Fingerprint as soon as possible (e.g., immediately after receiving
the Server Certificate message).
</t -->
<t>
Upon successful TLS connection and handshake, the client
computes the SPKI Fingerprints for the public keys found
in the validated server's 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. <xref target="example"/> provides a detailed example
of how this authentication could be performed in practice.
</t>
</section>
</section>
<section anchor="Performance" title="Performance Considerations">
<t>
DNS-over-TLS incurs additional latency at session startup. It
also requires additional state (memory) and increased processing
(CPU).
<list style="numbers">
<t>
Latency:
Compared to UDP, DNS-over-TCP requires an additional
round-trip-time (RTT) of latency to establish a TCP connection.
TCP Fast Open <xref target="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 <xref target="RFC5077"/> further reduces the
setup delay and avoids the DNS server keeping per-client session state.
TLS False Start <xref target="draft-ietf-tls-falsestart"/> can also lead to a latency
reduction in certain situations.
</t>
<t>
State:
The use of connection-oriented TCP requires keeping additional
state at the server in both the kernel and application.
The state requirements
are of particular concern on servers with many clients,
although memory-optimized TLS can add only modest state over TCP.
Smaller timeout values will reduce the number of concurrent
connections, and servers can preemptively close connections
when resource limits are exceeded.
</t>
<t>
Processing:
Use of TLS encryption algorithms results in slightly higher
CPU usage. Servers can choose to refuse new DNS-over-TLS
clients if processing limits are exceeded.
</t>
<t>
Number of connections: To minimize state on DNS servers and
connection startup time, clients SHOULD minimize creation
of new TCP connections. Use of a local DNS request aggregator
(a particular type of forwarder) allows a single active
DNS-over-TLS connection from any given client computer to
its server. Additional guidance can be found in <xref
target="I-D.ietf-dnsop-5966bis"/>.
</t>
</list>
A full performance evaluation is outside the scope of this
specification. A more detailed analysis of the performance
implications of DNS-over-TLS (and DNS-over-TCP) is discussed
in <xref target="tdns"/> and <xref
target="I-D.ietf-dnsop-5966bis"/>.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
IANA is requested to add the following value to the "Service Name
and Transport Protocol Port Number Registry" registry in the System
Range. The registry for that range requires IETF Review or IESG Approval
<xref target="RFC6335"/> and such a review was requested using the
Early Allocation process <xref target="RFC7120"/> for the well-known TCP port
in this document.
</t>
<t>
We further recommend that IANA reserve the same port number over UDP
for the proposed DNS-over-DTLS protocol <xref
target="draft-ietf-dprive-dnsodtls"/>.
</t>
<t>
IANA responded to the early allocation request with the following
TEMPORARY assignment:
</t>
<figure>
<artwork><![CDATA[
Service Name domain-s
Port Number 853
Transport Protocol(s) TCP/UDP
Assignee IETF DPRIVE Chairs
Contact Paul Hoffman
Description DNS query-response protocol run over TLS/DTLS
Reference This document
]]></artwork>
</figure>
<t>
The TEMPORARY assignment expires 2016-10-08. IANA is requested to make the
assigmnent permanent upon publication of this document as an RFC.
</t>
</section>
<section anchor="Evolution" title="Design Evolution">
<t>
[Note to RFC Editor: please do not remove this section prior to publication
as it may be useful to future Foo-over-TLS efforts]
</t>
<t>
Earlier versions of this document
proposed an upgrade-based approach 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
would signal its acceptance by responding with the TLS OK
bit set.
</t>
<t>
Since we assume the client doesn't want to reveal (leak)
any information prior to securing the channel, we proposed
the use of a "dummy query" that clients could send for this
purpose. The proposed query name was STARTTLS, query type
TXT, and query class CH.
</t>
<t>
The TLS OK signaling approach has both advantages and
disadvantages. One important advantage is that clients and
servers could negotiate TLS. If the server is too busy,
or doesn't want to provide TLS service to a particular
client, it can respond negatively to the TLS probe. An
ancillary benefit is that servers could collect information
on adoption of DNS-over-TLS (via the TLS OK bit in queries)
before implementation and deployment. Another anticipated
advantage is the expectation that DNS-over-TLS would work
over port 53. That is, no need to "waste" another port and
deploy new firewall rules on middleboxes.
</t>
<t>
However, at the same time, there was uncertainty whether
or not middleboxes would pass the TLS OK bit, given that
the EDNS0 flags field has been unchanged for many years.
Another disadvantage is that the TLS OK bit may make downgrade
attacks easy and indistinguishable from broken middleboxes.
From a performance standpoint, the upgrade-based approach
had the disadvantage of requiring 1xRTT additional latency
for the dummy query.
</t>
<t>
Following this proposal, DNS-over-DTLS was proposed separately.
DNS-over-DTLS claimed it could work over port 53, but only
because a non-DTLS server interprets a DNS-over-DTLS query
as a response. That is, the non-DTLS server observes the
QR flag set to 1. While this technically works, it seems
unfortunate and perhaps even undesirable.
</t>
<t>
DNS over both TLS and DTLS can benefit from a single
well-known port and avoid extra latency and mis-interpreted
queries as responses.
</t>
</section>
<section anchor="Implementation" title="Implementation Status">
<t>
[Note to RFC Editor: please remove this section and reference to
RFC 6982 prior to publication.]
</t>
<t>
This section records the status of known implementations of the
protocol defined by this specification at the time of posting
of this Internet-Draft, and is based on a proposal described
in RFC 6982. The description of implementations in this section
is intended to assist the IETF in its decision processes in
progressing drafts to RFCs. Please note that the listing of
any individual implementation here does not imply endorsement
by the IETF. Furthermore, no effort has been spent to verify
the information presented here that was supplied by IETF
contributors. This is not intended as, and must not be construed
to be, a catalog of available implementations or their features.
Readers are advised to note that other implementations may
exist.
</t>
<t>
According to RFC 6982, "this will allow reviewers and working
groups to assign due consideration to documents that have the
benefit of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented
protocols more mature. It is up to the individual working
groups to use this information as they see fit".
</t>
<section title="Unbound">
<t>
The Unbound recursive name server software added support for
DNS-over-TLS in version 1.4.14. The unbound.conf configuration file
has the following configuration directives: ssl-port, ssl-service-key,
ssl-service-pem, ssl-upstream. See https://unbound.net/documentation/unbound.conf.html.
</t>
</section>
<section title="ldns">
<t>
Sinodun Internet Technologies has implemented DNS-over-TLS
in the ldns library from NLnetLabs. This also gives DNS-over-TLS
support to the drill DNS client program. Patches available
at
https://portal.sinodun.com/stash/projects/TDNS/repos/dns-over-tls_patches/browse.
</t>
</section>
<section title="digit">
<t>
The digit DNS client from USC/ISI supports DNS-over-TLS.
Source code available at http://www.isi.edu/ant/software/tdns/index.html.
</t>
</section>
<section title="getdns">
<t>
The getdns API implementation supports DNS-over-TLS.
Source code available at https://getdnsapi.net.
</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>
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 address other security issues in DNS, and there are a
number of residual risks that may affect its success at protecting
privacy:
<list style="numbers">
<t>
There are known attacks on TLS, such as person-in-the-middle
and protocol downgrade. These are general attacks on TLS
and not specific to DNS-over-TLS; please refer to the TLS
RFCs for discussion of these security issues.
Clients and
servers MUST adhere to the TLS implementation recommendations
and security considerations of <xref target="RFC7525"/> or its successor.
DNS clients keeping track of servers known to support TLS
enables clients to detect downgrade attacks.
For servers with no connection history and no apparent
support for TLS, depending on their Privacy
Profile and privacy requirements, clients may choose to (a) try another server when
available, (b) continue without TLS, or (c) refuse to
forward the query.
</t>
<t>
Middleboxes <xref target="RFC3234"/> are present in some
networks and have been known to interfere with normal DNS
resolution.
Use of a designated port for DNS-over-TLS
should avoid such interference.
In general, clients that attempt TLS and fail can either fall
back on unencrypted DNS, or wait and retry later, depending
on their Privacy Profile and privacy requirements.
</t>
<!--
XXX The authors debated whether or not the following
paragraph belongs in the document. On one hand,
person-in-the-middle attacks are generally about data
integrity, which would be protected by DNSSEC rather
than TLS. On the other hand, it specifically calls out
server capabilities, which is something that clients
learn via responses and is not protected by DNSSEC.
-->
<t>
Any DNS protocol interactions
performed in the clear can be modified by a person-in-the-middle
attacker. For example, unencrypted queries and responses
might take place over port 53 between a client and server.
For this reason, clients MAY discard cached
information about server capabilities advertised in clear text.
</t>
<t>
This document does not itself specify ideas to resist
known traffic analysis or side channel leaks. Even with encrypted
messages, a well-positioned party may be able to glean
certain details from an analysis of message timings and
sizes. Clients and servers may consider the use of a padding
method to address privacy leakage due to message sizes
<xref target="I-D.edns0-padding"/>
</t>
<!-- <t>
Applications and systems using encrypted DNS queries have a
later risk of exposing the same names they encrypted in DNS
in cleartext protocol exchanges outside of DNS such as the TLS Server Name
Indication (SNI) extension. Mitigating this privacy risk is part of the
work in progress on TLS 1.3 <xref target="I-D.tls13"/>
</t> -->
</list>
</t>
</section>
<section anchor="contrib" title="Contributing Authors">
<t>
The below individuals contributed significantly to the draft. The
RFC Editor prefers a maximum of 5 names on the front page, and so
we have listed additional authors in this section.
</t>
<figure>
<artwork><![CDATA[
Sara Dickinson
Sinodun Internet Technologies
Magdalen Centre
Oxford Science Park
Oxford OX4 4GA
UK
Email: sara@sinodun.com
URI: http://sinodun.com
Daniel Kahn Gillmor
ACLU
125 Broad Street, 18th Floor
New York, NY 10004
USA
]]></artwork>
</figure>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>
The authors would like to thank
Stephane Bortzmeyer,
John Dickinson,
Brian Haberman,
Christian Huitema,
Shumon Huque,
Kim-Minh Kaplan,
Simon Joseffson,
Simon Kelley,
Warren Kumari,
John Levine,
Ilari Liusvaara,
Bill Manning,
George Michaelson,
Eric Osterweil,
Jinmei Tatuya,
Tim Wicinski,
and
Glen Wiley
for reviewing this Internet-draft.
They also thank
Nikita Somaiya for early work on this idea.
</t>
<t>
Work by Zi Hu, Liang Zhu, and John Heidemann on this document is
partially sponsored by the U.S. Dept. of Homeland Security (DHS)
Science and Technology Directorate, HSARPA, Cyber Security
Division, BAA 11-01-RIKA and Air Force Research Laboratory,
Information Directorate under agreement number FA8750-12-2-0344,
and contract number D08PC75599.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC2119;
&RFC1034;
&RFC1035;
&RFC5246;
<!-- &RFC6891; -->
&RFC5077;
&RFC6335;
<reference anchor='I-D.ietf-dnsop-5966bis'>
<front>
<title>DNS Transport over TCP - Implementation Requirements</title>
<author initials='J' surname='Dickinson' fullname='John Dickinson'>
<organization />
</author>
<author initials='S' surname='Dickinson' fullname='Sara Dickinson'>
<organization />
</author>
<author initials='R' surname='Bellis' fullname='Ray Bellis'>
<organization />
</author>
<author initials='A' surname='Mankin' fullname='Allison Mankin'>
<organization />
</author>
<author initials='D' surname='Wessels' fullname='Duane Wessels'>
<organization />
</author>
<date month='July' day='6' year='2015' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-dnsop-5966bis-02' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-dnsop-5966bis-02.txt' />
</reference>
&RFC7120;
&RFC7469;
&RFC7525;
</references>
<references title="Informative References">
<!-- &RFC1939; -->
<!-- &RFC2131; -->
<!-- &RFC2595; -->
&RFC2818;
<!-- &RFC3207; -->
&RFC3234;
<!-- &RFC3501; -->
&RFC4033;
<!-- &RFC4892; -->
&RFC5280;
&RFC5966;
&RFC6698;
&RFC7258;
&RFC7413;
&RFC7435;
&RFC7626;
<!-- <reference anchor='I-D.ietf-dprive-problem-statement'>
<front>
<title>DNS privacy considerations</title>
<author initials='S' surname='Bortzmeyer' fullname='Stephane Bortzmeyer'>
<organization />
</author>
<date month='October' day='26' year='2014' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-dprive-problem-statement-06' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-dprive-problem-statement-06.txt' />
</reference> -->
<reference anchor="I-D.ipseca" target="http://tools.ietf.org/html/draft-osterweil-dane-ipsec-03">
<front>
<title>Opportunistic Encryption with DANE Semantics and IPsec: IPSECA</title>
<author initials="E." surname="Osterweil" fullname="Eric Osterweil">
<organization abbrev="VeriSign">VeriSign, Inc</organization>
<address></address>
</author>
<author initials="G." surname="Wiley" fullname="Glen Wiley">
<organization abbrev="VeriSign">VeriSign, Inc</organization>
<address></address>
</author>
<author initials="T." surname="Okubo" fullname="Tomofumi Okubo">
<organization abbrev="VeriSign">Verisign, Inc</organization>
<address></address>
</author>
<author initials="R." surname="Lavu" fullname="Ramana Lavu">
<organization abbrev="VeriSign">VeriSign, Inc</organization>
<address></address>
</author>
<author initials="A." surname="Mohaisen" fullname="Aziz Mohaisen">
<organization abbrev="Buffalo">SUNY Buffalo</organization>
<address></address>
</author>
<date month="July" year="2015" />
</front>
<seriesInfo name="Internet-Draft" value="draft-osterweil-dane-ipsec-03"/>
</reference>
<!-- ><reference anchor="unbound" target="http://unbound.net/">
<front>
<title>Unbound</title>
<author>
<organization abbrev="NLnet_Verisign">NLnet Labs, Verisign labs</organization>
<address></address>
</author>
<date year="2013" />
</front>
</reference> -->
<reference anchor="dnssec-trigger" target="https://www.nlnetlabs.nl/projects/dnssec-trigger/">
<front>
<title>Dnssec-Trigger</title>
<author>
<organization abbrev="NLnet">NLnet Labs</organization>
<address></address>
</author>
<date month="May" year="2014" />
</front>
</reference>
<reference anchor="dempsky-dnscurve" target="http://tools.ietf.org/html/draft-dempsky-dnscurve-01">
<front>
<title>DNSCurve</title>
<author initials="M." surname="Dempsky" fullname="Matthew Dempsky">
<organization abbrev="OpenDNS">OpenDNS, INC.</organization>
<address></address>
</author>
<date month="August" year="2010" />
</front>
<seriesInfo name="Internet-Draft" value="draft-dempsky-dnscurve-01" />
</reference>
<reference anchor="dgr-dprive-dtls-and-tls-profiles" target="https://tools.ietf.org/html/draft-dgr-dprive-dtls-and-tls-profiles-00">
<front>
<title>Authentication and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS</title>
<author initials="S." surname="Dickinson" fullname="Sara Dickinson">
<organization abbrev="Sinodun">Sinodun Internet Technologies</organization>
<address></address>
</author>
<author initials="D." surname="Gillmor" fullname="Dan Gillmor">
<organization abbrev="ACLU">ACLU</organization>
<address></address>
</author>
<author initials="T." surname="Reddy" fullname="Tirumaleswar Reddy">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address></address>
</author>
<date month="December" year="2015"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-dgr-dprive-dtls-and-tls-profiles-00" />
</reference>
<reference anchor="I-D.edns0-padding" target="http://tools.ietf.org/html/draft-mayrhofer-edns0-padding-01">
<front>
<title>The EDNS(0) Padding Option</title>
<author initials='A.' surname="Mayrhofer" fullname="Anton Mayrhofer">
<organization abbrev="nic.at GmBH" />
</author>
<date month='August' day='14' year='2015' />
</front>
<seriesInfo name='Internet-Draft' value='draft-mayrhofer-edns0-padding-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-mayrhofer-edns0-padding-01.txt' />
</reference>
<!-- ><reference anchor="CA_Compromise" target="http://www.infosecisland.com/blogview/19782-Web-Authentication-A-Broken-Trust-with-No-Easy-Fix.html">
<front>
<title>CA Compromise</title>
<author>
<organization abbrev="Infosec">Infosec Island Admin</organization>
<address></address>
</author>
<date month="January" year="2012" />
</front>
</reference> -->
<!-- reference anchor="crime-attack" target="https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls">
<front>
<title>The CRIME attack against TLS</title>
<author initials="J." surname="Rizzo" fullname="Juliano Rizzo">
<address/>
</author>
<author initials="T." surname="Duong" fullname="Thai Duong">
<address/>
</author>
<date month="September" year="2012" />
</front>
</reference -->
<!-- <reference anchor="certificate_pinning" target="https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning">
<front>
<title>Certificate and Public Key Pinning</title>
<author>
<organization abbrev="OWASP">OWASP</organization>
<address></address>
</author>
<date year="2014" />
</front>
</reference>
-->
<reference anchor="I-D.confidentialdns" target="http://tools.ietf.org/html/draft-wijngaards-dnsop-confidentialdns-03">
<front>
<title>Confidential DNS</title>
<author initials="W." surname="Wijngaards" fullname="Wouter Wijngaards">
<organization abbrev="NLnet Labs">NLnet Labs</organization>
<address></address>
</author>
<date month="March" year="2015" />
</front>
<seriesInfo name="Internet-Draft" value="draft-wijngaards-dnsop-confidentialdns-03" />
</reference>
<reference anchor="I-D.edns-tcp-keepalive" target="http://tools.ietf.org/html/draft-ietf-dnsop-edns-tcp-keepalive-02">
<front>
<title>The edns-tcp-keepalive EDNS0 Option</title>
<author initials="P." surname="Wouters" fullname="Paul Wouters">
<organization abbrev="Red Hat">Red Hat</organization>
<address></address>
</author>
<author initials="J." surname="Abley" fullname="Joe Abley">
<organization abbrev="Dyn Inc.">Dyn Inc.</organization>
<address></address>
</author>
<author initials="S." surname="Dickinson" fullname="Sara Dickinson">
<organization abbrev="Sinodun">Sinodun</organization>
<address></address>
</author>
<author initials="R." surname="Bellis" fullname="Ray Bellis">
<organization abbrev="ISC">ISC</organization>
<address></address>
</author>
<date month="July" year="2015" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-edns-tcp-keepalive-02" />
</reference>
<reference anchor="tdns" target="Technical report, ISI-TR-688, ftp://ftp.isi.edu/isi-pubs/tr-688.pdf">
<front>
<title>T-DNS: Connection-Oriented DNS to Improve Privacy and Security</title>
<author initials="L." surname="Zhu" fullname="Liang Zhu"/>
<author initials="Z." surname="Hu" fullname="Zi Hu"/>
<author initials="J." surname="Heidemann" fullname="John Heidemann"/>
<author initials="D." surname="Wessels" fullname="Duane Wessels"/>
<author initials="A." surname="Mankin" fullname="Allison Mankin"/>
<author initials="N." surname="Somaiya" fullname="Nikita Somaiya"/>
<date month="February" year="2014" />
</front>
<seriesInfo name="Technical report" value="ISI-TR-688" />
</reference>
<reference anchor="draft-ietf-tls-falsestart" target="http://tools.ietf.org/html/draft-ietf-tls-falsestart-00">
<front>
<title>Transport Layer Security (TLS) False Start</title>
<author initials="B." surname="Moeller" fullname="Bodo Moeller">
<organization abbrev="Google">Google Switzerland GmbH</organization>
<address></address>
</author>
<author initials="A." surname="Langley" fullname="Adam Langley">
<organization abbrev="Google">Google Inc.</organization>
<address></address>
</author>
<date month="November" year="2014" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-falsestart-00" />
</reference>
<reference anchor="draft-ietf-dprive-dnsodtls" target="https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-01">
<front>
<title>DNS over DTLS (DNSoD)</title>
<author initials="T." surname="Reddy" fullname="Tirumaleswar Reddy">
<organization abbrev="Cisco">Cisco</organization>
<address></address>
</author>
<author initials="D." surname="Wing" fullname="Dan Wing">
<organization abbrev="Cisco">Cisco</organization>
<address></address>
</author>
<author initials="P." surname="Patil" fullname="Prashanth Patil">
<organization abbrev="Cisco">Cisco</organization>
<address></address>
</author>
<date month="June" year="2015" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-dprive-dnsodtls-01" />
</reference>
</references>
<section title="Out-of-band Key-pinned Privacy Profile Example" anchor="example">
<t>
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.
</t>
<t>
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 <xref
target="RFC7469">HPKP</xref> style, the pins are:
<list style="symbols">
<t>
pin-sha256="FHkyLhvI0n70E47cJlRTamTrnYVcsYdjUGbr79CfAVI="
</t>
<t>
pin-sha256="dFSY3wdPU8L0u/8qECuz5wtlSgnorYV2f66L6GNQg6w="
</t>
</list>
</t>
<t>
The client also configures the IP addresses of its
expected DNS server, 192.0.2.3 and 192.0.2.4.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
</back>
</rfc>
<!-- LocalWords: Rey McClintock RTH subdomain scalable johnh DNSEXT TXT
-->
<!-- LocalWords: ns Vixie subdomains RRs querier's DNSSEC TLS SMTP
-->
<!-- LocalWords: hostname EDNS ISC IANA wrt conf Ds Verisign Reston
-->
<!-- LocalWords: Bluemont DNSCurve ConfidentialDNS IMAP IETF RCODE
-->
<!-- LocalWords: QNAME QCLASS QTYPE RDATA CAs Bortzmeyer Haberman
-->
<!-- LocalWords: Minh Kaplan Michaelson AFNIC NLnet Infosec OWASP
-->
<!-- LocalWords: edns tcp keepalive Dyn IPSECA pre TBD fallbacks Hu
-->
<!-- LocalWords: gethostbyname Stephane Osterweil Somaiya Liang Zhu
-->
<!-- LocalWords: HSARPA RIKA FA8750 D08PC75599 IPsec VeriSign
-->
| PAFTECH AB 2003-2026 | 2026-04-23 23:11:15 |