< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/