< draft-mavrogiannopoulos-tls-dss-00.txt		draft-mavrogiannopoulos-tls-dss-01.txt >
	Network Working Group N. Mavrogiannopoulos		Network Working Group N. Mavrogiannopoulos
	Internet-Draft KUL		Internet-Draft KUL
	Intended status: Standards Track June 2, 2011		Intended status: Standards Track June 8, 2011
	Expires: December 4, 2011		Expires: December 10, 2011
	Using transport layer security (TLS) with DSA and ECDSA ciphersuites		Using transport layer security (TLS) with DSA and ECDSA ciphersuites
	draft-mavrogiannopoulos-tls-dss-00		draft-mavrogiannopoulos-tls-dss-01
	Abstract		Abstract
	This memo clarifies the usage of the digital signature algorithm		This memo clarifies the usage of the digital signature algorithm
	(DSA) with extended key lengths, in the transport layer security		(DSA) with extended key lengths, in the transport layer security
	(TLS) protocol earlier than 1.2, and makes clarifications for the		(TLS) protocol earlier than 1.2, and makes clarifications for the
	usage of DSA and its elliptic curves equivalent (ECDSA) in TLS 1.2.		usage of DSA and its elliptic curves equivalent (ECDSA) in TLS 1.2.
	Status of This Memo		Status of This Memo
	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 December 4, 2011.		This Internet-Draft will expire on December 10, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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
			1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
			2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
			3. DSA in FIPS-186-3 . . . . . . . . . . . . . . . . . . . . . . . 3
			4. The SSL 3.0, TLS 1.0 and 1.1 protocols . . . . . . . . . . . . 4
			4.1. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
			4.2. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
			5. The TLS protocol 1.2 . . . . . . . . . . . . . . . . . . . . . 5
			5.1. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
			5.1.1. Parameters not allowed by DSS . . . . . . . . . . . . . 6
			5.2. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
			6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
			7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
			7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
			7.2. Informative References . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	The TLS protocols support the DSA algorithm even from its first		The TLS protocols support the DSA algorithm even from its first
	incarnation in [RFC2246]. However the latest DSA publication from		incarnation in [RFC2246]. However the latest DSA publication from
	NIST at [DSS], suggests some changes that do not straightforwardly		NIST at [DSS], suggests some changes that do not straightforwardly
	apply to the TLS protocols.		apply to the TLS protocols.
	In this document we describe the differences on the new DSS		In this document we describe the differences on the new DSS
	algorithms[DSS], and define a profile for TLS implementations.		algorithms[DSS], and define a profile for TLS implementations.
	skipping to change at page 3, line 33 ¶		skipping to change at page 4, line 33 ¶
	| 2048 | 224 | 112 | SHA-224, SHA-256, |		| 2048 | 224 | 112 | SHA-224, SHA-256, |
	| | | | SHA-384, SHA-512 |		| | | | SHA-384, SHA-512 |
	| 2048 | 256 | (112,128) | SHA-256, SHA-384, SHA-512 |		| 2048 | 256 | (112,128) | SHA-256, SHA-384, SHA-512 |
	| 3072 | 256 | 128 | SHA-256, SHA-384, SHA-512 |		| 3072 | 256 | 128 | SHA-256, SHA-384, SHA-512 |
	+------------+------------+-------------+---------------------------+		+------------+------------+-------------+---------------------------+
	Table 2		Table 2
	4. The SSL 3.0, TLS 1.0 and 1.1 protocols		4. The SSL 3.0, TLS 1.0 and 1.1 protocols
			4.1. DSA
	The SSL 3.0, TLS 1.0 and 1.1 protocols support ciphersuites that		The SSL 3.0, TLS 1.0 and 1.1 protocols support ciphersuites that
	utilize the DSA algorithms for signing. The digital signatures are		utilize the DSA algorithms for signing. The digital signatures are
	used for the "Server key exchange" and "Certificate verify" messages.		used for the "Server key exchange" and "Certificate verify" messages.
	In those messages there is no indication of the signature algorithm		In those messages there is no indication of the signature algorithm
	used, thus the selection is implicit. The signature contained in		used, thus the selection is implicit. The signature contained in
	both messages is defined, for the DSA algorithm, as:		both messages is defined, for the DSA algorithm, as:
	select (SignatureAlgorithm)		select (SignatureAlgorithm)
	{		{
	case dsa:		case dsa:
	skipping to change at page 4, line 9 ¶		skipping to change at page 5, line 11 ¶
	This structure refers to the DSA algorithm with L=1024 and N=160, but		This structure refers to the DSA algorithm with L=1024 and N=160, but
	this is not an explicit requirement of those protocols and several		this is not an explicit requirement of those protocols and several
	existing implementations are using the SHA-1 algorithm for all DSA		existing implementations are using the SHA-1 algorithm for all DSA
	key sizes. For this reason it is RECOMMENDED not to use DSA keys of		key sizes. For this reason it is RECOMMENDED not to use DSA keys of
	sizes other than L=1024 and N=160 in combination with those		sizes other than L=1024 and N=160 in combination with those
	protocols.		protocols.
	If however keys of sizes larger than L=1024 and N=160 have to be		If however keys of sizes larger than L=1024 and N=160 have to be
	used, then the SHA-1 algorithm has to be used.		used, then the SHA-1 algorithm has to be used.
			4.2. ECDSA
			For TLS negotiation to proceed smoothly when an ECDSA enabled
			ciphersuite is negotiated both parties must agree to a curve.
			However given that [RFC4492] lists a very large number of curves but
			doesn't recommend any, it is unclear which curves should be used in
			certificates for TLS.
			To improve interoperability implementations SHOULD use certificates
			with curves restricted to the recommended by [RFC5480]. Those are
			summarized in Table 3.
			+-----------+
			| Curve |
			+-----------+
			| secp224r1 |
			| secp256r1 |
			| secp384r1 |
			| secp521r1 |
			+-----------+
			Table 3
	5. The TLS protocol 1.2		5. The TLS protocol 1.2
	This version of the protocol also requires signatures for the "Server		This version of the protocol also requires signatures for the "Server
	key exchange" and "Certificate verify" messages. However in this		key exchange" and "Certificate verify" messages. However in this
	version signature algorithm negotiation is explicit via the		version signature algorithm negotiation is explicit via the
	"Signature algorithms" extension. The signature used is as below:		"Signature algorithms" extension. The signature used is as below:
	struct {		struct {
	SignatureAndHashAlgorithm algorithm;		SignatureAndHashAlgorithm algorithm;
	opaque signature<0..2^16-1>;		opaque signature<0..2^16-1>;
	} DigitallySigned;		} DigitallySigned;
			It is however desirable for interoperability reasons to restrict the
			available options. This would allow constrained clients to support
			only the required algorithms, and servers that do not cache all
			messages up to "Certificate verify" in order to calculate the
			signature, to carry a single hash state instead.
	5.1. DSA		5.1. DSA
	In this case a signature algorithm should be selected that matches		In this case a signature algorithm should be selected that matches
	the requirements as in Table 3. Implementations SHOULD select the		the requirements as in Table 4. Implementations SHOULD select the
	algorithms shown on that table.		algorithms shown on that table.
	+--------------+--------------+------------+--------+---------------+		+--------------+--------------+------------+--------+---------------+
	| Length of p | Length of q | Hash | Hash | Truncated |		| Length of p | Length of q | Hash | Hash | Truncated |
	| in bits | in bits | algorithm | size | hash size |		| in bits | in bits | algorithm | size | hash size |
	+--------------+--------------+------------+--------+---------------+		+--------------+--------------+------------+--------+---------------+
	| 1024 | 160 | SHA-1 | 20 | 20 |		| 1024 | 160 | SHA-1 | 20 | 20 |
	| 2048 | 224 | SHA-256 | 32 | 28 |		| 2048 | 224 | SHA-256 | 32 | 28 |
	| 2048 | 256 | SHA-256 | 32 | 32 |		| 2048 | 256 | SHA-256 | 32 | 32 |
	| 3072 | 256 | SHA-256 | 32 | 32 |		| 3072 | 256 | SHA-256 | 32 | 32 |
	+--------------+--------------+------------+--------+---------------+		+--------------+--------------+------------+--------+---------------+
	Table 3		Table 4
	Note: When the hash size does not match the length of q, then only		Note: When the hash size does not match the length of q, then only
	the leftmost bytes of the hash, that match the length of q, are used.		the leftmost bytes of the hash, that match the length of q, are used.
	This is indicated in the "Truncated hash size" column of the table.		This is indicated in the "Truncated hash size" column of the table.
	Note: SHA-224 is not used to allow servers that do not cache all		5.1.1. Parameters not allowed by DSS
	messages up to "Certificate verify" to carry a single SHA-256 hash
	state instead. SHA-224 and SHA-256 have the exact same security		TLS implementations MUST NOT support parameter lengths not allowed by
	properties, because SHA-224 is a truncated SHA-256 (with a different		[DSS]. If illegal parameters are encountered, the handshake should
	internal start value).		be aborted using an "illegal_parameter" alert.
	5.2. ECDSA		5.2. ECDSA
	In this case a signature algorithm should be selected that matches		The signature hash algorithm SHOULD be selected in way that matches
	the requirements as in Table 4. Implementations SHOULD select the		the requirements of Table 5. Also implementations SHOULD use
	algorithms shown on that table.		certificates with curves restricted to the recommended by [RFC5480].
			Those are summarized in Table 3.
	+----------------+----------------+-----------+---------------------+		+----------------+----------------+-----------+---------------------+
	| ECDSA key size | Hash algorithm | Hash size | Truncated hash size |		| ECDSA key size | Hash algorithm | Hash size | Truncated hash size |
	+----------------+----------------+-----------+---------------------+		+----------------+----------------+-----------+---------------------+
	| 192 | SHA-256 | 32 | 24 |		| 192 | SHA-256 | 32 | 24 |
	| 224 | SHA-256 | 32 | 28 |		| 224 | SHA-256 | 32 | 28 |
	| 256 | SHA-256 | 32 | 32 |		| 256 | SHA-256 | 32 | 32 |
	| 384 | SHA-384 | 48 | 48 |		| 384 | SHA-384 | 48 | 48 |
	| 512 | SHA-512 | 64 | 64 |		| 512 | SHA-512 | 64 | 64 |
	+----------------+----------------+-----------+---------------------+		+----------------+----------------+-----------+---------------------+
	Table 4		Table 5
	Note: As with DSA, when the hash size does not match the curve		Note: As with DSA, when the hash size does not match the curve key
	length, only the leftmost bytes of the hash are used. This size is		size, only the leftmost bytes of the hash are used. This size is
	shown in the "Truncated hash size" column of the table.		shown in the "Truncated hash size" column of the table.
	6. Parameters not allowed by DSS		6. Security Considerations
	TLS implementations MUST NOT support parameter lengths not allowed by
	[DSS]. If illegal parameters are encountered, the handshake should
	be aborted using an "illegal_parameter" alert.
	7. Security Considerations
	When DSA keys are being used in connections that involve the SSL 3.0,		When DSA keys are being used in connections that involve the SSL 3.0,
	TLS 1.0 or TLS 1.1 protocols then the entire connection security		TLS 1.0 or TLS 1.1 protocols then the entire connection security
	depends on the SHA-1 algorithm. This is about 80-bits of security		depends on the SHA-1 algorithm. This is about 80-bits of security
	irrespective of the sizes of the DSA keys.		irrespective of the sizes of the DSA keys.
	All security considerations discussed in [RFC5246], apply to this		All security considerations discussed in [RFC5246], apply to this
	document.		document.
	8. References		7. References
	8.1. Normative References		7.1. Normative References
	[DSS] NIST FIPS PUB 186-3, "Digital Signature Standard",		[DSS] NIST FIPS PUB 186-3, "Digital Signature Standard",
	National Institute of Standards and Technology, U.S.		National Institute of Standards and Technology, U.S.
	Department of Commerce , June 2009.		Department of Commerce , June 2009.
	[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.
			[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
			"Elliptic Curve Cryptography Subject Public Key
			Information", RFC 5480, March 2009.
			[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and
			B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher
			Suites for Transport Layer Security (TLS)", RFC 4492,
			May 2006.
	[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, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	8.2. Informative References		7.2. Informative References
	[OLDDSS] NIST FIPS PUB 186, "Digital Signature Standard", National		[OLDDSS] NIST FIPS PUB 186, "Digital Signature Standard", National
	Institute of Standards and Technology, U.S. Department of		Institute of Standards and Technology, U.S. Department of
	Commerce , May 1994.		Commerce , May 1994.
	[SP800-57] NIST FIPS SP 800-57, "Recommendation for Key Management",		[SP800-57] NIST FIPS SP 800-57, "Recommendation for Key Management",
	National Institute of Standards and Technology, U.S.		National Institute of Standards and Technology, U.S.
	Department of Commerce , March 2007.		Department of Commerce , March 2007.
	[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",		[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
End of changes. 18 change blocks.
	27 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/