< draft-ietf-dprive-dtls-and-tls-profiles-09.txt   draft-ietf-dprive-dtls-and-tls-profiles-10.txt >
dprive S. Dickinson dprive S. Dickinson
Internet-Draft Sinodun Internet-Draft Sinodun
Updates: 7858 (if approved) D. Gillmor Updates: 7858 (if approved) D. Gillmor
Intended status: Standards Track ACLU Intended status: Standards Track ACLU
Expires: October 12, 2017 T. Reddy Expires: December 18, 2017 T. Reddy
Cisco McAfee
April 10, 2017 June 16, 2017
Authentication and (D)TLS Profile for DNS-over-(D)TLS Usage and (D)TLS Profiles for DNS-over-(D)TLS
draft-ietf-dprive-dtls-and-tls-profiles-09 draft-ietf-dprive-dtls-and-tls-profiles-10
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). These profiles can
specifies new authentication mechanisms - it describes several ways a increase the privacy of DNS transactions compared to using only clear
DNS client can use an authentication domain name to authenticate a text DNS. This document also specifies new authentication mechanisms
DNS server. Additionally, it defines (D)TLS profiles for DNS clients - it describes several ways a DNS client can use an authentication
and servers implementing DNS-over-(D)TLS. domain name to authenticate a (D)TLS connection to a DNS server.
Additionally, it defines (D)TLS protocol profiles for DNS clients and
servers implementing DNS-over-(D)TLS. This document updates RFC
7858.
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/.
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 October 12, 2017. This Internet-Draft will expire on December 18, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . 7 5. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. DNS Resolution . . . . . . . . . . . . . . . . . . . . . 9 5.1. DNS Resolution . . . . . . . . . . . . . . . . . . . . . 10
6. Authentication in DNS-over(D)TLS . . . . . . . . . . . . . . 9 6. Authentication in DNS-over(D)TLS . . . . . . . . . . . . . . 10
6.1. DNS-over-(D)TLS Startup Configuration Problems . . . . . 9 6.1. DNS-over-(D)TLS Startup Configuration Problems . . . . . 10
6.2. Credential Verification . . . . . . . . . . . . . . . . . 10 6.2. Credential Verification . . . . . . . . . . . . . . . . . 11
6.3. Summary of Authentication Mechanisms . . . . . . . . . . 10 6.3. Summary of Authentication Mechanisms . . . . . . . . . . 11
6.4. Combining Authentication Mechanisms . . . . . . . . . . . 13 6.4. Combining Authentication Mechanisms . . . . . . . . . . . 14
6.5. Authentication in Opportunistic Privacy . . . . . . . . . 13 6.5. Authentication in Opportunistic Privacy . . . . . . . . . 14
6.6. Authentication in Strict Privacy . . . . . . . . . . . . 13 6.6. Authentication in Strict Privacy . . . . . . . . . . . . 15
6.7. Implementation guidance . . . . . . . . . . . . . . . . . 14 6.7. Implementation guidance . . . . . . . . . . . . . . . . . 15
7. Sources of Authentication Domain Names . . . . . . . . . . . 14 7. Sources of Authentication Domain Names . . . . . . . . . . . 15
7.1. Full direct configuration . . . . . . . . . . . . . . . . 14 7.1. Full direct configuration . . . . . . . . . . . . . . . . 15
7.2. Direct configuration of name only . . . . . . . . . . . . 14 7.2. Direct configuration of ADN only . . . . . . . . . . . . 16
7.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.3. Dynamic discovery of ADN . . . . . . . . . . . . . . . . 16
8. Authentication Domain Name based Credential Verification . . 15 7.3.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. PKIX Certificate Based Authentication . . . . . . . . . . 15 8. Authentication Domain Name based Credential Verification . . 17
8.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. PKIX Certificate Based Authentication . . . . . . . . . . 17
8.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 17 8.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 17 8.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 18
9. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 17 8.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 18 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 21 13.1. Normative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Server capability probing and caching by DNS clients 22 13.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix B. Changes between revisions . . . . . . . . . . . . . 22 Appendix A. Server capability probing and caching by DNS clients 24
B.1. -09 version . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix B. Changes between revisions . . . . . . . . . . . . . 24
B.2. -08 version . . . . . . . . . . . . . . . . . . . . . . . 23 B.1. -10 version . . . . . . . . . . . . . . . . . . . . . . . 25
B.3. -07 version . . . . . . . . . . . . . . . . . . . . . . . 23 B.2. -09 version . . . . . . . . . . . . . . . . . . . . . . . 26
B.4. -06 version . . . . . . . . . . . . . . . . . . . . . . . 23 B.3. -08 version . . . . . . . . . . . . . . . . . . . . . . . 26
B.5. -05 version . . . . . . . . . . . . . . . . . . . . . . . 24 B.4. -07 version . . . . . . . . . . . . . . . . . . . . . . . 26
B.6. -04 version . . . . . . . . . . . . . . . . . . . . . . . 24 B.5. -06 version . . . . . . . . . . . . . . . . . . . . . . . 26
B.7. -03 version . . . . . . . . . . . . . . . . . . . . . . . 24 B.6. -05 version . . . . . . . . . . . . . . . . . . . . . . . 27
B.8. -02 version . . . . . . . . . . . . . . . . . . . . . . . 24 B.7. -04 version . . . . . . . . . . . . . . . . . . . . . . . 27
B.9. -01 version . . . . . . . . . . . . . . . . . . . . . . . 24 B.8. -03 version . . . . . . . . . . . . . . . . . . . . . . . 27
B.10. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 25 B.9. -02 version . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 B.10. -01 version . . . . . . . . . . . . . . . . . . . . . . . 28
B.11. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
DNS Privacy issues are discussed in [RFC7626]. Two documents that DNS Privacy issues are discussed in [RFC7626]. The specific issues
provide DNS privacy between DNS clients and DNS servers are: described there that are most relevant to this document are
o Passive attacks which eavesdrop on clear text DNS transactions on
the wire (Section 2.4) and
o Active attacks which redirect clients to rogue servers to monitor
DNS traffic (Section 2.5.3).
Mitigating against these attacks increases the privacy of DNS
transactions, however many of the other issues raised in [RFC7626]
still apply.
Two documents that provide ways to increase 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 Datagram Transport Layer Security (DTLS) [RFC8094],
simply as 'DNS-over-DTLS'. Note that this document has the referred to here simply as 'DNS-over-DTLS'. Note that this
Intended status of Experimental. document has the Category of Experimental.
Both documents are limited in scope to encrypting DNS messages Both documents are limited in scope to communications between stub
between stub clients and recursive resolvers and the same scope is clients and recursive resolvers and the same scope is applied to this
applied to this document (see Section 2 and Section 3). The document (see Section 2 and Section 3). The proposals here might be
proposals here might be adapted or extended in future to be used for adapted or extended in future to be used for recursive clients and
recursive clients and authoritative servers, but this application was authoritative servers, but this application was out of scope for the
out of scope for the Working Group charter at the time this document Working Group charter at the time this document was finished.
was finished.
This document specifies 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 provide improved levels of
properties a user should expect when using that profile to connect to mitigation against the attacks described above compared to using only
the available DNS servers. Section 5 presents a generalised clear text DNS.
discussion of Usage Profiles by separating the Usage Profile, which
is based purely on the security properties it offers the user, from Section 5 presents a generalized discussion of Usage Profiles by
the specific mechanism(s) that are used for authentication. The separating the Usage Profile, which is based purely on the security
Profiles described are: properties it offers the user, from the specific mechanism(s) that
are used for DNS server authentication. The Profiles described are:
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 mitigates both
privacy guarantees (at the expense of providing no DNS service if passive eavesdropping and client re-direction (at the expense of
this is not available). providing no DNS service if 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
privacy guarantees but offers maximum chance of DNS service. limited or no mitigation against such attacks 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.4 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 a Subject Public Key Info (SPKI) based
over-TLS in the context of a specific case of a Strict Usage Profile authentication mechanism for DNS-over-TLS in the context of a
using that single authentication mechanism. Therefore the "Out-of- specific case of a Strict Usage Profile using that single
band Key-pinned Privacy Profile" described in [RFC7858] would qualify authentication mechanism. Therefore the "Out-of-band Key-pinned
as a "Strict Usage Profile" that used SPKI pinning for Privacy Profile" described in [RFC7858] would qualify as a "Strict
authentication. Usage Profile" that used SPKI pinning for authentication.
This document extends the use of SPKI pinset based authentication so This document extends the use of SPKI pinset based authentication so
that it is considered a general authentication mechanism that can be that it is considered a general authentication mechanism that can be
used with either DNS-over-(D)TLS Usage Profile. That is, the SPKI used with either DNS-over-(D)TLS Usage Profile. That is, the SPKI
pinset mechanism described in [RFC7858] MAY be used with DNS- pinset mechanism described in [RFC7858] MAY be used with DNS-
over-(D)TLS. over-(D)TLS.
This document also describes a number of additional authentication This document also describes a number of additional authentication
mechanisms all of which specify how a DNS client should authenticate mechanisms all of which specify how a DNS client should authenticate
a DNS server based on an 'authentication domain name'. In a DNS server based on an 'authentication domain name'. In
skipping to change at page 5, line 14 skipping to change at page 5, line 32
o DNS client: a DNS stub resolver or forwarder. In the case of a o DNS client: a DNS stub resolver or forwarder. In the case of a
forwarder, the term "DNS client" is used to discuss the side that forwarder, the term "DNS client" is used to discuss the side that
sends queries. sends queries.
o DNS server: a DNS recursive resolver or forwarder. In the case of o DNS server: a DNS recursive resolver or forwarder. In the case of
a forwarder, the term "DNS server" is used to discuss the side a forwarder, the term "DNS server" is used to discuss the side
that responds to queries. For emphasis, in this document the term that responds to queries. For emphasis, in this document the term
does not apply to authoritative servers. does not apply to authoritative servers.
o Privacy-enabling DNS server: A DNS server that: o Privacy-enabling DNS server: A DNS server that implements DNS-
over-TLS [RFC7858] and may optionally implement DNS-over-DTLS
* MUST implement DNS-over-TLS [RFC7858] and MAY implement DNS- [RFC8094]. The server should also offer at least one of the
over-DTLS [I-D.ietf-dprive-dnsodtls]. credentials described in Section 8 and implement the (D)TLS
profile described in Section 9.
* Can offer at least one of the credentials described in
Section 8.
* 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 [RFC8094].
[I-D.ietf-dprive-dnsodtls]. Specific terms will be used for any Specific terms will be used for any statement that applies to
statement that applies to either protocol alone. 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 privacy-enabling DNS server. Sources of
authentication domain names are discussed in Section 7. authentication domain names are discussed in Section 7.
o SPKI Pinsets: [RFC7858] describes the use of cryptographic digests o SPKI Pinsets: [RFC7858] describes the use of cryptographic digests
to "pin" public key information in a manner similar to HPKP to "pin" public key information in a manner similar to HTTP Public
[RFC7469]. An SPKI pinset is a collection of these pins that Key Pinning [RFC7469] (HPKP). An SPKI pinset is a collection of
constrains a DNS server. these pins that constrains a DNS server.
o Authentication information: Information a DNS client may use as o Authentication information: Information a DNS client may use as
the basis of an authentication mechanism. In this context that the basis of an authentication mechanism. In this context that
can be either a: can be either a:
* a SPKI pinset or * a SPKI pinset or
* an authentication domain name * an authentication domain name
o Reference Identifier: a Reference Identifier as described in o Reference Identifier: a Reference Identifier as described in
skipping to change at page 6, line 25 skipping to change at page 6, line 38
* 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.
3. Scope 3. Scope
This document is limited to describing This document is limited to describing
o Usage Profiles based on general authentication mechanisms o Usage Profiles based on general authentication mechanisms
o The details of domain-name-based authentication of DNS servers by o The details of domain name based authentication of DNS servers by
DNS clients (as defined in the terminology section) DNS clients (as defined in the terminology section)
o The (D)TLS profiles needed to support authentication in DNS- o The (D)TLS profiles needed to support authentication in DNS-
over-(D)TLS. over-(D)TLS.
As such, the following things are out of scope: 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 The details of how to perform SPKI-pinset-based authentication. o The details of how to perform SPKI-pinset-based authentication.
This is defined in [RFC7858]. This is defined in [RFC7858].
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. addresses, organizational names, country of origin, etc.
4. Discussion 4. Discussion
To protect against passive attacks DNS privacy requires encrypting One way to mitigate against passive attackers eavesdropping on clear
the query (and response). Such encryption typically provides text DNS transactions is to encrypt the query (and response). Such
integrity protection as a side-effect, which means on-path attackers encryption typically provides integrity protection as a side-effect,
cannot simply inject bogus DNS responses. For DNS privacy to also which means on-path attackers cannot simply inject bogus DNS
provide protection against active attackers pretending to be the responses. To also mitigate against active attackers pretending to
server, the client must authenticate the server. be the server, the client must authenticate the (D)TLS connection to
the server.
This draft discusses Usage Profiles, which provide differing levels This document discusses Usage Profiles, which provide differing
of privacy guarantees to DNS clients, based on the requirements for levels of attack mitigation to DNS clients, based on the requirements
authentication and encryption, regardless of the context (for 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.
The term 'privacy-enabling DNS server' is used throughout this
document. This is a DNS server that:
o MUST implement DNS-over-TLS [RFC7858].
o MAY implement DNS-over-DTLS [RFC8094].
o SHOULD offer at least one of the credentials described in
Section 8.
o Implements the (D)TLS profile described in Section 9.
5. Usage Profiles 5. Usage Profiles
A DNS client has a choice of privacy Usage Profiles available. This A DNS client has a choice of Usage Profiles available to increase the
choice is briefly discussed in both [RFC7858] and privacy of DNS transactions. This choice is briefly discussed in
[I-D.ietf-dprive-dnsodtls]. These Usage Profiles are: both [RFC7858] and [RFC8094]. These Usage Profiles are:
o Strict Privacy: the DNS client requires both an encrypted and o Strict profile: 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 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 mitigates against both
meta queries (performed using Opportunistic Privacy) to securely passive and active attacks providing the client with the best
obtain the IP address and authentication information for the available privacy for DNS. This Profile is discussed in detail in
privacy-enabling DNS server to which the DNS client will
subsequently connect. The rationale for this is that requiring
Strict Privacy for such meta queries would introduce significant
deployment obstacles. This profile provides strong privacy
guarantees to the client. This Profile is discussed in detail in
Section 6.6. 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 increased privacy with a view to
widespread adoption of Strict Privacy. It should be employed when widespread adoption of the Strict profile. It should be employed
the DNS client might otherwise settle for cleartext; it provides when the DNS client might otherwise settle for cleartext; it
the maximum protection available. As described in [RFC7435] it provides the maximum protection an attacker will allow. As
might result in described in [RFC7435] it 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
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 all these cases the DNS client is willing to continue with a In all these cases the DNS client is willing to continue with a
connection to the DNS Server and perform resolution of queries. connection to the DNS Server and perform resolution of queries.
To compare the two Usage profiles the table below shows successful Both profiles can include an initial meta query (performed using an
Strict Privacy along side the 3 possible outcomes of Opportunistic Opportunistic lookup) to obtain the IP address for the privacy-
Privacy. In the best case scenario for Opportunistic Privacy (an enabling DNS server to which the DNS client will subsequently
authenticated and encrypted connection) it is equivalent to Strict connect. The rationale for permitting this for the Strict profile is
Privacy. In the worst case scenario it is equivalent to clear text. that requiring such meta queries to also be performed using the
Clients using Opportunistic Privacy SHOULD try for the best case but Strict profile would introduce significant deployment obstacles.
MAY fallback to the intermediate case and eventually the worst case However, it should be noted that in this scenario an active attack is
scenario in order to obtain a response. It therefore provides no possible on the meta query which could result in the client not being
privacy guarantee to the user and varying protection depending on able to connect to a privacy-enabling DNS server that it can
what kind of connection is actually used. authenticate.
To compare the two Usage profiles the table below shows a successful
Strict profile along side the 3 possible outcomes of an Opportunistic
profile. In the best case scenario for the Opportunistic profile (an
authenticated and encrypted connection) it is equivalent to the
Strict profile. In the worst case scenario it is equivalent to clear
text. Clients using the Opportunistic profile SHOULD try for the
best case but MAY fallback to the intermediate case and eventually
the worst case scenario in order to obtain a response. One reason to
fallback without trying every available privacy-enabling DNS server
is if latency is more important than attack mitigation, see
Appendix A. The Opportunistic profile therefore provides varying
protection depending on what kind of connection is actually used
including no attack mitigation at all.
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 the user can detect that the unauthenticated connection was used then the user can detect that the
connection may be subject to active attack. This is discussed in connection may be subject to active attack. In other words for the
Section 6.5. cases where no protection is provided against an attacker (N) it is
possible to detect that an attack might be happening (D). This is
discussed in 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 |
+---------------+------------+------------------+-----------------+ +---------------+------------+------------------+-----------------+
P == protection; N == no protection; D == detection is possible; A == P == Protection; N == No protection; D == Detection is possible; A ==
Authenticated Connection; E == Encrypted Connection Authenticated connection; E == Encrypted connection
Table 1: DNS Privacy Protection by Usage Profile and type of attacker Table 1: Attack protection by Usage Profile and type of attacker
Strict Privacy provides the strongest privacy guarantees and
therefore SHOULD always be implemented in DNS clients along with The Strict profile provides the best attack mitigation and therefore
SHOULD always be implemented in DNS clients that implement
Opportunistic Privacy. Opportunistic Privacy.
A DNS client that implements DNS-over-(D)TLS SHOULD NOT default to A DNS client that implements DNS-over-(D)TLS SHOULD NOT be configured
the use of clear text (no privacy). by default to use only clear text.
The choice between the two profiles depends on a number of factors The choice between the two profiles depends on a number of factors
including which is more important to the particular client: including which is more important to the particular client:
o DNS service at the cost of no privacy guarantee (Opportunistic) or o DNS service at the cost of no attack mitigation (Opportunistic) or
o best available attack mitigation at the potential cost of no DNS
o guaranteed privacy at the potential cost of no DNS service service (Strict).
(Strict).
Additionally the two profiles require varying levels of configuration Additionally the two profiles require varying levels of configuration
(or a trusted relationship with a provider) and DNS server (or a trusted relationship with a provider) and DNS server
capabilities, therefore DNS clients will need to carefully select capabilities, therefore DNS clients will need to carefully select
which profile to use based on their communication privacy needs. which profile to use based on their communication needs.
A DNS server that implements DNS-over-(D)TLS SHOULD provide at least A DNS server that implements DNS-over-(D)TLS SHOULD provide at least
one credential so that those DNS clients that wish to do so are able one credential so that those DNS clients that wish to do so are able
to use Strict Privacy (see Section 2). to use the Strict profile (see Section 2).
5.1. DNS Resolution 5.1. DNS Resolution
A DNS client SHOULD select a particular Usage Profile when resolving A DNS client SHOULD select a particular Usage Profile when resolving
a query. A DNS client MUST NOT fallback from Strict Privacy to a query. A DNS client MUST NOT fallback from Strict Privacy to
Opportunistic Privacy during the resolution process as this could Opportunistic Privacy during the resolution of a given query as this
invalidate the protection offered against active attackers. could invalidate the protection offered against attackers. It is
anticipated that DNS clients will use a particular Usage Profile for
all queries to all configured servers until an operational issue or
policy update dictates a change in the profile used.
6. Authentication in DNS-over(D)TLS 6. Authentication in DNS-over(D)TLS
This section describes authentication mechanisms and how they can be This section describes authentication mechanisms and how they can be
used in either Strict or Opportunistic Privacy for DNS-over-(D)TLS. used in either Strict or Opportunistic Privacy for DNS-over-(D)TLS.
6.1. DNS-over-(D)TLS Startup Configuration Problems 6.1. DNS-over-(D)TLS Startup Configuration Problems
Many (D)TLS clients use PKIX authentication [RFC6125] based on an Many (D)TLS clients use PKIX authentication [RFC6125] based on an
authentication domain name for the server they are contacting. These authentication domain name for the server they are contacting. These
skipping to change at page 10, line 8 skipping to change at page 10, line 46
DNS before making this connection. Such a DNS client therefore has a DNS before making this connection. Such a DNS client therefore has a
bootstrap problem, as it will typically only know the IP address of bootstrap problem, as it will typically only know the IP address of
its DNS server. its DNS server.
In this case, before connecting to a DNS server, a DNS client needs In this case, before connecting to a DNS server, a DNS client needs
to learn the authentication domain name it should associate with the to learn the authentication domain name it should associate with the
IP address of a DNS server for authentication purposes. Sources of IP address of a DNS server for authentication purposes. Sources of
authentication domain names are discussed in Section 7. authentication domain names are discussed in Section 7.
One advantage of this domain name based approach is that it One advantage of this domain name based approach is that it
encourages association of stable, human recognisable identifiers with encourages association of stable, human recognizable identifiers with
secure DNS service providers. secure DNS service providers.
6.2. Credential Verification 6.2. Credential Verification
The use of SPKI pinset verification is discussed in [RFC7858]. The use of SPKI pinset verification is discussed in [RFC7858].
In terms of domain name based verification, once an authentication In terms of domain name based verification, once an authentication
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
skipping to change at page 10, line 32 skipping to change at page 11, line 26
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. Summary of Authentication Mechanisms 6.3. Summary of Authentication Mechanisms
This section provides an overview of the various authentication This section provides an overview of the various authentication
mechanisms. The table below indicates how the DNS client obtains mechanisms. The table below indicates how the DNS client obtains
information to use for authentication for each option; either information to use for authentication for each option; either
statically via direct configuration or dynamically. Of course, the statically via direct configuration or dynamically. Of course, the
Opportunistic Usage Profile does not require authentication and so a Opportunistic Usage Profile does not require authentication and so a
client using that profile may choose to connect to a Privacy Enabling client using that profile may choose to connect to a privacy-enabling
DNS server on the basis of just an IP address. DNS server on the basis of just an IP address.
+---+------------+-------------+------------------------------------+ +---+------------+-------------+------------------------------------+
| # | Static | Dynamically | Short name: Description | | # | Static | Dynamically | Short name: Description |
| | Config | Obtained | | | | Config | Obtained | |
+---+------------+-------------+------------------------------------+ +---+------------+-------------+------------------------------------+
| 1 | SPKI + IP | | SPKI: SPKI pinset(s) and IP | | 1 | SPKI + IP | | SPKI: SPKI pinset(s) and IP |
| | | | address obtained out of band | | | | | address obtained out of band |
| | | | [RFC7858] | | | | | [RFC7858] |
| | | | | | | | | |
| 2 | ADN + IP | | ADN: ADN and IP address obtained | | 2 | ADN + IP | | ADN: ADN and IP address obtained |
| | | | out of band (see Section 7.1) | | | | | out of band (see Section 7.1) |
| | | | | | | | | |
| 3 | ADN | IP | ADN only: Opportunistic lookups to | | 3 | ADN | IP | ADN only: Opportunistic lookups to |
| | | | a NP DNS server for A/AAAA (see | | | | | a NP DNS server for A/AAAA (see |
| | | | Section 7.2) | | | | | Section 7.2) |
| | | | | | | | | |
| 4 | | ADN + IP | DHCP: DHCP configuration only (see | | 4 | | ADN + IP | DHCP: DHCP configuration only (see |
| | | | Section 7.3) | | | | | Section 7.3.1) |
| | | | | | | | | |
| 5 | [ADN + IP] | [ADN + IP] | DANE: DNSSEC chain obtained via | | 5 | [ADN + IP] | [ADN + IP] | DANE: DNSSEC chain obtained via |
| | | TLSA record | Opportunistic lookups to NP DNS | | | | TLSA record | Opportunistic lookups to NP DNS |
| | | | server (see Section 8.2.1) | | | | | server (see Section 8.2.1) |
| | | | | | | | | |
| 6 | [ADN + IP] | [ADN + IP] | TLS extension: DNSSEC chain | | 6 | [ADN + IP] | [ADN + IP] | TLS extension: DNSSEC chain |
| | | TLSA record | provided by PE DNS server in TLS | | | | TLSA record | provided by PE DNS server in TLS |
| | | | DNSSEC chain extension (see | | | | | DNSSEC chain extension (see |
| | | | Section 8.2.2) | | | | | Section 8.2.2) |
+---+------------+-------------+------------------------------------+ +---+------------+-------------+------------------------------------+
skipping to change at page 11, line 47 skipping to change at page 12, line 47
Table 2: Overview of Authentication Mechanisms Table 2: Overview of Authentication Mechanisms
The following summary attempts to present some key attributes of each The following summary attempts to present some key attributes of each
of the mechanisms (using the 'Short name' from Table 2), indicating of the mechanisms (using the 'Short name' from Table 2), indicating
attractive attributes with a '+' and undesirable attributes with a attractive attributes with a '+' and undesirable attributes with a
'-'. '-'.
1. SPKI 1. SPKI
+ Minimal leakage (Note that the ADN is always leaked in the + Minimal leakage (Note that the ADN is always leaked in the
SNI field in the Client Hello in TLS when communicating with a Server Name Indication (SNI) field in the Client Hello in TLS
privacy enabling DNS server) when communicating with a privacy-enabling DNS server)
- Overhead of on-going key management required - Overhead of on-going key management required
2. ADN 2. ADN
+ Minimal leakage + Minimal leakage
+ One-off direct configuration only + One-off direct configuration only
3. ADN only 3. ADN only
+ Minimal one-off direct configuration, only a human + Minimal one-off direct configuration, only a human
recognisable domain name needed recognizable domain name needed
- A/AAAA meta queries leaked to network provided DNS server - A/AAAA meta queries leaked to network provided DNS server
that may be subject to active attack
4. DHCP 4. DHCP
+ No static config + No static config
- Requires a non-standard or future DHCP option in order to - Requires a non-standard or future DHCP option in order to
provide the ADN provide the ADN
- Requires secure and trustworthy connection to DHCP server - Requires secure and trustworthy connection to DHCP server if
used with a Strict Usage profile
5. DANE 5. DANE
The ADN and/or IP may be obtained statically or dynamically The ADN and/or IP may be obtained statically or dynamically
and the relevant attributes of that method apply and the relevant attributes of that method apply
+ DANE options (e.g. matching on entire certificate) + DANE options (e.g., matching on entire certificate)
- Requires a DNSSEC validating stub implementation (deployment - Requires a DNSSEC validating stub implementation (deployment
of which is limited at the time of writing) of which is limited at the time of writing)
- DNSSEC chain meta queries leaked to network provided DNS - DNSSEC chain meta queries leaked to network provided DNS
server server that may be subject to active attack
6. TLS extension 6. TLS extension
The ADN and/or IP may be obtained statically or dynamically The ADN and/or IP may be obtained statically or dynamically
and the relevant attributes of that method apply and the relevant attributes of that method apply
+ Reduced latency compared with 'DANE' + Reduced latency compared with 'DANE'
+ No network provided DNS server required if ADN and IP + No network provided DNS server required if ADN and IP
statically configured statically configured
+ DANE options (e.g. matching on entire certificate) + DANE options (e.g., matching on entire certificate)
- Requires a DNSSEC validating stub implementation - Requires a DNSSEC validating stub implementation
6.4. Combining Authentication Mechanisms 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. In this
overall authentication result should only be considered successful if case the client SHOULD treat the SPKI pin as specified in Section 2.6
both authentication mechanisms are successful. of [RFC7469] with regard to user defined trust anchors. The overall
authentication result SHOULD only be considered successful if both
authentication mechanisms are successful.
6.5. 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 and which
authentication information for a given privacy-enabling DNS server know authentication information for a given privacy-enabling DNS
MAY choose to try to authenticate the server using the mechanisms server SHOULD 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 and encrypted connection. In this case, whilst a
cannot know the reason for an authentication failure, from a privacy client cannot know the reason for an authentication failure, from a
standpoint the client should consider an active attack in progress security standpoint the client should consider an active attack in
and proceed under that assumption. Attempting authentication is also progress and proceed under that assumption. For example, a client
useful for debugging or diagnostic purposes if there are means to that implements a nameserver selection algorithm that preferentially
report the result. This information can provide a basis for a DNS uses nameservers which successfully authenticated (see Section 5)
client to switch to (preferred) Strict Privacy where it is viable. might not continue to use the failing server if there were
alternative servers available.
Attempting authentication is also useful for debugging or diagnostic
purposes if there are means to report the result. This information
can provide a basis for a DNS client to switch to (preferred) Strict
Privacy where it is viable e.g, where all the configured servers
support DNS-over-(D)TLS and successfully authenticate.
6.6. Authentication in Strict Privacy 6.6. Authentication in Strict Privacy
To authenticate a privacy-enabling DNS server, a DNS client needs to To authenticate a privacy-enabling DNS server, a DNS client needs to
know authentication information for each server it is willing to know authentication information for each server it is willing to
contact. This is necessary to protect against active attacks on DNS contact. This is necessary to protect against active attacks which
privacy. attempt to re-direct clients to rogue DNS servers.
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 to obtain an authentication domain name sources listed in Section 7 to obtain an authentication domain name
for the server it contacts, or use an SPKI pinset as described in for the server it contacts, or use an SPKI pinset as described in
[RFC7858]. [RFC7858].
A DNS client requiring Strict Privacy MUST only attempt to connect to A DNS client requiring Strict Privacy MUST only attempt to connect to
DNS servers for which at least one piece of authentication DNS servers for which at least one piece of authentication
information is known. The client MUST use the available verification information is known. The client MUST use the available verification
mechanisms described in Section 8 to authenticate the server, and mechanisms described in Section 8 to authenticate the server, and
skipping to change at page 14, line 25 skipping to change at page 15, line 35
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. If using a Strict Usage profile
means that the DNS is not private during such bootstrap. the system MUST alert by some means that the DNS is not private
during such bootstrap.
6.7. Implementation guidance 6.7. Implementation guidance
Section 9 describes the (D)TLS profile for DNS-over(D)TLS. Section 9 describes the (D)TLS profile for DNS-over(D)TLS.
Additional considerations relating to general implementation Additional considerations relating to general implementation
guidelines are discussed in both Section 11 and in Appendix A. guidelines are discussed in both Section 11 and in Appendix A.
7. Sources of Authentication Domain Names 7. Sources of Authentication Domain Names
7.1. Full direct configuration 7.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 an authentication domain name for each DNS
server.
7.2. Direct configuration of name only 7.2. Direct configuration of ADN 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 each of its privacy-enabling DNS
example, using a client specific configuration file or API. servers. For 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 an untrusted recursive can then use Opportunistic DNS connections to an untrusted recursive
DNS resolver to establish the IP address of the intended privacy- DNS resolver to establish the IP address of the intended privacy-
enabling DNS resolver by doing a lookup of A/AAAA records. Private enabling DNS resolver by doing a lookup of A/AAAA records. Private
DNS resolution can now be done by the DNS client against the pre- DNS resolution can now be done by the DNS client against the pre-
configured privacy-enabling DNS resolver, using the IP address configured privacy-enabling DNS resolver, using the IP address
gathered from the untrusted DNS resolver. gathered from the untrusted DNS resolver.
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 server host IP enabling DNS server MAY choose to locally cache the server host IP
addresses in order to not have to repeat the opportunistic lookup. addresses in order to not have to repeat the opportunistic lookup.
7.3. DHCP 7.3. Dynamic discovery of ADN
Some clients may have an established trust relationship with a known This section discusses the general case of a DNS client discovering
DHCP [RFC2131] server for discovering their network configuration. both the authentication domain name and IP address dynamically. This
In the typical case, such a DHCP server provides a list of IP is not possible at the time of writing by any standard means.
addresses for DNS servers (see section 3.8 of [RFC2132]), but does However since, for example, a future DHCP extension could (in
not provide a domain name for the DNS server itself. principle) provide this mechanism the required security properties of
such mechanisms are outlined here.
In the future, a DHCP server might use a DHCP extension to provide a When using a Strict profile the dynamic discovery technique used as a
list of authentication domain names for the offered DNS servers, source of authentication domain names MUST be considered secure and
which correspond to IP addresses listed. trustworthy. This requirement does not apply when using an
Opportunistic profile given the security expectation of that profile.
Use of such a mechanism with any DHCP server when using an 7.3.1. DHCP
Opportunistic profile is reasonable, given the security expectation
of that profile. However when using a Strict profile the DHCP
servers used as sources of authentication domain names MUST be
considered secure and trustworthy. This document does not attempt to
describe secured and trusted relationships to DHCP servers.
It is noted (at the time of writing) that whilst some implementation In the typical case today, a DHCP server [RFC2131] [RFC3315] provides
work is in progress to secure IPv6 connections for DHCP, IPv4 a list of IP addresses for DNS resolvers (see Section 3.8 of
connections have received little to no implementation attention in [RFC2132]), but does not provide an authentication domain name for
this area. the DNS resolver, thus preventing the use of most of the
authentication methods described here (all those that are based on a
mechanism with ADN in Table 2).
This document does not specify or request any DHCP extension to
provide authentication domain names. However, if one is developed in
future work the issues outlined in Section 8 of [RFC7227] should be
taken into account as should the Security Considerations in
Section 23 of [RFC3315]).
This document does not attempt to describe secured and trusted
relationships to DHCP servers, which is a purely DHCP issue (still
open, at the time of writing.) Whilst some implementation work is in
progress to secure IPv6 connections for DHCP, IPv4 connections have
received little to no implementation attention in this area.
8. Authentication Domain Name based Credential Verification 8. Authentication Domain Name based Credential Verification
8.1. PKIX Certificate Based Authentication 8.1. PKIX Certificate Based Authentication
When a DNS client configured with an authentication domain name When a DNS client configured with an authentication domain name
connects to its configured DNS server over (D)TLS, the server may connects to its configured DNS server over (D)TLS, the server may
present it with a PKIX certificate. In order to ensure proper present it with a PKIX certificate. In order to ensure proper
authentication, DNS clients MUST verify the entire certification path authentication, DNS clients MUST verify the entire certification path
per [RFC5280]. The DNS client additionally uses [RFC6125] validation per [RFC5280]. The DNS client additionally uses [RFC6125] validation
skipping to change at page 16, line 30 skipping to change at page 18, line 4
public key trust with DNSSEC. However this requires the DNS client public key trust with DNSSEC. However this requires the DNS client
to have an authentication domain name for the DNS Privacy Server to have an authentication domain name for the DNS Privacy Server
which must be obtained via a trusted source. which must be obtained via a trusted source.
This section assumes a solid understanding of both DANE [RFC6698] and This section assumes a solid understanding of both DANE [RFC6698] and
DANE Operations [RFC7671]. A few pertinent issues covered in these DANE Operations [RFC7671]. A few pertinent issues covered in these
documents are outlined here as useful pointers, but familiarity with documents are outlined here as useful pointers, but familiarity with
both these documents in their entirety is expected. both these documents in their entirety is expected.
It is noted that [RFC6698] says It is noted that [RFC6698] says
"Clients that validate the DNSSEC signatures themselves MUST use "Clients that validate the DNSSEC signatures themselves MUST use
standard DNSSEC validation procedures. Clients that rely on standard DNSSEC validation procedures. Clients that rely on
another entity to perform the DNSSEC signature validation MUST use another entity to perform the DNSSEC signature validation MUST use
a secure mechanism between themselves and the validator." a secure mechanism between themselves and the validator."
It is noted that [RFC7671] covers the following topics: It is noted that [RFC7671] covers the following topics:
o Section 4.1: Opportunistic Security and PKIX Usages and o Section 4.1: Opportunistic Security and PKIX Usages and
Section 14: Security Considerations, which both discuss the use of Section 14: Security Considerations, which both discuss the use of
PKIX-TA(0) and PKIX-EE(1) for Opportunistic Security. Trust Anchor and End Entity based schemes (PKIX-TA(0) and PKIX-
EE(1) respectively) for Opportunistic Security.
o Section 5: Certificate-Usage-Specific DANE Updates and Guidelines. o Section 5: Certificate-Usage-Specific DANE Updates and Guidelines.
Specifically Section 5.1 which outlines the combination of Specifically Section 5.1 which outlines the combination of
Certificate Usage DANE-EE(3) and Selector Usage SPKI(1) with Raw Certificate Usage DANE-EE(3) and Selector Usage SPKI(1) with Raw
Public Keys [RFC7250]. Section 5.1 also discusses the security Public Keys [RFC7250]. Section 5.1 also discusses the security
implications of this mode, for example, it discusses key lifetimes implications of this mode, for example, it discusses key lifetimes
and specifies that validity period enforcement is based solely on and specifies that validity period enforcement is based solely on
the TLSA RRset properties for this case. the TLSA RRset properties for this case.
o Section 13: Operational Considerations, which discusses TLSA TTLs o Section 13: Operational Considerations, which discusses TLSA TTLs
skipping to change at page 17, line 16 skipping to change at page 18, line 38
form: form:
_853._tcp.[authentication-domain-name] for TLS _853._tcp.[authentication-domain-name] for TLS
_853._udp.[authentication-domain-name] for DTLS _853._udp.[authentication-domain-name] for DTLS
8.2.1. Direct DNS Lookup 8.2.1. Direct DNS Lookup
The DNS client MAY choose to perform the DNS lookups to retrieve the The DNS client MAY choose to perform the DNS lookups to retrieve the
required DANE records itself. The DNS queries for such DANE records required DANE records itself. The DNS queries for such DANE records
MAY use opportunistic encryption or be in the clear to avoid trust MAY use Opportunistic encryption or be in the clear to avoid trust
recursion. The records MUST be validated using DNSSEC as described recursion. The records MUST be validated using DNSSEC as described
above in [RFC6698]. above in [RFC6698].
8.2.2. TLS DNSSEC Chain extension 8.2.2. TLS DNSSEC Chain extension
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.
9. (D)TLS Protocol Profile 9. (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
protocol downgrade. These are general attacks on (D)TLS and not
specific to DNS-over-TLS; please refer to the (D)TLS RFCs for
discussion of these security issues.
Clients and servers MUST adhere to the (D)TLS implementation Clients and servers MUST adhere to the (D)TLS implementation
recommendations and security considerations of [RFC7525] except with recommendations and security considerations of [RFC7525] except with
respect to (D)TLS version. respect to (D)TLS version.
Since encryption of DNS using (D)TLS is a green-field deployment DNS Since encryption of DNS using (D)TLS is a green-field deployment DNS
clients and servers MUST implement only (D)TLS 1.2 or later. clients and servers MUST implement only (D)TLS 1.2 or later. For
example, implementing TLS 1.3 [I-D.ietf-tls-tls13] is also an option.
Implementations MUST NOT offer or provide TLS compression, since Implementations MUST NOT offer or provide TLS compression, since
compression can leak significant amounts of information, especially compression can leak significant amounts of information, especially
to a network observer capable of forcing the user to do an arbitrary to a network observer capable of forcing the user to do an arbitrary
DNS lookup in the style of the CRIME attacks [CRIME]. DNS lookup in the style of the CRIME attacks [CRIME].
Implementations compliant with this profile MUST implement all of the Implementations compliant with this profile MUST implement all of the
following items: following items:
o TLS session resumption without server-side state [RFC5077] which o TLS session resumption without server-side state [RFC5077] which
eliminates the need for the server to retain cryptographic state eliminates the need for the server to retain cryptographic state
for longer than necessary (This statement updates [RFC7858]). for longer than necessary (This statement updates [RFC7858]).
o Raw public keys [RFC7250] which reduce the size of the o Raw public keys [RFC7250] which reduce the size of the
ServerHello, and can be used by servers that cannot obtain ServerHello, and can be used by servers that cannot obtain
certificates (e.g., DNS servers on private networks). certificates (e.g., DNS servers on private networks). A client
MUST only indicate support for raw public keys if it has an SPKI
pinset pre-configured (for interoperability reasons).
Implementations compliant with this profile SHOULD implement all of Implementations compliant with this profile SHOULD implement all of
the following items: the following items:
o TLS False Start [RFC7918] which reduces round-trips by allowing o TLS False Start [RFC7918] which reduces round-trips by allowing
the TLS second flight of messages (ChangeCipherSpec) to also the TLS second flight of messages (ChangeCipherSpec) to also
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 [RFC8094].
10. IANA Considerations 10. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
11. Security Considerations 11. Security Considerations
Security considerations discussed in [RFC7525], Security considerations discussed in [RFC7525], [RFC8094] and
[I-D.ietf-dprive-dnsodtls] and [RFC7858] apply to this document. [RFC7858] apply to this document.
DNS Clients SHOULD consider implementing support for the mechanisms DNS Clients SHOULD implement support for the mechanisms described in
described in Section 8.2 and offering a configuration option which Section 8.2 and offering a configuration option which limits
limits authentication to using only those mechanisms (i.e. with no authentication to using only those mechanisms (i.e., with no fallback
fallback to pure PKIX based authentication) such that authenticating to pure PKIX based authentication) such that authenticating solely
solely via the PKIX infrastructure can be avoided. via the PKIX infrastructure can be avoided.
11.1. Counter-measures to DNS Traffic Analysis 11.1. Counter-measures to DNS Traffic Analysis
This section makes suggestions for measures that can reduce the This section makes suggestions for measures that can reduce the
ability of attackers to infer information pertaining to encrypted ability of attackers to infer information pertaining to encrypted
client queries by other means (e.g. via an analysis of encrypted client queries by other means (e.g., via an analysis of encrypted
traffic size, or via monitoring of resolver to authoritative traffic size, or via monitoring of resolver to authoritative
traffic). traffic).
DNS-over-(D)TLS clients and servers SHOULD consider implementing the DNS-over-(D)TLS clients and servers SHOULD implement the following
following relevant DNS extensions 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 making analysis of encrypted traffic
harder.
DNS-over-(D)TLS clients SHOULD consider implementing the following Guidance on padding policies for EDNS(0) is provided in
relevant DNS extensions [I-D.ietf-dprive-padding-policy]
DNS-over-(D)TLS clients SHOULD implement the following 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. Acknowledgments
Thanks to the authors of both [I-D.ietf-dprive-dnsodtls] and Thanks to the authors of both [RFC8094] and [RFC7858] for laying the
[RFC7858] for laying the ground work that this draft builds on and ground work that this draft builds on and for reviewing the contents.
for reviewing the contents. The authors would also like to thank The authors would also like to thank John Dickinson, Shumon Huque,
John Dickinson, Shumon Huque, Melinda Shore, Gowri Visweswaran, Ray Melinda Shore, Gowri Visweswaran, Ray Bellis, Stephane Bortzmeyer,
Bellis, Stephane Bortzmeyer, Jinmei Tatuya, Paul Hoffman, Christian Jinmei Tatuya, Paul Hoffman, Christian Huitema and John Levine for
Huitema and John Levine for review and discussion of the ideas review and discussion of the ideas presented 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 21, line 5 skipping to change at page 22, line 36
[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>.
[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport
Layer Security (TLS) False Start", RFC 7918,
DOI 10.17487/RFC7918, August 2016,
<http://www.rfc-editor.org/info/rfc7918>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016,
<http://www.rfc-editor.org/info/rfc7924>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017,
<http://www.rfc-editor.org/info/rfc8094>.
13.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-padding-policy]
Reddy, T., Wing, D., and P. Patil, "Specification for DNS Mayrhofer, A., "Padding Policy for EDNS(0)", draft-ietf-
over Datagram Transport Layer Security (DTLS)", draft- dprive-padding-policy-00 (work in progress), December
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-03 (work in draft-ietf-tls-dnssec-chain-extension-04 (work in
progress), March 2017. progress), June 2017.
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-20 (work in progress),
April 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>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic
Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
DOI 10.17487/RFC3646, December 2003, DOI 10.17487/RFC3646, December 2003,
<http://www.rfc-editor.org/info/rfc3646>. <http://www.rfc-editor.org/info/rfc3646>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
<http://www.rfc-editor.org/info/rfc7227>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <http://www.rfc-editor.org/info/rfc7435>. December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
2015, <http://www.rfc-editor.org/info/rfc7469>. 2015, <http://www.rfc-editor.org/info/rfc7469>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015, DOI 10.17487/RFC7626, August 2015,
<http://www.rfc-editor.org/info/rfc7626>. <http://www.rfc-editor.org/info/rfc7626>.
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
Kumari, "Client Subnet in DNS Queries", RFC 7871, Kumari, "Client Subnet in DNS Queries", RFC 7871,
DOI 10.17487/RFC7871, May 2016, DOI 10.17487/RFC7871, May 2016,
<http://www.rfc-editor.org/info/rfc7871>. <http://www.rfc-editor.org/info/rfc7871>.
[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport
Layer Security (TLS) False Start", RFC 7918,
DOI 10.17487/RFC7918, August 2016,
<http://www.rfc-editor.org/info/rfc7918>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016,
<http://www.rfc-editor.org/info/rfc7924>.
Appendix A. Server capability probing and caching by DNS clients Appendix A. Server capability probing and caching by DNS clients
This section presents a non-normative discussion of how DNS clients This section presents a non-normative discussion of how DNS clients
might probe for and cache privacy capabilities of DNS servers. might probe for and cache capabilities of privacy-enabling DNS
servers.
Deployment of both DNS-over-TLS and DNS-over-DTLS will be gradual. Deployment of both DNS-over-TLS and DNS-over-DTLS will be gradual.
Not all servers will support one or both of these protocols and the Not all servers will support one or both of these protocols and the
well-known port might be blocked by some middleboxes. Clients will well-known port might be blocked by some middleboxes. Clients will
be expected to keep track of servers that support DNS-over-TLS and/or be expected to keep track of servers that support DNS-over-TLS and/or
DNS-over-DTLS, and those that have been previously authenticated. DNS-over-DTLS, and those that have been previously authenticated.
If no server capability information is available then (unless If no server capability information is available then (unless
otherwise specified by the configuration of the DNS client) DNS otherwise specified by the configuration of the DNS client) DNS
clients that implement both TLS and DTLS should try to authenticate clients that implement both TLS and DTLS should try to authenticate
using both protocols before failing or falling back to a lower using both protocols before failing or falling back to a
security. DNS clients using opportunistic security should try all unauthenticated or clear text connections. DNS clients using an
available servers (possibly in parallel) in order to obtain an Opportunistic Usage profile should try all available servers
authenticated encrypted connection before falling back to a lower (possibly in parallel) in order to obtain an authenticated and
security. (RATIONALE: This approach can increase latency while encrypted connection before falling back. (RATIONALE: This approach
discovering server capabilities but maximizes the chance of sending can increase latency while discovering server capabilities but
the query over an authenticated encrypted connection.) maximizes the chance of sending the query over an authenticated and
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. -09 version B.1. -10 version
Clarified the specific attacks the Usage profiles mitigate against.
Revised wording in the draft relating 'security/privacy guarantees'
and generally improved consistency of wording throughout the
document.
Corrected and added a number of references:
o RFC7924 is now Normative
o RFC7918 and RFC8094 are now Normative (and therefore Downrefs)
o draft-ietf-tls-tls13, draft-ietf-dprive-padding-policy,RFC3315 and
RFC7227 added
Terminology: Update definition of Privacy-enabling DNS server and
moved normative definition to section 4.
Section 5 and 6.3: Included discussion of the additional attacks
possible when using meta-queries to bootstrap the DNS service
Section 5: Added sentence on why Opportunistic Profile may fallback
for latency reasons.
Section 5.1: Added discussion of when clients might change Usage
Profiles.
Section 6.4: Added caveat on use of combined authentication re
RFC7469.
Section 6.5: Added more detail on how authentication results might be
used in Opportunistic. Opportunistic clients now SHOULD try for the
best case.
Section 7.3: Re-worked this section and the discussion of DHCP.
Section 9: Removed unnecessary text, added condition on use of
RFC7250 (Raw public keys).
Section 11.: More detail on padding policies.
Numerous editorial corrections.
B.2. -09 version
Remove the SRV record to simplify the draft. Remove the SRV record to simplify the draft.
Add suggestion that clients offer option to avoid using only PKIX Add suggestion that clients offer option to avoid using only PKIX
authentication. authentication.
Clarify that the MUST on implementing TLS session resumption updates Clarify that the MUST on implementing TLS session resumption updates
RFC7858. RFC7858.
Update page header to be '(D)TLS Authentication for TLS'. Update page header to be '(D)TLS Authentication for TLS'.
B.2. -08 version B.3. -08 version
Removed hard failure as an option for Opportunistic Usage profile. Removed hard failure as an option for Opportunistic Usage profile.
Added a new section comparing the Authentication Mechanisms Added a new section comparing the Authentication Mechanisms
B.3. -07 version B.4. -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.4. -06 version B.5. -06 version
Introduction: Re-word discussion of Working group charter. Introduction: Re-word discussion of Working group charter.
Introduction: Re-word first and third bullet point about 'obtaining' Introduction: Re-word first and third bullet point about 'obtaining'
a domain name and IP address. a domain name and IP address.
Introduction: Update reference to DNS-over-TLS draft. Introduction: Update reference to DNS-over-TLS draft.
Terminology: Change forwarder/proxy to just forwarder Terminology: Change forwarder/proxy to just forwarder
skipping to change at page 24, line 5 skipping to change at page 27, line 13
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.5. -05 version B.6. -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.6. -04 version B.7. -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.7. -03 version B.8. -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.8. -02 version B.9. -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.9. -01 version B.10. -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.10. draft-ietf-dprive-dtls-and-tls-profiles-00 B.11. 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
skipping to change at page 25, line 35 skipping to change at page 29, line 4
Email: sara@sinodun.com Email: sara@sinodun.com
URI: http://sinodun.com URI: http://sinodun.com
Daniel Kahn Gillmor Daniel Kahn Gillmor
ACLU ACLU
125 Broad Street, 18th Floor 125 Broad Street, 18th Floor
New York NY 10004 New York NY 10004
USA USA
Email: dkg@fifthhorseman.net Email: dkg@fifthhorseman.net
Tirumaleswar Reddy Tirumaleswar Reddy
Cisco Systems, Inc. McAfee, Inc.
Cessna Business Park, Varthur Hobli Embassy Golf Link Business Park
Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560071
Bangalore, Karnataka 560103
India India
Email: tireddy@cisco.com Email: TirumaleswarReddy_Konda@McAfee.com
 End of changes. 99 change blocks. 
277 lines changed or deleted 411 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/