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

[Martin Rex <[e-mail]>]

Nikos Mavrogiannopoulos wrote:
> 
> On Thu, Feb 10, 2011 at 10:49 AM, Peter Gutmann
> <[e-mail]> 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 :)

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