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

[Juho Vähä-Herttua <[e-mail]>]

On 18.2.2011, at 21.28, Martin Rex wrote:
> So this part of rfc-5246 purports to solve a problem that actually
> does not exist in earlier versions of TLS.  The "solution" that
> TLSv1.2 alleges to provides looks more like a cumbersome
> limitation to me.  While there is zero problem of using certificate
> chains with arbitrary mixtures of signature algorithms in TLSv1.1
> and prior, this doesn't work anymore when negotiating TLSv1.2,
> in particular for signature algorithms which can not be represented
> with the code points of TLSv1.2.

This discussion has been going on for quite long, but I just want to mention that I support Martin here and I don't think I have seen a good response yet. I found the same issue a bit weird when I was going through the TLSv1.2 specification, but it wasn't relevant at the time so I just ignored and forgot it.

Forcing the TLS implementation to buffer all handshake messages is one thing that probably a performance problem in TLSv1.2, but it's not a compatibility issue and as someone said fixing it would require releasing TLSv1.3. However I don't see ANY sensible reasons why TLS would care about which signature algorithm is used for signing the actual certificate. As long as the certificate contains the keys necessary to sign the key exchange it should be fine just like it was before.

Yes, it might be possible for a client to for example only support one single hash and one single signature algorithm, which is most likely a combination included in signature_algorithms. In that case, I would support that the server SHOULD choose the certificate chain according to the sent signature_algorithms if possible. However if there is no such certificate chain available, it MUST continue the handshake by sending some valid certificate. The server has no way to know if the client can verify certificate chains outside the defined TLS signature algorithms, therefore it would be plain stupid for the server to abort the handshake just because it has a certificate which is signed with an algorithm not supported by TLS. (especially if both sides can handle it)

I don't think changing this from MUST to SHOULD would cause major compatibility issues, because for TLSv1.0 and TLSv1.1 the clients need to prepare for any kinds of certificates anyway. If someone has actually written code that rejects certificates that don't match the sent signature_algorithms it might cause an error, has anyone on this list written that kind of code or seen it anywhere? Personally I find the meddling with certificate signature hash and type annoying enough that I am inclined to ignore it, even if that means incompatibility....


Juho