[TLS] TLSv1.2 with DSA client cert and key size >1024 bits

[Martin Rex <[e-mail]>]

Dear implementors of TLSv1.2,

The use of TLSv1.2 with DSA client certs using key lengths > 1024
as defined by FIPS 186-3 appears slightly underspecified.
I would like to find out what current implementations of TLSv1.2
are doing -- and what they are doing when negotiating a protocol
version less that {0x03,0x03}.

The base protocol spec does not define what to do with a (L=2048,N=224),
(L=2048,N=256) or (L=3072,N=256) DSA key from FIPS 186-3 in a client cert
in TLSv1.1.  rfc4492 Page 20 provides a hint for how to represent
ECDSA signature values with hash algorithms other than SHA-1 but
does not describe a means to indicate to the receiver, which
other hash was actually used.

I think it would be sensible to imply SHA-256 whenever the DSA key
that is used for signature verification, does not allow creation of
SHA-1 based signatures according to FIPS 186-3, but does allow
creation of SHA-256 based signatures.  Avoiding SHA-224 entirely
would facilitate the Server Side verification of the CertificateVerify
handshake message with DSA client certificates using key sizes > 1024
for protocol version < TLSv1.2.


All TLS protocol specification (TLSv1.0->TLSv1.2 & SSLv3) share a
text that is limited to SHA-1 in Section 4.7 Cryptographic Algorihms:

   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 hint from rfc4492 "ECC Ciphersuites for TLS" about SHA/sha_hash not
being limited to SHA-1/20-octets did not make it into TLSv1.2, so the
situation is still somewhat undefined for the TLS protocol versions
that are actually being negotiated and used on the internet.

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

                                                                 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. 


There was a change in the representation of a digitally signed element
between TLSv1.2 and TLSv1.1&prior, which avoids the problem of not
really knowing the signature algorithm that was used for (EC)DSA,
in that digital signatures are now explicitly tagged in TLSv1.2:

up to TLSv1.1    http://tools.ietf.org/html/rfc4346#section-4.7

   In digital signing, one-way hash functions are used as input for a
   signing algorithm.
                       A digitally-signed element is encoded as an
   opaque vector <0..2^16-1>, where the length is specified by the
   signing algorithm and key.


TLSv1.2          http://tools.ietf.org/html/rfc5246#section-4.7

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

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


The latter is building on the definitions from the SignatureAlgorithm
TLSv1.2 extension: 

    http://tools.ietf.org/html/rfc5246#section-7.4.1.4.1

      enum {
          none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
          sha512(6), (255)
      } HashAlgorithm;

      enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
        SignatureAlgorithm;

      struct {
            HashAlgorithm hash;
            SignatureAlgorithm signature;
      } SignatureAndHashAlgorithm;


-Martin