< draft-ietf-dprive-dtls-and-tls-profiles-04.txt   draft-ietf-dprive-dtls-and-tls-profiles-05.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: April 10, 2017 ACLU Expires: April 23, 2017 ACLU
T. Reddy T. Reddy
Cisco Cisco
October 7, 2016 October 20, 2016
Authentication and (D)TLS Profile for DNS-over-(D)TLS Authentication and (D)TLS Profile for DNS-over-(D)TLS
draft-ietf-dprive-dtls-and-tls-profiles-04 draft-ietf-dprive-dtls-and-tls-profiles-05
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 April 10, 2017. This Internet-Draft will expire on April 23, 2017.
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
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Usage Profiles . . . . . . . . . . . . . . . . . . . . . 6 4.2. Usage Profiles . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. DNS Resolution . . . . . . . . . . . . . . . . . . . 8 4.2.1. DNS Resolution . . . . . . . . . . . . . . . . . . . 8
4.3. Authentication . . . . . . . . . . . . . . . . . . . . . 8 4.3. Authentication . . . . . . . . . . . . . . . . . . . . . 8
4.3.1. DNS-over-(D)TLS Bootstrapping Problems . . . . . . . 8 4.3.1. DNS-over-(D)TLS Bootstrapping Problems . . . . . . . 8
4.3.2. Credential Verification . . . . . . . . . . . . . . . 8 4.3.2. Credential Verification . . . . . . . . . . . . . . . 9
4.3.3. Implementation guidance . . . . . . . . . . . . . . . 9 4.3.3. Implementation guidance . . . . . . . . . . . . . . . 9
5. Authentication in Opportunistic DNS-over(D)TLS Privacy . . . 9 5. Authentication in Opportunistic DNS-over(D)TLS Privacy . . . 9
6. Authentication in Strict DNS-over(D)TLS Privacy . . . . . . . 9 6. Authentication in Strict DNS-over(D)TLS Privacy . . . . . . . 10
7. In Band Source of Domain Name: SRV Service Label . . . . . . 10 7. In Band Source of Domain Name: SRV Service Label . . . . . . 10
8. Out of Band Sources of Domain Name . . . . . . . . . . . . . 10 8. Out of Band Sources of Domain Name . . . . . . . . . . . . . 10
8.1. Full direct configuration . . . . . . . . . . . . . . . . 10 8.1. Full direct configuration . . . . . . . . . . . . . . . . 11
8.2. Direct configuration of name only . . . . . . . . . . . . 10 8.2. Direct configuration of name only . . . . . . . . . . . . 11
8.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Credential Verification . . . . . . . . . . . . . . . . . . . 12 9. Credential Verification . . . . . . . . . . . . . . . . . . . 12
9.1. X.509 Certificate Based Authentication . . . . . . . . . 12 9.1. PKIX Certificate Based Authentication . . . . . . . . . . 12
9.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 13 9.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 14
9.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 13 9.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 14
10. Combined Credentials with SPKI Pinsets . . . . . . . . . . . 14 10. Combined Credentials with SPKI Pinsets . . . . . . . . . . . 14
11. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 14 11. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
13. Security Considerations . . . . . . . . . . . . . . . . . . . 15 13. Security Considerations . . . . . . . . . . . . . . . . . . . 16
13.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 15 13.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 16
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
15.1. Normative References . . . . . . . . . . . . . . . . . . 16 15.1. Normative References . . . . . . . . . . . . . . . . . . 17
15.2. Informative References . . . . . . . . . . . . . . . . . 17 15.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Server capability probing and caching by DNS clients 19 Appendix A. Server capability probing and caching by DNS clients 19
Appendix B. Changes between revisions . . . . . . . . . . . . . 19 Appendix B. Changes between revisions . . . . . . . . . . . . . 20
B.1. -04 version . . . . . . . . . . . . . . . . . . . . . . . 19 B.1. -05 version . . . . . . . . . . . . . . . . . . . . . . . 20
B.2. -03 version . . . . . . . . . . . . . . . . . . . . . . . 19 B.2. -04 version . . . . . . . . . . . . . . . . . . . . . . . 20
B.3. -02 version . . . . . . . . . . . . . . . . . . . . . . . 19 B.3. -03 version . . . . . . . . . . . . . . . . . . . . . . . 20
B.4. -01 version . . . . . . . . . . . . . . . . . . . . . . . 20 B.4. -02 version . . . . . . . . . . . . . . . . . . . . . . . 20
B.5. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 20 B.5. -01 version . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 B.6. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
DNS Privacy issues are discussed in [RFC7626]. Two documents that DNS Privacy issues are discussed in [RFC7626]. Two documents that
provide DNS privacy between DNS clients and DNS servers are: provide DNS privacy between DNS clients and DNS servers are:
o Specification for DNS over Transport Layer Security (TLS) o Specification for DNS over Transport Layer Security (TLS)
[RFC7858], referred to here as simply 'DNS-over-TLS' [RFC7858], referred to here as simply 'DNS-over-TLS'
o DNS-over-DTLS (DNSoD) [I-D.ietf-dprive-dnsodtls], referred to here o DNS-over-DTLS (DNSoD) [I-D.ietf-dprive-dnsodtls], referred to here
skipping to change at page 5, line 12 skipping to change at page 5, line 12
o DNS-over-(D)TLS: For brevity this term is used for statements that o DNS-over-(D)TLS: For brevity this term is used for statements that
apply to both DNS-over-TLS [RFC7858] and DNS-over-DTLS apply to both DNS-over-TLS [RFC7858] and DNS-over-DTLS
[I-D.ietf-dprive-dnsodtls]. Specific terms will be used for any [I-D.ietf-dprive-dnsodtls]. Specific terms will be used for any
statement that applies to either protocol alone. statement that applies to either protocol alone.
o 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 * PKIX certificate
* DNSSEC validated chain to a TLSA record * DNSSEC validated chain to a TLSA record
but may also include SPKI pinsets. but may also include SPKI pinsets.
o SPKI Pinsets: [RFC7858] describes the use of cryptographic digests 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 HPKP
[RFC7469]. An SPKI pinset is a collection of these pins that [RFC7469]. An SPKI pinset is a collection of these pins that
constrains a DNS server. constrains a DNS server.
skipping to change at page 6, line 16 skipping to change at page 6, line 16
This draft discusses Usage Profiles, which provide differing levels This draft discusses Usage Profiles, which provide differing levels
of privacy guarantees to DNS clients, based on the requirements for of privacy guarantees to DNS clients, based on the requirements for
authentication and encryption, regardless of the context (for authentication and encryption, regardless of the context (for
example, which network the client is connected to). A Usage Profile example, which network the client is connected to). A Usage Profile
is a distinct concept to a usage policy or usage model, which might is a distinct concept to a usage policy or usage model, which might
dictate which Profile should be used in a particular context dictate which Profile should be used in a particular context
(enterprise vs coffee shop), with a particular set of DNS Servers or (enterprise vs coffee shop), with a particular set of DNS Servers or
with reference to other external factors. A description of the with reference to other external factors. A description of the
variety of usage policies is out of scope of this document, but may variety of usage policies is out of scope of this document, but may
be the subject of a future I-D. be the subject of future work.
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 [RFC7858] and choice is briefly discussed in both [RFC7858] and
[I-D.ietf-dprive-dnsodtls]. In summary, the usage profiles are: [I-D.ietf-dprive-dnsodtls]. 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
queries would introduce significant deployment obstacles. This queries would introduce significant deployment obstacles. This
profile provides strong privacy guarantees to the client. This is profile provides strong privacy guarantees to the client. This
Profile discussed in detail in Section 6. Profile is 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."
The use of Opportunistic Privacy is intended to support The use of Opportunistic Privacy is intended to support
incremental deployment of security capabilities with a view to incremental deployment of security capabilities with a view to
skipping to change at page 7, line 25 skipping to change at page 7, line 25
To compare the two Usage profiles the table below shows successful To compare the two Usage profiles the table below shows successful
Strict Privacy along side the 3 possible successful outcomes of Strict Privacy along side the 3 possible successful outcomes of
Opportunistic Privacy. In the best case scenario for Opportunistic Opportunistic Privacy. In the best case scenario for Opportunistic
Privacy (an authenticated and encrypted connection) it is equivalent Privacy (an authenticated and encrypted connection) it is equivalent
to Strict Privacy. In the worst case scenario it is equivalent to to Strict Privacy. In the worst case scenario it is equivalent to
clear text. Clients using Opportunistic Privacy SHOULD try for the clear text. Clients using Opportunistic Privacy SHOULD try for the
best case but MAY fallback to intermediate cases and eventually the best case but MAY fallback to intermediate cases and eventually the
worst case scenario in order to obtain a response. It therefore worst case scenario in order to obtain a response. It therefore
provides no privacy guarantee to the user and varying protection provides no privacy guarantee to the user and varying protection
depending on what kind of connection is actually used. Note that depending on what kind of connection is actually used.
there is no requirement in Opportunistic to notify the user what type
of connection is actually used, the 'detection' described below is Note that there is no requirement in Opportunistic Security to notify
only possible if such connection information is available. This is the user what type of connection is actually used, the 'detection'
discussed in Section 5. described below is only possible if such connection information is
available. However, if it is available and the user is informed that
an unencrypted connection was used to connect to a server then the
user should assume (detect) that the connection is subject to both
active and passive attack since the DNS queries are sent in clear
text. This might be particularly useful if a new connection to a
certain server is unencrypted when all previous connections were
encrypted. Similarly if the user is informed that an encrypted but
unauthenticated connection was used then user can detect that the
connection may be subject to active attack. This is discussed in
Section 5.
+---------------+------------+------------------+-----------------+ +---------------+------------+------------------+-----------------+
| Usage Profile | Connection | Passive Attacker | Active Attacker | | Usage Profile | Connection | Passive Attacker | Active Attacker |
+---------------+------------+------------------+-----------------+ +---------------+------------+------------------+-----------------+
| Strict | A, E | P | P | | Strict | A, E | P | P |
| Opportunistic | A, E | P | P | | Opportunistic | A, E | P | P |
| Opportunistic | E | P | N (D) | | Opportunistic | E | P | N (D) |
| Opportunistic | | N (D) | N (D) | | Opportunistic | | N (D) | N (D) |
+---------------+------------+------------------+-----------------+ +---------------+------------+------------------+-----------------+
skipping to change at page 8, line 46 skipping to change at page 9, line 21
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 [RFC7858]. The use of SPKI pinset verification is discussed in [RFC7858].
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 PKIX certificate based authentication and DANE.
Note that the use of DANE adds requirements on the ability of the Note that the use of DANE adds requirements on the ability of the
client to get validated DNSSEC results. This is discussed in more client to get validated DNSSEC results. This is discussed in more
detail in Section 9.2. detail in Section 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.
skipping to change at page 12, line 7 skipping to change at page 12, line 31
trustworthy. This document does not attempt to describe secured and trustworthy. This document does not attempt to describe secured and
trusted relationships to DHCP servers. 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.]
9. Credential Verification 9. Credential Verification
9.1. X.509 Certificate Based Authentication 9.1. PKIX 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 PKIX 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.
A DNS client constructs two Reference Identifiers for the server A DNS client constructs two Reference Identifiers for the server
based on the domain name: A DNS-ID and an SRV-ID [RFC4985]. The DNS- based on the domain name: A DNS-ID and an SRV-ID [RFC4985]. The DNS-
ID is simply the domain name itself. The SRV-ID uses a "_domain-s." ID is simply the domain name itself. The SRV-ID uses a "_domain-s."
prefix. So if the configured domain name is "dns.example.com", then prefix. So if the configured domain name is "dns.example.com", then
the two Reference Identifiers are: the two Reference Identifiers are:
DNS-ID: dns.example.com DNS-ID: dns.example.com
SRV-ID: _domain-s.dns.example.com SRV-ID: _domain-s.dns.example.com
If either of the Reference Identifiers are found in the X.509 If either of the Reference Identifiers are found in the PKIX
certificate's subjectAltName extension as described in section 6 of certificate's subjectAltName extension as described in section 6 of
[RFC6125], the DNS client should accept the certificate for the [RFC6125], the DNS client should accept the certificate for the
server. server.
A compliant DNS client MUST only inspect the certificate's A compliant DNS client MUST only inspect the certificate's
subjectAltName extension for these Reference Identifiers. In subjectAltName extension for these Reference Identifiers. In
particular, it MUST NOT inspect the Subject field itself. particular, it MUST NOT inspect the Subject field itself.
9.2. DANE 9.2. DANE
DANE [RFC6698] provides mechanisms to root certificate and raw public DANE [RFC6698] provides mechanisms to root certificate and raw public
skipping to change at page 13, line 18 skipping to change at page 13, line 44
Section 14: Security Considerations, which both discuss the use of Section 14: Security Considerations, which both discuss the use of
PKIX-TA(0) and PKIX-EE(1) for OS. PKIX-TA(0) and PKIX-EE(1) for OS.
o Section 5: Certificate-Usage-Specific DANE Updates and Guidelines. o Section 5: Certificate-Usage-Specific DANE Updates and Guidelines.
Specifically Section 5.1 which outlines the combination of Specifically Section 5.1 which outlines the combination of
Certificate Usage DANE-EE(3) and Selector Usage SPKI(1) with Raw Certificate Usage DANE-EE(3) and Selector Usage SPKI(1) with Raw
Public Keys [RFC7250]. Section 5.1 also discusses the security Public Keys [RFC7250]. Section 5.1 also discusses the security
implications of this mode, for example, it discusses key lifetimes implications of this mode, for example, it discusses key lifetimes
and specifies that validity period enforcement is based solely on and specifies that validity period enforcement is based solely on
the TLSA RRset properties for this case. [QUESTION: Should an the TLSA RRset properties for this case. [QUESTION: Should an
appendix be added with an example of how to use DANE without X.509 appendix be added with an example of how to use DANE without PKIX
certificates?] certificates?]
o Section 13: Operational Considerations, which discusses TLSA TTLs o Section 13: Operational Considerations, which discusses TLSA TTLs
and signature validity periods. and signature validity periods.
The specific DANE record for a DNS Privacy Server would take the The specific DANE record for a DNS Privacy Server would take the
form: form:
_853._tcp.[server-domain-name] for TLS _853._tcp.[server-domain-name] for TLS
skipping to change at page 19, line 32 skipping to change at page 20, line 23
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. -04 version B.1. -05 version
Add more details on detecting passive attacks to section 4.2
Changed X.509 to PKIX throughout
Change comment about future I-D on usage policies.
B.2. -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.2. -03 version B.3. -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.3. -02 version B.4. -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.4. -01 version B.5. -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.5. draft-ietf-dprive-dtls-and-tls-profiles-00 B.6. 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. 26 change blocks. 
46 lines changed or deleted 66 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/