< draft-ietf-tls-dnssec-chain-extension-05.txt		draft-ietf-tls-dnssec-chain-extension-06.txt >
	TLS M. Shore		TLS M. Shore
	Internet-Draft Fastly		Internet-Draft Fastly
	Intended status: Standards Track R. Barnes		Intended status: Standards Track R. Barnes
	Expires: May 2, 2018 Mozilla		Expires: July 27, 2018 Mozilla
	S. Huque		S. Huque
	Salesforce		Salesforce
	W. Toorop		W. Toorop
	NLnet Labs		NLnet Labs
	October 29, 2017		January 23, 2018
	A DANE Record and DNSSEC Authentication Chain Extension for TLS		A DANE Record and DNSSEC Authentication Chain Extension for TLS
	draft-ietf-tls-dnssec-chain-extension-05		draft-ietf-tls-dnssec-chain-extension-06
	Abstract		Abstract
	This draft describes a new TLS extension for transport of a DNS		This draft describes a new TLS extension for transport of a DNS
	record set serialized with the DNSSEC signatures needed to		record set serialized with the DNSSEC signatures needed to
	authenticate that record set. The intent of this proposal is to		authenticate that record set. The intent of this proposal is to
	allow TLS clients to perform DANE authentication of a TLS server		allow TLS clients to perform DANE authentication of a TLS server
	without needing to perform additional DNS record lookups. It will		without needing to perform additional DNS record lookups. It will
	typically not be used for general DNSSEC validation of TLS endpoint		typically not be used for general DNSSEC validation of TLS endpoint
	names.		names.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 May 2, 2018.		This Internet-Draft will expire on July 27, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 32 ¶		skipping to change at page 2, line 32 ¶
	5. Caching and Regeneration of the Authentication Chain . . . . 8		5. Caching and Regeneration of the Authentication Chain . . . . 8
	6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 8		6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 8
	7. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . 9		7. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . 9
	8. Mandating use of this extension . . . . . . . . . . . . . . . 9		8. Mandating use of this extension . . . . . . . . . . . . . . . 9
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 10		9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	12.1. Normative References . . . . . . . . . . . . . . . . . . 10		12.1. Normative References . . . . . . . . . . . . . . . . . . 10
	12.2. Informative References . . . . . . . . . . . . . . . . . 11		12.2. Informative References . . . . . . . . . . . . . . . . . 11
	Appendix A. Updates from -01 and -02 . . . . . . . . . . . . . . 13		Appendix A. Updates from -01 and -02 . . . . . . . . . . . . . . 12
	Appendix B. Updates from -01 . . . . . . . . . . . . . . . . . . 13		Appendix B. Updates from -01 . . . . . . . . . . . . . . . . . . 12
	Appendix C. Updates from -00 . . . . . . . . . . . . . . . . . . 13		Appendix C. Updates from -00 . . . . . . . . . . . . . . . . . . 12
	Appendix D. Test vectors . . . . . . . . . . . . . . . . . . . . 13		Appendix D. Test vectors . . . . . . . . . . . . . . . . . . . . 13
	D.1. _443._tcp.www.example.com . . . . . . . . . . . . . . . . 15		D.1. _443._tcp.www.example.com . . . . . . . . . . . . . . . . 14
	D.2. _25._tcp.example.com wildcard . . . . . . . . . . . . . . 17		D.2. _25._tcp.example.com wildcard . . . . . . . . . . . . . . 16
	D.3. _443._tcp.www.example.org CNAME . . . . . . . . . . . . . 19		D.3. _443._tcp.www.example.org CNAME . . . . . . . . . . . . . 17
	D.4. _443._tcp.www.example.net DNAME . . . . . . . . . . . . . 21		D.4. _443._tcp.www.example.net DNAME . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Requirements Notation		1. Requirements Notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Introduction		2. Introduction
	This draft describes a new TLS [RFC5246] extension for transport of a		This draft describes a new TLS [RFC5246] extension for transport of a
	skipping to change at page 8, line 44 ¶		skipping to change at page 8, line 49 ¶
	6. Verification		6. Verification
	A TLS client making use of this specification, and which receives a		A TLS client making use of this specification, and which receives a
	DNSSEC authentication chain extension from a server, SHOULD use this		DNSSEC authentication chain extension from a server, SHOULD use this
	information to perform DANE authentication of the server. In order		information to perform DANE authentication of the server. In order
	to do this, it uses the mechanism specified by the DNSSEC protocol		to do this, it uses the mechanism specified by the DNSSEC protocol
	[RFC4035] [RFC5155]. This mechanism is sometimes implemented in a		[RFC4035] [RFC5155]. This mechanism is sometimes implemented in a
	DNSSEC validation engine or library.		DNSSEC validation engine or library.
			If the authentication chain is correctly verified, the client then
			performs DANE authentication of the server according to the DANE TLS
			protocol [RFC6698] [RFC7671].
	Clients MAY cache the server's validated TLS RRset or other validated		Clients MAY cache the server's validated TLS RRset or other validated
	portions of the chain as an optimization to save signature		portions of the chain as an optimization to save signature
	verification work for future connections. The period of such caching		verification work for future connections. The period of such caching
	MUST NOT exceed the TTL associated with those records.		MUST NOT exceed the TTL associated with those records.
	7. Trust Anchor Maintenance		7. Trust Anchor Maintenance
	The trust anchor may change periodically, e.g. when the operator of		The trust anchor may change periodically, e.g. when the operator of
	the trust anchor zone performs a DNSSEC key rollover. TLS clients		the trust anchor zone performs a DNSSEC key rollover. TLS clients
	using this specification MUST implement a mechanism to keep their		using this specification MUST implement a mechanism to keep their
	skipping to change at page 10, line 17 ¶		skipping to change at page 10, line 17 ¶
	The security considerations of the normatively referenced RFCs all		The security considerations of the normatively referenced RFCs all
	pertain to this extension. Since the server is delivering a chain of		pertain to this extension. Since the server is delivering a chain of
	DNS records and signatures to the client, it MUST rebuild the chain		DNS records and signatures to the client, it MUST rebuild the chain
	in accordance with TTL and signature expiration of the chain		in accordance with TTL and signature expiration of the chain
	components as described in Section 5. TLS clients need roughly		components as described in Section 5. TLS clients need roughly
	accurate time in order to properly authenticate these signatures.		accurate time in order to properly authenticate these signatures.
	This could be achieved by running a time synchronization protocol		This could be achieved by running a time synchronization protocol
	like NTP [RFC5905] or SNTP [RFC5905], which are already widely used		like NTP [RFC5905] or SNTP [RFC5905], which are already widely used
	today. TLS clients MUST support a mechanism to track and rollover		today. TLS clients MUST support a mechanism to track and rollover
	the trust anchor key, or be able to avail themselves of a service		the trust anchor key, or be able to avail themselves of a service
	that does this, as described in Section 7.		that does this, as described in Section 7. Security considerations
			related to mandating the use of this extension are described in
			Section 8.
	10. IANA Considerations		10. IANA Considerations
	This extension requires the registration of a new value in the TLS		This extension requires the registration of a new value in the TLS
	ExtensionsType registry. The value requested from IANA is 53. If		ExtensionsType registry. The value requested from IANA is 53. If
	the draft is adopted by the WG, the authors expect to make an early		the draft is adopted by the WG, the authors expect to make an early
	allocation request as specified in [RFC7120].		allocation request as specified in [RFC7120].
	11. Acknowledgments		11. Acknowledgments
	skipping to change at page 10, line 41 ¶		skipping to change at page 10, line 43 ¶
	discussions with and review from the following people: Viktor		discussions with and review from the following people: Viktor
	Dukhovni, Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, Patrick		Dukhovni, Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, Patrick
	McManus, Rick van Rein, Ilari Liusvaara, Gowri Visweswaran, Duane		McManus, Rick van Rein, Ilari Liusvaara, Gowri Visweswaran, Duane
	Wessels, Nico Williams, and Paul Wouters.		Wessels, Nico Williams, and Paul Wouters.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,		specification", STD 13, RFC 1035, November 1987.
	November 1987, <https://www.rfc-editor.org/info/rfc1035>.
	[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, March 1997.
	DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	editor.org/info/rfc2119>.
	[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Resource Records for the DNS Security Extensions",		Rose, "Resource Records for the DNS Security Extensions",
	RFC 4034, DOI 10.17487/RFC4034, March 2005,		RFC 4034, March 2005.
	<https://www.rfc-editor.org/info/rfc4034>.
	[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Protocol Modifications for the DNS Security		Rose, "Protocol Modifications for the DNS Security
	Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,		Extensions", RFC 4035, March 2005.
	<https://www.rfc-editor.org/info/rfc4035>.
	[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS		[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
	Security (DNSSEC) Hashed Authenticated Denial of		Security (DNSSEC) Hashed Authenticated Denial of
	Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,		Existence", RFC 5155, March 2008.
	<https://www.rfc-editor.org/info/rfc5155>.
	[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, August 2008.
	DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
	editor.org/info/rfc5246>.
	[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)		[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
	Extensions: Extension Definitions", RFC 6066,		Extension Definitions", RFC 6066, January 2011.
	DOI 10.17487/RFC6066, January 2011, <https://www.rfc-
	editor.org/info/rfc6066>.
	[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, August 2012.
	2012, <https://www.rfc-editor.org/info/rfc6698>.
	[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, <https://www.rfc-editor.org/info/rfc7671>.		October 2015, <http://www.rfc-editor.org/info/rfc7671>.
	12.2. Informative References		12.2. Informative References
	[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)		[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
	Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,		Trust Anchors", STD 74, RFC 5011, September 2007.
	September 2007, <https://www.rfc-editor.org/info/rfc5011>.
	[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,		[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
	"Network Time Protocol Version 4: Protocol and Algorithms		Time Protocol Version 4: Protocol and Algorithms
	Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,		Specification", RFC 5905, June 2010.
	<https://www.rfc-editor.org/info/rfc5905>.
	[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code		[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
	Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January		Points", BCP 100, RFC 7120, January 2014.
	2014, <https://www.rfc-editor.org/info/rfc7120>.
	[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,		[RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
	Weiler, S., and T. Kivinen, "Using Raw Public Keys in		T. Kivinen, "Using Raw Public Keys in Transport Layer
	Transport Layer Security (TLS) and Datagram Transport		Security (TLS) and Datagram Transport Layer Security
	Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,		(DTLS)", RFC 7250, June 2014.
	June 2014, <https://www.rfc-editor.org/info/rfc7250>.
	[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via		[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
	Opportunistic DNS-Based Authentication of Named Entities		Opportunistic DNS-Based Authentication of Named Entities
	(DANE) Transport Layer Security (TLS)", RFC 7672,		(DANE) Transport Layer Security (TLS)", RFC 7672, DOI
	DOI 10.17487/RFC7672, October 2015, <https://www.rfc-		10.17487/RFC7672, October 2015,
	editor.org/info/rfc7672>.		<http://www.rfc-editor.org/info/rfc7672>.
	[RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901,		[RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901, DOI
	DOI 10.17487/RFC7901, June 2016, <https://www.rfc-		10.17487/RFC7901, June 2016,
	editor.org/info/rfc7901>.		<http://www.rfc-editor.org/info/rfc7901>.
	[I-D.agl-dane-serializechain]		[I-D.agl-dane-serializechain]
	Langley, A., "Serializing DNS Records with DNSSEC		Langley, A., "Serializing DNS Records with DNSSEC
	Authentication", draft-agl-dane-serializechain-01 (work in		Authentication", draft-agl-dane-serializechain-01 (work in
	progress), July 2011.		progress), July 2011.
	[I-D.barnes-dane-uks]		[I-D.barnes-dane-uks]
	Barnes, R., Thomson, M., and E. Rescorla, "Unknown Key-		Barnes, R., Thomson, M., and E. Rescorla, "Unknown Key-
	Share Attacks on DNS-based Authentications of Named		Share Attacks on DNS-based Authentications of Named
	Entities (DANE)", draft-barnes-dane-uks-00 (work in		Entities (DANE)", draft-barnes-dane-uks-00 (work in
	skipping to change at page 13, line 24 ¶		skipping to change at page 12, line 39 ¶
	o Added section describing applicability to raw public keys		o Added section describing applicability to raw public keys
	o Softened language about record order		o Softened language about record order
	Appendix C. Updates from -00		Appendix C. Updates from -00
	o Edits based on comments from Rick van Rein		o Edits based on comments from Rick van Rein
	o Warning about not overloading X.509 wildcards on DNSSEC wildcards		o Warning about not overloading X.509 wildcards on DNSSEC wildcards
	(from V. Dukhovny)		(from V. Dukhovny)
	o Added MUST include negative proof on wildcards (from V. Dukhovny)		o Added MUST include negative proof on wildcards (from V. Dukhovny)
	o Removed "TODO" on allowing the server to deliver only one		o Removed "TODO" on allowing the server to deliver only one
	signature per RRset		signature per RRset
	o Added additional minor edits suggested by Viktor Dukhovny		o Added additional minor edits suggested by Viktor Dukhovny
	Appendix D. Test vectors		Appendix D. Test vectors
	The provided test vectors will authenticate the certificate used with		The provided test vectors will authenticate the certificate used with
	https://example.com/, https://example.net/ and https://example.org/		https://example.com/, https://example.net/ and https://example.org/
End of changes. 26 change blocks.
	56 lines changed or deleted		46 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/