Re: [TLS] First TLS cached information draft posted

[Martin Rex <Martin.Rex at sap.com>]

Simon Josefsson wrote:
> Martin Rex wrote: 
> > The impact on implementations of TLS should be as small as possible.
> > To me, a requirement for a TLS server to precompute hashes over
> > parts of future handshake messages during ServerHello looks like
> > a significant additional burden, and personally, I do not yet see
> > any benefit this might provide.
> 
> Good point, but how would a client know whether a server replaced the
> cached information with a hash or not if there is no signaling whether
> this happened or not?

The client knows which Hash it would find, if the server would sent
the hash, so it could check for that.  Even a collision of the
hash and the original handshake data would not cause a problem
with this "heuristical" determination.

I'm wondering about the following: we should give a strong recommendation
about the minimum size of an object in order for caching to make any
sense at all, like >= 2x the size of the hash.

At least 2x, because the hash appears (at least) twice in a full SSL
handshake (ClientHello and the actual handshake message with the
cached information).

For a SSL session resume, the extension will create an unconditional
burden, because the ClientHello extension would need to be present
in every ClientHello, in order to actually save on the full handshake
in case the server decides to require one (e.g. session expired on
server side).

Maybe the minimum size should be rather 3x hash size, considering
the rest of the protocol overhead.


-Martin