[TLS] Signature Hash Agility

[Eric Rescorla <ekr at networkresonance.com>]

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
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls