Re: [TLS] First TLS cached information draft posted

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

Simon,

Simon Josefsson wrote:
> 
> Min Huang <huangmin123 at huaweisymantec.com> writes:
> 
> > This "heuristic" determination works well in most scenarioes, 
> > but the client still be confused in some specific cases.
> 
> Hi.  Yes.  I don't like TLS implementations playing guessing games on
> the intended interpretation of received data, though, and that is my
> primary concern with this document right now.  I'm wondering how other
> implementers feel about this, is it acceptable?

What you could do, is to unconditionally use an additional framing
for that being-cached parts of the TLS handshake messages for
for which the Client requested caching in the ClientHelloExtension
and and the Server acknowledged caching support in the
ServerHelloExtension.

(I'm not really accustomed to TLS spec language, so please
 apply common sense / corrections yourself):

enum {
   original_data(1),
   hash_over_original_data(2),
   omitted_hash_over_original_data(3),
   original_data_and_suggestion_to_not_cache(4),
   (255)
} CacheControlContentType;

struct {
   CacheControlContentType    type;
   opaque                     content<0..2^16-1>;
} CacheControlContent;

   
...and drop the things that are not needed (but mentioned for completeness)


This approach would unconditionally change the (affected) PDU if caching is
negotiated but hashes do not match (as well).  It facilitates to omit
the actual hash value at this point in a non-ambiguous fashion
(the hash should be part of the handshake once, but having it
three times looks like waste). 

-Martin