< draft-ietf-dane-smtp-with-dane-06.txt		draft-ietf-dane-smtp-with-dane-07.txt >
	DANE V. Dukhovni		DANE V. Dukhovni
	Internet-Draft Unaffiliated		Internet-Draft Unaffiliated
	Intended status: Standards Track W. Hardaker		Intended status: Standards Track W. Hardaker
	Expires: August 16, 2014 Parsons		Expires: August 18, 2014 Parsons
	February 12, 2014		February 14, 2014
	SMTP security via opportunistic DANE TLS		SMTP security via opportunistic DANE TLS
	draft-ietf-dane-smtp-with-dane-06		draft-ietf-dane-smtp-with-dane-07
	Abstract		Abstract
	This memo describes a downgrade-resistant protocol for SMTP transport		This memo describes a downgrade-resistant protocol for SMTP transport
	security between Mail Transfer Agents (MTAs) based on the DNS-Based		security between Mail Transfer Agents (MTAs) based on the DNS-Based
	Authentication of Named Entities (DANE) TLSA DNS record. Adoption of		Authentication of Named Entities (DANE) TLSA DNS record. Adoption of
	this protocol enables an incremental transition of the Internet email		this protocol enables an incremental transition of the Internet email
	backbone to one using encrypted and authenticated Transport Layer		backbone to one using encrypted and authenticated Transport Layer
	Security (TLS).		Security (TLS).
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 August 16, 2014.		This Internet-Draft will expire on August 18, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 37 ¶		skipping to change at page 2, line 37 ¶
	3. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 25		3. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 25
	4. Operational Considerations . . . . . . . . . . . . . . . . . 25		4. Operational Considerations . . . . . . . . . . . . . . . . . 25
	4.1. Client Operational Considerations . . . . . . . . . . . . 25		4.1. Client Operational Considerations . . . . . . . . . . . . 25
	4.2. Publisher Operational Considerations . . . . . . . . . . 25		4.2. Publisher Operational Considerations . . . . . . . . . . 25
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 26		5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 26		6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 26
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
	8.1. Normative References . . . . . . . . . . . . . . . . . . 27		8.1. Normative References . . . . . . . . . . . . . . . . . . 27
	8.2. Informative References . . . . . . . . . . . . . . . . . 28		8.2. Informative References . . . . . . . . . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
	1. Introduction		1. Introduction
	This memo specifies a new connection security model for Message		This memo specifies a new connection security model for Message
	Transfer Agents (MTAs). This model is motivated by key features of		Transfer Agents (MTAs). This model is motivated by key features of
	inter-domain SMTP delivery, in particular the fact that the		inter-domain SMTP delivery, in particular the fact that the
	destination server is selected indirectly via DNS Mail Exchange (MX)		destination server is selected indirectly via DNS Mail Exchange (MX)
	records and that with MTA to MTA SMTP the use of TLS is generally		records and that with MTA to MTA SMTP the use of TLS is generally
	opportunistic.		opportunistic.
	We note that the SMTP protocol is also used between Message User		We note that the SMTP protocol is also used between Message User
	Agents (MUAs) and Message Submission Agents (MSAs). In [RFC6186] a		Agents (MUAs) and Message Submission Agents (MSAs) [RFC6409]. In
	protocol is specified that enables an MUA to dynamically locate the		[RFC6186] a protocol is specified that enables an MUA to dynamically
	MSA based on the user's email address. SMTP connection security		locate the MSA based on the user's email address. SMTP connection
	requirements for MUAs implementing [RFC6186] are largely analogous to		security requirements for MUAs implementing [RFC6186] are largely
	connection security requirements for MTAs, and this specification		analogous to connection security requirements for MTAs, and this
	could be applied largely verbatim with DNS MX records replaced by		specification could be applied largely verbatim with DNS MX records
	corresponding DNS Service (SRV) records.		replaced by corresponding DNS Service (SRV) records
			[I-D.ietf-dane-srv].
	However, until MUAs begin to adopt the dynamic configuration		However, until MUAs begin to adopt the dynamic configuration
	mechanisms of [RFC6186] they are adequately served by more		mechanisms of [RFC6186] they are adequately served by more
	traditional static TLS security policies. This document will not		traditional static TLS security policies. This document will not
	discuss the MUA use case further, leaving specification of DANE TLS		discuss the MUA use case further, leaving specification of DANE TLS
	for MUAs to future documents that focus specifically on SMTP security		for MUAs to future documents that focus specifically on SMTP security
	between MUAs and MSAs. The rest of this memo will focus on securing		between MUAs and MSAs. The rest of this memo will focus on securing
	MTA to MTA SMTP connections.		MTA to MTA SMTP connections.
	1.1. Terminology		1.1. Terminology
	skipping to change at page 5, line 21 ¶		skipping to change at page 5, line 24 ¶
	The TLS protocol enables secure TCP communication. In the context of		The TLS protocol enables secure TCP communication. In the context of
	this memo, channel security is assumed to be provided by TLS. Used		this memo, channel security is assumed to be provided by TLS. Used
	without authentication, TLS provides only privacy protection against		without authentication, TLS provides only privacy protection against
	eavesdropping attacks. With authentication, TLS also provides data		eavesdropping attacks. With authentication, TLS also provides data
	integrity protection to guard against man-in-the-middle (MITM)		integrity protection to guard against man-in-the-middle (MITM)
	attacks.		attacks.
	1.3. SMTP channel security		1.3. SMTP channel security
	With HTTPS, Transport Layer Security (TLS) employs X.509 certificates		With HTTPS, Transport Layer Security (TLS) employs X.509 certificates
	issued by one of the many Certificate Authorities (CAs) bundled with		[RFC5280] issued by one of the many Certificate Authorities (CAs)
	popular web browsers to allow users to authenticate their "secure"		bundled with popular web browsers to allow users to authenticate
	websites. Before we specify a new DANE TLS security model for SMTP,		their "secure" websites. Before we specify a new DANE TLS security
	we will explain why a new security model is needed. In the process,		model for SMTP, we will explain why a new security model is needed.
	we will explain why the familiar HTTPS security model is inadequate		In the process, we will explain why the familiar HTTPS security model
	to protect inter-domain SMTP traffic.		is inadequate to protect inter-domain SMTP traffic.
	The subsections below outline four key problems with applying		The subsections below outline four key problems with applying
	traditional PKI to SMTP that are addressed by this specification.		traditional PKI to SMTP that are addressed by this specification.
	Since SMTP channel security policy is not explicitly specified in		Since SMTP channel security policy is not explicitly specified in
	either the recipient address or the MX record, a new signaling		either the recipient address or the MX record, a new signaling
	mechanism is required to indicate when channel security is possible		mechanism is required to indicate when channel security is possible
	and should be used. The publication of TLSA records allows server		and should be used. The publication of TLSA records allows server
	operators to securely signal to SMTP clients that TLS is available		operators to securely signal to SMTP clients that TLS is available
	and should be used. DANE TLSA makes it possible to simultaneously		and should be used. DANE TLSA makes it possible to simultaneously
	discover which destination domains support secure delivery via TLS		discover which destination domains support secure delivery via TLS
	skipping to change at page 8, line 48 ¶		skipping to change at page 8, line 45 ¶
	requirements needed to avoid downgrade attacks when using		requirements needed to avoid downgrade attacks when using
	opportunistic DANE TLS.		opportunistic DANE TLS.
	A DNS lookup may signal an error or return a definitive answer. A		A DNS lookup may signal an error or return a definitive answer. A
	security-aware resolver must be used for this specification.		security-aware resolver must be used for this specification.
	Security-aware resolvers will indicate the security status of a DNS		Security-aware resolvers will indicate the security status of a DNS
	RRset with one of four possible values defined in Section 4.3 of		RRset with one of four possible values defined in Section 4.3 of
	[RFC4035]: "secure", "insecure", "bogus" and "indeterminate". In		[RFC4035]: "secure", "insecure", "bogus" and "indeterminate". In
	[RFC4035] the meaning of the "indeterminate" security status is:		[RFC4035] the meaning of the "indeterminate" security status is:
	An RRset for which the resolver is not able to determine whether		An RRset for which the resolver is not able to determine whether
	the RRset should be signed, as the resolver is not able to obtain		the RRset should be signed, as the resolver is not able to obtain
	the necessary DNSSEC RRs. This can occur when the security-aware		the necessary DNSSEC RRs. This can occur when the security-aware
	resolver is not able to contact security-aware name servers for		resolver is not able to contact security-aware name servers for
	the relevant zones.		the relevant zones.
	Note, the "indeterminate" security status has a conflicting		Note, the "indeterminate" security status has a conflicting
	definition in section 5 of [RFC4033].		definition in section 5 of [RFC4033].
	There is no trust anchor that would indicate that a specific		There is no trust anchor that would indicate that a specific
	portion of the tree is secure.		portion of the tree is secure.
	SMTP clients following this specification SHOULD NOT distinguish		SMTP clients following this specification SHOULD NOT distinguish
	between "insecure" and "indeterminate" in the [RFC4033] sense. Both		between "insecure" and "indeterminate" in the [RFC4033] sense. Both
	"insecure" and RFC4033 "indeterminate" are handled identically: in		"insecure" and RFC4033 "indeterminate" are handled identically: in
	either case unvalidated data for the query domain is all that is and		either case unvalidated data for the query domain is all that is and
	can be available, and authentication using the data is impossible.		can be available, and authentication using the data is impossible.
	In what follows, when we say "insecure", we include also DNS results		In what follows, when we say "insecure", we include also DNS results
	for domains that lie in a portion of the DNS tree for which there is		for domains that lie in a portion of the DNS tree for which there is
	no applicable trust anchor. With the DNS root zone signed, we expect		no applicable trust anchor. With the DNS root zone signed, we expect
	that validating resolvers used by Internet-facing MTAs will be		that validating resolvers used by Internet-facing MTAs will be
	skipping to change at page 9, line 41 ¶		skipping to change at page 9, line 41 ¶
	resolver does signal an RFC4035 "indeterminate" security status, this		resolver does signal an RFC4035 "indeterminate" security status, this
	MUST be treated by the SMTP client as though a "bogus" or error		MUST be treated by the SMTP client as though a "bogus" or error
	result had been returned.		result had been returned.
	An MTA making use of a non-validating security-aware stub resolver		An MTA making use of a non-validating security-aware stub resolver
	MAY use the stub resolver's ability, if available, to signal DNSSEC		MAY use the stub resolver's ability, if available, to signal DNSSEC
	validation status based on information the stub resolver has learned		validation status based on information the stub resolver has learned
	from an upstream validating recursive resolver. In accordance with		from an upstream validating recursive resolver. In accordance with
	section 4.9.3 of [RFC4035]:		section 4.9.3 of [RFC4035]:
	... a security-aware stub resolver MUST NOT place any reliance on		... a security-aware stub resolver MUST NOT place any reliance on
	signature validation allegedly performed on its behalf, except		signature validation allegedly performed on its behalf, except
	when the security-aware stub resolver obtained the data in question		when the security-aware stub resolver obtained the data in question
	from a trusted security-aware recursive name server via a secure		from a trusted security-aware recursive name server via a secure
	channel.		channel.
	To avoid much repetition in the text below, we will pause to explain		To avoid much repetition in the text below, we will pause to explain
	the handling of "bogus" or "indeterminate" DNSSEC query responses.		the handling of "bogus" or "indeterminate" DNSSEC query responses.
	These are not necessarily the result of a malicious actor; they can,		These are not necessarily the result of a malicious actor; they can,
	for example, occur when network packets are corrupted or lost in		for example, occur when network packets are corrupted or lost in
	transit. Therefore, "bogus" or "indeterminate" replies are equated		transit. Therefore, "bogus" or "indeterminate" replies are equated
	in this memo with lookup failure.		in this memo with lookup failure.
	There is an important non-failure condition we need to highlight in		There is an important non-failure condition we need to highlight in
	addition to the obvious case of the DNS client obtaining a non-empty		addition to the obvious case of the DNS client obtaining a non-empty
	skipping to change at page 12, line 39 ¶		skipping to change at page 12, line 39 ¶
	TLS for one or more destinations. The choice to disable DANE TLS		TLS for one or more destinations. The choice to disable DANE TLS
	security should not be made lightly. Every reasonable effort should		security should not be made lightly. Every reasonable effort should
	be made to determine that problems with mail delivery are the result		be made to determine that problems with mail delivery are the result
	of an operational error, and not an attack. A fallback strategy may		of an operational error, and not an attack. A fallback strategy may
	be to configure explicit out-of-band TLS security settings if		be to configure explicit out-of-band TLS security settings if
	supported by the sending MTA.		supported by the sending MTA.
	A note about DNAME aliases: a query for a domain name whose ancestor		A note about DNAME aliases: a query for a domain name whose ancestor
	domain is a DNAME alias returns the DNAME RR for the ancestor domain,		domain is a DNAME alias returns the DNAME RR for the ancestor domain,
	along with a CNAME that maps the query domain to the corresponding		along with a CNAME that maps the query domain to the corresponding
	sub-domain of the target domain of the DNAME alias. Therefore,		sub-domain of the target domain of the DNAME alias [RFC6672].
	whenever we speak of CNAME aliases, we implicitly allow for the		Therefore, whenever we speak of CNAME aliases, we implicitly allow
	possibility that the alias in question is the result of an ancestor		for the possibility that the alias in question is the result of an
	domain DNAME record. Consequently, no explicit support for DNAME		ancestor domain DNAME record. Consequently, no explicit support for
	records is needed in SMTP software, it is sufficient to process the		DNAME records is needed in SMTP software, it is sufficient to process
	resulting CNAME aliases. DNAME records only require special		the resulting CNAME aliases. DNAME records only require special
	processing in the validating stub-resolver library that checks the		processing in the validating stub-resolver library that checks the
	integrity of the combined DNAME + CNAME reply. When DNSSEC		integrity of the combined DNAME + CNAME reply. When DNSSEC
	validation is handled by a local caching resolver, rather than the		validation is handled by a local caching resolver, rather than the
	MTA itself, even that part of the DNAME support logic is outside the		MTA itself, even that part of the DNAME support logic is outside the
	MTA.		MTA.
	When the original next-hop destination is an address literal, rather		When the original next-hop destination is an address literal, rather
	than a DNS domain, DANE TLS does not apply. Delivery proceeds using		than a DNS domain, DANE TLS does not apply. Delivery proceeds using
	any relevant security policy configured by the MTA administrator.		any relevant security policy configured by the MTA administrator.
	Similarly, when an MX RRset incorrectly lists an network address in		Similarly, when an MX RRset incorrectly lists an network address in
	skipping to change at page 17, line 9 ¶		skipping to change at page 17, line 9 ¶
	name used in peer certificate name checks.		name used in peer certificate name checks.
	Note, shared end entity certificate associations expose the		Note, shared end entity certificate associations expose the
	publishing domain to substitution attacks, where an MITM attacker can		publishing domain to substitution attacks, where an MITM attacker can
	reroute traffic to a different server that shares the same end entity		reroute traffic to a different server that shares the same end entity
	certificate. Such shared end entity records should be avoided unless		certificate. Such shared end entity records should be avoided unless
	the servers in question are interchangeable.		the servers in question are interchangeable.
	For example, given the DNSSEC validated records below:		For example, given the DNSSEC validated records below:
	example.com. IN MX 0 mail.example.com.		example.com. IN MX 0 mail.example.com.
	example.com. IN MX 0 mail2.example.com.		example.com. IN MX 0 mail2.example.com.
	_25._tcp.mail.example.com. IN CNAME tlsa211._dane.example.com.		_25._tcp.mail.example.com. IN CNAME tlsa211._dane.example.com.
	_25._tcp.mail2.example.com. IN CNAME tlsa211._dane.example.com.		_25._tcp.mail2.example.com. IN CNAME tlsa211._dane.example.com.
	tlsa211._dane.example.com. IN TLSA 2 1 1 e3b0c44298fc1c14....		tlsa211._dane.example.com. IN TLSA 2 1 1 e3b0c44298fc1c14....
	The SMTP servers mail.example.com and mail2.example.com will be		The SMTP servers mail.example.com and mail2.example.com will be
	expected to have certificates issued under a common trust anchor, but		expected to have certificates issued under a common trust anchor, but
	each MX hostname's TLSA base domain remains unchanged despite the		each MX hostname's TLSA base domain remains unchanged despite the
	above CNAME records. Each SMTP server's certificate subject name (or		above CNAME records. Each SMTP server's certificate subject name (or
	one of the subject alternative names) is expected to match either the		one of the subject alternative names) is expected to match either the
	corresponding MX hostname or else "example.com".		corresponding MX hostname or else "example.com".
	If, during TLSA resolution (including possible CNAME indirection), at		If, during TLSA resolution (including possible CNAME indirection), at
	least one "secure" TLSA record is found (even if not usable because		least one "secure" TLSA record is found (even if not usable because
	skipping to change at page 21, line 27 ¶		skipping to change at page 21, line 27 ¶
	domain MUST also be accepted.		domain MUST also be accepted.
	Accepting certificates with the original next-hop domain in addition		Accepting certificates with the original next-hop domain in addition
	to the MX hostname allows a domain with multiple MX hostnames to		to the MX hostname allows a domain with multiple MX hostnames to
	field a single certificate bearing a single domain name (i.e., the		field a single certificate bearing a single domain name (i.e., the
	email domain) across all the SMTP servers. This also aids inter-		email domain) across all the SMTP servers. This also aids inter-
	operability with pre-DANE SMTP clients that are configured to look		operability with pre-DANE SMTP clients that are configured to look
	for the email domain name in server certificates. For example, with		for the email domain name in server certificates. For example, with
	"secure" DNS records as below:		"secure" DNS records as below:
	exchange.example.org. IN CNAME mail.example.org.		exchange.example.org. IN CNAME mail.example.org.
	mail.example.org. IN CNAME example.com.		mail.example.org. IN CNAME example.com.
	example.com. IN MX 10 mx10.example.com.		example.com. IN MX 10 mx10.example.com.
	example.com. IN MX 15 mx15.example.com.		example.com. IN MX 15 mx15.example.com.
	example.com. IN MX 20 mx20.example.com.		example.com. IN MX 20 mx20.example.com.
	;		;
	mx10.example.com. IN A 192.0.2.10		mx10.example.com. IN A 192.0.2.10
	_25._tcp.mx10.example.com. IN TLSA 2 0 1 ...		_25._tcp.mx10.example.com. IN TLSA 2 0 1 ...
	;		;
	mx15.example.com. IN CNAME mxbackup.example.com.		mx15.example.com. IN CNAME mxbackup.example.com.
	mxbackup.example.com. IN A 192.0.2.15		mxbackup.example.com. IN A 192.0.2.15
	; _25._tcp.mxbackup.example.com. IN TLSA ? (NXDOMAIN)		; _25._tcp.mxbackup.example.com. IN TLSA ? (NXDOMAIN)
	_25._tcp.mx15.example.com. IN TLSA 2 0 1 ...		_25._tcp.mx15.example.com. IN TLSA 2 0 1 ...
	;		;
	mx20.example.com. IN CNAME mxbackup.example.net.		mx20.example.com. IN CNAME mxbackup.example.net.
	mxbackup.example.net. IN A 198.51.100.20		mxbackup.example.net. IN A 198.51.100.20
	_25._tcp.mxbackup.example.net. IN TLSA 2 0 1 ...		_25._tcp.mxbackup.example.net. IN TLSA 2 0 1 ...
	Certificate name checks for delivery of mail to exchange.example.org		Certificate name checks for delivery of mail to exchange.example.org
	via any of the associated SMTP servers MUST accept at least the names		via any of the associated SMTP servers MUST accept at least the names
	"exchange.example.org" and "example.com", which are respectively the		"exchange.example.org" and "example.com", which are respectively the
	original and fully expanded next-hop domain. When the SMTP server is		original and fully expanded next-hop domain. When the SMTP server is
	mx10.example.com, name checks MUST accept the TLSA base domain		mx10.example.com, name checks MUST accept the TLSA base domain
	"mx10.example.com". If, despite the fact that MX hostnames are		"mx10.example.com". If, despite the fact that MX hostnames are
	required to not be aliases, the MTA supports delivery via		required to not be aliases, the MTA supports delivery via
	"mx15.example.com" or "mx20.example.com" then name checks MUST accept		"mx15.example.com" or "mx20.example.com" then name checks MUST accept
	the respective TLSA base domains "mx15.example.com" and		the respective TLSA base domains "mx15.example.com" and
	skipping to change at page 27, line 26 ¶		skipping to change at page 27, line 26 ¶
	valuable review comments. Thanks also to Wietse Venema who created		valuable review comments. Thanks also to Wietse Venema who created
	Postfix, and whose advice and feedback were essential to the		Postfix, and whose advice and feedback were essential to the
	development of the Postfix DANE implementation.		development of the Postfix DANE implementation.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-dane-ops]		[I-D.ietf-dane-ops]
	Dukhovni, V. and W. Hardaker, "DANE TLSA implementation		Dukhovni, V. and W. Hardaker, "DANE TLSA implementation
	and operational guidance", draft-ietf-dane-ops-00 (work in		and operational guidance", draft-ietf-dane-ops-02 (work in
	progress), October 2013.		progress), January 2014.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, November 1987.		specification", STD 13, RFC 1035, November 1987.
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over		[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
	Transport Layer Security", RFC 3207, February 2002.		Transport Layer Security", RFC 3207, February 2002.
	skipping to change at page 28, line 25 ¶		skipping to change at page 28, line 25 ¶
	[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, March 2011.		Security (TLS)", RFC 6125, March 2011.
	[RFC6186] Daboo, C., "Use of SRV Records for Locating Email		[RFC6186] Daboo, C., "Use of SRV Records for Locating Email
	Submission/Access Services", RFC 6186, March 2011.		Submission/Access Services", RFC 6186, March 2011.
	[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
	STD 72, RFC 6409, November 2011.
	[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the		[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
	DNS", RFC 6672, June 2012.		DNS", RFC 6672, June 2012.
	[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, August 2012.		Protocol: TLSA", RFC 6698, August 2012.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-dane-registry-acronyms]		[I-D.ietf-dane-registry-acronyms]
	Gudmundsson, O., "Adding acronyms to simplify DANE		Gudmundsson, O., "Adding acronyms to simplify DANE
	conversations", draft-ietf-dane-registry-acronyms-01 (work		conversations", draft-ietf-dane-registry-acronyms-03 (work
	in progress), October 2013.		in progress), January 2014.
	[I-D.ietf-dane-smtp]
	Finch, T., "Secure SMTP using DNS-Based Authentication of
	Named Entities (DANE) TLSA records.", draft-ietf-dane-
	smtp-01 (work in progress), February 2013.
	[I-D.ietf-dane-srv]		[I-D.ietf-dane-srv]
	Finch, T., "Using DNS-Based Authentication of Named		Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
	Entities (DANE) TLSA records with SRV and MX records.",		Based Authentication of Named Entities (DANE) TLSA records
	draft-ietf-dane-srv-02 (work in progress), February 2013.		with SRV and MX records.", draft-ietf-dane-srv-05 (work in
			progress), February 2014.
	[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July		[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July
	2009.		2009.
	[RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based		[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
	Authentication of Named Entities (DANE)", RFC 6394,		STD 72, RFC 6409, November 2011.
	October 2011.
	[RFC6895] Eastlake, D., "Domain Name System (DNS) IANA
	Considerations", BCP 42, RFC 6895, April 2013.
	Authors' Addresses		Authors' Addresses
	Viktor Dukhovni		Viktor Dukhovni
	Unaffiliated		Unaffiliated
	Email: ietf-dane@dukhovni.org		Email: ietf-dane@dukhovni.org
	Wes Hardaker		Wes Hardaker
	Parsons		Parsons
	P.O. Box 382		P.O. Box 382
	Davis, CA 95617		Davis, CA 95617
	US		US
End of changes. 18 change blocks.
	80 lines changed or deleted		69 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/