draft-ietf-dprive-dtls-and-tls-profiles-10.txt   draft-ietf-dprive-dtls-and-tls-profiles-11.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: December 18, 2017 T. Reddy Expires: March 15, 2018 T. Reddy
McAfee McAfee
June 16, 2017 September 11, 2017
Usage and (D)TLS Profiles for DNS-over-(D)TLS Usage and (D)TLS Profiles for DNS-over-(D)TLS
draft-ietf-dprive-dtls-and-tls-profiles-10 draft-ietf-dprive-dtls-and-tls-profiles-11
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). These profiles can Layer Security (TLS) or Datagram TLS (DTLS). These profiles can
increase the privacy of DNS transactions compared to using only clear increase the privacy of DNS transactions compared to using only clear
text DNS. This document also specifies new authentication mechanisms text DNS. This document also specifies new authentication mechanisms
- it describes several ways a DNS client can use an authentication - it describes several ways a DNS client can use an authentication
domain name to authenticate a (D)TLS connection to a DNS server. domain name to authenticate a (D)TLS connection to a DNS server.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 December 18, 2017. This Internet-Draft will expire on March 15, 2018.
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
skipping to change at page 2, line 51 skipping to change at page 2, line 51
9. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 19 9. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 20 11.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 20
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 21 13.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 23 13.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Server capability probing and caching by DNS clients 24 Appendix A. Server capability probing and caching by DNS clients 24
Appendix B. Changes between revisions . . . . . . . . . . . . . 24 Appendix B. Changes between revisions . . . . . . . . . . . . . 24
B.1. -10 version . . . . . . . . . . . . . . . . . . . . . . . 25 B.1. -11 version . . . . . . . . . . . . . . . . . . . . . . . 25
B.2. -09 version . . . . . . . . . . . . . . . . . . . . . . . 26 B.2. -10 version . . . . . . . . . . . . . . . . . . . . . . . 25
B.3. -08 version . . . . . . . . . . . . . . . . . . . . . . . 26 B.3. -09 version . . . . . . . . . . . . . . . . . . . . . . . 26
B.4. -07 version . . . . . . . . . . . . . . . . . . . . . . . 26 B.4. -08 version . . . . . . . . . . . . . . . . . . . . . . . 26
B.5. -06 version . . . . . . . . . . . . . . . . . . . . . . . 26 B.5. -07 version . . . . . . . . . . . . . . . . . . . . . . . 26
B.6. -05 version . . . . . . . . . . . . . . . . . . . . . . . 27 B.6. -06 version . . . . . . . . . . . . . . . . . . . . . . . 26
B.7. -04 version . . . . . . . . . . . . . . . . . . . . . . . 27 B.7. -05 version . . . . . . . . . . . . . . . . . . . . . . . 27
B.8. -03 version . . . . . . . . . . . . . . . . . . . . . . . 27 B.8. -04 version . . . . . . . . . . . . . . . . . . . . . . . 27
B.9. -02 version . . . . . . . . . . . . . . . . . . . . . . . 27 B.9. -03 version . . . . . . . . . . . . . . . . . . . . . . . 27
B.10. -01 version . . . . . . . . . . . . . . . . . . . . . . . 28 B.10. -02 version . . . . . . . . . . . . . . . . . . . . . . . 27
B.11. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 28 B.11. -01 version . . . . . . . . . . . . . . . . . . . . . . . 28
B.12. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
DNS Privacy issues are discussed in [RFC7626]. The specific issues DNS Privacy issues are discussed in [RFC7626]. The specific issues
described there that are most relevant to this document are described there that are most relevant to this document are
o Passive attacks which eavesdrop on clear text DNS transactions on o Passive attacks which eavesdrop on clear text DNS transactions on
the wire (Section 2.4) and the wire (Section 2.4) and
skipping to change at page 8, line 14 skipping to change at page 8, line 14
available privacy for DNS. This Profile is discussed in detail in available privacy for DNS. 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 As described in [RFC7435] it might result in
incremental deployment of increased privacy with a view to
widespread adoption of the Strict profile. It should be employed
when the DNS client might otherwise settle for cleartext; it
provides the maximum protection an attacker will allow. As
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.
The use of Opportunistic Privacy is intended to support
incremental deployment of increased privacy with a view to
widespread adoption of the Strict profile. It should be employed
when the DNS client might otherwise settle for cleartext; it
provides the maximum protection available depending on the
combination of factors described above. If all the configured DNS
Servers are DNS Privacy servers then it provides protection
against passive attacks but not active ones.
Both profiles can include an initial meta query (performed using an Both profiles can include an initial meta query (performed using an
Opportunistic lookup) to obtain the IP address for the privacy- Opportunistic lookup) to obtain the IP address for the privacy-
enabling DNS server to which the DNS client will subsequently enabling DNS server to which the DNS client will subsequently
connect. The rationale for permitting this for the Strict profile is connect. The rationale for permitting this for the Strict profile is
that requiring such meta queries to also be performed using the that requiring such meta queries to also be performed using the
Strict profile would introduce significant deployment obstacles. Strict profile would introduce significant deployment obstacles.
However, it should be noted that in this scenario an active attack is However, it should be noted that in this scenario an active attack is
possible on the meta query which could result in the client not being possible on the meta query. Such an attack could result in a Strict
able to connect to a privacy-enabling DNS server that it can profile client connecting to a server it cannot authenticate and so
authenticate. not obtaining DNS service, or an Opportunistic Privacy client
connecting to a server controlled by the attacker. DNSSEC validation
can detect the attack on the meta query and results in the client not
obtaining DNS service (for both Usage profiles) because it will not
proceed to connect to the server in question (see Section 7.2)
To compare the two Usage profiles the table below shows a successful To compare the two Usage profiles the table below shows a successful
Strict profile along side the 3 possible outcomes of an Opportunistic Strict profile along side the 3 possible outcomes of an Opportunistic
profile. In the best case scenario for the Opportunistic profile (an profile. In the best case scenario for the Opportunistic profile (an
authenticated and encrypted connection) it is equivalent to the authenticated and encrypted connection) it is equivalent to the
Strict profile. In the worst case scenario it is equivalent to clear Strict profile. In the worst case scenario it is equivalent to clear
text. Clients using the Opportunistic profile SHOULD try for the text. Clients using the Opportunistic profile SHOULD try for the
best case but MAY fallback to the intermediate case and eventually best case but MAY fallback to the intermediate case and eventually
the worst case scenario in order to obtain a response. One reason to the worst case scenario in order to obtain a response. One reason to
fallback without trying every available privacy-enabling DNS server fallback without trying every available privacy-enabling DNS server
skipping to change at page 13, line 14 skipping to change at page 13, line 14
+ 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
recognizable 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 that may be subject to active attack (attack can be mitigated
by DNSSEC validation).
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 if - Requires secure and trustworthy connection to DHCP server if
used with a Strict Usage profile used with a Strict Usage profile
skipping to change at page 16, line 20 skipping to change at page 16, line 20
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 each of its privacy-enabling DNS authentication domain name of each of its privacy-enabling DNS
servers. For example, using a client specific configuration file or servers. For example, using a client specific configuration file or
API. 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. Such
DNS resolution can now be done by the DNS client against the pre- records SHOULD be DNSSEC validated when using a Strict Usage profile
and MUST be validated when using Opportunistic Privacy. Private 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. Dynamic discovery of ADN 7.3. Dynamic discovery of ADN
This section discusses the general case of a DNS client discovering This section discusses the general case of a DNS client discovering
skipping to change at page 21, line 20 skipping to change at page 21, line 20
Melinda Shore, Gowri Visweswaran, Ray Bellis, Stephane Bortzmeyer, Melinda Shore, Gowri Visweswaran, Ray Bellis, Stephane Bortzmeyer,
Jinmei Tatuya, Paul Hoffman, Christian Huitema and John Levine for Jinmei Tatuya, Paul Hoffman, Christian Huitema and John Levine for
review and discussion of the ideas presented here. review and discussion of the ideas 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, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <http://www.rfc-editor.org/info/rfc5077>. January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5246>. editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <http://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <http://www.rfc-editor.org/info/rfc6698>. 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
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, <https://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, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based
Authentication of Named Entities (DANE) Protocol: Updates Authentication of Named Entities (DANE) Protocol: Updates
and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
October 2015, <http://www.rfc-editor.org/info/rfc7671>. October 2015, <https://www.rfc-editor.org/info/rfc7671>.
[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, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7830>. 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, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport
Layer Security (TLS) False Start", RFC 7918, Layer Security (TLS) False Start", RFC 7918,
DOI 10.17487/RFC7918, August 2016, DOI 10.17487/RFC7918, August 2016, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7918>. editor.org/info/rfc7918>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924, (TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016, DOI 10.17487/RFC7924, July 2016, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7924>. editor.org/info/rfc7924>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094, Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017, DOI 10.17487/RFC8094, February 2017, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc8094>. 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-padding-policy] [I-D.ietf-dprive-padding-policy]
Mayrhofer, A., "Padding Policy for EDNS(0)", draft-ietf- Mayrhofer, A., "Padding Policy for EDNS(0)", draft-ietf-
dprive-padding-policy-00 (work in progress), December dprive-padding-policy-01 (work in progress), July 2017.
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-04 (work in draft-ietf-tls-dnssec-chain-extension-04 (work in
progress), June 2017. progress), June 2017.
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-20 (work in progress), Version 1.3", draft-ietf-tls-tls13-21 (work in progress),
April 2017. July 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>. <https://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>. <https://www.rfc-editor.org/info/rfc2132>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>. 2003, <https://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, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3646>. editor.org/info/rfc3646>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options", S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
<http://www.rfc-editor.org/info/rfc7227>. <https://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, <https://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, <https://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, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7626>. 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, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7871>. 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 capabilities of privacy-enabling DNS might probe for and cache capabilities of privacy-enabling DNS
servers. 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
skipping to change at page 25, line 5 skipping to change at page 25, line 5
encrypted connection before falling back. (RATIONALE: This approach encrypted connection before falling back. (RATIONALE: This approach
can increase latency while discovering server capabilities but can increase latency while discovering server capabilities but
maximizes the chance of sending the query over an authenticated and maximizes the chance of sending the query over an authenticated and
encrypted connection.) 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. -10 version B.1. -11 version
Section 5: Re-ordered and re-worded the text in section on
Opportunistic profile to make the protection offered by Opportunistic
clearer.
Section 5: Provide a more detailed analysis of attacks on the meta
queries
Section 7.2: Re-introduce a requirement to DNSSEC validate the meta-
queries making it as SHOULD for Strict and a MUST for Opportunistic.
B.2. -10 version
Clarified the specific attacks the Usage profiles mitigate against. Clarified the specific attacks the Usage profiles mitigate against.
Revised wording in the draft relating 'security/privacy guarantees' Revised wording in the draft relating 'security/privacy guarantees'
and generally improved consistency of wording throughout the and generally improved consistency of wording throughout the
document. document.
Corrected and added a number of references: Corrected and added a number of references:
o RFC7924 is now Normative o RFC7924 is now Normative
o RFC7918 and RFC8094 are now Normative (and therefore Downrefs) o RFC7918 and RFC8094 are now Normative (and therefore Downrefs)
o draft-ietf-tls-tls13, draft-ietf-dprive-padding-policy,RFC3315 and o draft-ietf-tls-tls13, draft-ietf-dprive-padding-policy, RFC3315
RFC7227 added and RFC7227 added
Terminology: Update definition of Privacy-enabling DNS server and Terminology: Update definition of Privacy-enabling DNS server and
moved normative definition to section 4. moved normative definition to section 4.
Section 5 and 6.3: Included discussion of the additional attacks Section 5 and 6.3: Included discussion of the additional attacks
possible when using meta-queries to bootstrap the DNS service possible when using meta-queries to bootstrap the DNS service
Section 5: Added sentence on why Opportunistic Profile may fallback Section 5: Added sentence on why Opportunistic Profile may fallback
for latency reasons. for latency reasons.
skipping to change at page 26, line 5 skipping to change at page 26, line 14
Section 7.3: Re-worked this section and the discussion of DHCP. Section 7.3: Re-worked this section and the discussion of DHCP.
Section 9: Removed unnecessary text, added condition on use of Section 9: Removed unnecessary text, added condition on use of
RFC7250 (Raw public keys). RFC7250 (Raw public keys).
Section 11.: More detail on padding policies. Section 11.: More detail on padding policies.
Numerous editorial corrections. Numerous editorial corrections.
B.2. -09 version B.3. -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.3. -08 version B.4. -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.4. -07 version B.5. -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.5. -06 version B.6. -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 27, line 13 skipping to change at page 27, line 22
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.6. -05 version B.7. -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.7. -04 version B.8. -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.8. -03 version B.9. -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.9. -02 version B.10. -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.10. -01 version B.11. -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.11. draft-ietf-dprive-dtls-and-tls-profiles-00 B.12. 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. 48 change blocks. 
77 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/