One document matched: draft-wing-dnsop-dnsodtls-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-wing-dnsop-dnsodtls-00"
ipr="trust200902">
<front>
<title abbrev="DNS over DTLS (DNSoD)">DNS over DTLS (DNSoD)</title>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>tireddy@cisco.com</email>
</address>
</author>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>California</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<author fullname="Prashanth Patil" initials="P." surname="Patil">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street/>
<street/>
<city>Bangalore</city>
<country>India</country>
</postal>
<email>praspati@cisco.com</email>
</address>
</author>
<date />
<workgroup>DNSOP Working Group</workgroup>
<abstract>
<t>DNS queries and responses are visible to network elements on
the path between the DNS client and its server. These queries
and responses can contain privacy-sensitive information which is
valuable to protect. An active attacker can send bogus
responses causing misdirection of the subsequent connection.</t>
<t>To counter passive listening and active attacks, this
document proposes the use of Datagram Transport Layer Security
(DTLS) for DNS, to protect against passive listeners and certain
active attacks. As DNS needs to remain fast, this proposal also
discusses mechanisms to reduce DTLS round trips and reduce DTLS
handshake size. The proposed mechanism runs over the default
DNS port and can also run over an alternate port.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>The Domain Name System is specified in
<xref target="RFC1034"/> and <xref target="RFC1035"/>. DNS
queries and responses are normally exchanged unencrypted and are
thus vulnerable to eavesdropping. Such
eavesdropping can result in an undesired entity learning domains
that a host wishes to access, thus resulting in privacy
leakage. DNS privacy problem is further discussed in
<xref target="I-D.bortzmeyer-dnsop-dns-privacy"/>.</t>
<t>Active attackers have long been successful at injecting bogus
responses, causing cache poisoning and causing misdirection of
the subsequent connection (if attacking A or AAAA records). A
popular mitigation against that attack is to use ephemeral and
random source ports for DNS queries.</t>
<t>This document defines DNS over DTLS (DNSoD, pronounced
"dee-enn-sod") which provides confidential DNS communication for
stub resolvers, recursive resolvers, iterative resolvers and
authoritative servers.</t>
</section>
<section title="Relationship to TCP Queries and to DNSSEC">
<t>DNS queries can be sent over UDP or TCP. This document scope is
only UDP. DNS over TCP could be protected with TLS, such as described
by <xref target="I-D.hzhwm-start-tls-for-dns"/>. Alternatively, a
shim protocol could be defined between DTLS and DNS, allowing
large responses to be sent over DTLS itself, see
<xref target="performance"/>.</t>
<t>DNS Security Extensions
(<xref target="RFC4033">DNSSEC</xref>) provides object integrity
of DNS resource records, allowing end-users (or their resolver)
to verify legitimacy of responses. However, DNSSEC does not
protect privacy of DNS requests or responses. DNSoD works in
conjunction with DNSSEC, but DNSoD does not replace the need or
value of DNSSEC.</t>
</section>
<section anchor="term" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119"/>.</t>
</section>
<section anchor="problem_stmt" title="Incremental Deployment">
<t>DNSoD can be deployed incrementally by the Internet Service
Provider or as an Internet service.</t>
<t>If the ISP's DNS resolver supports DNSoD, then DNS queries are
protected from passive listening and from many active attacks along
that path.</t>
<t>DNSoD can be offered as an Internet service, and a stub
resolver or DNS resolver can be configured to point to that
DNSoD server (rather than to the ISP-provided DNS server).</t>
</section>
<section anchor="demux" title="Demultiplexing, Polling, Port Usage, and Discovery">
<t>[Note - This section requires further discussion]</t>
<t>Many modern operating systems already detect if a web proxy is
interfering with Internet communications, using proprietary
mechanisms that are out of scope of this document. After that
mechanism has run (and detected Internet connectivity is
working), the DNSoD procedure described in this document
should commence. This timing avoids delays in joining the
network (and displaying an icon indicating successful Internet
connection), at the risk that those initial DNS queries will be
sent without protection afforded by DNSoD.</t>
<t>DNSoD can run over standard UDP port 53 as defined in
<xref target="RFC1035"/>. A DNS client or server that does not
implement this specification will not respond to the incoming
DTLS packets because they don't parse as DNS packets (the DNS
Opcode would be 15, which is undefined). A DNS client or server
that does implement this specification can demultiplex DNS and
DTLS packets by examining the third octet. For TLS 1.2, which is
what is defined by this specification, a DTLS packet will contain
253 in the third octet, whereas a DNS packet will never contain
253 in the third octet.</t>
<t>There has been some concern with sending DNSoD traffic
over the same port as normal, un-encrypted DNS traffic. The intent
of this section is to show that DNSoD could successfully
be sent over port 53. Further analysis and testing on the Internet
may be valuable to determine if multiplexing on port 53, using
a separate port, or some fallback between a separate port and port
53 brings the most success.</t>
<t>After performing the above steps, the host should determine
if the DNS server supports DNSoD by sending a DTLS ClientHello
message. A DNS server that does not support DNSoD will not
respond to ClientHello messages sent by the client, because they
are not valid DNS requests (specifically, the DNS Opcode is
invalid). The client MUST use timer values defined in Section 4.2.4.1
of <xref target="RFC6347"/> for retransmission of ClientHello
message and if no response is received from the DNS server.
After 15 seconds, it MUST cease attempts to re-transmit its
ClientHello. Thereafter, the client MAY repeat that procedure
in the event the DNS server has been upgraded to support DNSoD,
but such probing SHOULD NOT be done more frequently than every
24 hours and MUST NOT be done more frequently than every 15
minutes. This mechanism requires no additional signaling
between the client and server.</t>
</section>
<section anchor="performance" title="Performance Considerations">
<t>To reduce number of octets of the DTLS handshake, especially the
size of the certificate in the ServerHello (which can be several
kilobytes), we should consider using plain public keys
<xref target="I-D.ietf-tls-oob-pubkey"/>. Considering that to
authorize a certain DNS server the client already needs explicit
configuration of the DNS servers it trusts, maybe the public key
configuration problem is really no worse than the configuration
problem of those whitelisted certificates?</t>
<t>Multiple DNS queries can be sent over a single DNSoD security
association. The existing QueryID allows multiple requests and
responses to be interleaved in whatever order they can be fulfilled by
the DNS server. This means DNSoD reduces the consumption of UDP port
numbers, and because DTLS protects the communication between the DNS
client and its server, the resolver SHOULD NOT use random ephemeral
source ports (Section 9.2 of <xref target="RFC5452"/>) because such
source port use would incur additional, unnecessary DTLS load on the
DNSoD server.</t>
<t>It is highly advantageous to avoid server-side DTLS state and
reduce the number of new DTLS security associations on the server
which can be done with <xref target="RFC5077"/>. This also eliminates
a round-trip for subsequent DNSoD queries, because with
<xref target="RFC5077"/> the DTLS security association does not need
to be re-established. Note: with the shim (described below) perhaps
we could send the query and the restore server-side state in the
ClientHello packet.</t>
<t>Compared to normal DNS, DTLS adds at least 13 octets of header,
plus cipher and authentication overhead to every query and every
response. This reduces the size of the DNS payload that can be
carried. Certain DNS responses are large (e.g., many AAAA records,
TXT, SRV) and don't fit into a single UDP packet, causing a partial
response with the truncation (TC) bit set. The client is then
expected to repeat the query over TCP, which causes additional name
resolution delay. We have considered two ideas, one that reduces the
need to switch to TCP and another that eliminates the need to switch
to TCP:
<list style="symbols"><t>Path MTU can be determined
using <xref target="RFC4821">Packetization Layer Path MTU
Discovery</xref> using DTLS heartbeat. <xref target="RFC4821"/> does
not rely on ICMP or ICMPv6, and would not affect DNS state or
responsiveness on the client or server. However, it would be
additional chattiness.</t>
<t>To avoid IP fragmentation, DTLS handshake messages incorporate their
own fragment offset and fragment length. We might utilize a similar
mechanism in a shim layer between DTLS and DNS, so that large DNS
messages could be carried without causing IP fragmentation.</t>
</list></t>
<t>DNSoD puts an additional computational load on servers. The
largest gain for privacy is to protect the communication between the
DNS client (the end user's machine) and its caching resolver. Because
of the load imposed, and because of the infrequency of queries to root
servers means the DTLS overhead is unlikely to be amoritized over the
DNS queries sent over that DTLS connection, implementing DNSoD on root
servers is NOT RECOMMENDED.</t>
</section>
<section anchor="in_band_signaling" title="In-Band Signaling">
<t>Probing with DTLS ClientHello packets to determine if a DNS
server supports DNSoD is somewhat inefficient, as it requires multiple
probe packets to each DNS server. It may well be preferable to have a
method of determining, within the DNS protocol itself, if a certain
DNS server supports DNSoD. Two approaches are discussed below, one
using DNS SRV query or <xref target="RFC4892">Name Server
Instance</xref> query, and another extending the EDNS0 OPT meta-RR
<xref target="I-D.hzhwm-start-tls-for-dns"/> to describe DNSoD
support.</t>
<t>To use <xref target="RFC4892">Name Server Instance</xref> query, we
would define a new CHAOS class resource record. The name is not
significant, so let's pretend it would be called "DNSoD". Note:
we might to indicate an alternate port, querying a CHAOS SRV
resource record is probably most ideal.</t>
<t>To extend the EDNS0 OPT meta-RR defined in
<xref target="I-D.hzhwm-start-tls-for-dns"/>, we can add another bit
indicating support for DNSoD, denoted as "SO". Clients and servers
indicate their support for, and desire to use, DNSoD by
setting a bit in the Flags field of the EDNS0 <xref target="RFC6891"/>
OPT meta-RR. The "DTLS OK" (SO) bit is defined as the third bit of the
third and fourth bytes of the "extended RCODE and flags" portion of
the EDNS0 OPT meta-RR, immediately adjacent to the "TLS OK" (TO) bit
defined in <xref target="I-D.hzhwm-start-tls-for-dns"/>, as shown below:</t>
<figure align="center">
<artwork align="center"><![CDATA[
+0 (MSB) +1 (LSB)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2: |DO|TO|SO| Must be zero |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+]]></artwork>
</figure>
</section>
<!--
<section title="Use by DNS clients">
-->
<section title="Authenticating a DNS Server">
<t>As DTLS provides integrity protection, some protection from on-path
attackers sending bogus responses is provided by simply using
DTLS. That is, a device on the path between a DNS client and
its DNS server cannot simply inject a bogus DNS response, as
could be done with normal DNS. However, that protection is not
terribly strong, because that attacker could intercept the DTLS
handshake itself and pretend to be the actual DNS server. To
prevent that, we need to resolve two problems: identifying the
trusted servers and determining an appropriate action when no
trusted servers are available.</t>
<t>The first problem, of identifying the legitimate server,
requires extending the host configuration. This is because DNS
clients have their DNS servers configured by IP address (from
DHCP or from a local configuration file such as
/etc/resolv.conf), but certificates have a DNS name in the
SubjectAltName field. We can't change how certificates are
issued, but we already have to modify the DNS client to support
DNSoD. With that in mind, the DNS client would have a
list of SubjectAltNames it trusts, configured by the user. That
could be configured in the resolv.conf file itself, as shown below,
or could be maintained in a separate file.</t>
<figure align="center">
<artwork align="center"><![CDATA[nameserver 192.0.2.1 dns.example.net
nameserver 198.51.100.1 dns.example.com]]></artwork>
</figure>
<t>The second problem is determining an appropriate action when
no trusted servers are available. Although the DNS client could
still use DNSoD with an un-trusted server which still
provides protection from on-path passive listeners and from on-
and off-path active attackers, this use does not protect from a
malicious server returning bogus responses. While DNSSEC can protect
against bogus responses (lies), DNSSEC cannot protect against a
server that simply does not return certain answers.
<list style="empty"><t>[[Editor's Note: Is there more we could
do? Trust certain responses (like for my enterprise VPN or other
sites where I will be doing a TLS handshake)? Keep in mind that
with web portals at hotels/airports, we won't have access to a
trusted DNS server on initial connect at all.]] </t></list></t>
</section>
<!--
dwing: this section needs a re-write
<section title="Sending Queries">
<t>DNS clients MAY set the SO bit in queries sent using UDP
transport to signal their general ability to support DNSoD.
[For discussion: is this a bad idea because ignorant middleboxes
might drop the SO=1 UDP queries?]</t>
<t>DNS clients MAY set the SO bit in the initial query sent to a
server using UDP transport to signal their desire that the UDP
connection be upgraded to DTLS. DNS clients MUST NOT set the SO bit
on subsequent queries when already using DNSoD.</t>
<t>Since the motivation for DNSoD is to preserve
privacy, DNS clients SHOULD use a query that reveals no
private information in the initial SO=1 query to a
server. To provide a standard "dummy" query, it is
RECOMMENDED to do a CHAOS SRV resource record query
<xref target="RFC4892"/>.</t>
<t>After sending the initial SO=1 query using UDP transport, DNS
clients MUST wait for the initial response before sending any
subsequent queries over the same UDP connection.</t>
</section>
<section title="Receiving Responses">
<t>A DNS client that receives a response that matches its outstanding
request with the Meta RR with the SO bit set SHOULD record
the server's support for DNSoD and use that information as
part of its server selection algorithm in the case where multiple
servers are available to service a particular query. [For
discussion: UDP is subject to spoofing and a client which depends on
SO=1 in a UDP response may be tricked into never upgrading to
DTLS.]</t>
<t>A DNS client that receives a response to its initial query using
UDP transport that has the SO bit set SHOULD immediately initiate a
DTLS handshake using the procedure described in <xref
target="RFC6347"/>.</t>
<t>A DNS client that receives a response to its initial query using
UDP transport that has the SO bit clear MUST not initiate a DTLS
handshake and SHOULD utilize the existing UDP connection for
subsequent queries. DNS clients SHOULD remember server IP addresses
that don't support DNSoD and SHOULD NOT request DNSoD
from them for reasonable period. (We suggest 1 hour, or when
the client discovers a new resolver)</t>
</section>
</section>
-->
<!-- dwing: this section also needs a re-write. What new thing are we
trying to explain? We need more than just how to handle the Meta RR;
we need to describe how to demultiplex the arriving packet (DNS or
DTLS)
<section title="Use by DNS Servers">
<section title="Receiving a Query">
<t>A DNS server receiving a query over TCP with the EDNS0
OPT meta Resource Record with the SO bit set it MUST ignore that
SO bit. [Editor's Note: is there interoperability harm if
it responds properly to that query?].</t>
<t>A DNS server receiving a query over an existing DTLS session MUST
ignore the SO bit.</t>
why ignore? what harm occurs?
<t>A DNS server receiving an initial query over UDP that has the SO
bit set MAY inform the client it is willing to establish a DTLS
session, as described in the next section.</t>
<t>A DNS server receiving subsequent queries over a DTLS session
MUST ignore the SO bit.</t>
</section>
<section title="Sending Responses">
<t>A DNS server sending a response over UDP SHOULD set the SO bit to
indicate its general support for DNS over DTLS, as long as it is
willing and able to support a DTLS connection with the particular
client. A DNS server receiving an initial query over UDP that has
the SO bit set MAY set the TO bit in its response. The server MUST
then proceed with the DTLS handshake protocol. A DNS server
receiving a "dummy" STARTDTLS/CH/TXT query over UDP MUST respond
with RCODE=0 and a TXT RR in the Answer section. Contents of the TXT
RR are strictly informative (for humans) and MUST NOT be interpreted
by the client software. Recommended TXT RDATA values are "STARTDTLS"
or "NO_DTLS".</t>
</section>
</section>
-->
<section anchor="DTLS" title="Established sessions">
<t>In DTLS, all data is protected using the same record encoding and
mechanisms. When the mechanism described in this document is in effect,
DNS messages are encrypted using the standard DTLS record encoding. When
a user of DTLS wishes to send an DNS message, it delivers it to the DTLS
implementation as an ordinary application data write (e.g.,
SSL_write()). A single DTLS session can be used to receive multiple DNS
requests and generate DNS multiple responses.</t>
<figure title="Message Flow for Full Handshake Issuing New Session Ticket">
<artwork align="left"><![CDATA[
Client Server
------ ------
ClientHello -------->
<------- HelloVerifyRequest
(contains cookie)
ClientHello -------->
(contains cookie)
(empty SessionTicket extension)
ServerHello
(empty SessionTicket extension)
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
NewSessionTicket
[ChangeCipherSpec]
<-------- Finished
DNS Request --------->
<--------- DNS Response
]]></artwork>
</figure>
</section>
<section title="IANA Considerations">
<t>This document defines a new bit ("SO") in the Flags field of the
EDNS0 OPT meta-RR. At the time of approval of this draft in the
standards track, as per the IANA Considerations of <xref
target="RFC6891"/>, IANA is requested to reserve the third leftmost bit
of the flags as the SO bit, immediately adjacent to the DNSSEC SO bit,
as shown in <xref target="in_band_signaling"/>.</t>
<t>If demultiplexing DTLS and DNS (using the third octet,
<xref target="demux"/>) is useful, we should reserve DNS Opcode 15 to
ensure DNS always has a 0 bit where DTLS always has a 1 bit.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>Once a DNSoD client has established a security association
with a particular DNS server, and outstanding normal DNS queries
with that server (if any) have been received, the DNSoD client
MUST ignore any subsequent normal DNS responses from that server,
as all subsequent responses should be inside DNSoD. This
behavior mitigates all (?) attacks described
in <xref target="RFC5452">Measures for Making DNS More Resilient
against Forged Answers</xref>.</t>
<t>Security considerations discussed
in <xref target="RFC6347">DTLS</xref> also apply to this
document.</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>The EDNS0 OPT meta-RR described in <xref target="in_band_signaling"/>
are an extension of the technique described in
<xref target="I-D.hzhwm-start-tls-for-dns">Starting TLS over
DNS</xref>.</t>
<t>Thanks to Phil Hedrick for his review comments on TCP and to
Josh Littlefield for pointing out DNSoD load on busy servers
(most notably root servers).</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.1034"?>
<?rfc include="reference.RFC.1035"?>
<?rfc include="reference.RFC.4033"?>
<?rfc include="reference.RFC.5077"?>
<?rfc include="reference.RFC.6347"?>
<?rfc include="reference.RFC.6891"?>
<?rfc include="reference.RFC.5452"?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.bortzmeyer-dnsop-dns-privacy'?>
<?rfc include='reference.I-D.hzhwm-start-tls-for-dns'?>
<?rfc include='reference.I-D.ietf-tls-oob-pubkey'?>
<?rfc include="reference.RFC.4892"?>
<?rfc include="reference.RFC.4821"?>
<!--
<reference anchor="IANA-domain" target="http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml">
<front>
<title>Special-Use Domain Names</title>
<author>
<organization>IANA</organization>
</author>
<date month="February" year="2013"/>
</front>
</reference>
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:27:37 |