Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and

[Michael D'Errico <[e-mail]>]

I see the potential problem.  For me, though, I just hold onto all of
the handshake messages until the handshake concludes.  It may use a bit
more memory for a short amount of time, but the issue you raise is
completely avoided.  Call it a space <-> code complexity trade-off.

In TLS 1.2, a CertificateRequest message is where the server tells the
client which signature algorithms are acceptable.  I don't think it's
allowed to be an empty list, but if it is, the sensible thing to do is
to assume the same hash functions are supported as previous versions
which didn't have that parameter.  In other words choose rsa/sha1,
rsa/md5 or dsa/sha1.

This issue would have been avoided if the supported_signature_algorithms
extension was symmetric and allowed the server to specify its list of
algorithms in a ServerHello extension.  Alas, that was not the design
we ended up with.

Mike



Martin Rex wrote:
> 
> The more I think about it, the more I believe it is, in fact, a
> design flaw in TLSv1.2 responsible for a handshake performance issue
> (at least when a client certificate is requested).
> 
> 
> While the PRF was changed from SSLv3->TLSv1.0, there was no change to
> the CertificateVerify handshake message.  So for creating and
> verifying a CertificateVerify handshake message, two hashes must
> be maintained over all handshake messages:  MD5 + SHA1.
> 
> With TLSv1.2, if a server does not want to artificially limit the
> signature algorithms on acceptable client certificates, it must
> send a long list of acceptable combinations
> 
> (sha1,rsa), (sha1,dsa), (sha256,rsa), (sha384,rsa), (sha512,rsa),
> (sha224,dsa), (sha256,dsa), ...
> 
> So unless both, server and client must either hold on to all handshake
> messages up to CertificateVerify or carry along hash contexts for all
> of the possible algorithms.
> 
> Compare:
>    SSLv3, TLSv1.0/1.1  md5 + sha1
>    TLSv1.2             md5 + sha1 + sha224 + sha256 + sha384 + sha512
> 
> If you look at this list, look at how TLS uses hashes for digital
> signatures and think about the algorithmic relationships between
> sha224&sha256 and between sha384&sha52, then sha224 and sha384
> are utterly useless fifth and sixth wheel on the TLS cart.
> For TLS itself, sha256 -- or maybe even sha256 alone would have
> been PERFECTLY sufficent, and a LOT less work.
> 
> 
> What I also don't understand is the idea behind "default signature
> algorithms".  For implementing TLSv1.2, SHA-256 _must_ be supported,
> but unless explicitly negotiated with the TLS SignatureAlgorithm
> extension, SHA-256 appears not allowed to be used for CertificateVerify.
> 
> That would mean, when TLSv1.2 is negotiated, but no SignatureAlgorithms
> extension exchanged, the resulting signature with an RSA client cert
> in CertificateVerify no longer uses MD5+SHA-1 as in TLS up to v1.1,
> but _only_ SHA-1 (which slightly weakens that signature compared to
> prior protocol versions...).  The use of SHA-256 is prohibited!??!
> 
> Weird, really.
> 
> -Martin