Re: [TLS] First TLS cached information draft posted

Thanks for all the analysis and proposals.

Unfortunately I have been on constant travel and meetings since Monday
morning and it is not over until tomorrow night when I get home again.

I will go through this more carefully then and get back to you no later than
Monday.

/Stefan

On 09-06-10 11:04 PM, "Simon Josefsson" <simon@josefsson.org> wrote:

> Martin Rex <Martin.Rex@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
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls