Re: [TLS] First TLS cached information draft posted

[Simon Josefsson <simon at josefsson.org>]

Here is a modified idea.  Replace the CachedInformationHash with this
structure:

struct {
           HashAlgorithm hash;
           uint32 datasize;       /* NEW.  Size of hashed data.
                                     MUST be >= 4 * hashsize(hash) */
           opaque hash_value<0..255>;
      } CachedInformationHash;

The server respond by indicating whether it supports cached data in
principle, but defers until later in the handshake to decide whether to
replace data or not.  This addresses Martin's concern.

Then add text to say that datasize MUST be >= 4 * hashsize(hash) where
hashsize is the hash output size, i.e., 20 for SHA-1.  Smaller objects
cannot be cached with this extension.

The server can decide, when constructing later handshake packets,
whether to replace the generated data with a hash or not.  Typically,
the server would generate the data as normal.  Then if the client
provided a cache extension type for the object, it will compare a hash
of the generated data with the hash provided by the client.  If they
match, it will send the CachedInformationHash value instead of the
generated data.

The client parses the response, and can by looking at the size of each
object decide whether it is a hash or real data.

This runs into a problem if the server instead of returning a hash
returned data that was considerably smaller than the value cached by the
client.  The client could then be confused whether the returned data is
real data or a hash value.  A type-specific tag could be constructed
here -- for both certificate_list and certificate_authorities it could
be some invalid ASN.1 followed by the CachedInformationHash.

This is a compromise, but it seems difficult to solve both Martin's
concern and my concern that clients needs to reliably be able to decode
incoming data.  Better ideas welcome.

/Simon