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

[Nikos Mavrogiannopoulos <[e-mail]>]

On 02/19/2011 02:06 AM, Michael D'Errico wrote:
> The point of the signature_algorithms extension is to permit a graceful
> upgrade of server certificates to using better than SHA-1 hash functions.
> You couldn't just suddenly switch your server cert to one signed with
> RSA/SHA-256 and expect every client to cope.  It would certainly cause
> problems for some.
> To benefit from the extension, you would need to have two concurrent
> server certificates: one signed with RSA/SHA-1, and another signed with
> RSA/SHA-256.  Then based on the signature algorithms presented by the
> client, your TLS code would choose the best one.

It's pretty bad that a single extension is being used for two
distinct use-cases[0]. The use cases are:
* Negotiate which signature algorithms to use for Server Key Exchange,
and Certificate Verify messages.
* Specify the signature algorithms allowed by a certificate sent
by the server.

There is no reason to assume that these are related. The first
use-case applies to the server and client since they are the
ones doing the signing. On this use case a reply to this
extension with the selected algorithm is required to avoid
caching all messages up to the point of signing.

The latter use-case is relevant to the client only, and says,
I don't accept a certificate that is not signed with any
of these algorithms. The server however obtains his
certificate already signed through a 3rd party (a CA), so there
is little to do in the general case.  This use-case does
not require a reply to the extension from the server.

I think that those extensions could be split into two to
account for the different use-cases.

regards,
Nikos

[0]. What if I have a security module doing TLS that
supports only RSA-SHA256 for signatures, but I have
no restriction for the verification of the certificates
since this is done outside of the module?