Re: [TLS] First TLS cached information draft posted

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

Simon Josefsson wrote:
> 
> Martin Rex <Martin.Rex at sap.com> writes:
>
> >Simon Josefsson wrote: 
> >> 
> >> 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.
> >
> > 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.

Not quite.

The caching extension is supposed to be generic, and the to-be-cached
real data may in some situations be quite short or even the same size
than the hash value (probably not for the server certificate caching,
but maybe for the list of certification authorities in the certificate
request message, which consists of distinguished names only, and
there could be just one very short DName (or none at all with TLS v1.1+)
 

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

There are several conceivable approaches, so we might want to weigh
the pros and cons for them.

 - out-of-band signalling, i.e. in the Server-Hello extension
    (++)  no ambiguity about what is sent, no matter what is acutually
          used as replacement in the encoded handshake message
    (---) would require server to pre-compute hashes over parts of future
          tls handshake messages when composing Server-Hello

 - in-band-signalling, i.e. a combination of the Server-Hello acknowledgement
   for principle support of caching a particular piece of information of
   the (full) SSL handshake plus a replacement tag that the client can
   recognize for the cached piece of information within the SSL handshake
   message in case the hash provided by the client matches the hash over
   the data that the server would normally send.

    (++) smaller impact on the overall architecture of the TLS
         implementation, because there is no requirement to precompute
         a hash over parts of a future tls handshake message

    (-) requires a sort-of heuristic determination whether the data
        encoded in a handshake message is real data or the replacement
        tag--be it a fixed short tag or the hash (pre-requisite: the
        client asserted the hash for cached information in ClientHello
        and the server acknowledged support for this in ServerHello)


-Martin