Re: [TLS] First TLS cached information draft posted

[Min Huang <[e-mail]>]

Hi,Simon

This "heuristic" determination works well in most scenarioes, 
but the client still be confused in some specific cases. I think
adding a type-specific tag as you mentioned is a doable method, 
and it can solve the problems by now. 

And if we will construct a type-specific tag, the new "datasize" 
field in CachedInformationHash is still necessary? It seems not 
necessary any more. It can be a policy conformed by the client 
when caching data or sending a CachedObject.



regards,
Min






>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
simon wrote:


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