Network Working Group N. Mavrogiannopoulos Internet-Draft KUL Intended status: Standards Track June 2, 2011 Expires: December 4, 2011 Using transport layer security (TLS) with DSA and ECDSA ciphersuites draft-mavrogiannopoulos-tls-dss-00 Abstract This memo clarifies the usage of the digital signature algorithm (DSA) with extended key lengths, in the transport layer security (TLS) protocol earlier than 1.2, and makes clarifications for the usage of DSA and its elliptic curves equivalent (ECDSA) in TLS 1.2. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 4, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Mavrogiannopoulos Expires December 4, 2011 [Page 1] Internet-Draft TLS with DSA and ECDSA June 2011 1. Introduction The TLS protocols support the DSA algorithm even from its first incarnation in [RFC2246]. However the latest DSA publication from NIST at [DSS], suggests some changes that do not straightforwardly apply to the TLS protocols. In this document we describe the differences on the new DSS algorithms[DSS], and define a profile for TLS implementations. 2. Terminology This document uses the same notation and terminology used in the TLS Protocol specification [RFC5246]. 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 [RFC2119]. 3. DSA in FIPS-186-3 In this section we discuss the differences between the old DSS publication [OLDDSS] and the new one [DSS], that justify the need for a TLS profile. DSA parameters include a prime modulus p and a prime divisor of p-1 called q. In [OLDDSS] the bit length of p was fixed to 1024 bits, the length of q to 160 bits and the underlying hash algorithm was fixed to SHA-1. However the DSA algorithm in [DSS] allows more lengths for p and q, as well different hash algorithms, than the older version which is currently referred by TLS protocols. The new document relies on the "bits of security" term defined in [SP800-57], and recommends that security strength of the hash algorithm matches the security strength of other DSA parameters. It is required either the bits of the hash algorithm to match the bits of length of q (N), or if the hash size is larger, only the N leftmost bits of the hash output are being used. The corresponding mappings are shown in Table 1 and Table 2. Mavrogiannopoulos Expires December 4, 2011 [Page 2] Internet-Draft TLS with DSA and ECDSA June 2011 +----------------+-----------+------------------+ | Hash algorithm | Hash size | Bits of security | +----------------+-----------+------------------+ | SHA-1 | 160 | 80 | | SHA-224 | 224 | 112 | | SHA-256 | 256 | 128 | | SHA-384 | 384 | 192 | | SHA-512 | 512 | 256 | +----------------+-----------+------------------+ Table 1 +------------+------------+-------------+---------------------------+ | Length of | Length of | Bits of | Matching hash algorithms | | p (L) | q (N) | security | | +------------+------------+-------------+---------------------------+ | 1024 | 160 | 80 | SHA-1, SHA-224, SHA-256, | | | | | SHA-384, SHA-512 | | 2048 | 224 | 112 | SHA-224, 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 | +------------+------------+-------------+---------------------------+ Table 2 4. The SSL 3.0, TLS 1.0 and 1.1 protocols The SSL 3.0, TLS 1.0 and 1.1 protocols support ciphersuites that utilize the DSA algorithms for signing. The digital signatures are used for the "Server key exchange" and "Certificate verify" messages. In those messages there is no indication of the signature algorithm used, thus the selection is implicit. The signature contained in both messages is defined, for the DSA algorithm, as: select (SignatureAlgorithm) { case dsa: digitally-signed struct { opaque sha_hash[20]; }; } Signature; 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 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 sizes other than L=1024 and N=160 in combination with those Mavrogiannopoulos Expires December 4, 2011 [Page 3] Internet-Draft TLS with DSA and ECDSA June 2011 protocols. 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. 5. The TLS protocol 1.2 This version of the protocol also requires signatures for the "Server key exchange" and "Certificate verify" messages. However in this version signature algorithm negotiation is explicit via the "Signature algorithms" extension. The signature used is as below: struct { SignatureAndHashAlgorithm algorithm; opaque signature<0..2^16-1>; } DigitallySigned; 5.1. DSA In this case a signature algorithm should be selected that matches the requirements as in Table 3. Implementations SHOULD select the algorithms shown on that table. +--------------+--------------+------------+--------+---------------+ | Length of p | Length of q | Hash | Hash | Truncated | | in bits | in bits | algorithm | size | hash size | +--------------+--------------+------------+--------+---------------+ | 1024 | 160 | SHA-1 | 20 | 20 | | 2048 | 224 | SHA-256 | 32 | 28 | | 2048 | 256 | SHA-256 | 32 | 32 | | 3072 | 256 | SHA-256 | 32 | 32 | +--------------+--------------+------------+--------+---------------+ Table 3 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. 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 messages up to "Certificate verify" to carry a single SHA-256 hash state instead. SHA-224 and SHA-256 have the exact same security properties, because SHA-224 is a truncated SHA-256 (with a different internal start value). Mavrogiannopoulos Expires December 4, 2011 [Page 4] Internet-Draft TLS with DSA and ECDSA June 2011 5.2. ECDSA In this case a signature algorithm should be selected that matches the requirements as in Table 4. Implementations SHOULD select the algorithms shown on that table. +----------------+----------------+-----------+---------------------+ | ECDSA key size | Hash algorithm | Hash size | Truncated hash size | +----------------+----------------+-----------+---------------------+ | 192 | SHA-256 | 32 | 24 | | 224 | SHA-256 | 32 | 28 | | 256 | SHA-256 | 32 | 32 | | 384 | SHA-384 | 48 | 48 | | 512 | SHA-512 | 64 | 64 | +----------------+----------------+-----------+---------------------+ Table 4 Note: As with DSA, when the hash size does not match the curve length, only the leftmost bytes of the hash are used. This size is shown in the "Truncated hash size" column of the table. 6. Parameters not allowed by DSS 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, 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 irrespective of the sizes of the DSA keys. All security considerations discussed in [RFC5246], apply to this document. 8. References 8.1. Normative References [DSS] NIST FIPS PUB 186-3, "Digital Signature Standard", National Institute of Standards and Technology, U.S. Department of Commerce , June 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Mavrogiannopoulos Expires December 4, 2011 [Page 5] Internet-Draft TLS with DSA and ECDSA June 2011 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. 8.2. Informative References [OLDDSS] NIST FIPS PUB 186, "Digital Signature Standard", National Institute of Standards and Technology, U.S. Department of Commerce , May 1994. [SP800-57] NIST FIPS SP 800-57, "Recommendation for Key Management", National Institute of Standards and Technology, U.S. Department of Commerce , March 2007. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. Author's Address Nikos Mavrogiannopoulos ESAT/COSIC Katholieke Universiteit Leuven Kasteelpark Arenberg 10, bus 2446 Leuven-Heverlee, B-3001 Belgium EMail: nikos.mavrogiannopoulos@esat.kuleuven.be Mavrogiannopoulos Expires December 4, 2011 [Page 6]