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

[Adam Langley <[e-mail]>]

On Tue, Feb 2, 2010 at 3:50 AM, Brian Smith <[e-mail]> wrote:
> I am very interested in the ideas that motivate the cached info extension.
> It obviously makes sense for the client to tell the server that it already
> knows the certificate, so that the server doesn't have to send the
> certificate.

Indeed. I've been bugging the author of this draft to update it
somewhat(*) and repost here. I've also written implementations for
OpenSSL and NSS. Hopefully life can be injected into this draft.

(* Martin Rex requested that the server inform the client of the
degree of its support for cached-info, to save the clients uselessly
caching information. This seems like a good idea)

> But, if the client already knows the certificate, then it
> already knows the server's public key. Consequently, it is wasteful for the
> client NOT to send the ClientKeyExchange along with the client hello.

Given a client-speaks-first protocol like HTTP (which I happen to be
mostly concerned with), this could cut the full handshake from two to
one round trips.

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.

However, with cached certificates it's possible to get a full
handshake down to 0-RTT if the client can choose the server's random.
This means that the server has to be able to assert that it will never
reuse the same random, but that's doable if you assume some degree of
clock synchronisation and client-cached epoch values.

This idea has been banging about for a while now and you're the second
person that I've seen mention something similar in a week. I intend to
start experimenting with this, hopefully this quarter.


AGL