< draft-ietf-dprive-dtls-and-tls-profiles-05.txt   draft-ietf-dprive-dtls-and-tls-profiles-06.txt >
dprive S. Dickinson dprive S. Dickinson
Internet-Draft Sinodun Internet-Draft Sinodun
Intended status: Standards Track D. Gillmor Intended status: Standards Track D. Gillmor
Expires: April 23, 2017 ACLU Expires: May 1, 2017 ACLU
T. Reddy T. Reddy
Cisco Cisco
October 20, 2016 October 28, 2016
Authentication and (D)TLS Profile for DNS-over-(D)TLS Authentication and (D)TLS Profile for DNS-over-(D)TLS
draft-ietf-dprive-dtls-and-tls-profiles-05 draft-ietf-dprive-dtls-and-tls-profiles-06
Abstract Abstract
This document describes how a DNS client can use a domain name to This document describes how a DNS client can use a domain name to
authenticate a DNS server that uses Transport Layer Security (TLS) authenticate a DNS server that uses Transport Layer Security (TLS)
and Datagram TLS (DTLS). Additionally, it defines (D)TLS profiles and Datagram TLS (DTLS). Additionally, it defines (D)TLS profiles
for DNS clients and servers implementing DNS-over-TLS and DNS-over- for DNS clients and servers implementing DNS-over-TLS and DNS-over-
DTLS. DTLS.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2017. This Internet-Draft will expire on May 1, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 13 skipping to change at page 2, line 13
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Usage Profiles . . . . . . . . . . . . . . . . . . . . . 6 4.2. Usage Profiles . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. DNS Resolution . . . . . . . . . . . . . . . . . . . 8 4.2.1. DNS Resolution . . . . . . . . . . . . . . . . . . . 8
4.3. Authentication . . . . . . . . . . . . . . . . . . . . . 8 4.3. Authentication . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. DNS-over-(D)TLS Bootstrapping Problems . . . . . . . 8 4.3.1. DNS-over-(D)TLS Startup Configuration Problems . . . 9
4.3.2. Credential Verification . . . . . . . . . . . . . . . 9 4.3.2. Credential Verification . . . . . . . . . . . . . . . 9
4.3.3. Implementation guidance . . . . . . . . . . . . . . . 9 4.3.3. Implementation guidance . . . . . . . . . . . . . . . 9
5. Authentication in Opportunistic DNS-over(D)TLS Privacy . . . 9 5. Authentication in Opportunistic DNS-over(D)TLS Privacy . . . 9
6. Authentication in Strict DNS-over(D)TLS Privacy . . . . . . . 10 6. Authentication in Strict DNS-over(D)TLS Privacy . . . . . . . 10
7. In Band Source of Domain Name: SRV Service Label . . . . . . 10 7. In Band Source of Authentication Domain Name: SRV Service
8. Out of Band Sources of Domain Name . . . . . . . . . . . . . 10 Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Out of Band Sources of Authentication Domain Name . . . . . . 11
8.1. Full direct configuration . . . . . . . . . . . . . . . . 11 8.1. Full direct configuration . . . . . . . . . . . . . . . . 11
8.2. Direct configuration of name only . . . . . . . . . . . . 11 8.2. Direct configuration of name only . . . . . . . . . . . . 11
8.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Credential Verification . . . . . . . . . . . . . . . . . . . 12 9. Credential Verification . . . . . . . . . . . . . . . . . . . 12
9.1. PKIX Certificate Based Authentication . . . . . . . . . . 12 9.1. PKIX Certificate Based Authentication . . . . . . . . . . 12
9.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 14 9.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 14
9.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 14 9.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 14
10. Combined Credentials with SPKI Pinsets . . . . . . . . . . . 14 10. Combined Credentials with SPKI Pinsets . . . . . . . . . . . 14
11. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 15 11. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
13. Security Considerations . . . . . . . . . . . . . . . . . . . 16 13. Security Considerations . . . . . . . . . . . . . . . . . . . 16
13.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 16 13.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 16
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
15.1. Normative References . . . . . . . . . . . . . . . . . . 17 15.1. Normative References . . . . . . . . . . . . . . . . . . 17
15.2. Informative References . . . . . . . . . . . . . . . . . 18 15.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Server capability probing and caching by DNS clients 19 Appendix A. Server capability probing and caching by DNS clients 20
Appendix B. Changes between revisions . . . . . . . . . . . . . 20 Appendix B. Changes between revisions . . . . . . . . . . . . . 20
B.1. -05 version . . . . . . . . . . . . . . . . . . . . . . . 20 B.1. -06 version . . . . . . . . . . . . . . . . . . . . . . . 20
B.2. -04 version . . . . . . . . . . . . . . . . . . . . . . . 20 B.2. -05 version . . . . . . . . . . . . . . . . . . . . . . . 21
B.3. -03 version . . . . . . . . . . . . . . . . . . . . . . . 20 B.3. -04 version . . . . . . . . . . . . . . . . . . . . . . . 21
B.4. -02 version . . . . . . . . . . . . . . . . . . . . . . . 20 B.4. -03 version . . . . . . . . . . . . . . . . . . . . . . . 21
B.5. -01 version . . . . . . . . . . . . . . . . . . . . . . . 21 B.5. -02 version . . . . . . . . . . . . . . . . . . . . . . . 21
B.6. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 21 B.6. -01 version . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 B.7. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
DNS Privacy issues are discussed in [RFC7626]. Two documents that DNS Privacy issues are discussed in [RFC7626]. Two documents that
provide DNS privacy between DNS clients and DNS servers are: provide DNS privacy between DNS clients and DNS servers are:
o Specification for DNS over Transport Layer Security (TLS) o Specification for DNS over Transport Layer Security (TLS)
[RFC7858], referred to here as simply 'DNS-over-TLS' [RFC7858], referred to here as simply 'DNS-over-TLS'
o DNS-over-DTLS (DNSoD) [I-D.ietf-dprive-dnsodtls], referred to here o DNS-over-DTLS (DNSoD) [I-D.ietf-dprive-dnsodtls], referred to here
simply as 'DNS-over-DTLS'. Note that this document has the simply as 'DNS-over-DTLS'. Note that this document has the
Intended status of Experimental. Intended status of Experimental.
Both documents are limited in scope to encrypting DNS messages Both documents are limited in scope to encrypting DNS messages
between stub clients and recursive resolvers and the same scope is between stub clients and recursive resolvers and the same scope is
applied to this document (see Section 2 and Section 3). The applied to this document (see Section 2 and Section 3). The
proposals here might be adapted or extended in future to be used for proposals here might be adapted or extended in future to be used for
recursive clients and authoritative servers, but this application is recursive clients and authoritative servers, but this application was
out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group per out of scope for the Working Group charter at the time this document
its current charter. was finished.
This document defines two Usage Profiles (Strict and Opportunistic) This document defines two Usage Profiles (Strict and Opportunistic)
for DTLS [RFC6347] and TLS [RFC5246] which define the security for DTLS [RFC6347] and TLS [RFC5246] which define the security
properties a user should expect when using that profile to connect to properties a user should expect when using that profile to connect to
the available DNS servers. In essence: the available DNS servers. In essence:
o the Strict Profile requires an encrypted connection and successful o the Strict Profile requires an encrypted connection and successful
authentication of the DNS server which provides strong privacy authentication of the DNS server which provides strong privacy
guarantees (at the expense of providing no DNS service if this is guarantees (at the expense of providing no DNS service if this is
not available). not available).
o the Opportunistic Profile will attempt, but does not require, o the Opportunistic Profile will attempt, but does not require,
encryption and successful authentication; it therefore provides no encryption and successful authentication; it therefore provides no
privacy guarantees but offers maximum chance of DNS service. privacy guarantees but offers maximum chance of DNS service.
Additionally, a number of authentication mechanisms are defined that Additionally, a number of authentication mechanisms are defined that
specify how a DNS client should authenticate a DNS server based on a specify how a DNS client should authenticate a DNS server based on a
domain name. In particular, the following is described: domain name. In particular, the following is described:
o How a DNS client can obtain a domain name for a DNS server to use o How a DNS client can obtain the combination of an authentication
for (D)TLS authentication. domain name and IP address for a DNS server.
o What are the acceptable credentials a DNS server can present to o What are the acceptable credentials a DNS server can present to
prove its identity for (D)TLS authentication based on a given prove its identity for (D)TLS authentication based on a given
domain name. domain name.
o How a DNS client can verify that any given credential matches the o How a DNS client can verify that any given credential matches the
domain name obtained for a DNS server. authentication domain name obtained for a DNS server.
It should be noted that [RFC7858] includes a description of a It should be noted that [RFC7858] includes a description of a
specific case of a Strict Usage Profile using a single authentication specific case of a Strict Usage Profile using a single authentication
mechanism (SPKI pinning). This draft generalises the picture by mechanism (SPKI pinning). This document generalises the picture by
separating the Usage Profile, which is based purely on the security separating the Usage Profile, which is based purely on the security
properties it offers the user, from the specific mechanism that is properties it offers the user, from the specific mechanism that is
used for authentication. Therefore the "Out-of-band Key-pinned used for authentication. Therefore the "Out-of-band Key-pinned
Privacy Profile" described in the DNS-over-TLS draft would qualify as Privacy Profile" described in [RFC7858] would qualify as a "Strict
a "Strict Usage Profile" that used SPKI pinning for authentication. Usage Profile" that used SPKI pinning for authentication.
This document also defines a (D)TLS protocol profile for use with This document also defines a (D)TLS protocol profile for use with
DNS. This profile defines the configuration options and protocol DNS. This profile defines the configuration options and protocol
extensions required of both parties to optimize connection extensions required of both parties to optimize connection
establishment and session resumption for transporting DNS, and to establishment and session resumption for transporting DNS, and to
support the authentication mechanisms defined here. support the authentication mechanisms defined here.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Several terms are used specifically in the context of this draft: Several terms are used specifically in the context of this draft:
o DNS client: a DNS stub resolver or forwarder/proxy. In the case o DNS client: a DNS stub resolver or forwarder. In the case of a
of a forwarder, the term "DNS client" is used to discuss the side forwarder, the term "DNS client" is used to discuss the side that
that sends queries. sends queries.
o DNS server: a DNS recursive resolver or forwarder/proxy. In the o DNS server: a DNS recursive resolver or forwarder. In the case of
case of a forwarder, the term "DNS server" is used to discuss the a forwarder, the term "DNS server" is used to discuss the side
side that responds to queries. that responds to queries.
o Privacy-enabling DNS server: A DNS server that: o Privacy-enabling DNS server: A DNS server that:
* MUST implement DNS-over-TLS [RFC7858] and MAY implement DNS- * MUST implement DNS-over-TLS [RFC7858] and MAY implement DNS-
over-DTLS [I-D.ietf-dprive-dnsodtls]. over-DTLS [I-D.ietf-dprive-dnsodtls].
* Can offer at least one of the credentials described in * Can offer at least one of the credentials described in
Section 9. Section 9.
* Implements the (D)TLS profile described in Section 11. * Implements the (D)TLS profile described in Section 11.
skipping to change at page 5, line 4 skipping to change at page 5, line 7
* Implements the (D)TLS profile described in Section 11. * Implements the (D)TLS profile described in Section 11.
o (D)TLS: For brevity this term is used for statements that apply to o (D)TLS: For brevity this term is used for statements that apply to
both Transport Layer Security [RFC5246] and Datagram Transport both Transport Layer Security [RFC5246] and Datagram Transport
Layer Security [RFC6347]. Specific terms will be used for any Layer Security [RFC6347]. Specific terms will be used for any
statement that applies to either protocol alone. statement that applies to either protocol alone.
o DNS-over-(D)TLS: For brevity this term is used for statements that o DNS-over-(D)TLS: For brevity this term is used for statements that
apply to both DNS-over-TLS [RFC7858] and DNS-over-DTLS apply to both DNS-over-TLS [RFC7858] and DNS-over-DTLS
[I-D.ietf-dprive-dnsodtls]. Specific terms will be used for any [I-D.ietf-dprive-dnsodtls]. Specific terms will be used for any
statement that applies to either protocol alone. statement that applies to either protocol alone.
o Authentication domain name: A domain name that can be used to
authenticate a DNS Privacy enabling server. Sources of
authentication domain names are discussed in Section 7 and
Section 8.
o Credential: Information available for a DNS server which proves o Credential: Information available for a DNS server which proves
its identity for authentication purposes. Credentials discussed its identity for authentication purposes. Credentials discussed
here include: here include:
* PKIX certificate * PKIX certificate
* DNSSEC validated chain to a TLSA record * DNSSEC validated chain to a TLSA record
but may also include SPKI pinsets. but may also include SPKI pinsets.
skipping to change at page 5, line 40 skipping to change at page 5, line 47
servers by DNS clients (as defined in the terminology section), and servers by DNS clients (as defined in the terminology section), and
the (D)TLS profiles needed to support this. As such, the following the (D)TLS profiles needed to support this. As such, the following
things are out of scope: things are out of scope:
o Authentication of authoritative servers by recursive resolvers. o Authentication of authoritative servers by recursive resolvers.
o Authentication of DNS clients by DNS servers. o Authentication of DNS clients by DNS servers.
o SPKI-pinset-based authentication. This is defined in [RFC7858]. o SPKI-pinset-based authentication. This is defined in [RFC7858].
However, Section 10 does describe how to combine that approach However, Section 10 does describe how to combine that approach
with the domain name based mechanism described here. with the authentication domain name based mechanism described
here.
o Any server identifier other than domain names, including IP o Any server identifier other than domain names, including IP
address, organizational name, country of origin, etc. address, organizational name, country of origin, etc.
4. Discussion 4. Discussion
4.1. Background 4.1. Background
To protect against passive attacks DNS privacy requires encrypting To protect against passive attacks DNS privacy requires encrypting
the query (and response). Such encryption typically provides the query (and response). Such encryption typically provides
skipping to change at page 8, line 10 skipping to change at page 8, line 10
encrypted. Similarly if the user is informed that an encrypted but encrypted. Similarly if the user is informed that an encrypted but
unauthenticated connection was used then user can detect that the unauthenticated connection was used then user can detect that the
connection may be subject to active attack. This is discussed in connection may be subject to active attack. This is discussed in
Section 5. Section 5.
+---------------+------------+------------------+-----------------+ +---------------+------------+------------------+-----------------+
| Usage Profile | Connection | Passive Attacker | Active Attacker | | Usage Profile | Connection | Passive Attacker | Active Attacker |
+---------------+------------+------------------+-----------------+ +---------------+------------+------------------+-----------------+
| Strict | A, E | P | P | | Strict | A, E | P | P |
| Opportunistic | A, E | P | P | | Opportunistic | A, E | P | P |
| Opportunistic | E | P | N (D) | | Opportunistic | E | P | N, D |
| Opportunistic | | N (D) | N (D) | | Opportunistic | | N, D | N, D |
+---------------+------------+------------------+-----------------+ +---------------+------------+------------------+-----------------+
P == protection; N == no protection; D == detection is possible; A == P == protection; N == no protection; D == detection is possible; A ==
Authenticated Connection; E == Encrypted Connection Authenticated Connection; E == Encrypted Connection
Table 1: DNS Privacy Protection by Usage Profile and type of attacker Table 1: DNS Privacy Protection by Usage Profile and type of attacker
Since Strict Privacy provides the strongest privacy guarantees it is Strict Privacy provides the strongest privacy guarantees and
preferable to Opportunistic Privacy. therefore SHOULD always be implemented in DNS clients along with
Opportunistic Privacy.
However since the two profiles require varying levels of A DNS client that implements DNS-over-(D)TLS SHOULD NOT default to
configuration (or a trusted relationship with a provider) and DNS the use of clear text (no privacy).
server capabilities, DNS clients will need to carefully select which
profile to use based on their communication privacy needs. For the The choice between the two profiles depends on a number of factors
case where a client has a trusted relationship with a provider it is including which is more important to the particular client:
expected that the provider will provide either a domain name or SPKI
pinset via a secure out-of-band mechanism and therefore Strict o DNS service at the cost of no privacy guarantee (Opportunistic) or
Privacy should be used.
o guaranteed privacy at the potential cost of no DNS service
(Strict).
Additionally the two profiles require varying levels of configuration
(or a trusted relationship with a provider) and DNS server
capabilities therefore DNS clients will need to carefully select
which profile to use based on their communication privacy needs.
A DNS server that implements DNS-over-TLS SHOULD provide at least one
credential in order that those DNS clients that wish to do so are
able to use Strict Privacy (see Section 2).
4.2.1. DNS Resolution 4.2.1. DNS Resolution
A DNS client SHOULD select a particular usage profile when resolving A DNS client SHOULD select a particular usage profile when resolving
a query. A DNS client MUST NOT fallback from Strict Privacy to a query. A DNS client MUST NOT fallback from Strict Privacy to
Opportunistic Privacy during the resolution process as this could Opportunistic Privacy during the resolution process as this could
invalidate the protection offered against active attackers. invalidate the protection offered against active attackers.
4.3. Authentication 4.3. Authentication
This document describes authentication mechanisms that can be used in This document describes authentication mechanisms that can be used in
either Strict or Opportunistic Privacy for DNS-over-(D)TLS. either Strict or Opportunistic Privacy for DNS-over-(D)TLS.
4.3.1. DNS-over-(D)TLS Bootstrapping Problems 4.3.1. DNS-over-(D)TLS Startup Configuration Problems
Many (D)TLS clients use PKIX authentication [RFC6125] based on a Many (D)TLS clients use PKIX authentication [RFC6125] based on an
domain name for the server they are contacting. These clients authentication domain name for the server they are contacting. These
typically first look up the server's network address in the DNS clients typically first look up the server's network address in the
before making this connection. A DNS client therefore has a DNS before making this connection. A DNS client therefore has a
bootstrap problem. DNS clients typically know only the IP address of bootstrap problem. DNS clients typically know only the IP address of
a DNS server. a DNS server.
As such, before connecting to a DNS server, a DNS client needs to As such, before connecting to a DNS server, a DNS client needs to
learn the domain name it should associate with the IP address of a learn the authentication domain name it should associate with the IP
DNS server for authentication purposes. Sources of domains names are address of a DNS server for authentication purposes. Sources of
discussed in Section 7 and Section 8. domains names are discussed in Section 7 and Section 8.
One advantage of this domain name based approach is that it One advantage of this domain name based approach is that it
encourages association of stable, human recognisable identifiers with encourages association of stable, human recognisable identifiers with
secure DNS service providers. secure DNS service providers.
4.3.2. Credential Verification 4.3.2. Credential Verification
The use of SPKI pinset verification is discussed in [RFC7858]. The use of SPKI pinset verification is discussed in [RFC7858].
In terms of domain name based verification, once a domain name is In terms of domain name based verification, once an authentication
known for a DNS server a choice of mechanisms can be used for domain name is known for a DNS server a choice of mechanisms can be
authentication. Section 9 discusses these mechanisms in detail, used for authentication. Section 9 discusses these mechanisms in
namely PKIX certificate based authentication and DANE. detail, namely PKIX certificate based authentication and DANE.
Note that the use of DANE adds requirements on the ability of the Note that the use of DANE adds requirements on the ability of the
client to get validated DNSSEC results. This is discussed in more client to get validated DNSSEC results. This is discussed in more
detail in Section 9.2. detail in Section 9.2.
4.3.3. Implementation guidance 4.3.3. Implementation guidance
Section 11 describes the (D)TLS profile for DNS-over(D)TLS. Section 11 describes the (D)TLS profile for DNS-over(D)TLS.
Additional considerations relating to general implementation Additional considerations relating to general implementation
guidelines are discussed in both Section 13 and in Appendix A. guidelines are discussed in both Section 13 and in Appendix A.
5. Authentication in Opportunistic DNS-over(D)TLS Privacy 5. Authentication in Opportunistic DNS-over(D)TLS Privacy
An Opportunistic Security [RFC7435] profile is described in [RFC7858] An Opportunistic Security [RFC7435] profile is described in [RFC7858]
which MAY be used for DNS-over-(D)TLS. which MAY be used for DNS-over-(D)TLS.
DNS clients issuing queries under an opportunistic profile which know DNS clients issuing queries under an opportunistic profile which know
of a domain name or SPKI pinset for a given privacy-enabling DNS of an authentication domain name or SPKI pinset for a given privacy-
server MAY choose to try to authenticate the server using the enabling DNS server MAY choose to try to authenticate the server
mechanisms described here. This is useful for detecting (but not using the mechanisms described here. This is useful for detecting
preventing) active attack, since the fact that authentication (but not preventing) active attack, since the fact that
information is available indicates that the server in question is a authentication information is available indicates that the server in
privacy-enabling DNS server to which it should be possible to question is a privacy-enabling DNS server to which it should be
establish an authenticated, encrypted connection. In this case, possible to establish an authenticated, encrypted connection. In
whilst a client cannot know the reason for an authentication failure, this case, whilst a client cannot know the reason for an
from a privacy standpoint the client should consider an active attack authentication failure, from a privacy standpoint the client should
in progress and proceed under that assumption. Attempting consider an active attack in progress and proceed under that
authentication is also useful for debugging or diagnostic purposes if assumption. Attempting authentication is also useful for debugging
there are means to report the result. This information can provide a or diagnostic purposes if there are means to report the result. This
basis for a DNS client to switch to (preferred) Strict Privacy where information can provide a basis for a DNS client to switch to
it is viable. (preferred) Strict Privacy where it is viable.
6. Authentication in Strict DNS-over(D)TLS Privacy 6. Authentication in Strict DNS-over(D)TLS Privacy
To authenticate a privacy-enabling DNS server, a DNS client needs to To authenticate a privacy-enabling DNS server, a DNS client needs to
know the domain name for each server it is willing to contact. This know the domain name for each server it is willing to contact. This
is necessary to protect against active attacks on DNS privacy. is necessary to protect against active attacks on DNS privacy.
A DNS client requiring Strict Privacy MUST either use one of the A DNS client requiring Strict Privacy MUST either use one of the
sources listed in Section 8 to obtain a domain name for the server it sources listed in Section 8 to obtain an authentication domain name
contacts, or use an SPKI pinset as described in [RFC7858]. for the server it contacts, or use an SPKI pinset as described in
[RFC7858].
A DNS client requiring Strict Privacy MUST only attempt to connect to A DNS client requiring Strict Privacy MUST only attempt to connect to
DNS servers for which either a domain name or a SPKI pinset is known DNS servers for which either an authentication domain name or a SPKI
(or both). The client MUST use the available verification mechanisms pinset is known (or both). The client MUST use the available
described in Section 9 to authenticate the server, and MUST abort verification mechanisms described in Section 9 to authenticate the
connections to a server when no verification mechanism succeeds. server, and MUST abort connections to a server when no verification
mechanism succeeds.
With Strict Privacy, the DNS client MUST NOT commence sending DNS With Strict Privacy, the DNS client MUST NOT commence sending DNS
queries until at least one of the privacy-enabling DNS servers queries until at least one of the privacy-enabling DNS servers
becomes available. becomes available.
A privacy-enabling DNS server may be temporarily unavailable when A privacy-enabling DNS server may be temporarily unavailable when
configuring a network. For example, for clients on networks that configuring a network. For example, for clients on networks that
require registration through web-based login (a.k.a. "captive require registration through web-based login (a.k.a. "captive
portals"), such registration may rely on DNS interception and portals"), such registration may rely on DNS interception and
spoofing. Techniques such as those used by DNSSEC-trigger spoofing. Techniques such as those used by DNSSEC-trigger
[dnssec-trigger] MAY be used during network configuration, with the [dnssec-trigger] MAY be used during network configuration, with the
intent to transition to the designated privacy-enabling DNS servers intent to transition to the designated privacy-enabling DNS servers
after captive portal registration. The system MUST alert by some after captive portal registration. The system MUST alert by some
means that the DNS is not private during such bootstrap. means that the DNS is not private during such bootstrap.
7. In Band Source of Domain Name: SRV Service Label 7. In Band Source of Authentication Domain Name: SRV Service Label
This specification adds a SRV service label "domain-s" for privacy- This specification adds a SRV service label "domain-s" for privacy-
enabling DNS servers. enabling DNS servers.
Example service records (for TLS and DTLS respectively): Example service records (for TLS and DTLS respectively):
_domain-s._tcp.dns.example.com. SRV 0 1 853 dns1.example.com. _domain-s._tcp.dns.example.com. SRV 0 1 853 dns1.example.com.
_domain-s._tcp.dns.example.com. SRV 0 1 853 dns2.example.com. _domain-s._tcp.dns.example.com. SRV 0 1 853 dns2.example.com.
_domain-s._udp.dns.example.com. SRV 0 1 853 dns3.example.com. _domain-s._udp.dns.example.com. SRV 0 1 853 dns3.example.com.
8. Out of Band Sources of Domain Name 8. Out of Band Sources of Authentication Domain Name
8.1. Full direct configuration 8.1. Full direct configuration
DNS clients may be directly and securely provisioned with the domain DNS clients may be directly and securely provisioned with the
name of each privacy-enabling DNS server. For example, using a authentication domain name of each privacy-enabling DNS server. For
client specific configuration file or API. example, using a client specific configuration file or API.
In this case, direct configuration for a DNS client would consist of In this case, direct configuration for a DNS client would consist of
both an IP address and a domain name for each DNS server. both an IP address and a domain name for each DNS server.
8.2. Direct configuration of name only 8.2. Direct configuration of name only
A DNS client may be configured directly and securely with only the A DNS client may be configured directly and securely with only the
domain name of its privacy-enabling DNS server. For example, using a authentication domain name of its privacy-enabling DNS server. For
client specific configuration file or API. example, using a client specific configuration file or API.
A DNS client might learn of a default recursive DNS resolver from an A DNS client might learn of a default recursive DNS resolver from an
untrusted source (such as DHCP's DNS server option [RFC3646]). It untrusted source (such as DHCP's DNS server option [RFC3646]). It
can then use opportunistic DNS connections to untrusted recursive DNS can then use opportunistic DNS connections to untrusted recursive DNS
resolver to establish the IP address of the intended privacy-enabling resolver to establish the IP address of the intended privacy-enabling
DNS server by doing a lookup of SRV records. Such records MUST be DNS server by doing a lookup of SRV records. Such records MUST be
validated using DNSSEC. Private DNS resolution can now be done by validated using DNSSEC. Private DNS resolution can now be done by
the DNS client against the configured privacy-enabling DNS server. the DNS client against the configured privacy-enabling DNS server.
Example: Example:
skipping to change at page 12, line 14 skipping to change at page 12, line 27
8.3. DHCP 8.3. DHCP
Some clients may have an established trust relationship with a known Some clients may have an established trust relationship with a known
DHCP [RFC2131] server for discovering their network configuration. DHCP [RFC2131] server for discovering their network configuration.
In the typical case, such a DHCP server provides a list of IP In the typical case, such a DHCP server provides a list of IP
addresses for DNS servers (see section 3.8 of [RFC2132]), but does addresses for DNS servers (see section 3.8 of [RFC2132]), but does
not provide a domain name for the DNS server itself. not provide a domain name for the DNS server itself.
In the future, a DHCP server might use a DHCP extension to provide a In the future, a DHCP server might use a DHCP extension to provide a
list of domain names for the offered DNS servers, which correspond to list of authentication domain names for the offered DNS servers,
IP addresses listed. which correspond to IP addresses listed.
Use of such a mechanism with any DHCP server when using an Use of such a mechanism with any DHCP server when using an
Opportunistic profile is reasonable, given the security expectation Opportunistic profile is reasonable, given the security expectation
of that profile. However when using a Strict profile the DHCP of that profile. However when using a Strict profile the DHCP
servers used as sources of domain names MUST be considered secure and servers used as sources of authentication domain names MUST be
trustworthy. This document does not attempt to describe secured and considered secure and trustworthy. This document does not attempt to
trusted relationships to DHCP servers. describe secured and trusted relationships to DHCP servers.
[NOTE: It is noted (at the time of writing) that whilst some It is noted (at the time of writing) that whilst some implementation
implementation work is in progress to secure IPv6 connections for work is in progress to secure IPv6 connections for DHCP, IPv4
DHCP, IPv4 connections have received little to no implementation connections have received little to no implementation attention in
attention in this area.] this area.
9. Credential Verification 9. Credential Verification
9.1. PKIX Certificate Based Authentication 9.1. PKIX Certificate Based Authentication
When a DNS client configured with a domain name connects to its When a DNS client configured with an authentication domain name
configured DNS server over (D)TLS, the server may present it with an connects to its configured DNS server over (D)TLS, the server may
PKIX certificate. In order to ensure proper authentication, DNS present it with an PKIX certificate. In order to ensure proper
clients MUST verify the entire certification path per [RFC5280]. The authentication, DNS clients MUST verify the entire certification path
DNS client additionally uses [RFC6125] validation techniques to per [RFC5280]. The DNS client additionally uses [RFC6125] validation
compare the domain name to the certificate provided. techniques to compare the domain name to the certificate provided.
A DNS client constructs two Reference Identifiers for the server A DNS client constructs two Reference Identifiers for the server
based on the domain name: A DNS-ID and an SRV-ID [RFC4985]. The DNS- based on the authentication domain name: A DNS-ID and an SRV-ID
ID is simply the domain name itself. The SRV-ID uses a "_domain-s." [RFC4985]. The DNS-ID is simply the authentication domain name
prefix. So if the configured domain name is "dns.example.com", then itself. The SRV-ID uses a "_domain-s." prefix. So if the configured
the two Reference Identifiers are: authentication domain name is "dns.example.com", then the two
Reference Identifiers are:
DNS-ID: dns.example.com DNS-ID: dns.example.com
SRV-ID: _domain-s.dns.example.com SRV-ID: _domain-s.dns.example.com
If either of the Reference Identifiers are found in the PKIX If either of the Reference Identifiers are found in the PKIX
certificate's subjectAltName extension as described in section 6 of certificate's subjectAltName extension as described in section 6 of
[RFC6125], the DNS client should accept the certificate for the [RFC6125], the DNS client should accept the certificate for the
server. server.
A compliant DNS client MUST only inspect the certificate's A compliant DNS client MUST only inspect the certificate's
subjectAltName extension for these Reference Identifiers. In subjectAltName extension for these Reference Identifiers. In
particular, it MUST NOT inspect the Subject field itself. particular, it MUST NOT inspect the Subject field itself.
9.2. DANE 9.2. DANE
DANE [RFC6698] provides mechanisms to root certificate and raw public DANE [RFC6698] provides mechanisms to root certificate and raw public
key trust with DNSSEC. However this requires the DNS client to have key trust with DNSSEC. However this requires the DNS client to have
a domain name for the DNS Privacy Server which must be obtained via a an authentication domain name for the DNS Privacy Server which must
trusted source. be obtained via a trusted source.
This section assumes a solid understanding of both DANE [RFC6698] and This section assumes a solid understanding of both DANE [RFC6698] and
DANE Operations [RFC7671]. A few pertinent issues covered in these DANE Operations [RFC7671]. A few pertinent issues covered in these
documents are outlined here as useful pointers, but familiarity with documents are outlined here as useful pointers, but familiarity with
both these documents in their entirety is expected. both these documents in their entirety is expected.
It is noted that [RFC6698] says It is noted that [RFC6698] says
"Clients that validate the DNSSEC signatures themselves MUST use "Clients that validate the DNSSEC signatures themselves MUST use
standard DNSSEC validation procedures. Clients that rely on standard DNSSEC validation procedures. Clients that rely on
skipping to change at page 14, line 39 skipping to change at page 14, line 51
10. Combined Credentials with SPKI Pinsets 10. Combined Credentials with SPKI Pinsets
The SPKI pinset profile described in [RFC7858] MAY be used with DNS- The SPKI pinset profile described in [RFC7858] MAY be used with DNS-
over-(D)TLS. over-(D)TLS.
This draft does not make explicit recommendations about how a SPKI This draft does not make explicit recommendations about how a SPKI
pinset based authentication mechanism should be combined with a pinset based authentication mechanism should be combined with a
domain based mechanism from an operator perspective. However it can domain based mechanism from an operator perspective. However it can
be envisaged that a DNS server operator may wish to make both an SPKI be envisaged that a DNS server operator may wish to make both an SPKI
pinset and a domain name available to allow clients to choose which pinset and an authentication domain name available to allow clients
mechanism to use. Therefore, the following is guidance on how to choose which mechanism to use. Therefore, the following is
clients ought to behave if they choose to configure both, as is guidance on how clients ought to behave if they choose to configure
possible in HPKP [RFC7469]. both, as is possible in HPKP [RFC7469].
A DNS client that is configured with both a domain name and a SPKI A DNS client that is configured with both an authentication domain
pinset for a DNS server SHOULD match on both a valid credential for name and a SPKI pinset for a DNS server SHOULD match on both a valid
the domain name and a valid SPKI pinset if both are available when credential for the authentication domain name and a valid SPKI pinset
connecting to that DNS server. if both are available when connecting to that DNS server.
11. (D)TLS Protocol Profile 11. (D)TLS Protocol Profile
This section defines the (D)TLS protocol profile of DNS-over-(D)TLS. This section defines the (D)TLS protocol profile of DNS-over-(D)TLS.
There are known attacks on (D)TLS, such as machine-in-the-middle and There are known attacks on (D)TLS, such as machine-in-the-middle and
protocol downgrade. These are general attacks on (D)TLS and not protocol downgrade. These are general attacks on (D)TLS and not
specific to DNS-over-TLS; please refer to the (D)TLS RFCs for specific to DNS-over-TLS; please refer to the (D)TLS RFCs for
discussion of these security issues. Clients and servers MUST adhere discussion of these security issues.
to the (D)TLS implementation recommendations and security
considerations of [RFC7525] except with respect to (D)TLS version. Clients and servers MUST adhere to the (D)TLS implementation
recommendations and security considerations of [RFC7525] except with
respect to (D)TLS version.
Since encryption of DNS using (D)TLS is virtually a green-field Since encryption of DNS using (D)TLS is virtually a green-field
deployment DNS clients and server MUST implement only (D)TLS 1.2 or deployment DNS clients and server MUST implement only (D)TLS 1.2 or
later. later.
Implementations MUST NOT offer or provide TLS compression, since Implementations MUST NOT offer or provide TLS compression, since
compression can leak significant amounts of information, especially compression can leak significant amounts of information, especially
to a network observer capable of forcing the user to do an arbitrary to a network observer capable of forcing the user to do an arbitrary
DNS lookup in the style of the CRIME attacks [CRIME]. DNS lookup in the style of the CRIME attacks [CRIME].
Implementations compliant with this profile MUST implement all of the Implementations compliant with this profile MUST implement all of the
skipping to change at page 20, line 23 skipping to change at page 20, line 32
authenticated encrypted connection before falling back to a lower authenticated encrypted connection before falling back to a lower
security. (RATIONALE: This approach can increase latency while security. (RATIONALE: This approach can increase latency while
discovering server capabilities but maximizes the chance of sending discovering server capabilities but maximizes the chance of sending
the query over an authenticated encrypted connection.) the query over an authenticated encrypted connection.)
Appendix B. Changes between revisions Appendix B. Changes between revisions
[Note to RFC Editor: please remove this section prior to [Note to RFC Editor: please remove this section prior to
publication.] publication.]
B.1. -05 version B.1. -06 version
Introduction: Re-word discussion of Working group charter.
Introduction: Re-word first and third bullet point about 'obtaining'
a domain name and IP address.
Introduction: Update reference to DNS-over-TLS draft.
Terminology: Change forwarder/proxy to just forwarder
Terminology: Add definition of 'Authentication domain name' and use
this throughout
Section 4.2: Remove parenthesis in the table.
Section 4.2: Change the text after the table as agreed with Paul
Hoffman.
Section 4.3.1: Change title and remove brackets around last
statement.
Section 11: Split second paragraph.
B.2. -05 version
Add more details on detecting passive attacks to section 4.2 Add more details on detecting passive attacks to section 4.2
Changed X.509 to PKIX throughout Changed X.509 to PKIX throughout
Change comment about future I-D on usage policies. Change comment about future I-D on usage policies.
B.2. -04 version B.3. -04 version
Introduction: Add comment that DNS-over-DTLS draft is Experiments Introduction: Add comment that DNS-over-DTLS draft is Experiments
Update 2 I-D references to RFCs. Update 2 I-D references to RFCs.
B.3. -03 version B.4. -03 version
Section 9: Update DANE section with better references to RFC7671 and Section 9: Update DANE section with better references to RFC7671 and
RFC7250 RFC7250
B.4. -02 version B.5. -02 version
Introduction: Added paragraph on the background and scope of the Introduction: Added paragraph on the background and scope of the
document. document.
Introduction and Discussion: Added more information on what a Usage Introduction and Discussion: Added more information on what a Usage
profiles is (and is not) the the two presented here. profiles is (and is not) the the two presented here.
Introduction: Added paragraph to make a comparison with the Strict Introduction: Added paragraph to make a comparison with the Strict
profile in RFC7858 clearer. profile in RFC7858 clearer.
Section 4.2: Re-worked the description of Opportunistic and the Section 4.2: Re-worked the description of Opportunistic and the
table. table.
Section 8.3: Clarified statement about use of DHCP in Opportunistic Section 8.3: Clarified statement about use of DHCP in Opportunistic
profile profile
Title abbreviated. Title abbreviated.
B.5. -01 version B.6. -01 version
Section 4.2: Make clear that the Strict Privacy Profile can include Section 4.2: Make clear that the Strict Privacy Profile can include
meta queries performed using Opportunistic Privacy. meta queries performed using Opportunistic Privacy.
Section 4.2, Table 1: Update to clarify that Opportunistic Privacy Section 4.2, Table 1: Update to clarify that Opportunistic Privacy
does not guarantee protection against passive attack. does not guarantee protection against passive attack.
Section 4.2: Add sentence discussing client/provider trusted Section 4.2: Add sentence discussing client/provider trusted
relationships. relationships.
Section 5: Add more discussion of detection of active attacks when Section 5: Add more discussion of detection of active attacks when
using Opportunistic Privacy. using Opportunistic Privacy.
Section 8.2: Clarify description and example. Section 8.2: Clarify description and example.
B.6. draft-ietf-dprive-dtls-and-tls-profiles-00 B.7. draft-ietf-dprive-dtls-and-tls-profiles-00
Re-submission of draft-dgr-dprive-dtls-and-tls-profiles with name Re-submission of draft-dgr-dprive-dtls-and-tls-profiles with name
change to draft-ietf-dprive-dtls-and-tls-profiles. Also minor nits change to draft-ietf-dprive-dtls-and-tls-profiles. Also minor nits
fixed. fixed.
Authors' Addresses Authors' Addresses
Sara Dickinson Sara Dickinson
Sinodun Internet Technologies Sinodun Internet Technologies
Magdalen Centre Magdalen Centre
 End of changes. 49 change blocks. 
125 lines changed or deleted 175 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/