< draft-ietf-dprive-dtls-and-tls-profiles-06.txt   draft-ietf-dprive-dtls-and-tls-profiles-07.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: May 1, 2017 ACLU
T. Reddy T. Reddy
Cisco Cisco
October 28, 2016 October 28, 2016
Authentication and (D)TLS Profile for DNS-over-(D)TLS Authentication and (D)TLS Profile for DNS-over-(D)TLS
draft-ietf-dprive-dtls-and-tls-profiles-06 draft-ietf-dprive-dtls-and-tls-profiles-07
Abstract Abstract
This document describes how a DNS client can use a domain name to This document discusses Usage Profiles, based on one or more
authenticate a DNS server that uses Transport Layer Security (TLS) authentication mechanisms, which can be used for DNS over Transport
and Datagram TLS (DTLS). Additionally, it defines (D)TLS profiles Layer Security (TLS) or Datagram TLS (DTLS). This document also
for DNS clients and servers implementing DNS-over-TLS and DNS-over- specifies new authentication mechanisms - it describes several ways a
DTLS. DNS client can use an authentication domain name to authenticate a
DNS server. Additionally, it defines (D)TLS profiles for DNS clients
and servers implementing DNS-over-(D)TLS.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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/.
skipping to change at page 2, line 12 skipping to change at page 2, line 14
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 6 5. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Usage Profiles . . . . . . . . . . . . . . . . . . . . . 6 5.1. DNS Resolution . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. DNS Resolution . . . . . . . . . . . . . . . . . . . 8 6. Authentication in DNS-over(D)TLS . . . . . . . . . . . . . . 9
4.3. Authentication . . . . . . . . . . . . . . . . . . . . . 9 6.1. DNS-over-(D)TLS Startup Configuration Problems . . . . . 9
4.3.1. DNS-over-(D)TLS Startup Configuration Problems . . . 9 6.2. Credential Verification . . . . . . . . . . . . . . . . . 10
4.3.2. Credential Verification . . . . . . . . . . . . . . . 9 6.3. Combining Authentication Mechanisms . . . . . . . . . . . 10
4.3.3. Implementation guidance . . . . . . . . . . . . . . . 9 6.4. Authentication in Opportunistic Privacy . . . . . . . . . 10
5. Authentication in Opportunistic DNS-over(D)TLS Privacy . . . 9 6.5. Authentication in Strict Privacy . . . . . . . . . . . . 11
6. Authentication in Strict DNS-over(D)TLS Privacy . . . . . . . 10 6.6. Implementation guidance . . . . . . . . . . . . . . . . . 11
7. In Band Source of Authentication Domain Name: SRV Service 7. Sources of Authentication Domain Names . . . . . . . . . . . 11
Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. In Band Sources: SRV Service Label . . . . . . . . . . . 12
8. Out of Band Sources of Authentication Domain Name . . . . . . 11 7.2. Out of Band Sources . . . . . . . . . . . . . . . . . . . 12
8.1. Full direct configuration . . . . . . . . . . . . . . . . 11 7.2.1. Full direct configuration . . . . . . . . . . . . . . 12
8.2. Direct configuration of name only . . . . . . . . . . . . 11 7.2.2. Direct configuration of name only . . . . . . . . . . 12
8.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Credential Verification . . . . . . . . . . . . . . . . . . . 12 8. Authentication Domain Name based Credential Verification . . 13
9.1. PKIX Certificate Based Authentication . . . . . . . . . . 12 8.1. PKIX Certificate Based Authentication . . . . . . . . . . 13
9.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 14 8.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 15
9.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 14 8.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 15
10. Combined Credentials with SPKI Pinsets . . . . . . . . . . . 14 9. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 15
11. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
13. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 17
13.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 16 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 13.1. Normative References . . . . . . . . . . . . . . . . . . 17
15.1. Normative References . . . . . . . . . . . . . . . . . . 17 13.2. Informative References . . . . . . . . . . . . . . . . . 19
15.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Server capability probing and caching by DNS clients 20 Appendix A. Server capability probing and caching by DNS clients 20
Appendix B. Changes between revisions . . . . . . . . . . . . . 20 Appendix B. Changes between revisions . . . . . . . . . . . . . 21
B.1. -06 version . . . . . . . . . . . . . . . . . . . . . . . 20 B.1. -07 version . . . . . . . . . . . . . . . . . . . . . . . 21
B.2. -05 version . . . . . . . . . . . . . . . . . . . . . . . 21 B.2. -06 version . . . . . . . . . . . . . . . . . . . . . . . 21
B.3. -04 version . . . . . . . . . . . . . . . . . . . . . . . 21 B.3. -05 version . . . . . . . . . . . . . . . . . . . . . . . 21
B.4. -03 version . . . . . . . . . . . . . . . . . . . . . . . 21 B.4. -04 version . . . . . . . . . . . . . . . . . . . . . . . 22
B.5. -02 version . . . . . . . . . . . . . . . . . . . . . . . 21 B.5. -03 version . . . . . . . . . . . . . . . . . . . . . . . 22
B.6. -01 version . . . . . . . . . . . . . . . . . . . . . . . 21 B.6. -02 version . . . . . . . . . . . . . . . . . . . . . . . 22
B.7. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 22 B.7. -01 version . . . . . . . . . . . . . . . . . . . . . . . 22
B.8. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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 27 skipping to change at page 3, line 28
Intended status of Experimental. Intended status of Experimental.
Both documents are limited in scope to encrypting DNS messages Both documents are limited in scope to encrypting DNS messages
between stub clients and recursive resolvers and the same scope is between stub clients and recursive resolvers and the same scope is
applied to this document (see Section 2 and Section 3). The applied to this document (see Section 2 and Section 3). The
proposals here might be adapted or extended in future to be used for proposals here might be adapted or extended in future to be used for
recursive clients and authoritative servers, but this application was recursive clients and authoritative servers, but this application was
out of scope for the Working Group charter at the time this document out of scope for the Working Group charter at the time this document
was finished. was finished.
This document defines two Usage Profiles (Strict and Opportunistic) This document specifies two Usage Profiles (Strict and Opportunistic)
for DTLS [RFC6347] and TLS [RFC5246] which define the security for DTLS [RFC6347] and TLS [RFC5246] which define the security
properties a user should expect when using that profile to connect to properties a user should expect when using that profile to connect to
the available DNS servers. In essence: the available DNS servers. Section 5 presents a generalised
discussion of Usage Profiles by separating the Usage Profile, which
is based purely on the security properties it offers the user, from
the specific mechanism(s) that are used for authentication. The
Profiles described are:
o the Strict Profile requires an encrypted connection and successful o A Strict Profile that requires an encrypted connection and
authentication of the DNS server which provides strong privacy successful authentication of the DNS server which provides strong
guarantees (at the expense of providing no DNS service if this is privacy guarantees (at the expense of providing no DNS service if
not available). this is not available).
o the Opportunistic Profile 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.
Additionally, a number of authentication mechanisms are defined that The above Usage Profiles attempt authentication of the server using
specify how a DNS client should authenticate a DNS server based on a at least one authentication mechanism. Section 6.3 discusses how to
domain name. In particular, the following is described: combine authentication mechanisms to determine the overall
authentication result. Depending on that overall authentication
result (and whether encryption is available) the Usage Profile will
determine if the connection should proceed, fallback or fail.
One authentication mechanism is already described in [RFC7858]. That
document specifies an SPKI based authentication mechanism for DNS-
over-TLS in the context of a specific case of a Strict Usage Profile
using that single authentication mechanism. Therefore the "Out-of-
band Key-pinned Privacy Profile" described in [RFC7858] would qualify
as a "Strict Usage Profile" that used SPKI pinning for
authentication.
This document extends the use of SPKI pinset based authentication so
that it is considered a general authentication mechanism that can be
used with either DNS-over-(D)TLS Usage Profile. That is, the SPKI
pinset mechanism described in [RFC7858] MAY be used with DNS-
over-(D)TLS.
This document also describes a number of additional authentication
mechanisms all of which specify how a DNS client should authenticate
a DNS server based on an 'authentication domain name'. In
particular, the following is described:
o How a DNS client can obtain the combination of an authentication o How a DNS client can obtain the combination of an authentication
domain name and IP address for a DNS server. domain name and IP address for a DNS server. See Section 7.
o What are the acceptable credentials a DNS server can present to o What are the acceptable credentials a DNS server can present to
prove its identity for (D)TLS authentication based on a given prove its identity for (D)TLS authentication based on a given
domain name. authentication domain name. See Section 8.
o How a DNS client can verify that any given credential matches the o How a DNS client can verify that any given credential matches the
authentication domain name obtained for a DNS server. authentication domain name obtained for a DNS server. See
Section 8.
It should be noted that [RFC7858] includes a description of a
specific case of a Strict Usage Profile using a single authentication
mechanism (SPKI pinning). This document generalises the picture by
separating the Usage Profile, which is based purely on the security
properties it offers the user, from the specific mechanism that is
used for authentication. Therefore the "Out-of-band Key-pinned
Privacy Profile" described in [RFC7858] would qualify as a "Strict
Usage Profile" that used SPKI pinning for authentication.
This document also defines a (D)TLS protocol profile for use with In Section 9 this document defines a (D)TLS protocol profile for use
DNS. This profile defines the configuration options and protocol with DNS. This profile defines the configuration options and
extensions required of both parties to optimize connection protocol extensions required of both parties to optimize connection
establishment and session resumption for transporting DNS, and to establishment and session resumption for transporting DNS, and to
support the authentication mechanisms defined here. support all currently specified authentication mechanisms.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Several terms are used specifically in the context of this draft: Several terms are used specifically in the context of this draft:
o DNS client: a DNS stub resolver or forwarder. In the case of a o DNS client: a DNS stub resolver or forwarder. In the case of a
skipping to change at page 4, line 45 skipping to change at page 5, line 15
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.
o Privacy-enabling DNS server: A DNS server that: o Privacy-enabling DNS server: A DNS server that:
* MUST implement DNS-over-TLS [RFC7858] and MAY implement DNS- * MUST implement DNS-over-TLS [RFC7858] and MAY implement DNS-
over-DTLS [I-D.ietf-dprive-dnsodtls]. over-DTLS [I-D.ietf-dprive-dnsodtls].
* Can offer at least one of the credentials described in * Can offer at least one of the credentials described in
Section 9. Section 8.
* Implements the (D)TLS profile described in Section 11. * Implements the (D)TLS profile described in Section 9.
o (D)TLS: For brevity this term is used for statements that apply to o (D)TLS: For brevity this term is used for statements that apply to
both Transport Layer Security [RFC5246] and Datagram Transport both Transport Layer Security [RFC5246] and Datagram Transport
Layer Security [RFC6347]. Specific terms will be used for any Layer Security [RFC6347]. Specific terms will be used for any
statement that applies to either protocol alone. statement that applies to either protocol alone.
o DNS-over-(D)TLS: For brevity this term is used for statements that o DNS-over-(D)TLS: For brevity this term is used for statements that
apply to both DNS-over-TLS [RFC7858] and DNS-over-DTLS apply to both DNS-over-TLS [RFC7858] and DNS-over-DTLS
[I-D.ietf-dprive-dnsodtls]. Specific terms will be used for any [I-D.ietf-dprive-dnsodtls]. Specific terms will be used for any
statement that applies to either protocol alone. statement that applies to either protocol alone.
o Authentication domain name: A domain name that can be used to o Authentication domain name: A domain name that can be used to
authenticate a DNS Privacy enabling server. Sources of authenticate a DNS Privacy enabling server. Sources of
authentication domain names are discussed in Section 7 and authentication domain names are discussed in Section 7.
Section 8.
o SPKI Pinsets: [RFC7858] describes the use of cryptographic digests
to "pin" public key information in a manner similar to HPKP
[RFC7469]. An SPKI pinset is a collection of these pins that
constrains a DNS server.
o Authentication information: Information a DNS client may use as
the basis of an authentication mechanism. In this context that
can be either a:
* a SPKI pinset or
* an authentication domain name
o Reference Identifier: a Reference Identifier as described in
[RFC6125], constructed by the DNS client when performing TLS
authentication of a DNS server.
o Credential: Information available for a DNS server which proves o Credential: Information available for a DNS server which proves
its identity for authentication purposes. Credentials discussed its identity for authentication purposes. Credentials discussed
here include: here include:
* PKIX certificate * PKIX certificate
* DNSSEC validated chain to a TLSA record * DNSSEC validated chain to a TLSA record
but may also include SPKI pinsets. but may also include SPKI pinsets.
o SPKI Pinsets: [RFC7858] describes the use of cryptographic digests 3. Scope
to "pin" public key information in a manner similar to HPKP
[RFC7469]. An SPKI pinset is a collection of these pins that
constrains a DNS server.
o Reference Identifier: a Reference Identifier as described in This document is limited to describing
[RFC6125], constructed by the DNS client when performing TLS
authentication of a DNS server.
3. Scope o Usage Profiles based on general authentication mechanisms
This document is limited to domain-name-based authentication of DNS o The details of domain-name-based authentication of DNS servers by
servers by DNS clients (as defined in the terminology section), and DNS clients (as defined in the terminology section)
the (D)TLS profiles needed to support this. As such, the following
things are out of scope: o The (D)TLS profiles needed to support authentication in DNS-
over-(D)TLS.
As such, the following things are out of scope:
o Authentication of authoritative servers by recursive resolvers. o Authentication of authoritative servers by recursive resolvers.
o Authentication of DNS clients by DNS servers. o Authentication of DNS clients by DNS servers.
o SPKI-pinset-based authentication. This is defined in [RFC7858]. o The details of how to perform SPKI-pinset-based authentication.
However, Section 10 does describe how to combine that approach This is defined in [RFC7858].
with the authentication domain name based mechanism described
here.
o Any server identifier other than domain names, including IP o Any server identifier other than domain names, including IP
address, organizational name, country of origin, etc. address, organizational name, country of origin, etc.
4. Discussion 4. Discussion
4.1. Background
To protect against passive attacks DNS privacy requires encrypting To protect against passive attacks DNS privacy requires encrypting
the query (and response). Such encryption typically provides the query (and response). Such encryption typically provides
integrity protection as a side-effect, which means on-path attackers integrity protection as a side-effect, which means on-path attackers
cannot simply inject bogus DNS responses. For DNS privacy to also cannot simply inject bogus DNS responses. For DNS privacy to also
provide protection against active attackers pretending to be the provide protection against active attackers pretending to be the
server, the client must authenticate the server. server, the client must authenticate the server.
This draft discusses Usage Profiles, which provide differing levels This draft discusses Usage Profiles, which provide differing levels
of privacy guarantees to DNS clients, based on the requirements for of privacy guarantees to DNS clients, based on the requirements for
authentication and encryption, regardless of the context (for authentication and encryption, regardless of the context (for
example, which network the client is connected to). A Usage Profile example, which network the client is connected to). A Usage Profile
is a distinct concept to a usage policy or usage model, which might is a distinct concept to a usage policy or usage model, which might
dictate which Profile should be used in a particular context dictate which Profile should be used in a particular context
(enterprise vs coffee shop), with a particular set of DNS Servers or (enterprise vs coffee shop), with a particular set of DNS Servers or
with reference to other external factors. A description of the with reference to other external factors. A description of the
variety of usage policies is out of scope of this document, but may variety of usage policies is out of scope of this document, but may
be the subject of future work. be the subject of future work.
4.2. Usage Profiles 5. Usage Profiles
A DNS client has a choice of privacy Usage Profiles available. This A DNS client has a choice of privacy Usage Profiles available. This
choice is briefly discussed in both [RFC7858] and choice is briefly discussed in both [RFC7858] and
[I-D.ietf-dprive-dnsodtls]. In summary, the usage profiles are: [I-D.ietf-dprive-dnsodtls]. These Usage Profiles are:
o Strict Privacy: the DNS client requires both an encrypted and o Strict Privacy: the DNS client requires both an encrypted and
authenticated connection to a privacy-enabling DNS Server. A hard authenticated connection to a privacy-enabling DNS Server. A hard
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 information it can use to authenticate the to securely obtain authentication information it can use to
server. This profile can include some initial meta queries authenticate the server. This profile can include some initial
(performed using Opportunistic Privacy) to securely obtain the IP meta queries (performed using Opportunistic Privacy) to securely
address and authentication information for the privacy-enabling obtain the IP address and authentication information for the
DNS server to which the DNS client will subsequently connect. The privacy-enabling DNS server to which the DNS client will
rationale for this is that requiring Strict Privacy for such meta subsequently connect. The rationale for this is that requiring
queries would introduce significant deployment obstacles. This Strict Privacy for such meta queries would introduce significant
profile provides strong privacy guarantees to the client. This deployment obstacles. This profile provides strong privacy
Profile is discussed in detail in Section 6. guarantees to the client. This Profile is discussed in detail in
Section 6.5.
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 49 skipping to change at page 8, line 30
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 5. Section 6.4.
+---------------+------------+------------------+-----------------+ +---------------+------------+------------------+-----------------+
| 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 43 skipping to change at page 9, line 22
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-TLS SHOULD provide at least one
credential in order that those DNS clients that wish to do so are credential in order that those DNS clients that wish to do so are
able to use Strict Privacy (see Section 2). able to use Strict Privacy (see Section 2).
4.2.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.
4.3. Authentication 6. Authentication in DNS-over(D)TLS
This document describes authentication mechanisms that can be used in This section describes authentication mechanisms and how they can be
either Strict or Opportunistic Privacy for DNS-over-(D)TLS. used in either Strict or Opportunistic Privacy for DNS-over-(D)TLS.
4.3.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. 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. DNS clients typically know only the IP address of
a DNS server. a DNS server.
As such, before connecting to a DNS server, a DNS client needs to In this case, before connecting to a DNS server, a DNS client needs
learn the authentication domain name it should associate with the IP to learn the authentication domain name it should associate with the
address of a DNS server for authentication purposes. Sources of IP address of a DNS server for authentication purposes. Sources of
domains names are discussed in Section 7 and Section 8. authentication domains 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.
4.3.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
domain name is known for a DNS server a choice of mechanisms can be domain name is known for a DNS server a choice of authentication
used for authentication. Section 9 discusses these mechanisms in mechanisms can be used for credential verification. Section 8
detail, namely PKIX certificate based authentication and DANE. discusses these mechanisms in detail, namely PKIX certificate based
authentication and DANE.
Note that the use of DANE adds requirements on the ability of the Note that the use of DANE adds requirements on the ability of the
client to get validated DNSSEC results. This is discussed in more client to get validated DNSSEC results. This is discussed in more
detail in Section 9.2. detail in Section 8.2.
4.3.3. Implementation guidance 6.3. Combining Authentication Mechanisms
Section 11 describes the (D)TLS profile for DNS-over(D)TLS. This draft does not make explicit recommendations about how an SPKI
Additional considerations relating to general implementation pinset based authentication mechanism should be combined with a
guidelines are discussed in both Section 13 and in Appendix A. domain based mechanism from an operator perspective. However it can
be envisaged that a DNS server operator may wish to make both an SPKI
pinset and an authentication domain name available to allow clients
to choose which mechanism to use. Therefore, the following is
guidance on how clients ought to behave if they choose to configure
both, as is possible in HPKP [RFC7469].
5. Authentication in Opportunistic DNS-over(D)TLS Privacy 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
credential for the authentication domain name and a valid SPKI pinset
(if both are available) when connecting to that DNS server. The
overall authentication result should only be considered successful if
both authentication mechanisms are successful.
6.4. 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
of an authentication domain name or SPKI pinset for a given privacy- authentication information for a given privacy-enabling DNS server
enabling DNS server MAY choose to try to authenticate the server MAY choose to try to authenticate the server using the mechanisms
using the mechanisms described here. This is useful for detecting described here. This is useful for detecting (but not preventing)
(but not preventing) active attack, since the fact that active attack, since the fact that authentication information is
authentication information is available indicates that the server in available indicates that the server in question is a privacy-enabling
question is a privacy-enabling DNS server to which it should be DNS server to which it should be possible to establish an
possible to establish an authenticated, encrypted connection. In authenticated, encrypted connection. In this case, whilst a client
this case, whilst a client cannot know the reason for an cannot know the reason for an authentication failure, from a privacy
authentication failure, from a privacy standpoint the client should standpoint the client should consider an active attack in progress
consider an active attack in progress and proceed under that and proceed under that assumption. Attempting authentication is also
assumption. Attempting authentication is also useful for debugging useful for debugging or diagnostic purposes if there are means to
or diagnostic purposes if there are means to report the result. This report the result. This information can provide a basis for a DNS
information can provide a basis for a DNS client to switch to client to switch to (preferred) Strict Privacy where it is viable.
(preferred) Strict Privacy where it is viable.
6. Authentication in Strict DNS-over(D)TLS Privacy 6.5. 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 the domain name for each server it is willing to contact. This know authentication information for each server it is willing to
is necessary to protect against active attacks on DNS privacy. contact. This is necessary to protect against active attacks on DNS
privacy.
A DNS client requiring Strict Privacy MUST either use one of the A DNS client requiring Strict Privacy MUST either use one of the
sources listed in Section 8 to obtain 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 either an authentication domain name or a SPKI DNS servers for which at least on piece of authentication information
pinset is known (or both). The client MUST use the available is known. The client MUST use the available verification mechanisms
verification mechanisms described in Section 9 to authenticate the described in Section 8 to authenticate the server, and MUST abort
server, and MUST abort connections to a server when no verification connections to a server when no verification mechanism succeeds.
mechanism succeeds.
With Strict Privacy, the DNS client MUST NOT commence sending DNS With Strict Privacy, the DNS client MUST NOT commence sending DNS
queries until at least one of the privacy-enabling DNS servers queries until at least one of the privacy-enabling DNS servers
becomes available. becomes available.
A privacy-enabling DNS server may be temporarily unavailable when A privacy-enabling DNS server may be temporarily unavailable when
configuring a network. For example, for clients on networks that configuring a network. For example, for clients on networks that
require registration through web-based login (a.k.a. "captive require registration through web-based login (a.k.a. "captive
portals"), such registration may rely on DNS interception and portals"), such registration may rely on DNS interception and
spoofing. Techniques such as those used by DNSSEC-trigger spoofing. Techniques such as those used by DNSSEC-trigger
[dnssec-trigger] MAY be used during network configuration, with the [dnssec-trigger] MAY be used during network configuration, with the
intent to transition to the designated privacy-enabling DNS servers intent to transition to the designated privacy-enabling DNS servers
after captive portal registration. The system MUST alert by some after captive portal registration. The system MUST alert by some
means that the DNS is not private during such bootstrap. means that the DNS is not private during such bootstrap.
7. In Band Source of Authentication Domain Name: SRV Service Label 6.6. Implementation guidance
Section 9 describes the (D)TLS profile for DNS-over(D)TLS.
Additional considerations relating to general implementation
guidelines are discussed in both Section 11 and in Appendix A.
7. Sources of Authentication Domain Names
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.
_domain-s._udp.dns.example.com. SRV 0 1 853 dns3.example.com. _domain-s._udp.dns.example.com. SRV 0 1 853 dns3.example.com.
8. Out of Band Sources of Authentication Domain Name 7.2. Out of Band Sources
8.1. Full direct configuration 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.
8.2. Direct configuration of name only 7.2.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 untrusted recursive DNS
resolver to establish the IP address of the intended privacy-enabling resolver to establish the IP address of the intended privacy-enabling
DNS server by doing a lookup of SRV records. Such records MUST be DNS server by doing a lookup of SRV records. Such records MUST be
skipping to change at page 12, line 18 skipping to change at page 13, line 18
o Client validates all the records obtained in the previous step o Client validates all the records obtained in the previous step
using DNSSEC. using DNSSEC.
o If the records successfully validate the client proceeds to o If the records successfully validate the client proceeds to
connect to the privacy-enabling DNS server using Strict Privacy. 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 looked up
addresses in order to not have to repeat the opportunistic lookup. addresses in order to not have to repeat the opportunistic lookup.
8.3. DHCP 7.2.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 12, line 42 skipping to change at page 13, line 42
of that profile. However when using a Strict profile the DHCP of that profile. However when using a Strict profile the DHCP
servers used as sources of authentication domain names MUST be servers used as sources of authentication domain names MUST be
considered secure and trustworthy. This document does not attempt to considered secure and trustworthy. This document does not attempt to
describe secured and trusted relationships to DHCP servers. describe secured and trusted relationships to DHCP servers.
It is noted (at the time of writing) that whilst some implementation It is noted (at the time of writing) that whilst some implementation
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.
9. Credential Verification 8. Authentication Domain Name based Credential Verification
9.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 an 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 two Reference Identifiers for the server
based on the authentication domain name: A DNS-ID and an SRV-ID based on the authentication domain name: A DNS-ID and an SRV-ID
skipping to change at page 13, line 25 skipping to change at page 14, line 25
If either of the Reference Identifiers are found in the PKIX If either of the Reference Identifiers are found in the PKIX
certificate's subjectAltName extension as described in section 6 of certificate's subjectAltName extension as described in section 6 of
[RFC6125], the DNS client should accept the certificate for the [RFC6125], the DNS client should accept the certificate for the
server. server.
A compliant DNS client MUST only inspect the certificate's A compliant DNS client MUST only inspect the certificate's
subjectAltName extension for these Reference Identifiers. In subjectAltName extension for these Reference Identifiers. In
particular, it MUST NOT inspect the Subject field itself. particular, it MUST NOT inspect the Subject field itself.
9.2. DANE 8.2. DANE
DANE [RFC6698] provides mechanisms to root certificate and raw public DANE [RFC6698] provides mechanisms to root certificate and raw public
key trust with DNSSEC. However this requires the DNS client to have key trust with DNSSEC. However this requires the DNS client to have
an authentication domain name for the DNS Privacy Server which must an authentication domain name for the DNS Privacy Server which must
be obtained via a trusted source. be obtained via a trusted source.
This section assumes a solid understanding of both DANE [RFC6698] and This section assumes a solid understanding of both DANE [RFC6698] and
DANE Operations [RFC7671]. A few pertinent issues covered in these DANE Operations [RFC7671]. A few pertinent issues covered in these
documents are outlined here as useful pointers, but familiarity with documents are outlined here as useful pointers, but familiarity with
both these documents in their entirety is expected. both these documents in their entirety is expected.
skipping to change at page 14, line 21 skipping to change at page 15, line 21
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
9.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].
9.2.2. TLS DNSSEC Chain extension 8.2.2. TLS DNSSEC Chain extension
The DNS client MAY offer the TLS extension described in The DNS client MAY offer the TLS extension described in
[I-D.ietf-tls-dnssec-chain-extension]. If the DNS server supports [I-D.ietf-tls-dnssec-chain-extension]. If the DNS server supports
this extension, it can provide the full chain to the client in the this extension, it can provide the full chain to the client in the
handshake. handshake.
If the DNS client offers the TLS DNSSEC Chain extension, it MUST be If the DNS client offers the TLS DNSSEC Chain extension, it MUST be
capable of validating the full DNSSEC authentication chain down to capable of validating the full DNSSEC authentication chain down to
the leaf. If the supplied DNSSEC chain does not validate, the client the leaf. If the supplied DNSSEC chain does not validate, the client
MUST ignore the DNSSEC chain and validate only via other supplied MUST ignore the DNSSEC chain and validate only via other supplied
credentials. credentials.
10. Combined Credentials with SPKI Pinsets 9. (D)TLS Protocol Profile
The SPKI pinset profile described in [RFC7858] MAY be used with DNS-
over-(D)TLS.
This draft does not make explicit recommendations about how a SPKI
pinset based authentication mechanism should be combined with a
domain based mechanism from an operator perspective. However it can
be envisaged that a DNS server operator may wish to make both an SPKI
pinset and an authentication domain name available to allow clients
to choose which mechanism to use. Therefore, the following is
guidance on how clients ought to behave if they choose to configure
both, as is possible in HPKP [RFC7469].
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
credential for the authentication domain name and a valid SPKI pinset
if both are available when connecting to that DNS server.
11. (D)TLS Protocol Profile
This section defines the (D)TLS protocol profile of DNS-over-(D)TLS. This section defines the (D)TLS protocol profile of DNS-over-(D)TLS.
There are known attacks on (D)TLS, such as machine-in-the-middle and There are known attacks on (D)TLS, such as machine-in-the-middle and
protocol downgrade. These are general attacks on (D)TLS and not protocol downgrade. These are general attacks on (D)TLS and not
specific to DNS-over-TLS; please refer to the (D)TLS RFCs for specific to DNS-over-TLS; please refer to the (D)TLS RFCs for
discussion of these security issues. 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
skipping to change at page 16, line 12 skipping to change at page 16, line 43
the TLS second flight of messages (ChangeCipherSpec) to also the TLS second flight of messages (ChangeCipherSpec) to also
contain the (encrypted) DNS query contain the (encrypted) DNS query
o Cached Information Extension [RFC7924] which avoids transmitting o Cached Information Extension [RFC7924] which avoids transmitting
the server's certificate and certificate chain if the client has the server's certificate and certificate chain if the client has
cached that information from a previous TLS handshake cached that information from a previous TLS handshake
Guidance specific to TLS is provided in [RFC7858] and that specific Guidance specific to TLS is provided in [RFC7858] and that specific
to DTLS it is provided in[I-D.ietf-dprive-dnsodtls]. to DTLS it is provided in[I-D.ietf-dprive-dnsodtls].
12. IANA Considerations 10. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
13. 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.
13.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 16, line 47 skipping to change at page 17, line 31
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.
14. 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 and
Christian Huitema for review and discussion of the ideas presented Christian Huitema for review and discussion of the ideas presented
here. here.
15. References 13. References
15.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 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure
Subject Alternative Name for Expression of Service Name", Subject Alternative Name for Expression of Service Name",
RFC 4985, DOI 10.17487/RFC4985, August 2007, RFC 4985, DOI 10.17487/RFC4985, August 2007,
<http://www.rfc-editor.org/info/rfc4985>. <http://www.rfc-editor.org/info/rfc4985>.
skipping to change at page 18, line 36 skipping to change at page 19, line 19
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
DOI 10.17487/RFC7830, May 2016, DOI 10.17487/RFC7830, May 2016,
<http://www.rfc-editor.org/info/rfc7830>. <http://www.rfc-editor.org/info/rfc7830>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <http://www.rfc-editor.org/info/rfc7858>. 2016, <http://www.rfc-editor.org/info/rfc7858>.
15.2. Informative References 13.2. Informative References
[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-
skipping to change at page 20, line 32 skipping to change at page 21, line 10
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. -06 version B.1. -07 version
Re-work of the Abstract and Introduction to better describe the
contents in this version.
Terminology: New definition of 'authentication information'.
Scope: Changes to the Scope section.
Moved discussion of combining authentication mechanism earlier.
Changes to the section headings and groupings to make the
presentation more logical.
B.2. -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 7 skipping to change at page 21, line 48
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.2. -05 version B.3. -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.3. -04 version B.4. -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.4. -03 version B.5. -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.5. -02 version B.6. -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.6. -01 version B.7. -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.7. draft-ietf-dprive-dtls-and-tls-profiles-00 B.8. 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. 72 change blocks. 
195 lines changed or deleted 238 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/