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

["Joseph Salowey (jsalowey)" <[e-mail]>]

It looks to me that the client-side hash computation option is simpler if we don't try to build in agility and negotiation.  If we feel we need these then having the server assign an identity for these values seems simpler. 

Joe

> -----Original Message-----
> From: Brian Smith [mailto:[e-mail]]
> Sent: Monday, March 01, 2010 6:29 AM
> To: Stefan Santesson
> Cc: Joseph Salowey (jsalowey); Simon Josefsson; [e-mail]
> Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft
> 
> Stefan Santesson wrote:
> > 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.
> >
> In the alternative approach, there is no need to pass multiple hashes of
> the same item back/forth, so the syntax becomes simpler. Also, the
> client and server do not have to agree on a hash algorithm at all, which
> is a big simplification. The client doesn't have to calculate anything,
> which is a further simplification.
> 
> Many clients won't want to cache this information unless the server says
> that it supports the extension. That is why Adam Langley and others have
> asked for a ServerHello extension that indicates the items for which the
> server supports caching. It is very easy for the server to just stuff
> the identifiers inside that extension.
> 
> Regards,
> Brian