< draft-ietf-dprive-dtls-and-tls-profiles-01.txt   draft-ietf-dprive-dtls-and-tls-profiles-02.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: September 22, 2016 ACLU Expires: December 12, 2016 ACLU
T. Reddy T. Reddy
Cisco Cisco
March 21, 2016 June 10, 2016
Authentication and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS Authentication and (D)TLS Profile for DNS-over-(D)TLS
draft-ietf-dprive-dtls-and-tls-profiles-01 draft-ietf-dprive-dtls-and-tls-profiles-02
Abstract Abstract
This document describes how a DNS client can use a domain name to This document describes how a DNS client can use a domain name to
authenticate a DNS server that uses Transport Layer Security (TLS) authenticate a DNS server that uses Transport Layer Security (TLS)
and Datagram TLS (DTLS). Additionally, it defines (D)TLS profiles and Datagram TLS (DTLS). Additionally, it defines (D)TLS profiles
for DNS clients and servers implementing DNS-over-TLS and DNS-over- for DNS clients and servers implementing DNS-over-TLS and DNS-over-
DTLS. DTLS.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2016. This Internet-Draft will expire on December 12, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Usage Profiles . . . . . . . . . . . . . . . . . . . . . 5 4.2. Usage Profiles . . . . . . . . . . . . . . . . . . . . . 6
4.3. Authentication . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. DNS Resolution . . . . . . . . . . . . . . . . . . . 8
4.3.1. DNS-over-(D)TLS Bootstrapping Problems . . . . . . . 6 4.3. Authentication . . . . . . . . . . . . . . . . . . . . . 8
4.3.2. Credential Verification . . . . . . . . . . . . . . . 7 4.3.1. DNS-over-(D)TLS Bootstrapping Problems . . . . . . . 8
4.3.3. Implementation guidance . . . . . . . . . . . . . . . 7 4.3.2. Credential Verification . . . . . . . . . . . . . . . 8
5. Authentication in Opportunistic DNS-over(D)TLS Privacy . . . 7 4.3.3. Implementation guidance . . . . . . . . . . . . . . . 9
6. Authentication in Strict DNS-over(D)TLS Privacy . . . . . . . 8 5. Authentication in Opportunistic DNS-over(D)TLS Privacy . . . 9
7. In Band Source of Domain Name: SRV Service Label . . . . . . 8 6. Authentication in Strict DNS-over(D)TLS Privacy . . . . . . . 9
8. Out of Band Sources of Domain Name . . . . . . . . . . . . . 8 7. In Band Source of Domain Name: SRV Service Label . . . . . . 10
8.1. Full direct configuration . . . . . . . . . . . . . . . . 9 8. Out of Band Sources of Domain Name . . . . . . . . . . . . . 10
8.2. Direct configuration of name only . . . . . . . . . . . . 9 8.1. Full direct configuration . . . . . . . . . . . . . . . . 10
8.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.2. Direct configuration of name only . . . . . . . . . . . . 10
9. Credential Verification . . . . . . . . . . . . . . . . . . . 10 8.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. X.509 Certificate Based Authentication . . . . . . . . . 10 9. Credential Verification . . . . . . . . . . . . . . . . . . . 12
9.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. X.509 Certificate Based Authentication . . . . . . . . . 12
9.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 11 9.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 11 9.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 13
10. Combined Credentials with SPKI Pinsets . . . . . . . . . . . 12 9.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 13
11. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 12 10. Combined Credentials with SPKI Pinsets . . . . . . . . . . . 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 14
13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
13.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 13 13. Security Considerations . . . . . . . . . . . . . . . . . . . 15
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 13.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 15
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
15.1. Normative References . . . . . . . . . . . . . . . . . . 14 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
15.2. Informative References . . . . . . . . . . . . . . . . . 15 15.1. Normative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Server capability probing and caching by DNS clients 17 15.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix B. Changes between revisions . . . . . . . . . . . . . 17 Appendix A. Server capability probing and caching by DNS clients 18
B.1. -01 version . . . . . . . . . . . . . . . . . . . . . . . 17 Appendix B. Changes between revisions . . . . . . . . . . . . . 19
B.2. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 18 B.1. -02 version . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 B.2. -01 version . . . . . . . . . . . . . . . . . . . . . . . 19
B.3. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The DPRIVE working group has two active documents that provide DNS DNS Privacy issues are discussed in [RFC7626]. Two documents that
privacy between DNS clients and DNS servers (to address the concerns provide DNS privacy between DNS clients and DNS servers are:
in [RFC7626]):
o DNS-over-TLS [I-D.ietf-dprive-dns-over-tls] o Specification for DNS over Transport Layer Security (TLS)
[RFC7858], referred to here as simply 'DNS-over-TLS'
o DNS-over-DTLS [I-D.ietf-dprive-dnsodtls] o DNS-over-DTLS (DNSoD) [I-D.ietf-dprive-dnsodtls], referred to here
simply as 'DNS-over-DTLS'
This document defines usage profiles and authentication mechanisms Both documents are limited in scope to encrypting DNS messages
for DTLS [RFC6347] and TLS [RFC5246] that specify how a DNS client between stub clients and recursive resolvers and the same scope is
should authenticate a DNS server based on a domain name. In applied to this document (see Section 2 and Section 3). The
particular, it describes: proposals here might be adapted or extended in future to be used for
recursive clients and authoritative servers, but this application is
out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group per
its current charter.
This document defines two Usage Profiles (Strict and Opportunistic)
for DTLS [RFC6347] and TLS [RFC5246] which define the security
properties a user should expect when using that profile to connect to
the available DNS servers. In essence:
o the Strict Profile requires an encrypted connection and successful
authentication of the DNS server which provides strong privacy
guarantees (at the expense of providing no DNS service if this is
not available).
o the Opportunistic Profile will attempt, but does not require,
encryption and successful authentication; it therefore provides no
privacy guarantees but offers maximum chance of DNS service.
Additionally, a number of authentication mechanisms are defined that
specify how a DNS client should authenticate a DNS server based on a
domain name. In particular, the following is described:
o How a DNS client can obtain a domain name for a DNS server to use o How a DNS client can obtain a domain name for a DNS server to use
for (D)TLS authentication. for (D)TLS authentication.
o What are the acceptable credentials a DNS server can present to o What are the acceptable credentials a DNS server can present to
prove its identity for (D)TLS authentication based on a given prove its identity for (D)TLS authentication based on a given
domain name. domain name.
o How a DNS client can verify that any given credential matches the o How a DNS client can verify that any given credential matches the
domain name obtained for a DNS server. domain name obtained for a DNS server.
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 draft 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 the DNS-over-TLS draft 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 This document also defines a (D)TLS protocol profile for use with
DNS. This profile defines the configuration options and protocol DNS. This profile defines the configuration options and protocol
extensions required of both parties to optimize connection extensions required of both parties to optimize connection
establishment and session resumption for transporting DNS, and to establishment and session resumption for transporting DNS, and to
support the authentication profiles defined here. support the authentication mechanisms defined here.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Several terms are used specifically in the context of this draft: Several terms are used specifically in the context of this draft:
o DNS client: a DNS stub resolver or forwarder/proxy. In the case o DNS client: a DNS stub resolver or forwarder/proxy. In the case
of a forwarder, the term "DNS client" is used to discuss the side of a forwarder, the term "DNS client" is used to discuss the side
that sends queries. that sends queries.
o DNS server: a DNS recursive resolver or forwarder/proxy. In the o DNS server: a DNS recursive resolver or forwarder/proxy. In the
case of a forwarder, the term "DNS server" is used to discuss the case of a forwarder, the term "DNS server" is used to discuss the
side that responds to queries. side 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 [I-D.ietf-dprive-dns-over-tls] and * MUST implement DNS-over-TLS [RFC7858] and MAY implement DNS-
MAY implement DNS-over-DTLS [I-D.ietf-dprive-dnsodtls]. over-DTLS [I-D.ietf-dprive-dnsodtls].
* Can offer at least one of the credentials described in * Can offer at least one of the credentials described in
Section 9. Section 9.
* Implements the (D)TLS profile described in Section 11. * Implements the (D)TLS profile described in Section 11.
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 [I-D.ietf-dprive-dns-over-tls] and DNS- apply to both DNS-over-TLS [RFC7858] and DNS-over-DTLS
over-DTLS [I-D.ietf-dprive-dnsodtls]. Specific terms will be used
for any statement that applies to either protocol alone. [I-D.ietf-dprive-dnsodtls]. Specific terms will be used for any
statement that applies to either protocol alone.
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:
* X.509 certificate * X.509 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: [I-D.ietf-dprive-dns-over-tls] describes the use of o SPKI Pinsets: [RFC7858] describes the use of cryptographic digests
cryptographic digests to "pin" public key information in a manner to "pin" public key information in a manner similar to HPKP
similar to HPKP [RFC7469]. An SPKI pinset is a collection of [RFC7469]. An SPKI pinset is a collection of these pins that
these pins that constrains a DNS server. constrains a DNS server.
o Reference Identifier: a Reference Identifier as described in o Reference Identifier: a Reference Identifier as described in
[RFC6125], constructed by the DNS client when performing TLS [RFC6125], constructed by the DNS client when performing TLS
authentication of a DNS server. authentication of a DNS server.
3. Scope 3. Scope
This document is limited to domain-name-based authentication of DNS This document is limited to domain-name-based authentication of DNS
servers by DNS clients (as defined in the terminology section), and servers by DNS clients (as defined in the terminology section), and
the (D)TLS profiles needed to support this. As such, the following the (D)TLS profiles needed to support this. As such, the following
things are out of scope: things are out of scope:
o Authentication of authoritative servers by recursive resolvers. o Authentication of authoritative servers by recursive resolvers.
o Authentication of DNS clients by DNS servers. o Authentication of DNS clients by DNS servers.
o SPKI-pinset-based authentication. This is defined in o SPKI-pinset-based authentication. This is defined in [RFC7858].
[I-D.ietf-dprive-dns-over-tls]. However, Section 10 does describe However, Section 10 does describe how to combine that approach
how to combine that approach with the domain name based mechanism with the domain name based mechanism described here.
described here.
o Any server identifier other than domain names, including IP o Any server identifier other than domain names, including IP
address, organizational name, country of origin, etc. address, organizational name, country of origin, etc.
4. Discussion 4. Discussion
4.1. Background 4.1. Background
To protect against passive attacks DNS privacy requires encrypting To protect against passive attacks DNS privacy requires encrypting
the query (and response). Such encryption typically provides the query (and response). Such encryption typically provides
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
of privacy guarantees to DNS clients, based on the requirements for
authentication and encryption, regardless of the context (for
example, which network the client is connected to). A Usage Profile
is a distinct concept to a usage policy or usage model, which might
dictate which Profile should be used in a particular context
(enterprise vs coffee shop), with a particular set of DNS Servers or
with reference to other external factors. A description of the
variety of usage policies is out of scope of this document, but may
be the subject of a future I-D.
4.2. Usage Profiles 4.2. 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 [I-D.ietf-dprive-dns-over-tls] choice is briefly discussed in both [RFC7858] and
and [I-D.ietf-dprive-dnsodtls]. In summary, the usage profiles are: [I-D.ietf-dprive-dnsodtls]. In summary, the 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 information it can use to authenticate the
server. This profile can include some initial meta queries server. This profile can include some initial meta queries
(performed using Opportunistic Privacy) to securely obtain the IP (performed using Opportunistic Privacy) to securely obtain the IP
address and authentication information for the privacy-enabling address and authentication information for the privacy-enabling
DNS server to which the DNS client will subsequently connect. The DNS server to which the DNS client will subsequently connect. The
rationale for this is that requiring Strict Privacy for such meta rationale for this is that requiring Strict Privacy for such meta
skipping to change at page 5, line 45 skipping to change at page 6, line 44
profile provides strong privacy guarantees to the client. This is profile provides strong privacy guarantees to the client. This is
discussed in detail in Section 6. discussed in detail in Section 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."
In the best case scenario (authenticated and encrypted connection) The use of Opportunistic Privacy is intended to support
this is equivalent to Strict Privacy, in the worst case (clear incremental deployment of security capabilities with a view to
text connection) this is equivalent to No Privacy. Clients will widespread adoption of Strict Privacy. It should be employed when
try for the best case but are willing to fallback to intermediate the DNS client might otherwise settle for cleartext; it provides
cases and eventually the worst case scenario in order to obtain a the maximum protection available. As described in [RFC7435] it
response. This provides an undetermined privacy guarantee to the might result in
user depending on what kind of connection is actually used. This
is discussed in Section 5.
o No Privacy: the DNS client does not require or attempt to use * an encrypted and authenticated connection
either encryption or authentication. Queries are always sent in * an encrypted connection
clear text. This provides no privacy guarantees to the client.
+-----------------------+------------------+-----------------+ * a clear text connection
| Usage Profile | Passive Attacker | Active Attacker |
+-----------------------+------------------+-----------------+
| No Privacy | N | N |
| Opportunistic Privacy | N (D) | N (D) |
| Strict Privacy | P | P |
+-----------------------+------------------+-----------------+
P == protection; N == no protection; D == detection is possible * hard failure
depending on the fallback logic of the client, the available
authentication information and the capabilities of the DNS Server.
In the first three cases the DNS client is willing to continue
with a connection to the DNS Server and perform resolution of
queries.
To compare the two Usage profiles the table below shows successful
Strict Privacy along side the 3 possible successful outcomes of
Opportunistic Privacy. In the best case scenario for Opportunistic
(authenticated and encrypted connection) it is equivalent to Strict
Privacy. In the worst case scenario it is equivalent to clear text.
Clients using Opportunistic Privacy SHOULD try for the best case but
MAY fallback to intermediate cases and eventually the worst case
scenario in order to obtain a response. It therefore provides no
privacy guarantee to the user and varying protection depending on
what kind of connection is actually used. Note that there is no
requirement in Opportunistic to notify the user what type of
connection is actually used, the detection described below is only
possible if such connection information is available. This is
discussed in Section 5.
+---------------+------------+------------------+-----------------+
| Usage Profile | Connection | Passive Attacker | Active Attacker |
+---------------+------------+------------------+-----------------+
| Strict | A, E | P | P |
| Opportunistic | A, E | P | P |
| Opportunistic | E | P | N (D) |
| Opportunistic | | N (D) | N (D) |
+---------------+------------+------------------+-----------------+
P == protection; N == no protection; D == detection is possible; A ==
Authenticated Connection; E == Encrypted Connection
Table 1: DNS Privacy Protection by Usage Profile and type of attacker Table 1: DNS Privacy Protection by Usage Profile and type of attacker
Since Strict Privacy provides the strongest privacy guarantees it is Since Strict Privacy provides the strongest privacy guarantees it is
preferable to Opportunistic Privacy which is preferable to No preferable to Opportunistic Privacy.
Privacy. However since the different profiles require varying levels
of configuration (or a trusted relationship with a provider) DNS However since the two profiles require varying levels of
clients will need to carefully select which profile to use based on configuration (or a trusted relationship with a provider) and DNS
their communication privacy needs. For the case where a client has a server capabilities, DNS clients will need to carefully select which
trusted relationship with a provider it is expected that the provider profile to use based on their communication privacy needs. For the
will provide either a domain name or SPKI pinset via a secure out-of- case where a client has a trusted relationship with a provider it is
band mechanism and therefore Strict Privacy should be used. expected that the provider will provide either a domain name or SPKI
pinset via a secure out-of-band mechanism and therefore Strict
Privacy should be used.
4.2.1. DNS Resolution
A DNS client SHOULD select a particular usage profile when resolving A DNS client SHOULD select a particular usage profile when resolving
a query. A DNS client MUST NOT fallback from Strict Privacy to a query. A DNS client MUST NOT fallback from Strict Privacy to
Opportunistic Privacy during the resolution process as this could Opportunistic Privacy during the resolution process as this could
invalidate the protection offered against active attackers. invalidate the protection offered against active attackers.
4.3. Authentication 4.3. Authentication
This document describes authentication mechanisms that can be used in This document describes authentication mechanisms that can be used in
either Strict or Opportunistic Privacy for DNS-over-(D)TLS. either Strict or Opportunistic Privacy for DNS-over-(D)TLS.
skipping to change at page 7, line 13 skipping to change at page 8, line 41
learn the domain name it should associate with the IP address of a learn the domain name it should associate with the IP address of a
DNS server for authentication purposes. Sources of domains names are DNS server for authentication purposes. Sources of domains names are
discussed in Section 7 and Section 8. discussed in Section 7 and Section 8.
One advantage of this domain name based approach is that it One advantage of this domain name based approach is that it
encourages association of stable, human recognisable identifiers with encourages association of stable, human recognisable identifiers with
secure DNS service providers. secure DNS service providers.
4.3.2. Credential Verification 4.3.2. Credential Verification
The use of SPKI pinset verification is discussed in The use of SPKI pinset verification is discussed in [RFC7858].
[I-D.ietf-dprive-dns-over-tls].
In terms of domain name based verification, once a domain name is In terms of domain name based verification, once a domain name is
known for a DNS server a choice of mechanisms can be used for known for a DNS server a choice of mechanisms can be used for
authentication. Section 9 discusses these mechanisms in detail, authentication. Section 9 discusses these mechanisms in detail,
namely X.509 certificate based authentication and DANE. namely X.509 certificate based authentication and DANE.
Note that the use of DANE adds requirements on the ability of the Note that the use of DANE adds requirements on the ability of the
client to get validated DNSSEC results. This is discussed in more client to get validated DNSSEC results. This is discussed in more
detail in Section 9.2. detail in Section 9.2.
4.3.3. Implementation guidance 4.3.3. Implementation guidance
Section 11 describes the (D)TLS profile for DNS-over(D)TLS. Section 11 describes the (D)TLS profile for DNS-over(D)TLS.
Additional considerations relating to general implementation Additional considerations relating to general implementation
guidelines are discussed in both Section 13 and in Appendix A. guidelines are discussed in both Section 13 and in Appendix A.
5. Authentication in Opportunistic DNS-over(D)TLS Privacy 5. Authentication in Opportunistic DNS-over(D)TLS Privacy
An Opportunistic Security [RFC7435] profile is described in An Opportunistic Security [RFC7435] profile is described in [RFC7858]
[I-D.ietf-dprive-dns-over-tls] which MAY be used for DNS-over-(D)TLS. which MAY be used for DNS-over-(D)TLS.
DNS clients issuing queries under an opportunistic profile which know DNS clients issuing queries under an opportunistic profile which know
of a domain name or SPKI pinset for a given privacy-enabling DNS of a domain name or SPKI pinset for a given privacy-enabling DNS
server MAY choose to try to authenticate the server using the server MAY choose to try to authenticate the server using the
mechanisms described here. This is useful for detecting (but not mechanisms described here. This is useful for detecting (but not
preventing) active attack, since the fact that authentication preventing) active attack, since the fact that authentication
information is available indicates that the server in question is a information is available indicates that the server in question is a
privacy-enabling DNS server to which it should be possible to privacy-enabling DNS server to which it should be possible to
establish an authenticated, encrypted connection. In this case, establish an authenticated, encrypted connection. In this case,
whilst a client cannot know the reason for an authentication failure, whilst a client cannot know the reason for an authentication failure,
skipping to change at page 8, line 13 skipping to change at page 9, line 40
it is viable. it is viable.
6. Authentication in Strict DNS-over(D)TLS Privacy 6. Authentication in Strict DNS-over(D)TLS Privacy
To authenticate a privacy-enabling DNS server, a DNS client needs to To authenticate a privacy-enabling DNS server, a DNS client needs to
know the domain name for each server it is willing to contact. This know the domain name for each server it is willing to contact. This
is necessary to protect against active attacks on DNS privacy. is necessary to protect against active attacks on DNS privacy.
A DNS client requiring Strict Privacy MUST either use one of the A DNS client requiring Strict Privacy MUST either use one of the
sources listed in Section 8 to obtain a domain name for the server it sources listed in Section 8 to obtain a domain name for the server it
contacts, or use an SPKI pinset as described in contacts, or use an SPKI pinset as described in [RFC7858].
[I-D.ietf-dprive-dns-over-tls].
A DNS client requiring Strict Privacy MUST only attempt to connect to A DNS client requiring Strict Privacy MUST only attempt to connect to
DNS servers for which either a domain name or a SPKI pinset is known DNS servers for which either a domain name or a SPKI pinset is known
(or both). The client MUST use the available verification mechanisms (or both). The client MUST use the available verification mechanisms
described in Section 9 to authenticate the server, and MUST abort described in Section 9 to authenticate the server, and MUST abort
connections to a server when no verification mechanism succeeds. connections to a server when no verification mechanism succeeds.
With Strict Privacy, the DNS client MUST NOT commence sending DNS With Strict Privacy, the DNS client MUST NOT commence sending DNS
queries until at least one of the privacy-enabling DNS servers queries until at least one of the privacy-enabling DNS servers
becomes available. becomes available.
skipping to change at page 10, line 13 skipping to change at page 11, line 35
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 8.3. DHCP
Some clients may have an established trust relationship with a known Some clients may have an established trust relationship with a known
DHCP [RFC2131] server for discovering their network configuration. DHCP [RFC2131] server for discovering their network configuration.
In the typical case, such a DHCP server provides a list of IP In the typical case, such a DHCP server provides a list of IP
addresses for DNS servers (see section 3.8 of [RFC2132]), but does addresses for DNS servers (see section 3.8 of [RFC2132]), but does
not provide a domain name for the DNS server itself. not provide a domain name for the DNS server itself.
A DHCP server might use a DHCP extension to provide a list of domain In the future, a DHCP server might use a DHCP extension to provide a
names for the offered DNS servers, which correspond to IP addresses list of domain names for the offered DNS servers, which correspond to
listed. IP addresses listed.
Note that this requires the client to trust the DHCP server, and to Use of such a mechanism with any DHCP server when using an
have a secured/authenticated connection to it. Therefore this Opportunistic profile is reasonable, given the security expectation
mechanism may be limited to only certain environments. This document of that profile. However when using a Strict profile the DHCP
does not attempt to describe secured and trusted relationships to servers used as sources of domain names MUST be considered secure and
DHCP servers. trustworthy. This document does not attempt to describe secured and
trusted relationships to DHCP servers.
[NOTE: It is noted (at the time of writing) that whilst some [NOTE: It is noted (at the time of writing) that whilst some
implementation work is in progress to secure IPv6 connections for implementation work is in progress to secure IPv6 connections for
DHCP, IPv4 connections have received little to no implementation DHCP, IPv4 connections have received little to no implementation
attention in this area.] attention in this area.]
[QUESTION: The authors would like to solicit feedback on the use of
DHCP to determine whether to pursue a new DHCP option in a later
version of this draft, or defer it.]
9. Credential Verification 9. Credential Verification
9.1. X.509 Certificate Based Authentication 9.1. X.509 Certificate Based Authentication
When a DNS client configured with a domain name connects to its When a DNS client configured with a domain name connects to its
configured DNS server over (D)TLS, the server may present it with an configured DNS server over (D)TLS, the server may present it with an
X.509 certificate. In order to ensure proper authentication, DNS X.509 certificate. In order to ensure proper authentication, DNS
clients MUST verify the entire certification path per [RFC5280]. The clients MUST verify the entire certification path per [RFC5280]. The
DNS client additionally uses [RFC6125] validation techniques to DNS client additionally uses [RFC6125] validation techniques to
compare the domain name to the certificate provided. compare the domain name to the certificate provided.
skipping to change at page 11, line 44 skipping to change at page 13, line 16
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 9.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.shore-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.
[ TODO: specify guidance for DANE parameters to be used here. For [ TODO: specify guidance for DANE parameters to be used here. For
skipping to change at page 12, line 17 skipping to change at page 13, line 38
(section 2.1.1 of [RFC6698]) and a Selector of 1 (SPKI) (section (section 2.1.1 of [RFC6698]) and a Selector of 1 (SPKI) (section
2.1.2) would completely remove all X.509 and certificate authorities 2.1.2) would completely remove all X.509 and certificate authorities
from the verification path and allows for private certification ] from the verification path and allows for private certification ]
[ TODO: discuss combination of DNSSEC Chain Extension with cert [ TODO: discuss combination of DNSSEC Chain Extension with cert
validation. Note that the combination depends on the Certificate validation. Note that the combination depends on the Certificate
Usage value of the TLSA response. ] Usage value of the TLSA response. ]
10. Combined Credentials with SPKI Pinsets 10. Combined Credentials with SPKI Pinsets
The SPKI pinset profile described in [I-D.ietf-dprive-dns-over-tls] The SPKI pinset profile described in [RFC7858] MAY be used with DNS-
MAY be used with DNS-over-(D)TLS. over-(D)TLS.
This draft does not make explicit recommendations about how a SPKI This draft does not make explicit recommendations about how a SPKI
pinset based authentication mechanism should be combined with a pinset based authentication mechanism should be combined with a
domain based mechanism from an operator perspective. However it can domain based mechanism from an operator perspective. However it can
be envisaged that a DNS server operator may wish to make both an SPKI be envisaged that a DNS server operator may wish to make both an SPKI
pinset and a domain name available to allow clients to choose which pinset and a domain name available to allow clients to choose which
mechanism to use. Therefore, the following is guidance on how mechanism to use. Therefore, the following is guidance on how
clients ought to behave if they choose to configure both, as is clients ought to behave if they choose to configure both, as is
possible in HPKP [RFC7469]. possible in HPKP [RFC7469].
skipping to change at page 13, line 31 skipping to change at page 15, line 4
(ChangeCipherSpec) to also contain the (encrypted) DNS query (ChangeCipherSpec) to also contain the (encrypted) DNS query
o Cached Information Extension [I-D.ietf-tls-cached-info] which o Cached Information Extension [I-D.ietf-tls-cached-info] which
avoids transmitting the server's certificate and certificate chain avoids transmitting the server's certificate and certificate chain
if the client has cached that information from a previous TLS if the client has cached that information from a previous TLS
handshake handshake
[NOTE: The references to (works in progress) should be upgraded to [NOTE: The references to (works in progress) should be upgraded to
MUST's if those references become RFC's prior to publication of this MUST's if those references become RFC's prior to publication of this
document.] document.]
Guidance specific to TLS is provided in [RFC7858] and that specific
Guidance specific to TLS or DTLS is provided in either to DTLS it is provided in[I-D.ietf-dprive-dnsodtls].
[I-D.ietf-dprive-dnsodtls] or [I-D.ietf-dprive-dns-over-tls].
12. IANA Considerations 12. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
13. Security Considerations 13. Security Considerations
Security considerations discussed in [RFC7525], Security considerations discussed in [RFC7525],
[I-D.ietf-dprive-dnsodtls] and [I-D.ietf-dprive-dns-over-tls] apply [I-D.ietf-dprive-dnsodtls] and [RFC7858] apply to this document.
to this document.
13.1. Counter-measures to DNS Traffic Analysis 13.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
o EDNS(0) padding [I-D.ietf-dprive-edns0-padding], which allows o EDNS(0) padding [RFC7830], which allows encrypted queries and
encrypted queries and responses to hide their size. responses to hide their size.
DNS-over-(D)TLS clients SHOULD consider implementing the following DNS-over-(D)TLS clients SHOULD consider implementing the following
relevant DNS extensions relevant DNS extensions
o Privacy Election using Client Subnet in DNS Queries o Privacy Election using Client Subnet in DNS Queries [RFC7871]. If
[I-D.ietf-dnsop-edns-client-subnet]. If a DNS client does not a DNS client does not include an EDNS0 Client Subnet Option with a
include an EDNS0 Client Subnet Option with a SOURCE PREFIX-LENGTH SOURCE PREFIX-LENGTH set to 0 in a query, the DNS server may
set to 0 in a query, the DNS server may potentially leak client potentially leak client address information to the upstream
address information to the upstream authoritative DNS servers. A authoritative DNS servers. A DNS client ought to be able to
DNS client ought to be able to inform the DNS Resolver that it inform the DNS Resolver that it does not want any address
does not want any address information leaked, and the DNS Resolver information leaked, and the DNS Resolver should honor that
should honor that request. request.
14. Acknowledgements 14. 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
[I-D.ietf-dprive-dns-over-tls] for laying the ground work that this [RFC7858] for laying the ground work that this draft builds on and
draft builds on and for reviewing the contents. The authors would for reviewing the contents. The authors would also like to thank
also like to thank John Dickinson, Shumon Huque, Melinda Shore, Gowri John Dickinson, Shumon Huque, Melinda Shore, Gowri Visweswaran, Ray
Visweswaran, Ray Bellis, Stephane Bortzmeyer and Jinmei Tatuya for Bellis, Stephane Bortzmeyer, Jinmei Tatuya, Paul Hoffman and
review and discussion of the ideas presented here. Christian Huitema for review and discussion of the ideas presented
here.
15. References 15. References
15.1. Normative References 15.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 15, line 44 skipping to change at page 17, line 17
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <http://www.rfc-editor.org/info/rfc7250>. June 2014, <http://www.rfc-editor.org/info/rfc7250>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>. 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
DOI 10.17487/RFC7830, May 2016,
<http://www.rfc-editor.org/info/rfc7830>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <http://www.rfc-editor.org/info/rfc7858>.
15.2. Informative References 15.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-dnsop-edns-client-subnet]
Contavalli, C., Gaast, W., tale, t., and W. Kumari,
"Client Subnet in DNS Queries", draft-ietf-dnsop-edns-
client-subnet-06 (work in progress), December 2015.
[I-D.ietf-dprive-dns-over-tls]
Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over TLS", draft-
ietf-dprive-dns-over-tls-09 (work in progress), March
2016.
[I-D.ietf-dprive-dnsodtls] [I-D.ietf-dprive-dnsodtls]
Reddy, T., Wing, D., and P. Patil, "DNS over DTLS Reddy, T., Wing, D., and P. Patil, "DNS over DTLS
(DNSoD)", draft-ietf-dprive-dnsodtls-05 (work in (DNSoD)", draft-ietf-dprive-dnsodtls-06 (work in
progress), March 2016. progress), April 2016.
[I-D.ietf-dprive-edns0-padding]
Mayrhofer, A., "The EDNS(0) Padding Option", draft-ietf-
dprive-edns0-padding-03 (work in progress), March 2016.
[I-D.ietf-tls-cached-info] [I-D.ietf-tls-cached-info]
Santesson, S. and H. Tschofenig, "Transport Layer Security Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", draft-ietf-tls- (TLS) Cached Information Extension", draft-ietf-tls-
cached-info-22 (work in progress), January 2016. cached-info-23 (work in progress), May 2016.
[I-D.ietf-tls-dnssec-chain-extension]
Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE
Record and DNSSEC Authentication Chain Extension for TLS",
draft-ietf-tls-dnssec-chain-extension-00 (work in
progress), June 2016.
[I-D.ietf-tls-falsestart] [I-D.ietf-tls-falsestart]
Langley, A., Modadugu, N., and B. Moeller, "Transport Langley, A., Modadugu, N., and B. Moeller, "Transport
Layer Security (TLS) False Start", draft-ietf-tls- Layer Security (TLS) False Start", draft-ietf-tls-
falsestart-01 (work in progress), November 2015. falsestart-02 (work in progress), May 2016.
[I-D.shore-tls-dnssec-chain-extension]
Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE
Record and DNSSEC Authentication Chain Extension for TLS",
draft-shore-tls-dnssec-chain-extension-02 (work in
progress), October 2015.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997, RFC 2131, DOI 10.17487/RFC2131, March 1997,
<http://www.rfc-editor.org/info/rfc2131>. <http://www.rfc-editor.org/info/rfc2131>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<http://www.rfc-editor.org/info/rfc2132>. <http://www.rfc-editor.org/info/rfc2132>.
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic
skipping to change at page 17, line 17 skipping to change at page 18, line 35
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.
Kumari, "Client Subnet in DNS Queries", RFC 7871,
DOI 10.17487/RFC7871, May 2016,
<http://www.rfc-editor.org/info/rfc7871>.
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 privacy capabilities of 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.
skipping to change at page 17, line 44 skipping to change at page 19, line 18
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. -01 version B.1. -02 version
Introduction: Added paragraph on the background and scope of the
document.
Introduction and Discussion: Added more information on what a Usage
profiles is (and is not) the the two presented here.
Introduction: Added paragraph to make a comparison with the Strict
profile in RFC7858 clearer.
Section 4.2: Re-worked the description of Opportunistic and the
table.
Section 8.3: Clarified statement about use of DHCP in Opportunistic
profile
Title abbreviated.
B.2. -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.2. draft-ietf-dprive-dtls-and-tls-profiles-00 B.3. 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. 44 change blocks. 
159 lines changed or deleted 243 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/