< draft-ietf-dprive-dtls-and-tls-profiles-07.txt   draft-ietf-dprive-dtls-and-tls-profiles-08.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: May 1, 2017 ACLU Expires: July 22, 2017 ACLU
T. Reddy T. Reddy
Cisco Cisco
October 28, 2016 January 18, 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-07 draft-ietf-dprive-dtls-and-tls-profiles-08
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 May 1, 2017. This Internet-Draft will expire on July 22, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . 7 5. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . 7
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. Combining Authentication Mechanisms . . . . . . . . . . . 10 6.3. Summary of Authentication Mechanisms . . . . . . . . . . 10
6.4. Authentication in Opportunistic Privacy . . . . . . . . . 10 6.4. Combining Authentication Mechanisms . . . . . . . . . . . 13
6.5. Authentication in Strict Privacy . . . . . . . . . . . . 11 6.5. Authentication in Opportunistic Privacy . . . . . . . . . 13
6.6. Implementation guidance . . . . . . . . . . . . . . . . . 11 6.6. Authentication in Strict Privacy . . . . . . . . . . . . 13
7. Sources of Authentication Domain Names . . . . . . . . . . . 11 6.7. Implementation guidance . . . . . . . . . . . . . . . . . 14
7.1. In Band Sources: SRV Service Label . . . . . . . . . . . 12 7. Sources of Authentication Domain Names . . . . . . . . . . . 14
7.2. Out of Band Sources . . . . . . . . . . . . . . . . . . . 12 7.1. In Band Sources: SRV Service Label . . . . . . . . . . . 14
7.2.1. Full direct configuration . . . . . . . . . . . . . . 12 7.2. Out of Band Sources . . . . . . . . . . . . . . . . . . . 15
7.2.2. Direct configuration of name only . . . . . . . . . . 12 7.2.1. Full direct configuration . . . . . . . . . . . . . . 15
7.2.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 13 7.2.2. Direct configuration of name only . . . . . . . . . . 15
8. Authentication Domain Name based Credential Verification . . 13 7.2.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. PKIX Certificate Based Authentication . . . . . . . . . . 13 8. Authentication Domain Name based Credential Verification . . 16
8.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. PKIX Certificate Based Authentication . . . . . . . . . . 16
8.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 15 8.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 15 8.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 18
9. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 15 8.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . 19 13.1. Normative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Server capability probing and caching by DNS clients 20 13.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix B. Changes between revisions . . . . . . . . . . . . . 21 Appendix A. Server capability probing and caching by DNS clients 23
B.1. -07 version . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix B. Changes between revisions . . . . . . . . . . . . . 23
B.2. -06 version . . . . . . . . . . . . . . . . . . . . . . . 21 B.1. -08 version . . . . . . . . . . . . . . . . . . . . . . . 23
B.3. -05 version . . . . . . . . . . . . . . . . . . . . . . . 21 B.2. -07 version . . . . . . . . . . . . . . . . . . . . . . . 23
B.4. -04 version . . . . . . . . . . . . . . . . . . . . . . . 22 B.3. -06 version . . . . . . . . . . . . . . . . . . . . . . . 24
B.5. -03 version . . . . . . . . . . . . . . . . . . . . . . . 22 B.4. -05 version . . . . . . . . . . . . . . . . . . . . . . . 24
B.6. -02 version . . . . . . . . . . . . . . . . . . . . . . . 22 B.5. -04 version . . . . . . . . . . . . . . . . . . . . . . . 24
B.7. -01 version . . . . . . . . . . . . . . . . . . . . . . . 22 B.6. -03 version . . . . . . . . . . . . . . . . . . . . . . . 25
B.8. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 23 B.7. -02 version . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 B.8. -01 version . . . . . . . . . . . . . . . . . . . . . . . 25
B.9. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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 3, line 47 skipping to change at page 3, line 49
o A Strict Profile that requires an encrypted connection and o A Strict Profile that requires an encrypted connection and
successful authentication of the DNS server which provides strong successful authentication of the DNS server which provides strong
privacy guarantees (at the expense of providing no DNS service if privacy guarantees (at the expense of providing no DNS service if
this is not available). this is not available).
o An Opportunistic Profile that will attempt, but does not require, o An Opportunistic Profile that 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.
The above Usage Profiles attempt authentication of the server using The above Usage Profiles attempt authentication of the server using
at least one authentication mechanism. Section 6.3 discusses how to at least one authentication mechanism. Section 6.4 discusses how to
combine authentication mechanisms to determine the overall combine authentication mechanisms to determine the overall
authentication result. Depending on that overall authentication authentication result. Depending on that overall authentication
result (and whether encryption is available) the Usage Profile will result (and whether encryption is available) the Usage Profile will
determine if the connection should proceed, fallback or fail. determine if the connection should proceed, fallback or fail.
One authentication mechanism is already described in [RFC7858]. That One authentication mechanism is already described in [RFC7858]. That
document specifies an SPKI based authentication mechanism for DNS- document specifies an SPKI based authentication mechanism for DNS-
over-TLS in the context of a specific case of a Strict Usage Profile over-TLS in the context of a specific case of a Strict Usage Profile
using that single authentication mechanism. Therefore the "Out-of- using that single authentication mechanism. Therefore the "Out-of-
band Key-pinned Privacy Profile" described in [RFC7858] would qualify band Key-pinned Privacy Profile" described in [RFC7858] would qualify
skipping to change at page 7, line 25 skipping to change at page 7, line 28
failure occurs if this is not available. This requires the client failure occurs if this is not available. This requires the client
to securely obtain authentication information it can use to to securely obtain authentication information it can use to
authenticate the server. This profile can include some initial authenticate the server. This profile can include some initial
meta queries (performed using Opportunistic Privacy) to securely meta queries (performed using Opportunistic Privacy) to securely
obtain the IP address and authentication information for the obtain the IP address and authentication information for the
privacy-enabling DNS server to which the DNS client will privacy-enabling DNS server to which the DNS client will
subsequently connect. The rationale for this is that requiring subsequently connect. The rationale for this is that requiring
Strict Privacy for such meta queries would introduce significant Strict Privacy for such meta queries would introduce significant
deployment obstacles. This profile provides strong privacy deployment obstacles. This profile provides strong privacy
guarantees to the client. This Profile is discussed in detail in guarantees to the client. This Profile is discussed in detail in
Section 6.5. Section 6.6.
o Opportunistic Privacy: the DNS client uses Opportunistic Security o Opportunistic Privacy: the DNS client uses Opportunistic Security
as described in [RFC7435] as described in [RFC7435]
"... the use of cleartext as the baseline communication "... the use of cleartext as the baseline communication
security policy, with encryption and authentication negotiated security policy, with encryption and authentication negotiated
and applied to the communication when available." and applied to the communication when available."
The use of Opportunistic Privacy is intended to support The use of Opportunistic Privacy is intended to support
incremental deployment of security capabilities with a view to incremental deployment of security capabilities with a view to
skipping to change at page 7, line 47 skipping to change at page 7, line 50
the DNS client might otherwise settle for cleartext; it provides the DNS client might otherwise settle for cleartext; it provides
the maximum protection available. As described in [RFC7435] it the maximum protection available. As described in [RFC7435] it
might result in might result in
* an encrypted and authenticated connection * an encrypted and authenticated connection
* an encrypted connection * an encrypted connection
* a clear text connection * a clear text connection
* hard failure
depending on the fallback logic of the client, the available depending on the fallback logic of the client, the available
authentication information and the capabilities of the DNS Server. authentication information and the capabilities of the DNS Server.
In the first three cases the DNS client is willing to continue
with a connection to the DNS Server and perform resolution of In all these cases the DNS client is willing to continue with a
queries. connection to the DNS Server and perform resolution of queries.
To compare the two Usage profiles the table below shows successful To compare the two Usage profiles the table below shows successful
Strict Privacy along side the 3 possible successful outcomes of Strict Privacy along side the 3 possible outcomes of Opportunistic
Opportunistic Privacy. In the best case scenario for Opportunistic Privacy. In the best case scenario for Opportunistic Privacy (an
Privacy (an authenticated and encrypted connection) it is equivalent authenticated and encrypted connection) it is equivalent to Strict
to Strict Privacy. In the worst case scenario it is equivalent to Privacy. In the worst case scenario it is equivalent to clear text.
clear text. Clients using Opportunistic Privacy SHOULD try for the Clients using Opportunistic Privacy SHOULD try for the best case but
best case but MAY fallback to intermediate cases and eventually the MAY fallback to the intermediate case and eventually the worst case
worst case scenario in order to obtain a response. It therefore scenario in order to obtain a response. It therefore provides no
provides no privacy guarantee to the user and varying protection privacy guarantee to the user and varying protection depending on
depending on what kind of connection is actually used. what kind of connection is actually used.
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 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.4. 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 10, line 19 skipping to change at page 10, line 19
In terms of domain name based verification, once an authentication In terms of domain name based verification, once an authentication
domain name is known for a DNS server a choice of authentication domain name is known for a DNS server a choice of authentication
mechanisms can be used for credential verification. Section 8 mechanisms can be used for credential verification. Section 8
discusses these mechanisms in detail, namely PKIX certificate based discusses these mechanisms in detail, namely PKIX certificate based
authentication and DANE. 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 8.2. detail in Section 8.2.
6.3. Combining Authentication Mechanisms 6.3. Summary of Authentication Mechanisms
This section provides an overview of the various authentication
mechanisms. The table below indicates how the DNS client obtains
information to use for authentication for each option; either
statically via direct configuration or dynamically. Of course, the
Opportunistic Usage Profile does not require authentication and so a
client using that profile may choose to connect to a Privacy Enabling
DNS server on the basis of just an IP address.
+---+------------+-------------+------------------------------------+
| # | Static | Dynamically | Short name: Description |
| | Config | Obtained | |
+---+------------+-------------+------------------------------------+
| 1 | SPKI + IP | | SPKI: SPKI pinset(s) and IP |
| | | | address obtained out of band |
| | | | [RFC7858] |
| | | | |
| 2 | ADN + IP | | ADN: ADN and IP address obtained |
| | | | out of band (see Section 7.2.1) |
| | | | |
| 3 | ADN | IP | ADN only: DNSSEC validated |
| | | | Opportunistic lookups to a NP DNS |
| | | | server for SRV, A/AAAA (see |
| | | | Section 7.2.2) |
| | | | |
| 4 | | ADN + IP | DHCP: DHCP configuration only (see |
| | | | Section 7.2.3) |
| | | | |
| 5 | [ADN + IP] | [ADN + IP] | DANE: DNSSEC chain obtained via |
| | | TLSA record | Opportunistic lookups to NP DNS |
| | | | server (see Section 8.2.1) |
| | | | |
| 6 | [ADN + IP] | [ADN + IP] | TLS extension: DNSSEC chain |
| | | TLSA record | provided by PE DNS server in TLS |
| | | | DNSSEC chain extension (see |
| | | | Section 8.2.2) |
+---+------------+-------------+------------------------------------+
SPKI == SPKI pinset(s), IP == IP Address, ADN == Authentication
Domain Name, NP == Network provided, PE == Privacy-enabling, [ ] ==
Data may be obtained either statically or dynamically
Table 2: Overview of Authentication Mechanisms
The following summary attempts to present some key attributes of each
of the mechanisms (using the 'Short name' from Table 2), indicating
attractive attributes with a '+' and undesirable attributes with a
'-'.
1. SPKI
+ Minimal leakage (Note that the ADN is always leaked in the
SNI field in the Client Hello in TLS when communicating with a
privacy enabling DNS server)
- Overhead of on-going key management required
2. ADN
+ Minimal leakage
+ One-off direct configuration only
3. ADN only
+ Minimal one-off direct configuration, only a human
recognisable domain name needed
- SRV, A/AAAA meta queries leaked to network provided DNS
server
4. DHCP
+ No static config
- Requires a non-standard or future DHCP option in order to
provide the ADN
- Requires secure and trustworthy connection to DHCP server
5. DANE
The ADN and/or IP may be obtained statically or dynamically
and the relevant attributes of that method apply
+ DANE options (e.g. matching on entire certificate)
- Requires a DNSSEC validating stub implementation (deployment
of which is limited at the time of writing)
- DNSSEC chain meta queries leaked to network provided DNS
server
6. TLS extension
The ADN and/or IP may be obtained statically or dynamically
and the relevant attributes of that method apply
+ Reduced latency compared with 'DANE'
+ No network provided DNS server required if ADN and IP
statically configured
+ DANE options (e.g. matching on entire certificate)
- Requires a DNSSEC validating stub implementation
6.4. Combining Authentication Mechanisms
This draft does not make explicit recommendations about how an SPKI This draft does not make explicit recommendations about how an 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 an authentication domain name available to allow clients pinset and an authentication domain name available to allow clients
to choose which mechanism to use. Therefore, the following is to choose which mechanism to use. Therefore, the following is
guidance on how clients ought to behave if they choose to configure guidance on how clients ought to behave if they choose to configure
both, as is possible in HPKP [RFC7469]. both, as is possible in HPKP [RFC7469].
A DNS client that is configured with both an authentication domain A DNS client that is configured with both an authentication domain
name and a SPKI pinset for a DNS server SHOULD match on both a valid name and a SPKI pinset for a DNS server SHOULD match on both a valid
credential for the authentication domain name and a valid SPKI pinset credential for the authentication domain name and a valid SPKI pinset
(if both are available) when connecting to that DNS server. The (if both are available) when connecting to that DNS server. The
overall authentication result should only be considered successful if overall authentication result should only be considered successful if
both authentication mechanisms are successful. both authentication mechanisms are successful.
6.4. Authentication in Opportunistic Privacy 6.5. Authentication in Opportunistic 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
authentication information for a given privacy-enabling DNS server authentication information for a given privacy-enabling DNS server
MAY choose to try to authenticate the server using the mechanisms MAY choose to try to authenticate the server using the mechanisms
described here. This is useful for detecting (but not preventing) described here. This is useful for detecting (but not preventing)
active attack, since the fact that authentication information is active attack, since the fact that authentication information is
available indicates that the server in question is a privacy-enabling available indicates that the server in question is a privacy-enabling
DNS server to which it should be possible to establish an DNS server to which it should be possible to establish an
authenticated, encrypted connection. In this case, whilst a client authenticated, encrypted connection. In this case, whilst a client
cannot know the reason for an authentication failure, from a privacy cannot know the reason for an authentication failure, from a privacy
standpoint the client should consider an active attack in progress standpoint the client should consider an active attack in progress
and proceed under that assumption. Attempting authentication is also and proceed under that assumption. Attempting authentication is also
useful for debugging or diagnostic purposes if there are means to useful for debugging or diagnostic purposes if there are means to
report the result. This information can provide a basis for a DNS report the result. This information can provide a basis for a DNS
client to switch to (preferred) Strict Privacy where it is viable. client to switch to (preferred) Strict Privacy where it is viable.
6.5. 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.2 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 on piece of authentication information DNS servers for which at least one piece of authentication
is known. The client MUST use the available verification mechanisms information is known. The client MUST use the available verification
described in Section 8 to authenticate the server, and MUST abort mechanisms described in Section 8 to authenticate the server, and
connections to a server when no verification mechanism succeeds. 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.
6.6. 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. In Band Sources: 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.
skipping to change at page 15, line 7 skipping to change at page 17, line 43
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 OS.
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. [QUESTION: Should an the TLSA RRset properties for this case.
appendix be added with an example of how to use DANE without PKIX
certificates?]
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.[server-domain-name] for TLS
_853._udp.[server-domain-name] for DTLS _853._udp.[server-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].
skipping to change at page 17, line 21 skipping to change at page 20, line 4
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
o EDNS(0) padding [RFC7830], which allows encrypted queries and o EDNS(0) padding [RFC7830], which allows encrypted queries and
responses to hide their size. responses to hide their size.
DNS-over-(D)TLS clients SHOULD consider implementing the following DNS-over-(D)TLS clients SHOULD consider implementing the following
relevant DNS extensions relevant DNS extensions
o Privacy Election using Client Subnet in DNS Queries [RFC7871]. If o Privacy Election using Client Subnet in DNS Queries [RFC7871]. If
a DNS client does not include an EDNS0 Client Subnet Option with a a DNS client does not include an EDNS0 Client Subnet Option with a
SOURCE PREFIX-LENGTH set to 0 in a query, the DNS server may SOURCE PREFIX-LENGTH set to 0 in a query, the DNS server may
potentially leak client address information to the upstream potentially leak client address information to the upstream
authoritative DNS servers. A DNS client ought to be able to authoritative DNS servers. A DNS client ought to be able to
inform the DNS Resolver that it does not want any address inform the DNS Resolver that it does not want any address
information leaked, and the DNS Resolver should honor that information leaked, and the DNS Resolver should honor that
request. request.
12. Acknowledgements 12. Acknowledgements
Thanks to the authors of both [I-D.ietf-dprive-dnsodtls] and Thanks to the authors of both [I-D.ietf-dprive-dnsodtls] and
[RFC7858] for laying the ground work that this draft builds on and [RFC7858] for laying the ground work that this draft builds on and
for reviewing the contents. The authors would also like to thank for reviewing the contents. The authors would also like to thank
John Dickinson, Shumon Huque, Melinda Shore, Gowri Visweswaran, Ray John Dickinson, Shumon Huque, Melinda Shore, Gowri Visweswaran, Ray
Bellis, Stephane Bortzmeyer, Jinmei Tatuya, Paul Hoffman and Bellis, Stephane Bortzmeyer, Jinmei Tatuya, Paul Hoffman, Christian
Christian Huitema for review and discussion of the ideas presented Huitema and John Levine for review and discussion of the ideas
here. presented here.
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>.
skipping to change at page 19, line 30 skipping to change at page 22, line 12
[CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", 2012. [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", 2012.
[dnssec-trigger] [dnssec-trigger]
NLnetLabs, "Dnssec-Trigger", May 2014, NLnetLabs, "Dnssec-Trigger", May 2014,
<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-12 (work in progress), September ietf-dprive-dnsodtls-15 (work in progress), December 2016.
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-01 (work in draft-ietf-tls-dnssec-chain-extension-02 (work in
progress), July 2016. progress), January 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 21, line 10 skipping to change at page 23, 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. -07 version B.1. -08 version
Removed hard failure as an option for Opportunistic Usage profile.
Added a new section comparing the Authentication Mechanisms
B.2. -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.2. -06 version B.3. -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 21, line 48 skipping to change at page 24, line 38
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.3. -05 version B.4. -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.4. -04 version B.5. -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.5. -03 version B.6. -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.6. -02 version B.7. -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.7. -01 version B.8. -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.8. draft-ietf-dprive-dtls-and-tls-profiles-00 B.9. 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. 33 change blocks. 
84 lines changed or deleted 195 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/