< draft-ietf-curdle-cms-chacha20-poly1305-03.txt		draft-ietf-curdle-cms-chacha20-poly1305-04.txt >
	Internet-Draft R. Housley		Internet-Draft R. Housley
	Intended status: Standards Track Vigil Security		Intended status: Standards Track Vigil Security
	Expires: 28 April 2017 28 October 2016		Expires: 1 June 2017 1 December 2016
	Using ChaCha20-Poly1305 Authenticated Encryption		Using ChaCha20-Poly1305 Authenticated Encryption
	in the Cryptographic Message Syntax (CMS)		in the Cryptographic Message Syntax (CMS)
	<draft-ietf-curdle-cms-chacha20-poly1305-03.txt>		<draft-ietf-curdle-cms-chacha20-poly1305-04.txt>
	Abstract		Abstract
	This document describes the conventions for using ChaCha20-Poly1305		This document describes the conventions for using ChaCha20-Poly1305
	Authenticated Encryption in the Cryptographic Message Syntax (CMS).		Authenticated Encryption in the Cryptographic Message Syntax (CMS).
	ChaCha20-Poly1305 is an authenticated encryption algorithm		ChaCha20-Poly1305 is an authenticated encryption algorithm
	constructed of the ChaCha stream cipher and Poly1305 authenticator.		constructed of the ChaCha stream cipher and Poly1305 authenticator.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	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 22 March 2017.		This Internet-Draft will expire on 1 June 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 43 ¶		skipping to change at page 2, line 43 ¶
	ChaCha20 and Poly1305 have been combined to create an Authenticated		ChaCha20 and Poly1305 have been combined to create an Authenticated
	Encryption with Associated Data (AEAD) algorithm [AEAD]. This AEAD		Encryption with Associated Data (AEAD) algorithm [AEAD]. This AEAD
	algorithm is often referred to as AEAD_CHACHA20_POLY1305, and it is		algorithm is often referred to as AEAD_CHACHA20_POLY1305, and it is
	described [FORIETF].		described [FORIETF].
	AEAD_CHACHA20_POLY1305 accepts four inputs: a 256-bit key, a 96-bit		AEAD_CHACHA20_POLY1305 accepts four inputs: a 256-bit key, a 96-bit
	nonce, an arbitrary length plaintext, and an arbitrary length		nonce, an arbitrary length plaintext, and an arbitrary length
	additional authenticated data (AAD). As the name implies, a nonce		additional authenticated data (AAD). As the name implies, a nonce
	value cannot be used securely more than once with the same key.		value cannot be used securely more than once with the same key.
	A high-level summary of AEAD_CHACHA20_POLY1305 authenticated		AEAD_CHACHA20_POLY1305 produces two outputs: ciphertext of the same
	encryption processing is:		length as the plaintext and a 128-bit authentication tag.
	1) A 256-bit Poly1305 one-time key is generated from the input
	256-bit key and nonce using the procedure described in
	Section 2.6 of [FORIETF].
	2) The ChaCha20 encryption function is used to encrypt the
	plaintext, using the same 256-bit key and nonce, and with the
	initial counter set to 1.
	3) The Poly1305 function is used with the Poly1305 key from
	step 1, and a buffer constructed as a concatenation of the AAD,
	padding1, the ciphertext, padding2, the length of the AAD in
	octets, and the length of the ciphertext in octets. The
	padding fields contain up to 15 octets, with all bits set to
	zero, and the padding brings the total length of the buffer so
	far to an integral multiple of 16. If the buffer length was
	already an integral multiple of 16 octets, then the padding
	field is zero octets. The length fields contain 64-bit little-
	endian integers.
	AEAD_CHACHA20_POLY1305 produces ciphertext of the same length as the
	plaintext and a 128-bit authentication tag.
	AEAD_CHACHA20_POLY1305 authenticated decryption processing is similar		AEAD_CHACHA20_POLY1305 authenticated decryption processing is similar
	to the encryption processing. Of course, the roles of ciphertext and		to the encryption processing. Of course, the roles of ciphertext and
	plaintext are reversed, so the ChaCha20 encryption function is		plaintext are reversed, so the ChaCha20 encryption function is
	applied to the ciphertext, producing the plaintext. The Poly1305		applied to the ciphertext, producing the plaintext. The Poly1305
	function is run over the AAD and the ciphertext, not the plaintext,		function is run over the AAD and the ciphertext, not the plaintext,
	and the resulting authentication tag is bitwise compared to the		and the resulting authentication tag is bitwise compared to the
	received authentication tag. The message is authenticated if and		received authentication tag. The message is authenticated if and
	only if the calculated and received authentication tags match.		only if the calculated and received authentication tags match.
	1.2. Terminology		1.2. ASN.1
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [STDWORDS].
	1.3. ASN.1
	CMS values are generated using ASN.1 [X680], which uses the Basic		CMS values are generated using ASN.1 [X680], which uses the Basic
	Encoding Rules (BER) and the Distinguished Encoding Rules (DER)		Encoding Rules (BER) and the Distinguished Encoding Rules (DER)
	[X690].		[X690].
	2. Automated Key Management		1.3. Terminology
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in RFC 2119 [STDWORDS].
			2. Key Management
	The reuse of an AEAD_CHACHA20_POLY1305 nonce value with the same key		The reuse of an AEAD_CHACHA20_POLY1305 nonce value with the same key
	destroys the security guarantees. I can be extremely difficult to		destroys the security guarantees. It can be extremely difficult to
	use a statically configured AEAD_CHACHA20_POLY1305 key and never		use a statically configured AEAD_CHACHA20_POLY1305 key and never
	repeat a nonce value. For safety's sake, implementations MUST use an		repeat a nonce value; however, the CMS authenticated-enveloped-data
	automated key management system [KEYMGMT].		content type supports four key management techniques that allow a
			fresh AEAD_CHACHA20_POLY1305 key to be used as the content-
	The CMS authenticated-enveloped-data content type supports four		authenticated-encryption key for a single protected content:
	general key management techniques:
	Key Transport: the content-authenticated-encryption key is		Key Transport: the fresh content-authenticated-encryption key
	encrypted in the recipient's public key;		is encrypted in the recipient's public key;
	Key Agreement: the recipient's public key and the sender's		Key Agreement: the recipient's public key and the sender's
	private key are used to generate a pairwise symmetric key, then		private key are used to generate a pairwise symmetric key-
	the content-authenticated-encryption key is encrypted in the		encryption key, then the fresh content-authenticated-encryption
	pairwise symmetric key;		key is encrypted in the pairwise symmetric key;
	Symmetric Key-Encryption Keys: the content-authenticated-		Symmetric Key-Encryption Keys: the fresh content-authenticated-
	encryption key is encrypted in a previously distributed		encryption key is encrypted in a previously distributed
	symmetric key-encryption key; and		symmetric key-encryption key; and
	Passwords: the content-authenticated-encryption key is encrypted		Passwords: the fresh content-authenticated-encryption key is
	in a key-encryption key that is derived from a password or		encrypted in a key-encryption key that is derived from a
	other shared secret value.		password or other shared secret value.
	All of these key management techniques meet the automated key
	management system requirement as long as a fresh content-
	authenticated-encryption key is generated for the protection of each
	content. Note that some of these key management techniques use one
	key-encryption key to encrypt more than one content-authenticated-
	encryption key during the system life cycle. As long as fresh
	content-authenticated-encryption key is used each time,
	AEAD_CHACHA20_POLY1305 can be used safely with the CMS authenticated-
	enveloped-data content type.
	In addition to these four general key management techniques, CMS		In addition to these four general key management techniques, CMS
	supports other key management techniques. See Section 6.2.5 of		supports other key management techniques. See Section 6.2.5 of
	[CMS]. Since the properties of these key management techniques are		[CMS]. Since the properties of these key management techniques are
	unknown, no statement can be made about whether these key management		unknown, no statement about their support of fresh content-
	techniques meet the automated key management system requirement.		authenticated-encryption keys can be made. Designers and
	Designers and implementers must perform their own analysis if one of		implementers must perform their own analysis if one of these other
	these other key management techniques is supported.		key management techniques is supported.
	3. Using the AEAD_CHACHA20_POLY1305 Algorithm with AuthEnvelopedData		3. Using the AEAD_CHACHA20_POLY1305 Algorithm with AuthEnvelopedData
	This section specifies the conventions employed by CMS		This section specifies the conventions employed by CMS
	implementations that support content authenticated encryption using		implementations that support the authenticated-enveloped-data content
	the AEAD_CHACHA20_POLY1305 algorithm.		type and the AEAD_CHACHA20_POLY1305 algorithm.
	Content authenticated encryption algorithm identifiers are located in		The AEAD_CHACHA20_POLY1305 algorithm identifier is located in the
	the AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm		AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm
	field.		field.
	Content authenticated encryption algorithms are used to encipher the		The AEAD_CHACHA20_POLY1305 algorithm is used to encipher the content
	content located in the AuthEnvelopedData EncryptedContentInfo		located in the AuthEnvelopedData EncryptedContentInfo
	encryptedContent field and to provide the message authentication code		encryptedContent field and to provide the message authentication code
	for the AuthEnvelopedData mac field. Note that the message		(MAC) located in the AuthEnvelopedData mac field. The ciphertext and
	authentication code provides integrity protection for both the		the MAC are the two outputs of the AEAD_CHACHA20_POLY1305 Algorithm.
			Note that the MAC, which is called the authentication tag in
			[FORIETF], provides integrity protection for both the
	AuthEnvelopedData authAttrs and the AuthEnvelopedData		AuthEnvelopedData authAttrs and the AuthEnvelopedData
	EncryptedContentInfo encryptedContent.		EncryptedContentInfo encryptedContent.
	Neither the plaintext content nor the optional AAD inputs need to be		Neither the plaintext content nor the optional AAD inputs need to be
	padded prior to invoking the AEAD_CHACHA20_POLY1305 algorithm.		padded prior to invoking the AEAD_CHACHA20_POLY1305 algorithm.
	There is one algorithm identifiers for the AEAD_CHACHA20_POLY1305		There is one algorithm identifier for the AEAD_CHACHA20_POLY1305
	algorithm:		algorithm:
	id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::=		id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::=
	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)		{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
	pkcs9(9) smime(16) alg(3) TBD1 }		pkcs9(9) smime(16) alg(3) TBD1 }
	The AlgorithmIdentifier parameters field MUST be present, and the		The AlgorithmIdentifier parameters field MUST be present, and the
	parameters field must contain a AEADChaCha20Poly1305Nonce:		parameters field must contain a AEADChaCha20Poly1305Nonce:
	AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12))		AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12))
	The AEADChaCha20Poly1305Nonce contains a 12-octet nonce. With the		The AEADChaCha20Poly1305Nonce contains a 12-octet nonce. With the
	CMS, the content-authenticated-encryption key is normally used for a		CMS, the content-authenticated-encryption key is normally used for a
	single content. Within the scope of any content-authenticated-		single content. Within the scope of any content-authenticated-
	encryption key, the nonce value MUST be unique. That is, the set of		encryption key, the nonce value MUST be unique. That is, the set of
	nonce values used with any given key MUST NOT contain any duplicate		nonce values used with any given key MUST NOT contain any duplicate
	values.		values.
	4. S/MIME Capabilities		4. S/MIME Capabilities Attribute
	{{{ This can be written once the Object Identifier is assigned. }}}		Section 2.5.2 of RFC 5751 [MSG] defines the SMIMECapabilities
			attribute, which is used to specify a partial list of algorithms that
			the software announcing the SMIMECapabilities can support. When
			constructing a CMS signed-data content type, compliant software MAY
			include the SMIMECapabilities signed attribute to announce support
			for the AEAD_CHACHA20_POLY1305 algorithm.
			The SMIMECapability SEQUENCE representing the AEAD_CHACHA20_POLY1305
			algorithm MUST include the id-alg-AEADChaCha20Poly1305 object
			identifier in the capabilityID field and MUST omit the parameters
			field.
			The DER encoding of a SMIMECapability SEQUENCE is the same as the DER
			encoding of an AlgorithmIdentifier. The DER encoding for the
			AEAD_CHACHA20_POLY1305 algorithm in the SMIMECapability SEQUENCE (in
			hexadecimal) is:
			30 0c 06 0b 2a 86 48 86 f7 0d 01 09 10 03 ??
			{{{ Correct above after IANA assigns the object identifier. }}}
	5. IANA Considerations		5. IANA Considerations
	IANA is requested to add the following entry in the SMI Security for		IANA is requested to add the following entry in the SMI Security for
	S/MIME Algorithms (1.2.840.113549.1.9.16.3) registry:		S/MIME Algorithms (1.2.840.113549.1.9.16.3) registry:
	TBD1 id-alg-AEADChaCha20Poly1305 [This Document]		TBD1 id-alg-AEADChaCha20Poly1305 [This Document]
	IANA is requested to add the following entry in the SMI Security for		IANA is requested to add the following entry in the SMI Security for
	S/MIME Module Identifier (1.2.840.113549.1.9.16.0) registry:		S/MIME Module Identifier (1.2.840.113549.1.9.16.0) registry:
	TBD2 id-mod-CMS-AEADChaCha20Poly1305 [This Document]		TBD2 id-mod-CMS-AEADChaCha20Poly1305 [This Document]
	6. Security Considerations		6. Security Considerations
	The CMS AuthEnvelopedData provides all of the tools needed to avoid		The CMS AuthEnvelopedData provides all of the tools needed to avoid
	reuse of the same nonce value under the same key. Automated key		reuse of the same nonce value under the same key. See the discussion
	management is discussed in Section 2.		in Section 2 of this document. RFC 7539 [FORIETF] describes the
			consequences of using a nonce value more than once:
			Consequences of repeating a nonce: If a nonce is repeated, then
			both the one-time Poly1305 key and the keystream are identical
			between the
			messages. This reveals the XOR of the plaintexts, because the
			XOR of the plaintexts is equal to the XOR of the ciphertexts.
	When using AEAD_CHACHA20_POLY1305, the resulting ciphertext is always		When using AEAD_CHACHA20_POLY1305, the resulting ciphertext is always
	the same size as the original plaintext. Some other mechanism needs		the same size as the original plaintext. Some other mechanism needs
	to be used in conjunction with AEAD_CHACHA20_POLY1305 if disclosure		to be used in conjunction with AEAD_CHACHA20_POLY1305 if disclosure
	of the size of the plaintext is a concern.		of the size of the plaintext is a concern.
	The amount of encrypted data possible in a single invocation of		The amount of encrypted data possible in a single invocation of
	AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octets each, because of		AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octets each, because of
	the size of the block counter field in the ChaCha20 block function.		the size of the block counter field in the ChaCha20 block function.
	This gives a total of 247,877,906,880 octets, which likely to be		This gives a total of 247,877,906,880 octets, which likely to be
	skipping to change at page 6, line 40 ¶		skipping to change at page 6, line 27 ¶
	generators (PRNGs) to generate cryptographic keys can result in		generators (PRNGs) to generate cryptographic keys can result in
	little or no security. An attacker may find it much easier to		little or no security. An attacker may find it much easier to
	reproduce the PRNG environment that produced the keys, searching the		reproduce the PRNG environment that produced the keys, searching the
	resulting small set of possibilities, rather than brute force		resulting small set of possibilities, rather than brute force
	searching the whole key space. The generation of quality random		searching the whole key space. The generation of quality random
	numbers is difficult. RFC 4086 [RANDOM] offers important guidance in		numbers is difficult. RFC 4086 [RANDOM] offers important guidance in
	this area.		this area.
	7. Acknowledgements		7. Acknowledgements
	Thanks to Jim Schaad and Daniel Migault for their review and		Thanks to Jim Schaad, Daniel Migault, and Stephen Farrell for their
	insightful comments.		review and insightful comments.
	8. Normative References		8. Normative References
	[AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS)		[AUTHENV] Housley, R., "Cryptographic Message Syntax (CMS)
	Authenticated-Enveloped-Data Content Type", RFC 5083,		Authenticated-Enveloped-Data Content Type", RFC 5083,
	November 2007.		November 2007.
	[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC		[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
	5652, September 2009.		5652, September 2009.
	[FORIETF] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF		[FORIETF] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
	Protocols", RFC 7539, May 2015.		Protocols", RFC 7539, May 2015.
			[MSG] Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet
			Mail Extensions (S/MIME) Version 3.2 Message
			Specification", RFC 5751, January 2010.
	[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate		[STDWORDS] 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.
	[X680] ITU-T, "Information technology -- Abstract Syntax Notation		[X680] ITU-T, "Information technology -- Abstract Syntax Notation
	One (ASN.1): Specification of basic notation", ITU-T		One (ASN.1): Specification of basic notation", ITU-T
	Recommendation X.680, 2015.		Recommendation X.680, 2015.
	[X690] ITU-T, "Information technology -- ASN.1 encoding rules:		[X690] ITU-T, "Information technology -- ASN.1 encoding rules:
	Specification of Basic Encoding Rules (BER), Canonical		Specification of Basic Encoding Rules (BER), Canonical
	Encoding Rules (CER) and Distinguished Encoding Rules		Encoding Rules (CER) and Distinguished Encoding Rules
	skipping to change at page 7, line 33 ¶		skipping to change at page 7, line 25 ¶
	[CHACHA] Bernstein, D., "ChaCha, a variant of Salsa20", January		[CHACHA] Bernstein, D., "ChaCha, a variant of Salsa20", January
	2008,		2008,
	<http://cr.yp.to/chacha/chacha-20080128.pdf>.		<http://cr.yp.to/chacha/chacha-20080128.pdf>.
	[ESTREAM] Babbage, S., DeCanniere, C., Cantenaut, A., Cid, C.,		[ESTREAM] Babbage, S., DeCanniere, C., Cantenaut, A., Cid, C.,
	Gilbert, H., Johansson, T., Parker, M., Preneel, B.,		Gilbert, H., Johansson, T., Parker, M., Preneel, B.,
	Rijmen, V., and M. Robshaw, "The eSTREAM Portfolio		Rijmen, V., and M. Robshaw, "The eSTREAM Portfolio
	(rev. 1)", September 2008,		(rev. 1)", September 2008,
	<http://www.ecrypt.eu.org/stream/finallist.html>.		<http://www.ecrypt.eu.org/stream/finallist.html>.
	[KEYMGMT] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
	Key Management", BCP 107, RFC 4107, June 2005.
	[POLY1305] Bernstein, D., "The Poly1305-AES message-authentication		[POLY1305] Bernstein, D., "The Poly1305-AES message-authentication
	code.", March 2005,		code.", March 2005,
	<http://cr.yp.to/mac/poly1305-20050329.pdf>.		<http://cr.yp.to/mac/poly1305-20050329.pdf>.
	[PROCTER] Procter, G., "A Security Analysis of the Composition of		[PROCTER] Procter, G., "A Security Analysis of the Composition of
	ChaCha20 and Poly1305", August 2014,		ChaCha20 and Poly1305", August 2014,
	<http://eprint.iacr.org/2014/613.pdf>.		<http://eprint.iacr.org/2014/613.pdf>.
	[RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness		[RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
	Recommendations for Security", BCP 106, RFC 4086, June		Recommendations for Security", BCP 106, RFC 4086, June
	skipping to change at page 8, line 38 ¶		skipping to change at page 8, line 38 ¶
	SMIME-CAPS { IDENTIFIED BY id-alg-AEADChaCha20Poly1305 } }		SMIME-CAPS { IDENTIFIED BY id-alg-AEADChaCha20Poly1305 } }
	id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::=		id-alg-AEADChaCha20Poly1305 OBJECT IDENTIFIER ::=
	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)		{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
	pkcs9(9) smime(16) alg(3) TBD1 }		pkcs9(9) smime(16) alg(3) TBD1 }
	AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12))		AEADChaCha20Poly1305Nonce ::= OCTET STRING (SIZE(12))
	END		END
	Author's Addresses		Author's Address
	Russell Housley		Russell Housley
	Vigil Security, LLC		Vigil Security, LLC
	918 Spring Knoll Drive		918 Spring Knoll Drive
	Herndon, VA 20170		Herndon, VA 20170
	USA		USA
	EMail: housley@vigilsec.com		EMail: housley@vigilsec.com
End of changes. 25 change blocks.
	83 lines changed or deleted		79 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/