TLS 1.2 Handshake: How is the ECDHE public key signed by server?

Question

I am dealing with a situation where a cipher option, such as ECDHE-ECDSA-AES128-SHA, is chosen for establishing a TLS connection. In this case, a server, when sending the ServerKeyExchange message to the client, is required to sign the ephemeral (EC) diffie hellman key using its ECDSA private key (associated with the public key certificate). The public key is first hashed before an ECDSA sign operation can be performance.

My question: how is the hashing algorithm determined during the handshake?

RFC 4492 which describes the application of ECC to TLS 1.2 has the following text to indicate how this algorithm is determined:

"“All ECDSA computations MUST be performed according to ANSI X9.62 [7] or its successors. Data to be signed/verified is hashed, and the
result run directly through the ECDSA algorithm with no additional
hashing. The default hash function is SHA-1 [10], and sha_size (see Sections 5.4 and 5.8) is 20. However, an alternative hash function, such as one of the new SHA hash functions specified in FIPS 180-2 [10], may be used instead if the certificate containing the EC public key explicitly requires use of another hash function. (The mechanism for specifying the required hash function has not been standardized, but this provision anticipates such standardization and obviates the need to update this document in response. Future PKIX RFCs may choose, for example, to specify the hash function to be used with a public key in the parameters field of subjectPublicKeyInfo.)”

However, if one refers to NIST Suite-B requirements for TLS 1.2 (RFC 5430), it is clear on the use of SHA256 and SHA384 for desired security level (since SHA1 is deprecated by NIST).

So, in TLS handshake, how does one specify the use SHA256 in the above signing procedure ?

Thanks,

Hari Tadepalli

Answer 1

RFC 4492 specifies ECC for TLS1.0 and TLS1.1. It does not cover TLS1.2 because it was written before TLS1.2; notice that 4492 is less than 5246. RFC 5246 TLS1.2 changes the signature structure for all signing algorithms including ECDSA, and also adds a Hello extension to negotiate supported signing algorithms (including hash) more flexibly.

RFC 5246 A.7 Changes to RFC 4492

RFC 4492 [TLSECC] adds Elliptic Curve cipher suites to TLS. This
document changes some of the structures used in that document. This
section details the required changes for implementors of both RFC
4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing
RFC 4492 do not need to read this section.

This document adds a "signature_algorithm" field to the digitally-
signed element in order to identify the signature and digest
algorithms used to create a signature. This change applies to
digital signatures formed using ECDSA as well, thus allowing ECDSA
signatures to be used with digest algorithms other than SHA-1,
provided such use is compatible with the certificate and any
restrictions imposed by future revisions of [PKIX].

As described in Sections 7.4.2 and 7.4.6, the restrictions on the
signature algorithms used to sign certificates are no longer tied to
the cipher suite (when used by the server) or the
ClientCertificateType (when used by the client). Thus, the
restrictions on the algorithm used to sign certificates specified in
Sections 2 and 3 of RFC 4492 are also relaxed. As in this document,
the restrictions on the keys in the end-entity certificate remain.

In particular RFC 5246 4.7 Cryptographic Attributes

A digitally-signed element is encoded as a struct DigitallySigned:

  struct {
     SignatureAndHashAlgorithm algorithm;
     opaque signature<0..2^16-1>;
  } DigitallySigned;

The algorithm field specifies the algorithm used (see Section
7.4.1.4.1 for the definition of this field). Note that the
introduction of the algorithm field is a change from previous
versions. .... RSA .... DSA ....

Additional points:

• the server signs its ECDHE public key and the curve (which in practice, especially for Suite B, is named form rather than explicit, thus quite small) (edit, thanks David) as well as the nonces, with at least the client nonce proving freshness

• Suite B requirements are set by NSA not NIST. IIRC Suite B required SHA256 and SHA384 before NIST "deprecated" SHA1.

• RFC 5430 was obsoleted by RFC 6460 which requires TLS1.2 and GCM as well as ECDHE-ECDSA.