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

["Brian Smith" <[e-mail]>]

Michael D'Errico wrote:
> Adam Langley wrote:
> > However, there's a much easier way of doing this: cut through mode.
> > In this scheme the client starts sending application data records
> > without waiting for the server's Finished message so long as the
> > ciphersuite is sufficiently strong. Android already does this.
> 
> I'm not a cryptographer, but it seems to me that sending data over
> the connection before it is validated is a very bad idea.  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.) 

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.

Cheers,
Brian