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

[Martin Rex <[e-mail]>]

Michael D'Errico wrote:
> 
> > It is extremely rare for TLS clients and servers to actually negotiate
> > TLSv1.2, and I currently do not expect this to change significantly
> > during the next couple of years.
> > 
> > There seem to be two reasons for this:
> > 
> >   - at least one vendor sees a performance problem with enabling
> >     TLSv1.2 for the server by default
> 
> This is not a problem with TLS 1.2 itself, but of that vendor's
> implementation of it.  My server shows virtually no difference in
> throughput for any SSL/TLS version, though SSL3 is a tiny bit
> slower than the rest.  This could be explained by the slightly
> more complicated MAC computation in SSLv3 vs HMAC in TLS.

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