Re: [TLS] First TLS cached information draft posted

[Simon Josefsson <simon at josefsson.org>]

Martin Rex <Martin.Rex at sap.com> writes:

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

This seems like a good idea -- and it solves the problem in the client
to identify whether the server replaced the data or not.  If the minimum
size is 3x hash size, the client can look at the length of the data.  If
it is longer than 3x hash size, it knows the server opted out from
sending the hash.  If it is shorter than 3x hash size, it knows the
server actually did replace the data with a hash value.

It seems wasteful that the same hash value is sent back and forth
_three_ times during a handshake, and possibly that could be optimized.
But that would add complexity.

/Simon