Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft

It seems like an unnecessary complexity.

The original approach have two functions
1) Client informs the server what information it has cached
2) Server accepts caching and replaces the data with the hash provided by
the client

In the alternative approach this is expanded to:
1) The client tells server that it wants to cache data
2) The server provides hashes/identifiers of info the client may cache
3) The client signals that it has cached info with identifiers provided by
the server
4) The server replaces cached data

I see no reason to make the protocol any more complex than it need to be.

/Stefan

On 10-03-01 6:47 AM, "Joseph Salowey (jsalowey)" <jsalowey@cisco.com> wrote:

> Hi Stefan,
> 
> What is the disadvantage if the client cannot cache information from a
> handshake in which the server does not include the hash?
> 
> Thanks,
> 
> Joe
> 
>> -----Original Message-----
>> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
>> Stefan Santesson
>> Sent: Friday, February 26, 2010 4:11 AM
>> To: Simon Josefsson; Brian Smith
>> Cc: tls@ietf.org
>> Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track"
> draft
>> 
>> Simon and Brian,
>> 
>> On 10-02-26 10:38 AM, "Simon Josefsson" <simon@josefsson.org> wrote:
>> 
>>>> My second suggestion is to have the server calculate the hash, and
>>>> give the calculated hash to the client along with the content. Then
>>>> the client and the server don't have to agree on any algorithms at
>>>> all, and the server can choose whatever algorithm it wants.
>>> 
>>> I like this approach.  The server gets to chose the hash, and the
> client
>>> will have to comply.  It is easy to implement, and it is possible to
>>> transition to other checksum algorithms over time.
>> 
>> 
>> I'm sorry, but this seems like a really bad idea.
>> 
>> The idea of this draft is that a client should be able to cash
> information
>> form a perfectly normal handshake (one where the server does not
> provide a
>> hash that may represent what it sends).
>> 
>> /Stefan
>> 
>> 
>> 
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls