draft-ietf-dprive-dtls-and-tls-profiles-02.txt   draft-ietf-dprive-dtls-and-tls-profiles-03.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: December 12, 2016 ACLU Expires: January 9, 2017 ACLU
T. Reddy T. Reddy
Cisco Cisco
June 10, 2016 July 8, 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-02 draft-ietf-dprive-dtls-and-tls-profiles-03
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 December 12, 2016. This Internet-Draft will expire on January 9, 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 33 skipping to change at page 2, line 33
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 . . . . . . . . . . . . . . . . 10
8.2. Direct configuration of name only . . . . . . . . . . . . 10 8.2. Direct configuration of name only . . . . . . . . . . . . 10
8.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Credential Verification . . . . . . . . . . . . . . . . . . . 12 9. Credential Verification . . . . . . . . . . . . . . . . . . . 12
9.1. X.509 Certificate Based Authentication . . . . . . . . . 12 9.1. X.509 Certificate Based Authentication . . . . . . . . . 12
9.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 13 9.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 13
9.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 13 9.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 13
10. Combined Credentials with SPKI Pinsets . . . . . . . . . . . 13 10. Combined Credentials with SPKI Pinsets . . . . . . . . . . . 14
11. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 14 11. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 14
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
13. Security Considerations . . . . . . . . . . . . . . . . . . . 15 13. Security Considerations . . . . . . . . . . . . . . . . . . . 15
13.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 15 13.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 15
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
15.1. Normative References . . . . . . . . . . . . . . . . . . 16 15.1. Normative References . . . . . . . . . . . . . . . . . . 16
15.2. Informative References . . . . . . . . . . . . . . . . . 17 15.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Server capability probing and caching by DNS clients 18 Appendix A. Server capability probing and caching by DNS clients 19
Appendix B. Changes between revisions . . . . . . . . . . . . . 19 Appendix B. Changes between revisions . . . . . . . . . . . . . 19
B.1. -02 version . . . . . . . . . . . . . . . . . . . . . . . 19 B.1. -03 version . . . . . . . . . . . . . . . . . . . . . . . 19
B.2. -01 version . . . . . . . . . . . . . . . . . . . . . . . 19 B.2. -02 version . . . . . . . . . . . . . . . . . . . . . . . 19
B.3. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 20 B.3. -01 version . . . . . . . . . . . . . . . . . . . . . . . 20
B.4. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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'
skipping to change at page 12, line 38 skipping to change at page 12, line 38
[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
keys trust with DNSSEC. However this requires a domain name which key trust with DNSSEC. However this requires the DNS client to have
must be obtained via a trusted source. a domain name for the DNS Privacy Server which must be obtained via a
trusted source.
This section assumes a solid understanding of both DANE [RFC6698] and
DANE Operations [RFC7671]. A few pertinent issues covered in these
documents are outlined here as useful pointers, but familiarity with
both these documents in their entirety is expected.
It is noted that [RFC6698] says It is noted that [RFC6698] says
"Clients that validate the DNSSEC signatures themselves MUST use "Clients that validate the DNSSEC signatures themselves MUST use
standard DNSSEC validation procedures. Clients that rely on standard DNSSEC validation procedures. Clients that rely on
another entity to perform the DNSSEC signature validation MUST use another entity to perform the DNSSEC signature validation MUST use
a secure mechanism between themselves and the validator." a secure mechanism between themselves and the validator."
The specific DANE record would take the form: It is noted that [RFC7671] covers the following topics:
o Section 4.1: Opportunistic Security and PKIX Usages and
Section 14: Security Considerations, which both discuss the use of
PKIX-TA(0) and PKIX-EE(1) for OS.
o Section 5: Certificate-Usage-Specific DANE Updates and Guidelines.
Specifically Section 5.1 which outlines the combination of
Certificate Usage DANE-EE(3) and Selector Usage SPKI(1) with Raw
Public Keys [RFC7250]. Section 5.1 also discusses the security
implications of this mode, for example, it discusses key lifetimes
and specifies that validity period enforcement is based solely on
the TLSA RRset properties for this case. [QUESTION: Should an
appendix be added with an example of how to use DANE without X.509
certificates?]
o Section 13: Operational Considerations, which discusses TLSA TTLs
and signature validity periods.
The specific DANE record for a DNS Privacy Server would take the
form:
_853._tcp.[server-domain-name] for TLS _853._tcp.[server-domain-name] for TLS
_853._udp.[server-domain-name] for DTLS _853._udp.[server-domain-name] for DTLS
9.2.1. Direct DNS Lookup 9.2.1. Direct DNS Lookup
The DNS client MAY choose to perform the DNS lookups to retrieve the The DNS client MAY choose to perform the DNS lookups to retrieve the
required DANE records itself. The DNS queries for such DANE records required DANE records itself. The DNS queries for such DANE records
MAY use opportunistic encryption or be in the clear to avoid trust MAY use opportunistic encryption or be in the clear to avoid trust
skipping to change at page 13, line 26 skipping to change at page 14, line 5
[I-D.ietf-tls-dnssec-chain-extension]. If the DNS server supports [I-D.ietf-tls-dnssec-chain-extension]. If the DNS server supports
this extension, it can provide the full chain to the client in the this extension, it can provide the full chain to the client in the
handshake. handshake.
If the DNS client offers the TLS DNSSEC Chain extension, it MUST be If the DNS client offers the TLS DNSSEC Chain extension, it MUST be
capable of validating the full DNSSEC authentication chain down to capable of validating the full DNSSEC authentication chain down to
the leaf. If the supplied DNSSEC chain does not validate, the client the leaf. If the supplied DNSSEC chain does not validate, the client
MUST ignore the DNSSEC chain and validate only via other supplied MUST ignore the DNSSEC chain and validate only via other supplied
credentials. credentials.
[ TODO: specify guidance for DANE parameters to be used here. For
example, a suggestion to use Certificate Usage of 3 (EE-DANE)
(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
from the verification path and allows for private certification ]
[ TODO: discuss combination of DNSSEC Chain Extension with cert
validation. Note that the combination depends on the Certificate
Usage value of the TLSA response. ]
10. Combined Credentials with SPKI Pinsets 10. Combined Credentials with SPKI Pinsets
The SPKI pinset profile described in [RFC7858] MAY be used with DNS- The SPKI pinset profile described in [RFC7858] 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
skipping to change at page 17, line 17 skipping to change at page 17, line 33
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>.
[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based
Authentication of Named Entities (DANE) Protocol: Updates
and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
October 2015, <http://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,
<http://www.rfc-editor.org/info/rfc7830>. <http://www.rfc-editor.org/info/rfc7830>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <http://www.rfc-editor.org/info/rfc7858>. 2016, <http://www.rfc-editor.org/info/rfc7858>.
15.2. Informative References 15.2. Informative References
skipping to change at page 19, line 18 skipping to change at page 19, line 41
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. -02 version B.1. -03 version
Section 9: Update DANE section with better references to RFC7671 and
RFC7250
B.2. -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.2. -01 version B.3. -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.3. draft-ietf-dprive-dtls-and-tls-profiles-00 B.4. 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. 15 change blocks. 
26 lines changed or deleted 53 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/