< draft-ietf-dane-smtp-with-dane-12.txt		draft-ietf-dane-smtp-with-dane-13.txt >
	DANE V. Dukhovni		DANE V. Dukhovni
	Internet-Draft Two Sigma		Internet-Draft Two Sigma
	Intended status: Standards Track W. Hardaker		Intended status: Standards Track W. Hardaker
	Expires: February 18, 2015 Parsons		Expires: April 29, 2015 Parsons
	August 17, 2014		October 26, 2014
	SMTP security via opportunistic DANE TLS		SMTP security via opportunistic DANE TLS
	draft-ietf-dane-smtp-with-dane-12		draft-ietf-dane-smtp-with-dane-13
	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 February 18, 2015.		This Internet-Draft will expire on April 29, 2015.
	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 50 ¶		skipping to change at page 2, line 50 ¶
	8.1. SNI support . . . . . . . . . . . . . . . . . . . . . . . 28		8.1. SNI support . . . . . . . . . . . . . . . . . . . . . . . 28
	8.2. Anonymous TLS cipher suites . . . . . . . . . . . . . . . 28		8.2. Anonymous TLS cipher suites . . . . . . . . . . . . . . . 28
	9. Operational Considerations . . . . . . . . . . . . . . . . . 29		9. Operational Considerations . . . . . . . . . . . . . . . . . 29
	9.1. Client Operational Considerations . . . . . . . . . . . . 29		9.1. Client Operational Considerations . . . . . . . . . . . . 29
	9.2. Publisher Operational Considerations . . . . . . . . . . 30		9.2. Publisher Operational Considerations . . . . . . . . . . 30
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 30		10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
	11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31		11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
	13.1. Normative References . . . . . . . . . . . . . . . . . . 31		13.1. Normative References . . . . . . . . . . . . . . . . . . 31
	13.2. Informative References . . . . . . . . . . . . . . . . . 32		13.2. Informative References . . . . . . . . . . . . . . . . . 33
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
	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 neither email addresses nor MX hostnames signal a		records and that neither email addresses nor MX hostnames signal a
	requirement for either secure or cleartext transport. Therefore,		requirement for either secure or cleartext transport. Therefore,
	skipping to change at page 23, line 5 ¶		skipping to change at page 23, line 5 ¶
	certificate chain presented in the TLS handshake server certificate		certificate chain presented in the TLS handshake server certificate
	message even when it is a self-signed root certificate. At this		message even when it is a self-signed root certificate. At this
	time, many SMTP servers are not configured with a comprehensive list		time, many SMTP servers are not configured with a comprehensive list
	of trust anchors, nor are they expected to at any point in the		of trust anchors, nor are they expected to at any point in the
	future. Some MTAs will ignore all locally trusted certificates when		future. Some MTAs will ignore all locally trusted certificates when
	processing usage DANE-TA(2) TLSA records. Thus even when the TA		processing usage DANE-TA(2) TLSA records. Thus even when the TA
	happens to be a public Certification Authority known to the SMTP		happens to be a public Certification Authority known to the SMTP
	client, authentication is likely to fail unless the TA certificate is		client, authentication is likely to fail unless the TA certificate is
	included in the TLS server certificate message.		included in the TLS server certificate message.
	TLSA records with selector Full(0) are discouraged. While these		TLSA records with matching type Full(0) are discouraged. While these
	potentially obviate the need to transmit the TA certificate in the		potentially obviate the need to transmit the TA certificate in the
	TLS server certificate message, client implementations may not be		TLS server certificate message, client implementations may not be
	able to augment the server certificate chain with the data obtained		able to augment the server certificate chain with the data obtained
	from DNS, especially when the TLSA record supplies a bare key		from DNS, especially when the TLSA record supplies a bare key
	(selector SPKI(1)). Since the server will need to transmit the TA		(selector SPKI(1)). Since the server will need to transmit the TA
	certificate in any case, server operators SHOULD publish TLSA records		certificate in any case, server operators SHOULD publish TLSA records
	with a selector other than Full(0) and avoid potential		with a matching type other than Full(0) and avoid potential
	interoperability issues with large TLSA records containing full		interoperability issues with large TLSA records containing full
	certificates or keys.		certificates or keys.
	TLSA Publishers employing DANE-TA(2) records SHOULD publish records		TLSA Publishers employing DANE-TA(2) records SHOULD publish records
	with a selector of Cert(0). Such TLSA records are associated with		with a selector of Cert(0). Such TLSA records are associated with
	the whole trust anchor certificate, not just with the trust anchor		the whole trust anchor certificate, not just with the trust anchor
	public key. In particular, the SMTP client SHOULD then apply any		public key. In particular, the SMTP client SHOULD then apply any
	relevant constraints from the trust anchor certificate, such as, for		relevant constraints from the trust anchor certificate, such as, for
	example, path length constraints.		example, path length constraints.
	skipping to change at page 30, line 18 ¶		skipping to change at page 30, line 18 ¶
	MUST include the TA certificate in their TLS server certificate		MUST include the TA certificate in their TLS server certificate
	chain, even when that TA certificate is a self-signed root		chain, even when that TA certificate is a self-signed root
	certificate.		certificate.
	TLSA Publishers MUST follow the guidelines in the "TLSA Publisher		TLSA Publishers MUST follow the guidelines in the "TLSA Publisher
	Requirements" section of [I-D.ietf-dane-ops].		Requirements" section of [I-D.ietf-dane-ops].
	TLSA Publishers SHOULD follow the TLSA publication size guidance		TLSA Publishers SHOULD follow the TLSA publication size guidance
	found in [I-D.ietf-dane-ops] under "DANE DNS Record Size Guidelines".		found in [I-D.ietf-dane-ops] under "DANE DNS Record Size Guidelines".
			TLSA Publishers SHOULD follow the TLSA record TTL and signature
			lifetime recommendations found in [I-D.ietf-dane-ops] under
			"Operational Considerations".
	10. Security Considerations		10. Security Considerations
	This protocol leverages DANE TLSA records to implement MITM resistant		This protocol leverages DANE TLSA records to implement MITM resistant
	opportunistic security ([I-D.dukhovni-opportunistic-security]) for		opportunistic security ([I-D.dukhovni-opportunistic-security]) for
	SMTP. For destination domains that sign their MX records and publish		SMTP. For destination domains that sign their MX records and publish
	signed TLSA records for their MX hostnames, this protocol allows		signed TLSA records for their MX hostnames, this protocol allows
	sending MTAs to securely discover both the availability of TLS and		sending MTAs to securely discover both the availability of TLS and
	how to authenticate the destination.		how to authenticate the destination.
	This protocol does not aim to secure all SMTP traffic, as that is not		This protocol does not aim to secure all SMTP traffic, as that is not
	skipping to change at page 33, line 6 ¶		skipping to change at page 33, line 10 ¶
	ITU-T X.690 (2002) | ISO/IEC 8825-1:2002, Information		ITU-T X.690 (2002) | ISO/IEC 8825-1:2002, Information
	technology - ASN.1 encoding rules: Specification of Basic		technology - ASN.1 encoding rules: Specification of Basic
	Encoding Rules (BER), Canonical Encoding Rules (CER) and		Encoding Rules (BER), Canonical Encoding Rules (CER) and
	Distinguished Encoding Rules (DER)", July 2002.		Distinguished Encoding Rules (DER)", July 2002.
	13.2. Informative References		13.2. Informative References
	[I-D.dukhovni-opportunistic-security]		[I-D.dukhovni-opportunistic-security]
	Dukhovni, V., "Opportunistic Security: Some Protection		Dukhovni, V., "Opportunistic Security: Some Protection
	Most of the Time", draft-dukhovni-opportunistic-		Most of the Time", draft-dukhovni-opportunistic-
	security-03 (work in progress), August 2014.		security-04 (work in progress), August 2014.
	[I-D.ietf-dane-srv]		[I-D.ietf-dane-srv]
	Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-		Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
	Based Authentication of Named Entities (DANE) TLSA Records		Based Authentication of Named Entities (DANE) TLSA Records
	with SRV Records", draft-ietf-dane-srv-07 (work in		with SRV Records", draft-ietf-dane-srv-08 (work in
	progress), July 2014.		progress), October 2014.
	[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July		[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July
	2009.		2009.
	[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",		[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
	STD 72, RFC 6409, November 2011.		STD 72, RFC 6409, November 2011.
	Authors' Addresses		Authors' Addresses
	Viktor Dukhovni		Viktor Dukhovni
End of changes. 9 change blocks.
	10 lines changed or deleted		14 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/