Re: [TLS] First TLS cached information draft posted

[Simon Josefsson <simon at josefsson.org>]

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

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

I like this approach, it addresses both your and my original concerns.
Stefan, what do you think?

The resulting protocol is more complex with the above, but given that
the original proposal is unreliable, I think the complexity is warranted
here.

/Simon