Subject: [TLS] DSS with other than SHA-1 algorithms

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 10 Feb 2011 09:11:52 +0100

Hello,
 According to FIPS-186-3 the DSA algorithm might
be used with hashes other than SHA-1. Moreover
it mentions:
"A hash function that provides a lower security strength than the (L, N)
pair ordinarily should not be used, since this would reduce the
security strength of the digital signature process to a level no greater
than that provided by the hash function."

So what I understand from that is for the parameters
discussed in the document the SHA variants allowed are:

L = 1024, N = 160: SHA-1 or better
L = 2048, N = 224: SHA-224 or better
L = 2048, N = 256: SHA-256 or better
L = 3072, N = 256: SHA-256 or better

How does this apply to TLS 1.0 and 1.1 messages
"Server Key Exchange" and "Certificate verify"
that sign the handshake data? How is the peer
going to understand which hash is being used?

For TLS 1.2 I suppose that the hash being negotiated
by the signature algorithm extension will be used,
and if it is larger than N, then it will be truncated.

So is my understanding of TLS 1.2 negotiation for DSA
correct? How do you solved the issue in TLS < 1.2?

regards,
Nikos

---

From: Martin Rex <[email-masked]>
Date: Thu, 10 Feb 2011 15:03:39 +0100 (MET)

> going to understand which hash is being used?

By looking at the AlgId parameters of the DSA public key that
is involved in the signature operation.  The public prime q, whose
length (in bits) is described by the Parameter N above, is part of the
AlgId Parameters of that DSA public key.  (The L refers to the length
(in bits) of the public prime p, also part of the AlgId Parameters).

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 10 Feb 2011 16:03:23 +0100

>> than that provided by the hash function."
[...]
> (in bits) of the public prime p, also part of the AlgId Parameters).

The problem is that FIPS-186-3 says you can use SHA-224
if N=224, or SHA-256 and truncate it to 224 bit. So the algorithm
needs to be explicit here...

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 10 Feb 2011 16:05:15 +0100

On Thu, Feb 10, 2011 at 10:49 AM, Peter Gutmann
<[email-masked]> wrote:

>>How does this apply to TLS 1.0 and 1.1 messages "Server Key Exchange" and
>>"Certificate verify" that sign the handshake data? How is the peer going to
>>understand which hash is being used?
> It's always SHA-1.

So here there is a choice either to violate FIPS-186-3 or TLS 1.0. If you use
SHA-1 you violate the FIPS-186-3, but if you don't you violate TLS 1.0
that requires 20 bytes of SHA-1... Quite some situation :)

regards,
Nikos

---

From: Dr Stephen Henson <[email-masked]>
Date: Thu, 10 Feb 2011 15:08:41 +0000

> that requires 20 bytes of SHA-1... Quite some situation :)

FIPS 186-3 also makes comments about RSA too, you can have just as much fun with
those.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 10 Feb 2011 17:05:59 +0100

On Thu, Feb 10, 2011 at 4:46 PM, Peter Gutmann
<[email-masked]> wrote:
>>SHA-1 you violate the FIPS-186-3, but if you don't you violate TLS 1.0 that
>>requires 20 bytes of SHA-1... Quite some situation :)
> Not really, use of DSA server certs is practically nonexistent (anyone want to
> trawl through the EFF cert database to count them?) and use of "DSA2" (i.e. >
> 1 kbit key) certs AFAIK *is* nonexistent, so it's nothing to worry about.  To
> look at it another way, worrying about this is like worrying about what colour
> unicorns are.

Well, it is chicken and egg problem. If they cannot be used in practice with any
application because the spec is not clear, no-one will use them. If the spec was
clear, and interoperable implementations could be made then, someone could
apply for a certificate with a DSA key. But anyway since it's supposed to
be supported by TLS, it should be clarified, otherwise it's better to drop it
completely...

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 10 Feb 2011 17:49:46 +0100

[...]
> and if it is larger than N, then it will be truncated.

I've tried to clarify a bit the issues and make a "best
current practice text":
http://homes.esat.kuleuven.be/~nikos/draft-mavrogiannopoulos-tls-dss.txt

Does this clarification match with what other implementations
have done in supporting DSA? (in gnutls for example we didn't
truncate the hash, if a larger hash was available to be selected, but
rather use the next available...), Would be better if truncation be
avoided at all?

regards,
Nikos

---

From: Martin Rex <[email-masked]>
Date: Thu, 10 Feb 2011 18:07:53 +0100 (MET)

> that requires 20 bytes of SHA-1... Quite some situation :)

Honestly I don't know how DSA signatures work in TLS, but a quick
glance looks confusing.

  http://tools.ietf.org/html/rfc2246#section-4.7

  In DSS, the 20 bytes of the SHA hash are run directly through the
  Digital Signing Algorithm with no additional hashing. This produces
  two values, r and s. The DSS signature is an opaque vector, as above,
  the contents of which are the DER encoding of:

       Dss-Sig-Value  ::=  SEQUENCE  {
            r       INTEGER,
            s       INTEGER
       }

The Dss-Sig-Value looks like the varying-size ASN.1 blob used in
X.509 certs and PKCS#7 (rather than the fixed octet string DSA signature
blobs that are used e.g. in XMLdsig).

Both values r and s are the result of a modulo (prime q) operation,
so their size depends on the size of the (prime q) parameter of the
DSA key rather than the hash algorithm.  Since ASN.1 DER encoding
suppresses leading zero octets may add a an octet for a positive sign,
the resulting size of this Dss-Sig-Value varies slightly.

The description "In DSS, the 20 bytes of the SHA[-1] hash are run directly
through the Digital Signing Algorithm with no additional hashing."
is limited to using (L=1024,N=160) DSA keypairs.

A reasonable and straight-forward approach to allowing the other three
DSA key sizes from FIPS 186-3 (L=2048,N=224), (L=2048,N=256),
(L=3072,N=256) with protocol version SSLv3 {0x03,0x00},
TLSv1.0 {0x03,0x01} and TLSv1.1 {0x03,0x02} would be to use the
respective smallest hash (SHA-224, SHA-256, SHA-256) for
calculating the hash in the underlying Signature struct defined here

   http://tools.ietf.org/html/rfc4346#page-44

This seems to be what the ECC cipher suite spec (rfc4492) for TLSv1.0/v1.1
appears to suggest doing, so it seems reasonable to do just the same
for the DSA key sizes >1024 bit from FIPS 186-3.

   http://tools.ietf.org/html/rfc4492#page-20

          enum { ecdsa } SignatureAlgorithm;

          select (SignatureAlgorithm) {
              case ecdsa:
                  digitally-signed struct {
                      opaque sha_hash[sha_size];
                  };
          } Signature;

        ServerKeyExchange.signed_params.sha_hash
            SHA(ClientHello.random + ServerHello.random +
                                              ServerKeyExchange.params);

   NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange
   algorithm and "anonymous" for ECDH_anon.  These cases are defined in
   TLS [2][3].  SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA.  ECDSA
   signatures are generated and verified as described in Section 5.10,
   and SHA in the above template for sha_hash accordingly may denote a
   hash algorithm other than SHA-1.  As per ANSI X9.62, an ECDSA
   signature consists of a pair of integers, r and s.  The digitally-
   signed element is encoded as an opaque vector <0..2^16-1>, the
   contents of which are the DER encoding [9] corresponding to the
   following ASN.1 notation [8].

-Martin