< draft-ietf-dprive-dtls-and-tls-profiles-08.txt   draft-ietf-dprive-dtls-and-tls-profiles-09.txt >
dprive S. Dickinson dprive S. Dickinson
Internet-Draft Sinodun Internet-Draft Sinodun
Intended status: Standards Track D. Gillmor Updates: 7858 (if approved) D. Gillmor
Expires: July 22, 2017 ACLU Intended status: Standards Track ACLU
T. Reddy Expires: October 12, 2017 T. Reddy
Cisco Cisco
January 18, 2017 April 10, 2017
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-08 draft-ietf-dprive-dtls-and-tls-profiles-09
Abstract Abstract
This document discusses Usage Profiles, based on one or more This document discusses Usage Profiles, based on one or more
authentication mechanisms, which can be used for DNS over Transport authentication mechanisms, which can be used for DNS over Transport
Layer Security (TLS) or Datagram TLS (DTLS). This document also Layer Security (TLS) or Datagram TLS (DTLS). This document also
specifies new authentication mechanisms - it describes several ways a specifies new authentication mechanisms - it describes several ways a
DNS client can use an authentication domain name to authenticate a DNS client can use an authentication domain name to authenticate a
DNS server. Additionally, it defines (D)TLS profiles for DNS clients DNS server. Additionally, it defines (D)TLS profiles for DNS clients
and servers implementing DNS-over-(D)TLS. and servers implementing DNS-over-(D)TLS.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 July 22, 2017. This Internet-Draft will expire on October 12, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 27 skipping to change at page 2, line 27
5.1. DNS Resolution . . . . . . . . . . . . . . . . . . . . . 9 5.1. DNS Resolution . . . . . . . . . . . . . . . . . . . . . 9
6. Authentication in DNS-over(D)TLS . . . . . . . . . . . . . . 9 6. Authentication in DNS-over(D)TLS . . . . . . . . . . . . . . 9
6.1. DNS-over-(D)TLS Startup Configuration Problems . . . . . 9 6.1. DNS-over-(D)TLS Startup Configuration Problems . . . . . 9
6.2. Credential Verification . . . . . . . . . . . . . . . . . 10 6.2. Credential Verification . . . . . . . . . . . . . . . . . 10
6.3. Summary of Authentication Mechanisms . . . . . . . . . . 10 6.3. Summary of Authentication Mechanisms . . . . . . . . . . 10
6.4. Combining Authentication Mechanisms . . . . . . . . . . . 13 6.4. Combining Authentication Mechanisms . . . . . . . . . . . 13
6.5. Authentication in Opportunistic Privacy . . . . . . . . . 13 6.5. Authentication in Opportunistic Privacy . . . . . . . . . 13
6.6. Authentication in Strict Privacy . . . . . . . . . . . . 13 6.6. Authentication in Strict Privacy . . . . . . . . . . . . 13
6.7. Implementation guidance . . . . . . . . . . . . . . . . . 14 6.7. Implementation guidance . . . . . . . . . . . . . . . . . 14
7. Sources of Authentication Domain Names . . . . . . . . . . . 14 7. Sources of Authentication Domain Names . . . . . . . . . . . 14
7.1. In Band Sources: SRV Service Label . . . . . . . . . . . 14 7.1. Full direct configuration . . . . . . . . . . . . . . . . 14
7.2. Out of Band Sources . . . . . . . . . . . . . . . . . . . 15 7.2. Direct configuration of name only . . . . . . . . . . . . 14
7.2.1. Full direct configuration . . . . . . . . . . . . . . 15 7.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2.2. Direct configuration of name only . . . . . . . . . . 15 8. Authentication Domain Name based Credential Verification . . 15
7.2.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. PKIX Certificate Based Authentication . . . . . . . . . . 15
8. Authentication Domain Name based Credential Verification . . 16 8.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. PKIX Certificate Based Authentication . . . . . . . . . . 16 8.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 17
8.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 17
8.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 18 9. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 17
8.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 18 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 13.1. Normative References . . . . . . . . . . . . . . . . . . 19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . 21 13.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Server capability probing and caching by DNS clients 23 Appendix A. Server capability probing and caching by DNS clients 22
Appendix B. Changes between revisions . . . . . . . . . . . . . 23 Appendix B. Changes between revisions . . . . . . . . . . . . . 22
B.1. -08 version . . . . . . . . . . . . . . . . . . . . . . . 23 B.1. -09 version . . . . . . . . . . . . . . . . . . . . . . . 22
B.2. -07 version . . . . . . . . . . . . . . . . . . . . . . . 23 B.2. -08 version . . . . . . . . . . . . . . . . . . . . . . . 23
B.3. -06 version . . . . . . . . . . . . . . . . . . . . . . . 24 B.3. -07 version . . . . . . . . . . . . . . . . . . . . . . . 23
B.4. -05 version . . . . . . . . . . . . . . . . . . . . . . . 24 B.4. -06 version . . . . . . . . . . . . . . . . . . . . . . . 23
B.5. -04 version . . . . . . . . . . . . . . . . . . . . . . . 24 B.5. -05 version . . . . . . . . . . . . . . . . . . . . . . . 24
B.6. -03 version . . . . . . . . . . . . . . . . . . . . . . . 25 B.6. -04 version . . . . . . . . . . . . . . . . . . . . . . . 24
B.7. -02 version . . . . . . . . . . . . . . . . . . . . . . . 25 B.7. -03 version . . . . . . . . . . . . . . . . . . . . . . . 24
B.8. -01 version . . . . . . . . . . . . . . . . . . . . . . . 25 B.8. -02 version . . . . . . . . . . . . . . . . . . . . . . . 24
B.9. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 25 B.9. -01 version . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 B.10. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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
skipping to change at page 5, line 11 skipping to change at page 5, line 11
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. In the case of a o DNS client: a DNS stub resolver or forwarder. In the case of a
forwarder, the term "DNS client" is used to discuss the side that forwarder, the term "DNS client" is used to discuss the side that
sends queries. sends queries.
o DNS server: a DNS recursive resolver or forwarder. In the case of o DNS server: a DNS recursive resolver or forwarder. In the case of
a forwarder, the term "DNS server" is used to discuss the side a forwarder, the term "DNS server" is used to discuss the side
that responds to queries. that responds to queries. For emphasis, in this document the term
does not apply to authoritative servers.
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 8. Section 8.
* Implements the (D)TLS profile described in Section 9. * Implements the (D)TLS profile described in Section 9.
skipping to change at page 8, line 29 skipping to change at page 8, line 32
Note that there is no requirement in Opportunistic Security to notify Note that there is no requirement in Opportunistic Security to notify
the user what type of connection is actually used, the 'detection' the user what type of connection is actually used, the 'detection'
described below is only possible if such connection information is described below is only possible if such connection information is
available. However, if it is available and the user is informed that available. However, if it is available and the user is informed that
an unencrypted connection was used to connect to a server then the an unencrypted connection was used to connect to a server then the
user should assume (detect) that the connection is subject to both user should assume (detect) that the connection is subject to both
active and passive attack since the DNS queries are sent in clear active and passive attack since the DNS queries are sent in clear
text. This might be particularly useful if a new connection to a text. This might be particularly useful if a new connection to a
certain server is unencrypted when all previous connections were certain server is unencrypted when all previous connections were
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 the 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 6.5. Section 6.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 |
skipping to change at page 8, line 46 skipping to change at page 9, line 4
| 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
Strict Privacy provides the strongest privacy guarantees and Strict Privacy provides the strongest privacy guarantees and
therefore SHOULD always be implemented in DNS clients along with therefore SHOULD always be implemented in DNS clients along with
Opportunistic Privacy. Opportunistic Privacy.
A DNS client that implements DNS-over-(D)TLS SHOULD NOT default to A DNS client that implements DNS-over-(D)TLS SHOULD NOT default to
the use of clear text (no privacy). the use of clear text (no privacy).
The choice between the two profiles depends on a number of factors The choice between the two profiles depends on a number of factors
including which is more important to the particular client: including which is more important to the particular client:
o DNS service at the cost of no privacy guarantee (Opportunistic) or o DNS service at the cost of no privacy guarantee (Opportunistic) or
o guaranteed privacy at the potential cost of no DNS service o guaranteed privacy at the potential cost of no DNS service
(Strict). (Strict).
Additionally the two profiles require varying levels of configuration Additionally the two profiles require varying levels of configuration
(or a trusted relationship with a provider) and DNS server (or a trusted relationship with a provider) and DNS server
capabilities therefore DNS clients will need to carefully select capabilities, therefore DNS clients will need to carefully select
which profile to use based on their communication privacy needs. which profile to use based on their communication privacy needs.
A DNS server that implements DNS-over-TLS SHOULD provide at least one A DNS server that implements DNS-over-(D)TLS SHOULD provide at least
credential in order that those DNS clients that wish to do so are one credential so that those DNS clients that wish to do so are able
able to use Strict Privacy (see Section 2). to use Strict Privacy (see Section 2).
5.1. DNS Resolution 5.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.
6. Authentication in DNS-over(D)TLS 6. Authentication in DNS-over(D)TLS
This section describes authentication mechanisms and how they can be This section describes authentication mechanisms and how they can be
used in either Strict or Opportunistic Privacy for DNS-over-(D)TLS. used in either Strict or Opportunistic Privacy for DNS-over-(D)TLS.
6.1. DNS-over-(D)TLS Startup Configuration Problems 6.1. DNS-over-(D)TLS Startup Configuration Problems
Many (D)TLS clients use PKIX authentication [RFC6125] based on an Many (D)TLS clients use PKIX authentication [RFC6125] based on an
authentication domain name for the server they are contacting. These authentication domain name for the server they are contacting. These
clients typically first look up the server's network address in the clients typically first look up the server's network address in the
DNS before making this connection. Such a DNS client therefore has a DNS before making this connection. Such a DNS client therefore has a
bootstrap problem. DNS clients typically know only the IP address of bootstrap problem, as it will typically only know the IP address of
a DNS server. its DNS server.
In this case, before connecting to a DNS server, a DNS client needs In this case, before connecting to a DNS server, a DNS client needs
to learn the authentication domain name it should associate with the to learn the authentication domain name it should associate with the
IP address of a DNS server for authentication purposes. Sources of IP address of a DNS server for authentication purposes. Sources of
authentication domains names are discussed in Section 7. authentication domain names are discussed in Section 7.
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.
6.2. Credential Verification 6.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 an authentication In terms of domain name based verification, once an authentication
skipping to change at page 11, line 14 skipping to change at page 11, line 14
+---+------------+-------------+------------------------------------+ +---+------------+-------------+------------------------------------+
| # | Static | Dynamically | Short name: Description | | # | Static | Dynamically | Short name: Description |
| | Config | Obtained | | | | Config | Obtained | |
+---+------------+-------------+------------------------------------+ +---+------------+-------------+------------------------------------+
| 1 | SPKI + IP | | SPKI: SPKI pinset(s) and IP | | 1 | SPKI + IP | | SPKI: SPKI pinset(s) and IP |
| | | | address obtained out of band | | | | | address obtained out of band |
| | | | [RFC7858] | | | | | [RFC7858] |
| | | | | | | | | |
| 2 | ADN + IP | | ADN: ADN and IP address obtained | | 2 | ADN + IP | | ADN: ADN and IP address obtained |
| | | | out of band (see Section 7.2.1) | | | | | out of band (see Section 7.1) |
| | | | | | | | | |
| 3 | ADN | IP | ADN only: DNSSEC validated | | 3 | ADN | IP | ADN only: Opportunistic lookups to |
| | | | Opportunistic lookups to a NP DNS | | | | | a NP DNS server for A/AAAA (see |
| | | | server for SRV, A/AAAA (see | | | | | Section 7.2) |
| | | | Section 7.2.2) |
| | | | | | | | | |
| 4 | | ADN + IP | DHCP: DHCP configuration only (see | | 4 | | ADN + IP | DHCP: DHCP configuration only (see |
| | | | Section 7.2.3) | | | | | Section 7.3) |
| | | | | | | | | |
| 5 | [ADN + IP] | [ADN + IP] | DANE: DNSSEC chain obtained via | | 5 | [ADN + IP] | [ADN + IP] | DANE: DNSSEC chain obtained via |
| | | TLSA record | Opportunistic lookups to NP DNS | | | | TLSA record | Opportunistic lookups to NP DNS |
| | | | server (see Section 8.2.1) | | | | | server (see Section 8.2.1) |
| | | | | | | | | |
| 6 | [ADN + IP] | [ADN + IP] | TLS extension: DNSSEC chain | | 6 | [ADN + IP] | [ADN + IP] | TLS extension: DNSSEC chain |
| | | TLSA record | provided by PE DNS server in TLS | | | | TLSA record | provided by PE DNS server in TLS |
| | | | DNSSEC chain extension (see | | | | | DNSSEC chain extension (see |
| | | | Section 8.2.2) | | | | | Section 8.2.2) |
+---+------------+-------------+------------------------------------+ +---+------------+-------------+------------------------------------+
skipping to change at page 12, line 6 skipping to change at page 12, line 4
1. SPKI 1. SPKI
+ Minimal leakage (Note that the ADN is always leaked in the + Minimal leakage (Note that the ADN is always leaked in the
SNI field in the Client Hello in TLS when communicating with a SNI field in the Client Hello in TLS when communicating with a
privacy enabling DNS server) privacy enabling DNS server)
- Overhead of on-going key management required - Overhead of on-going key management required
2. ADN 2. ADN
+ Minimal leakage + Minimal leakage
+ One-off direct configuration only + One-off direct configuration only
3. ADN only 3. ADN only
+ Minimal one-off direct configuration, only a human + Minimal one-off direct configuration, only a human
recognisable domain name needed recognisable domain name needed
- SRV, A/AAAA meta queries leaked to network provided DNS - A/AAAA meta queries leaked to network provided DNS server
server
4. DHCP 4. DHCP
+ No static config + No static config
- Requires a non-standard or future DHCP option in order to - Requires a non-standard or future DHCP option in order to
provide the ADN provide the ADN
- Requires secure and trustworthy connection to DHCP server - Requires secure and trustworthy connection to DHCP server
skipping to change at page 14, line 6 skipping to change at page 13, line 51
client to switch to (preferred) Strict Privacy where it is viable. client to switch to (preferred) Strict Privacy where it is viable.
6.6. Authentication in Strict Privacy 6.6. Authentication in Strict 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 authentication information for each server it is willing to know authentication information for each server it is willing to
contact. This is necessary to protect against active attacks on DNS contact. This is necessary to protect against active attacks on DNS
privacy. 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 7.2 to obtain an authentication domain name sources listed in Section 7 to obtain an authentication domain name
for the server it contacts, or use an SPKI pinset as described in for the server it contacts, or use an SPKI pinset as described in
[RFC7858]. [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 at least one piece of authentication DNS servers for which at least one piece of authentication
information is known. The client MUST use the available verification information is known. The client MUST use the available verification
mechanisms described in Section 8 to authenticate the server, and mechanisms described in Section 8 to authenticate the server, and
MUST abort connections to a server when no verification mechanism MUST abort connections to a server when no verification mechanism
succeeds. succeeds.
skipping to change at page 14, line 39 skipping to change at page 14, line 36
means that the DNS is not private during such bootstrap. means that the DNS is not private during such bootstrap.
6.7. Implementation guidance 6.7. Implementation guidance
Section 9 describes the (D)TLS profile for DNS-over(D)TLS. Section 9 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 11 and in Appendix A. guidelines are discussed in both Section 11 and in Appendix A.
7. Sources of Authentication Domain Names 7. Sources of Authentication Domain Names
7.1. In Band Sources: SRV Service Label 7.1. Full direct configuration
This specification adds a SRV service label "domain-s" for privacy-
enabling DNS servers.
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 dns2.example.com.
_domain-s._udp.dns.example.com. SRV 0 1 853 dns3.example.com.
7.2. Out of Band Sources
7.2.1. Full direct configuration
DNS clients may be directly and securely provisioned with the DNS clients may be directly and securely provisioned with the
authentication domain name of each privacy-enabling DNS server. For authentication domain name of each privacy-enabling DNS server. For
example, using a 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.
7.2.2. Direct configuration of name only 7.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
authentication domain name of its privacy-enabling DNS server. For authentication domain name of its privacy-enabling DNS server. For
example, using a 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 an untrusted recursive
resolver to establish the IP address of the intended privacy-enabling DNS resolver to establish the IP address of the intended privacy-
DNS server by doing a lookup of SRV records. Such records MUST be enabling DNS resolver by doing a lookup of A/AAAA records. Private
validated using DNSSEC. Private DNS resolution can now be done by DNS resolution can now be done by the DNS client against the pre-
the DNS client against the configured privacy-enabling DNS server. configured privacy-enabling DNS resolver, using the IP address
gathered from the untrusted DNS resolver.
Example:
o A DNSSEC validating DNS client is configured with the domain name
dns.example.net for a privacy-enabling DNS server
o Using Opportunistic Privacy to a default DNS resolver (acquired,
for example, using DHCP) the client performs look ups for
* SRV record for _domain-s._tcp.dns.example.net to obtain the
server host name
* A and/or AAAA lookups to obtain IP address for the server host
name
o Client validates all the records obtained in the previous step
using DNSSEC.
o If the records successfully validate the client proceeds to
connect to the privacy-enabling DNS server using Strict Privacy.
A DNS client so configured that successfully connects to a privacy- A DNS client so configured that successfully connects to a privacy-
enabling DNS server MAY choose to locally cache the looked up enabling DNS server MAY choose to locally cache the server host IP
addresses in order to not have to repeat the opportunistic lookup. addresses in order to not have to repeat the opportunistic lookup.
7.2.3. DHCP 7.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 authentication domain names for the offered DNS servers, list of authentication domain names for the offered DNS servers,
which correspond to IP addresses listed. which correspond to IP addresses listed.
skipping to change at page 16, line 35 skipping to change at page 15, line 48
work is in progress to secure IPv6 connections for DHCP, IPv4 work is in progress to secure IPv6 connections for DHCP, IPv4
connections have received little to no implementation attention in connections have received little to no implementation attention in
this area. this area.
8. Authentication Domain Name based Credential Verification 8. Authentication Domain Name based Credential Verification
8.1. PKIX Certificate Based Authentication 8.1. PKIX Certificate Based Authentication
When a DNS client configured with an authentication domain name When a DNS client configured with an authentication domain name
connects to its configured DNS server over (D)TLS, the server may connects to its configured DNS server over (D)TLS, the server may
present it with an PKIX certificate. In order to ensure proper present it with a PKIX certificate. In order to ensure proper
authentication, DNS clients MUST verify the entire certification path authentication, DNS clients MUST verify the entire certification path
per [RFC5280]. The DNS client additionally uses [RFC6125] validation per [RFC5280]. The DNS client additionally uses [RFC6125] validation
techniques to 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 one Reference Identifier for the server based
based on the authentication domain name: A DNS-ID and an SRV-ID on the authentication domain name: A DNS-ID which is simply the
[RFC4985]. The DNS-ID is simply the authentication domain name authentication domain name itself.
itself. The SRV-ID uses a "_domain-s." prefix. So if the configured
authentication domain name is "dns.example.com", then the two
Reference Identifiers are:
DNS-ID: dns.example.com
SRV-ID: _domain-s.dns.example.com
If either of the Reference Identifiers are found in the PKIX
certificate's subjectAltName extension as described in section 6 of
[RFC6125], the DNS client should accept the certificate for the If the Reference Identifier is found in the PKIX certificate's
server. subjectAltName extension as described in section 6 of [RFC6125], the
DNS client should accept the certificate for the 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 the Reference Identifier. In
particular, it MUST NOT inspect the Subject field itself. particular, it MUST NOT inspect the Subject field itself.
8.2. DANE 8.2. DANE
DANE [RFC6698] provides mechanisms to root certificate and raw public DANE [RFC6698] provides mechanisms to anchor certificate and raw
key trust with DNSSEC. However this requires the DNS client to have public key trust with DNSSEC. However this requires the DNS client
an authentication domain name for the DNS Privacy Server which must to have an authentication domain name for the DNS Privacy Server
be obtained via a trusted source. which must 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
another entity to perform the DNSSEC signature validation MUST use another entity to perform the DNSSEC signature validation MUST use
a secure mechanism between themselves and the validator." a secure mechanism between themselves and the validator."
It is noted that [RFC7671] covers the following topics: It is noted that [RFC7671] covers the following topics:
o Section 4.1: Opportunistic Security and PKIX Usages and o Section 4.1: Opportunistic Security and PKIX Usages and
Section 14: Security Considerations, which both discuss the use of Section 14: Security Considerations, which both discuss the use of
PKIX-TA(0) and PKIX-EE(1) for OS. PKIX-TA(0) and PKIX-EE(1) for Opportunistic Security.
o Section 5: Certificate-Usage-Specific DANE Updates and Guidelines. o Section 5: Certificate-Usage-Specific DANE Updates and Guidelines.
Specifically Section 5.1 which outlines the combination of Specifically Section 5.1 which outlines the combination of
Certificate Usage DANE-EE(3) and Selector Usage SPKI(1) with Raw Certificate Usage DANE-EE(3) and Selector Usage SPKI(1) with Raw
Public Keys [RFC7250]. Section 5.1 also discusses the security Public Keys [RFC7250]. Section 5.1 also discusses the security
implications of this mode, for example, it discusses key lifetimes implications of this mode, for example, it discusses key lifetimes
and specifies that validity period enforcement is based solely on and specifies that validity period enforcement is based solely on
the TLSA RRset properties for this case. the TLSA RRset properties for this case.
o Section 13: Operational Considerations, which discusses TLSA TTLs o Section 13: Operational Considerations, which discusses TLSA TTLs
and signature validity periods. and signature validity periods.
The specific DANE record for a DNS Privacy Server would take the The specific DANE record for a DNS Privacy Server would take the
form: form:
_853._tcp.[server-domain-name] for TLS _853._tcp.[authentication-domain-name] for TLS
_853._udp.[server-domain-name] for DTLS
_853._udp.[authentication-domain-name] for DTLS
8.2.1. Direct DNS Lookup 8.2.1. Direct DNS Lookup
The DNS client MAY choose to perform the DNS lookups to retrieve the The DNS client MAY choose to perform the DNS lookups to retrieve the
required DANE records itself. The DNS queries for such DANE records required DANE records itself. The DNS queries for such DANE records
MAY use opportunistic encryption or be in the clear to avoid trust MAY use opportunistic encryption or be in the clear to avoid trust
recursion. The records MUST be validated using DNSSEC as described recursion. The records MUST be validated using DNSSEC as described
above in [RFC6698]. above in [RFC6698].
8.2.2. TLS DNSSEC Chain extension 8.2.2. TLS DNSSEC Chain extension
skipping to change at page 18, line 40 skipping to change at page 17, line 46
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. discussion of these security issues.
Clients and servers MUST adhere to the (D)TLS implementation Clients and servers MUST adhere to the (D)TLS implementation
recommendations and security considerations of [RFC7525] except with recommendations and security considerations of [RFC7525] except with
respect to (D)TLS version. 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 a green-field deployment DNS
deployment DNS clients and server MUST implement only (D)TLS 1.2 or clients and servers 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
following items: following items:
o TLS session resumption without server-side state [RFC5077] which o TLS session resumption without server-side state [RFC5077] which
eliminates the need for the server to retain cryptographic state eliminates the need for the server to retain cryptographic state
for longer than necessary. for longer than necessary (This statement updates [RFC7858]).
o Raw public keys [RFC7250] which reduce the size of the o Raw public keys [RFC7250] which reduce the size of the
ServerHello, and can be used by servers that cannot obtain ServerHello, and can be used by servers that cannot obtain
certificates (e.g., DNS servers on private networks). certificates (e.g., DNS servers on private networks).
Implementations compliant with this profile SHOULD implement all of Implementations compliant with this profile SHOULD implement all of
the following items: the following items:
o TLS False Start [RFC7918] which reduces round-trips by allowing o TLS False Start [RFC7918] which reduces round-trips by allowing
the TLS second flight of messages (ChangeCipherSpec) to also the TLS second flight of messages (ChangeCipherSpec) to also
skipping to change at page 19, line 36 skipping to change at page 18, line 39
10. IANA Considerations 10. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
11. Security Considerations 11. Security Considerations
Security considerations discussed in [RFC7525], Security considerations discussed in [RFC7525],
[I-D.ietf-dprive-dnsodtls] and [RFC7858] apply to this document. [I-D.ietf-dprive-dnsodtls] and [RFC7858] apply to this document.
DNS Clients SHOULD consider implementing support for the mechanisms
described in Section 8.2 and offering a configuration option which
limits authentication to using only those mechanisms (i.e. with no
fallback to pure PKIX based authentication) such that authenticating
solely via the PKIX infrastructure can be avoided.
11.1. Counter-measures to DNS Traffic Analysis 11.1. Counter-measures to DNS Traffic Analysis
This section makes suggestions for measures that can reduce the This section makes suggestions for measures that can reduce the
ability of attackers to infer information pertaining to encrypted ability of attackers to infer information pertaining to encrypted
client queries by other means (e.g. via an analysis of encrypted client queries by other means (e.g. via an analysis of encrypted
traffic size, or via monitoring of resolver to authoritative traffic size, or via monitoring of resolver to authoritative
traffic). traffic).
DNS-over-(D)TLS clients and servers SHOULD consider implementing the DNS-over-(D)TLS clients and servers SHOULD consider implementing the
following relevant DNS extensions following relevant DNS extensions
skipping to change at page 20, line 32 skipping to change at page 19, line 42
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure
Subject Alternative Name for Expression of Service Name",
RFC 4985, DOI 10.17487/RFC4985, August 2007,
<http://www.rfc-editor.org/info/rfc4985>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <http://www.rfc-editor.org/info/rfc5077>. January 2008, <http://www.rfc-editor.org/info/rfc5077>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
skipping to change at page 22, line 17 skipping to change at page 21, line 21
<https://www.nlnetlabs.nl/projects/dnssec-trigger/>. <https://www.nlnetlabs.nl/projects/dnssec-trigger/>.
[I-D.ietf-dprive-dnsodtls] [I-D.ietf-dprive-dnsodtls]
Reddy, T., Wing, D., and P. Patil, "Specification for DNS Reddy, T., Wing, D., and P. Patil, "Specification for DNS
over Datagram Transport Layer Security (DTLS)", draft- over Datagram Transport Layer Security (DTLS)", draft-
ietf-dprive-dnsodtls-15 (work in progress), December 2016. ietf-dprive-dnsodtls-15 (work in progress), December 2016.
[I-D.ietf-tls-dnssec-chain-extension] [I-D.ietf-tls-dnssec-chain-extension]
Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE
Record and DNSSEC Authentication Chain Extension for TLS", Record and DNSSEC Authentication Chain Extension for TLS",
draft-ietf-tls-dnssec-chain-extension-02 (work in draft-ietf-tls-dnssec-chain-extension-03 (work in
progress), January 2017. progress), March 2017.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997, RFC 2131, DOI 10.17487/RFC2131, March 1997,
<http://www.rfc-editor.org/info/rfc2131>. <http://www.rfc-editor.org/info/rfc2131>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<http://www.rfc-editor.org/info/rfc2132>. <http://www.rfc-editor.org/info/rfc2132>.
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic
skipping to change at page 23, line 42 skipping to change at page 22, line 42
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. -08 version B.1. -09 version
Remove the SRV record to simplify the draft.
Add suggestion that clients offer option to avoid using only PKIX
authentication.
Clarify that the MUST on implementing TLS session resumption updates
RFC7858.
Update page header to be '(D)TLS Authentication for TLS'.
B.2. -08 version
Removed hard failure as an option for Opportunistic Usage profile. Removed hard failure as an option for Opportunistic Usage profile.
Added a new section comparing the Authentication Mechanisms Added a new section comparing the Authentication Mechanisms
B.2. -07 version B.3. -07 version
Re-work of the Abstract and Introduction to better describe the Re-work of the Abstract and Introduction to better describe the
contents in this version. contents in this version.
Terminology: New definition of 'authentication information'. Terminology: New definition of 'authentication information'.
Scope: Changes to the Scope section. Scope: Changes to the Scope section.
Moved discussion of combining authentication mechanism earlier. Moved discussion of combining authentication mechanism earlier.
Changes to the section headings and groupings to make the Changes to the section headings and groupings to make the
presentation more logical. presentation more logical.
B.3. -06 version B.4. -06 version
Introduction: Re-word discussion of Working group charter. Introduction: Re-word discussion of Working group charter.
Introduction: Re-word first and third bullet point about 'obtaining' Introduction: Re-word first and third bullet point about 'obtaining'
a domain name and IP address. a domain name and IP address.
Introduction: Update reference to DNS-over-TLS draft. Introduction: Update reference to DNS-over-TLS draft.
Terminology: Change forwarder/proxy to just forwarder Terminology: Change forwarder/proxy to just forwarder
skipping to change at page 24, line 38 skipping to change at page 24, line 5
Section 4.2: Remove parenthesis in the table. Section 4.2: Remove parenthesis in the table.
Section 4.2: Change the text after the table as agreed with Paul Section 4.2: Change the text after the table as agreed with Paul
Hoffman. Hoffman.
Section 4.3.1: Change title and remove brackets around last Section 4.3.1: Change title and remove brackets around last
statement. statement.
Section 11: Split second paragraph. Section 11: Split second paragraph.
B.4. -05 version B.5. -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.5. -04 version B.6. -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.6. -03 version B.7. -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.7. -02 version B.8. -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.8. -01 version B.9. -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.9. draft-ietf-dprive-dtls-and-tls-profiles-00 B.10. 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. 45 change blocks. 
142 lines changed or deleted 109 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/