[TLS] TLS Performance (was Re: draft-ietf-tls-cached-info-02 / New "Fast-Track" draft posted)

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

Brian Smith wrote:
> Michael D'Errico wrote:
>> On my
>> test server, people have established connections in less than 40 ms
>> using a full handshake.  Most handshakes from around the world
>> complete in less than half a second.  Don't get too carried away
>> trying to optimize this, especially if you're not able to maintain
>> the security guarantees.
> 
> Half a second is not an acceptable latency for many applications, especially
> over GPRS (even "3G"/"4G") connections. I developed my own HTTP+TLS stack
> for a mobile app just to reduce the latency to acceptable levels. Plus,
> ephemeral key exchange can add noticeable latency when the client's
> processor is weak--which again is the case especially for mobile apps. (The
> OS's TLS stack didn't provide adequate control over the session cache,
> didn't support compression, and didn't support session tickets.) 

I'm only in control of one side of the TLS connection in the numbers I
presented, so some of the delay can be attributed to the client software.

I just did some tests on my MacBookPro to eliminate the uncertainty of
the client software and the network latency factor.  Here are the times
to establish a full handshake for a few cipher suites:

     003D - RSA (1024) AES-256 SHA-256 + session ticket:            10 ms
     003D - RSA (1024) AES-256 SHA-256 (normal session):           8.5 ms

     006B - DHE_RSA (1024/1024) AES-256 SHA-256 + session ticket:   72 ms
     006B - DHE_RSA (1024/1024) AES-256 SHA-256:                    71 ms

     006A - DHE_DSS (1024/1024) AES-256 SHA-256 + session ticket:   72 ms
     006A - DHE_DSS (1024/1024) AES-256 SHA-256:                    71 ms

when the DH parameters are 1536-bit:

     006B - DHE_RSA (1536/1024) AES-256 SHA-256 + session ticket:  202 ms
     006B - DHE_RSA (1536/1024) AES-256 SHA-256:                   201 ms

So you can see that forward secrecy costs a lot in terms of latency, even
for a fast processor.

The timing for session resumption is independent of the key exchange
mechanism:

     AES-256 SHA-256 + session ticket:        4.2 ms
     AES-256 SHA-256:                         1.2 ms

Here you can see that server-side session caches are considerably faster
than session ticket resumption (at least in my code).

> Latency concerns seem to be a strong motivation for people to develop new
> protocols less secure than TLS like OAuth, and to choose non-ephemeral
> key-exchange over ephemeral key exchange. A safe zero-roundtrip
> handshake--even just for resumption--would make TLS practical for many more
> applications and would reduce pressure for apps to provide the user a switch
> to "turn off security" as many mobile apps are doing. If Adam or anybody
> else has already tried to work out a mechanism for that, I'd love to hear
> about it.

What you are trying to do is not bad, but it doesn't seem to fit well
with the existing TLS protocol.  It seems like you want the client to
send a "packet" to the server, which simultaneously authenticates the
server, establishes the keys, and delivers a payload.  I'm not sure
that trying to twist TLS into this shape is the correct approach.

Mike