Subject: [TLS] Signature Hash Agility

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 Jun 2007 09:06:10 -0700

I'd like to try to figure out how we're going to handle hash agility in
signatures. See (http://www1.ietf.org/mail-archive/web/tls/current/msg00699.html)
for backgrouns:

 As I see it, there are five separate (but related) issues:

 1. How does the client communicate to the server what hash algorithms
    he will accept for signatures
 2. How does the server communicate to the client what hash algorithms
    he will accepts.
 3. How do the client and server communicate what hash algorithms they
    are using to make their signatures.
 4. What do we do about algorithms like DSA/ECDSA where you can't just
    swap hash algorithms around (i.e., where the signature does not
    verify the digest).
 5. Should the lists in 1, 2 be preference ordered?

Currently in the draft, the answer to these is:

 1. In the CertHashTypes extension.
 2. In the certificate_hash field of the CertificateRequest
 3. It's deterministic from the certificate.
 4. Sort of (3) but it's screwed up.
 5. They're not.

1. Client->Server
As I read the list traffic, nobody is objecting to (1), so I'm going to
table that for now.

2. Server->Client
Several people have suggested that they don't like (2). Simon Joseffson
has suggested that it should be an extension. Bodo Moeller that we should
simply define new ClientCertificateTypes values that would be (for
instance) dsa_sign_fips_186_3. 

So, my reasoning for why it shouldn't be in an extension is that there
is already a message where the server expresses his cert preferences.
Why split this information over two messages.

In response to Bodo, who writes:
	
	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.)

But of course, the Finished message will no longer use MD5 but rather
the cipher suite PRF. And recall that CertificateVerify doesn't
even use the PRF, but rather just hashes. So, I think a single
(new) hash function is what's appropriate here.

That leaves us to the question of whether it should be combined with
the certificate type or a separate field. This is tricky either way
because it's orthogonal for RSA but not orthogonal for DSA! That said,
I would prefer to err on the side of orthogonality and deal with the
DSA special case differently (see below).

3. Communicating the signature/hash algorithm you're using
So, I agree that trying to figure out the hash from the signature algorithm
in the cert was a mistake. We clearly need to explicitly name the 
digest algorithm in the message. However, previewing point (4), 
DSA keys need to be bound to one specific digest algorithm. Accordingly
I think the right structure is:

    struct {
        select (SignatureAlgorithm) {
            case anonymous: struct { };
            case rsa:
                HashType digestAlgorithm;       // NEW
                digitally-signed struct {
                    opaque hash[Hash.length];
                };
            case dsa:
                digitally-signed struct {
                    opaque sha_hash[20];
                };
            };
        };
    } Signature;

And note that we'll need DigestInfo encoding to protect against hash
substitution.

4. DSA hash selection
I claim it must be deterministic from the DSA SubjectPublicKeyInfo what hash
algorithm it is to be used with. Otherwise you risk substitution attacks.

5. Preferences
I'm fine with preference ordering, though I doubt it matters. I don't see what
it really improves.

-Ekr

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Mike <[email-masked]>
Date: Sat, 30 Jun 2007 13:11:12 -0700

> I'm fine with preference ordering, though I doubt it matters. I don't see what

When the server receives the client's list of hashes, the easiest thing
for it to do is to start at the beginning of the list, and progress
through it until it finds a hash it also supports.  Therefore, the best
thing for the client to do is to send the list in the order it prefers.
We already do this with cipher suites and compression algorithms, so
why not hashes?

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 30 Jun 2007 14:07:23 -0700

At Sat, 30 Jun 2007 13:11:12 -0700,
Mike wrote:
> through it until it finds a hash it also supports.

Well, that's fine if you want to favor the client's preferences
over your own, but it's just as reasonable to favor your preferences
in which case this doesn't help.

> Therefore, the best

As I said, I'm happy to do this. I just don't think it adds
that much value. 

-Ekr

---

From: Mike <[email-masked]>
Date: Sat, 30 Jun 2007 14:41:56 -0700

> in which case this doesn't help.

The way I look at TLS is that the client specifies the parameters for
the connection, and the server either obliges by using those parameters
or it refuses to negotiate.  The server asserts its preferences by not
negotiating algorithms it considers to be insecure.

> As I said, I'm happy to do this. I just don't think it adds

Perhaps not, but I think being consistent is important.  Also, the
alternative (saying that order is not important) will lead to slower
implementations since the server will be forced to sort the list to
find its preferred algorithm.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 30 Jun 2007 14:58:38 -0700

At Sat, 30 Jun 2007 14:41:56 -0700,
> negotiating algorithms it considers to be insecure.

Well, that may be the way your implementation works, but the standard
is silent on the server's selection algorithm, so the "server
preference" algorithm is equally compliant.

> find its preferred algorithm.

You're kidding, right? The server is about to do a digital signature.
The cost of searching through a list of probably < 5 entries to
look through your preferred choice (when your list is probably <5
entries) is totally trivial by comparison.

-Ekr