Re: [TLS] Justification

[Nicolas Williams <[e-mail]>]

On Mon, May 17, 2010 at 05:35:24PM +0200, Stefan Santesson wrote:
> On 10-05-17 5:20 PM, "Nicolas Williams" <[e-mail]> wrote:
> > The key problem with this
> > extension is that the cached objects aren't bound into the handshake.
> > IMO regardless of how the cached object IDs are obtained, whether by
> > SHA-1 hashing, FNV-1a hashing, server-assigned IDs, or URIs, the object
> > data must be bound into the handshake.
> 
> How can the cached data NOT be bound to the handshake if they are hashed
> with a secure hash which in turn are included in the finished calculation?

They are certainly NOT bound if we use FNV-1a, which is the proposal on
the table.

Plus, if we agree that we need this binding and we want to keep the
current proposal more or less as-is, then we'll need hash agility, which
complicates the protocol.

I'd rather we do something along these lines instead:

 - use FNV-1a (or whatever) to _name_ the objects by checksum;

 - locally hash all the objects' data using the (rather, a) hash
   function used by TLS's Finished message computation and add this hash
   as an input to the Finished message computation:

    - this could be done without modifying the Finished message
      computation by adding a message bearing the hash of all cached
      objects' data to be sent before the first Finished message (then,
      by virtue of being a handshake message, this new message will be
      bound into the Finished messages).

On collision the handshake then fails.  The client should cache
handshake failure information so that on retry it can forgo caching and
then detect collisions.

Nico
--