Re: [TLS] Updated TLS 1.2 I-D

On Fri, Jul 14, 2006 at 10:19:38AM +0400, Gregory Chudov wrote:

> Concerning Certificate Verify message:

>>      If the SignatureAlgorithm
>>      is DSA, then the sha_hash value must be used. If it is RSA,
>>      the same function (denoted Hash) must be used as was used to
>>      create the signature for the client's certificate.

> This doesn't look reasonable.
> 
> Aside from general "bad feeling" about this, i have at least three
> examples in which this causes trouble:
[...]

Also, sha_hash is a SHA-1 hash, but the FIPS 186-3 (Digital Signature
Standard) draft also provides for use of the longer SHAs from FIPS
180-2 for prime moduli over 1024 bits.  (The subgroup size determines
the recommended SHA variant, although it can be agreed to use stronger
hash functions with truncation.)

> My proposition is:
> 
> 1) Change the structure of the CertificateVerify message to reflect
> the change to CertificateRequest:
[...]

My suggestion is different:

Don't change the definition of CertificateRequest in the first place,
i.e. don't introduce HashType in the first place.  Keep the
definitions of the rsa_sign and dss_sign client authentication methods
as in current TLS versions, but define new client authentication
methods where the hashing is done differently.

There could be something like dsa_sign_fips_186_3 where hashing is
done as recommended in FIPS 186-3 (here I'm hoping that this actually
gets standardized within a reasonable timeframe).

There are only aesthetical reasons to get rid of the current MD5/SHA-1
concatenation in RSA client authentication.  Authentication can only
broken if the attack succeeds in real time (and this requires a second
preimage, not just a collision!).  As long as we have the current
Finished message (which involves MD5 anyway, so no implementation can
do without it), not much speaks against leaving RSA signing as it is
now.  However, here too we could add a FIPS 186-3 variant, meaning
that depending on the modulus size a wider SHA can be used, adopting
the "security strength" for RSA moduli from NIST SP 800-57 to obtain
the appropriate SHA variant.  (I.e., SHA-1 up to 1024 bits, SHA-224 up
to 2048 bits, SHA-256 up to 3072 bits, SHA-384 up to 7680 bits,
SHA-512 up to 15360 bits.)

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls