Network Working Group N. Mavrogiannopoulos
Internet-Draft KUL
Intended status: Standards Track June 02, 2011
Expires: December 04, 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 04, 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.

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.

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

Length of p (L) Length of q (N) Bits of security Matching hash algorithms
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

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 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 in bits Length of q in bits Hash algorithm Hash size Truncated 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

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).

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

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.
[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

Table of Contents