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

["Kyle Hamilton" <[e-mail]>]

On Fri, Feb 18, 2011 at 2:39 PM, Juho Vähä-Herttua <[e-mail]> wrote:
> On 18.2.2011, at 21.28, Martin Rex wrote:
> 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.

Because TLS is the layer where communications policies are negotiated.  The client is informing the server that (e.g.) it doesn't accept MD5 as a valid hash algorithm for realtime communication.  If it doesn't accept it for realtime communication, there is also no reason to accept it for an offline proof -- because an attacker has that much more time to find a preimage.

> 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)

Two reasons why this is inappropriate.  First, if the server doesn't have a certificate chain the client will accept, it doesn't need to waste the bandwidth (it doesn't need to broadcast the server's details to someone who won't accept them anyway).  Second, TLS already specifies a valid unauthenticated mode.  The only reason why unauthenticated modes are unpopular is because of the commonly-held view of "if you don't know who you're talking to, what's the point?"

-Kyle H