Subject: Re: [TLS] Updated TLS 1.2 I-D

From: Rob Dugal <[email-masked]>
Date: Thu, 6 Jul 2006 09:49:23 -0400

7.4.3. Server key exchange message

<snip>

   If the SignatureAlgorithm being used to sign the ServerKeyExchange
   message is DSA, the hash function used MUST be SHA-1. If the
   SignatureAlgorithm it must be the same hash function used in the
   signature of the server's certificate (found in the Certificate)
   message. This algorithm is denoted Hash below. Hash.length is the
   length of the output of that algorithm.

Something is missing in this sentence  "If the SignatureAlgorithm it must 
be the " 

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: [email-masked]
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

Eric Rescorla <[email-masked]> wrote on 06/25/2006 12:54:30 PM:

> I've submitted an update TLS 1.2 I-D an in the meantime
> you can find it at:
> 
> http://scm.sipfoundry.org/rep/ietf-drafts/ekr/tls/tls.txt
> 
> The big thing I know is misisng is replaceable PRFs, which
> I wanted to discuss on the mailing list before I put in.
> As people will recall, there was a consensus on replaceable
> PRFs/KDFs in Dallas but we didn't discuss exactly how to do
> them.
> 
> My proposal is as follows:
> 
> - All PRFs must have the same "API" as the existing TLS 
>   PRFs.
> - New cipher suites MAY have as part of their specification
>   a new PRF.
> - There is no way to separately negotiate a new PRF for
>   an existing cipher suite.
> 
> The major alternative is some kind of extension, which makes
> me uncomfortable. 
> 
> Thoughts? Issues?
> -Ekr
> 
> 
> 
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: "Gregory Chudov" <[email-masked]>
Date: Fri, 14 Jul 2006 10:19:38 +0400

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:

1) First situation is a constrained client, which uses
client_certificate_url extension, and doesn't have to know it's own
certificate, only it's own private key. The heuristic that you propose
forces this client to also know the hash algorithm used by CA.

2) The second situation is a simple client implementation which
supports only one hash function. This paragraph forces it to support
also the hash functions, which were used by CA to sign his
certificates.

3) The third situation is this: a client posesses a certificate,
issued by a CA with a good hash function, which is not yet supported
by TLS HashType enum (e.g. SHA384). Certificate Request message, which
now contains a list of supported hash types, cannot contain such a
value, so the client is forced not to use such a certificate.

My proposition is:

1) Change the structure of the CertificateVerify message to reflect
the change to CertificateRequest:

       struct {
            HashType hash_type;
            Signature signature;
       } CertificateVerify;

Change the text to following:

       The Signature type is defined in 7.4.3. Client chooses a hash function
       (denoted Hash) from the list, contained in the
CertificateRequest.certificate_hash to
       create the signature for the client's certificate, and
specifies it's type in the
       CertificateVerify.hash_type field.

       CertificateVerify.signature.hash
           Hash(handshake_messages);

2) I think, the role of the CertificateRequest.certificate_hash list
must be clearly stated in the draft.

I see 3 possible choices:
a) it is provided to the client as a guidance
b) the server MUST verify that the CertificateVerify message uses one
of the hash_types that it proposed
c) the server MUST verify that the CertificateVerify message AND the
client certificate chain uses only the proposed set of hashes

I would strongly prefer the "b" case, because the "a" case can lead to
the sitiuation where the server cannot verify client's signature, and
the "c" case forces us to specify HashTypes for all the hash functions
supported by PKIX (see the 3d situation above).

The only alternative i see to this set of changes is to omit the
certificate_hash list from CertificateRequest completely, and state
that the Hash function is chosen by the cipher suite.

Regards,
Greg Chudov

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 14 Jul 2006 12:04:32 +0200

> 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.)

> 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.)