< draft-ietf-dane-smime-11.txt		draft-ietf-dane-smime-12.txt >
	Network Working Group P. Hoffman		Network Working Group P. Hoffman
	Internet-Draft ICANN		Internet-Draft ICANN
	Intended status: Experimental J. Schlyter		Intended status: Experimental J. Schlyter
	Expires: January 9, 2017 Kirei AB		Expires: February 1, 2017 Kirei AB
	July 8, 2016		July 31, 2016
	Using Secure DNS to Associate Certificates with Domain Names For S/MIME		Using Secure DNS to Associate Certificates with Domain Names For S/MIME
	draft-ietf-dane-smime-11		draft-ietf-dane-smime-12
	Abstract		Abstract
	This document describes how to use secure DNS to associate an S/MIME		This document describes how to use secure DNS to associate an S/MIME
	user's certificate with the intended domain name, similar to the way		user's certificate with the intended domain name, similar to the way
	that DANE (RFC 6698) does for TLS.		that DANE (RFC 6698) does for TLS.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 January 9, 2017.		This Internet-Draft will expire on February 1, 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
	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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. The SMIMEA Resource Record . . . . . . . . . . . . . . . . . 3		1.2. Experiment Goal . . . . . . . . . . . . . . . . . . . . . 3
	3. Email Addresses in Domain Names for S/MIME Certificate		2. The SMIMEA Resource Record . . . . . . . . . . . . . . . . . 4
	Associations . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Location of the SMIMEA Record . . . . . . . . . . . . . . . . 4
	4. Email Address Variants and Internationalization		4. Email Address Variants and Internationalization
	Considerations . . . . . . . . . . . . . . . . . . . . . . . 4		Considerations . . . . . . . . . . . . . . . . . . . . . . . 5
	5. Mandatory-to-Implement Features . . . . . . . . . . . . . . . 5		5. Mandatory-to-Implement Features . . . . . . . . . . . . . . . 6
	6. Application Use of S/MIME Certificate Associations . . . . . 5		6. Application Use of S/MIME Certificate Associations . . . . . 6
	7. Certificate Size and DNS . . . . . . . . . . . . . . . . . . 6		7. Certificate Size and DNS . . . . . . . . . . . . . . . . . . 6
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 6		9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	9.1. Email Address Information Leak . . . . . . . . . . . . . 7		9.1. Response Size . . . . . . . . . . . . . . . . . . . . . . 8
			9.2. Email Address Information Leak . . . . . . . . . . . . . 8
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	S/MIME [RFC5751] messages often contain a certificate (some messages		S/MIME [RFC5751] messages often contain a certificate (some messages
	contain more than one certificate). These certificates assist in		contain more than one certificate). These certificates assist in
	authenticating the sender of the message and can be used for		authenticating the sender of the message and can be used for
	encrypting messages that will be sent in reply. In order for the S/		encrypting messages that will be sent in reply. In order for the S/
	MIME receiver to authenticate that a message is from the sender who		MIME receiver to authenticate that a message is from the sender who
	is identified in the message, the receiver's mail user agent (MUA)		is identified in the message, the receiver's mail user agent (MUA)
	must validate that this certificate is associated with the purported		must validate that this certificate is associated with the purported
	skipping to change at page 3, line 19 ¶		skipping to change at page 3, line 20 ¶
	1.1. Terminology		1.1. Terminology
	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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	This document also makes use of standard PKIX, DNSSEC, and S/MIME		This document also makes use of standard PKIX, DNSSEC, and S/MIME
	terminology. See PKIX [RFC5280], DNSSEC [RFC4033], [RFC4034],		terminology. See PKIX [RFC5280], DNSSEC [RFC4033], [RFC4034],
	[RFC4035], and SMIME [RFC5751] for these terms.		[RFC4035], and SMIME [RFC5751] for these terms.
			1.2. Experiment Goal
			This specification is one experiment in improving access to public
			keys for end-to-end email security. There are a range of ways in
			which this can reasonably be done for OpenPGP or S/MIME, for example,
			using the DNS, or SMTP, or HTTP. Proposals for each of these have
			been made with various levels of support in terms of implementation
			and deployment. For each such experiment, specifications such as
			this will enable experiments to be carried out that may succeed or
			that may uncover technical or other impediments to large- or small-
			scale deployments. The IETF encourages those implementing and
			deploying such experiments to publicly document their experiences so
			that future specifications in this space can benefit.
			This document defines an RRtype whose use is Experimental. The goal
			of the experiment is to see whether encrypted email usage will
			increase if an automated discovery method is available to MTAs and
			MUAs to help the end user with email encryption key management.
			It is unclear if this RRtype will scale to some of the larger email
			service deployments. Concerns have been raised about the size of the
			SMIMEA record and the size of the resulting DNS zone files. This
			experiment hopefully will give the working group some insight into
			whether or not this is a problem.
			If the experiment is successful, it is expected that the findings of
			the experiment will result in an updated document for standards track
			approval.
	2. The SMIMEA Resource Record		2. The SMIMEA Resource Record
	The SMIMEA DNS resource record (RR) is used to associate an end		The SMIMEA DNS resource record (RR) is used to associate an end
	entity certificate or public key with the associated email address,		entity certificate or public key with the associated email address,
	thus forming a "SMIMEA certificate association". The semantics of		thus forming a "SMIMEA certificate association". The semantics of
	how the SMIMEA resource record is interpreted are given later in this		how the SMIMEA resource record is interpreted are given later in this
	document. Note that the information returned in the SMIMEA record		document. Note that the information returned in the SMIMEA record
	might be for the end entity certificate, or it might be for the trust		might be for the end entity certificate, or it might be for the trust
	anchor or an intermediate certificate.		anchor or an intermediate certificate.
	The type value for the SMIMEA RRtype is defined in Section 8. The		The type value for the SMIMEA RRtype is defined in Section 8. The
	SMIMEA resource record is class independent. The SMIMEA resource		SMIMEA resource record is class independent.
	record has no special TTL requirements.
	The SMIMEA wire format and presentation format are the same as for		The SMIMEA wire format and presentation format are the same as for
	the TLSA record as described in section 2.1 of RFC 6698. The		the TLSA record as described in section 2.1 of RFC 6698. The
	certificate usage field, the selector field, and the matching type		certificate usage field, the selector field, and the matching type
	field have the same format; the semantics are also the same except		field have the same format; the semantics are also the same except
	where RFC 6698 talks about TLS at the target protocol for the		where RFC 6698 talks about TLS at the target protocol for the
	certificate information.		certificate information.
	3. Email Addresses in Domain Names for S/MIME Certificate Associations		3. Location of the SMIMEA Record
	The DNS does not allow the use of all characters that are supported		The DNS does not allow the use of all characters that are supported
	in the "local-part" of email addresses as defined in [RFC5322] and		in the "local-part" of email addresses as defined in [RFC5322] and
	[RFC6530]. Therefore, email addresses are mapped into DNS using the		[RFC6530]. Therefore, email addresses are mapped into DNS using the
	following method:		following method:
	o The "left-hand side" of the email address, called the "local-part"		o The "left-hand side" of the email address, called the "local-part"
	in both the mail message format definition [RFC5322] and in the		in both the mail message format definition [RFC5322] and in the
	specification for internationalized email [RFC6530]) is encoded in		specification for internationalized email [RFC6530]) is encoded in
	UTF-8 (or its subset ASCII). If the local-part is written in		UTF-8 (or its subset ASCII). If the local-part is written in
	skipping to change at page 5, line 38 ¶		skipping to change at page 6, line 24 ¶
	5. Mandatory-to-Implement Features		5. Mandatory-to-Implement Features
	S/MIME MUAs conforming to this specification MUST be able to		S/MIME MUAs conforming to this specification MUST be able to
	correctly interpret SMIMEA records with certificate usages 0, 1, 2,		correctly interpret SMIMEA records with certificate usages 0, 1, 2,
	and 3. S/MIME MUAs conforming to this specification MUST be able to		and 3. S/MIME MUAs conforming to this specification MUST be able to
	compare a certificate association with a certificate offered by		compare a certificate association with a certificate offered by
	another S/MIME MUA using selector types 0 and 1, and matching type 0		another S/MIME MUA using selector types 0 and 1, and matching type 0
	(no hash used) and matching type 1 (SHA-256), and SHOULD be able to		(no hash used) and matching type 1 (SHA-256), and SHOULD be able to
	make such comparisons with matching type 2 (SHA-512).		make such comparisons with matching type 2 (SHA-512).
			S/MIME MUAs conforming to this specification MUST be able to
			interpret any S/MIME capabilities (defined in [RFC4262]) in any
			certificates that it receives through SMIMEA records.
	6. Application Use of S/MIME Certificate Associations		6. Application Use of S/MIME Certificate Associations
	The SMIMEA record allows an application or service to obtain an S/		The SMIMEA record allows an application or service to obtain an S/
	MIME certificate or public key and use it for verifying a digital		MIME certificate or public key and use it for verifying a digital
	signature or encrypting a message to the public key. The DNS answer		signature or encrypting a message to the public key. The DNS answer
	MUST pass DNSSEC validation; if DNSSEC validation reaches any state		MUST pass DNSSEC validation; if DNSSEC validation reaches any state
	other than "Secure" (as specified in [RFC4035]), the DNSSEC		other than "Secure" (as specified in [RFC4035]), the DNSSEC
	validation MUST be treated as a failure.		validation MUST be treated as a failure.
	If no S/MIME certificates are known for an email address, an SMIMEA		If no S/MIME certificates are known for an email address, an SMIMEA
	skipping to change at page 7, line 26 ¶		skipping to change at page 8, line 13 ¶
	message in plaintext.		message in plaintext.
	Anyone who can obtain a DNSSEC private key of a domain name via		Anyone who can obtain a DNSSEC private key of a domain name via
	coercion, theft or brute force calculations, can replace any SMIMEA		coercion, theft or brute force calculations, can replace any SMIMEA
	record in that zone and all of the delegated child zones. Any future		record in that zone and all of the delegated child zones. Any future
	messages encrypted with the malicious SMIMEA key could then be read.		messages encrypted with the malicious SMIMEA key could then be read.
	Therefore, an certificate or key obtained from a DNSSEC validated		Therefore, an certificate or key obtained from a DNSSEC validated
	SMIMEA record can only be trusted as much as the DNS domain can be		SMIMEA record can only be trusted as much as the DNS domain can be
	trusted.		trusted.
	9.1. Email Address Information Leak		9.1. Response Size
			To prevent amplification attacks, an Authoritative DNS server MAY
			wish to prevent returning SMIMEA records over UDP unless the source
			IP address has been confirmed with [RFC7873]. Such servers MUST NOT
			return REFUSED, but answer the query with an empty answer section and
			the truncation flag set ("TC=1").
			9.2. Email Address Information Leak
	The hashing of the local-part in this document is not a security		The hashing of the local-part in this document is not a security
	feature. Publishing SMIMEA records will create a list of hashes of		feature. Publishing SMIMEA records will create a list of hashes of
	valid email addresses, which could simplify obtaining a list of valid		valid email addresses, which could simplify obtaining a list of valid
	email addresses for a particular domain. It is desirable to not ease		email addresses for a particular domain. It is desirable to not ease
	the harvesting of email addresses where possible.		the harvesting of email addresses where possible.
	The domain name part of the email address is not used as part of the		The domain name part of the email address is not used as part of the
	hash so that hashes can be used in multiple zones deployed using		hash so that hashes can be used in multiple zones deployed using
	DNAME [RFC6672]. This does makes it slightly easier and cheaper to		DNAME [RFC6672]. This makes it slightly easier and cheaper to brute-
	brute-force the SHA2-256 hashes into common and short local-parts, as		force the SHA2-256 hashes into common and short local-parts, as
	single rainbow tables can be re-used across domains. This can be		single rainbow tables can be re-used across domains. This can be
	somewhat countered by using NSEC3.		somewhat countered by using NSEC3.
	DNS zones that are signed with DNSSEC using NSEC for denial of		DNS zones that are signed with DNSSEC using NSEC for denial of
	existence are susceptible to zone-walking, a mechanism that allows		existence are susceptible to zone-walking, a mechanism that allows
	someone to enumerate all the SMIMEA hashes in a zone. This can be		someone to enumerate all the SMIMEA hashes in a zone. This can be
	used in combination with previously hashed common or short local-		used in combination with previously hashed common or short local-
	parts (in rainbow tables) to deduce valid email addresses. DNSSEC-		parts (in rainbow tables) to deduce valid email addresses. DNSSEC-
	signed zones using NSEC3 for denial of existence instead of NSEC are		signed zones using NSEC3 for denial of existence instead of NSEC are
	significantly harder to brute-force after performing a zone-walk.		significantly harder to brute-force after performing a zone-walk.
	10. Acknowledgements		10. Acknowledgements
	A great deal of material in this document is copied from RFC-to-be		A great deal of material in this document is copied from RFC-to-be
	draft-ietf-dane-openpgpkey-12. That material was created by Paul		draft-ietf-dane-openpgpkey-12. That material was created by Paul
	Wouters and other participants in the IETF DANE WG.		Wouters and other participants in the IETF DANE WG.
	Brian Dickson, Miek Gieben, and Martin Pels contributed technical		Brian Dickson, Miek Gieben, and Martin Pels, and Jim Schaad
	ideas and support to this document.		contributed technical ideas and support to this document.
	11. References		11. References
	[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,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements",		Rose, "DNS Security Introduction and Requirements",
	skipping to change at page 8, line 36 ¶		skipping to change at page 9, line 27 ¶
	[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, DOI 10.17487/RFC4034, March 2005,
	<http://www.rfc-editor.org/info/rfc4034>.		<http://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, DOI 10.17487/RFC4035, March 2005,
	<http://www.rfc-editor.org/info/rfc4035>.		<http://www.rfc-editor.org/info/rfc4035>.
			[RFC4262] Santesson, S., "X.509 Certificate Extension for Secure/
			Multipurpose Internet Mail Extensions (S/MIME)
			Capabilities", RFC 4262, DOI 10.17487/RFC4262, December
			2005, <http://www.rfc-editor.org/info/rfc4262>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<http://www.rfc-editor.org/info/rfc5280>.		<http://www.rfc-editor.org/info/rfc5280>.
	[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,		[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
	DOI 10.17487/RFC5321, October 2008,		DOI 10.17487/RFC5321, October 2008,
	<http://www.rfc-editor.org/info/rfc5321>.		<http://www.rfc-editor.org/info/rfc5321>.
	skipping to change at page 9, line 41 ¶		skipping to change at page 10, line 36 ¶
	[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an		[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
	Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May		Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
	2014, <http://www.rfc-editor.org/info/rfc7258>.		2014, <http://www.rfc-editor.org/info/rfc7258>.
	[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, <http://www.rfc-editor.org/info/rfc7671>.		October 2015, <http://www.rfc-editor.org/info/rfc7671>.
			[RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
			Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
			<http://www.rfc-editor.org/info/rfc7873>.
	[Unicode52]		[Unicode52]
	The Unicode Consortium, "The Unicode Standard, Version		The Unicode Consortium, "The Unicode Standard, Version
	5.2.0, defined by: "The Unicode Standard, Version 5.2.0",		5.2.0, defined by: "The Unicode Standard, Version 5.2.0",
	(Mountain View, CA: The Unicode Consortium, 2009. ISBN		(Mountain View, CA: The Unicode Consortium, 2009. ISBN
	978-1-936213-00-9).", October 2009.		978-1-936213-00-9).", October 2009.
	Authors' Addresses		Authors' Addresses
	Paul Hoffman		Paul Hoffman
	ICANN		ICANN
End of changes. 16 change blocks.
	23 lines changed or deleted		73 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/