Re: [TLS] Wrapping up cached info

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

If there was a short discussion of this in the document, I'd be happy
with this approach.  

Joe

> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: Wednesday, May 19, 2010 7:32 AM
> To: Joseph Salowey (jsalowey); [e-mail]
> Cc: [e-mail]
> Subject: Re: [TLS] Wrapping up cached info
> 
> The thought is that you would apply the same rules as you do when
choosing
> hah for the finished calculation.
> 
> To the extent that choice is dependent on the prf, then choice of this
> hash
> will also be dependent on the prf.
> 
> There is no reason to chose any different hash algorithm than the one
used
> for the finished calculation since the security aspects of this is
tied to
> the finished calculation anyway. That is, you can't do better than the
> hash
> of the finished calculation, and if you pick the same hash, you can't
do
> worse. Analysis is therefore easy.
> 
> Since the hash chosen to calculate the finished message is known only
> after
> receiving the server hello, the client have to choose the one used on
a
> previous handshake, i.e. The one when the data was cached.
> 
> Yes, I think it would be OK for the server to not accept the choice of
a
> hash algorithm if it is less secure than the one used in the finished
> calculation, but I see no reason to demand it. It could be left to the
> server to decide based on local policy, but I would not object to
require
> the server to reject the cached data if that is the general
preference.
> 
> /Stefan
> 
> 
> 
> 
> 
> 
> 
> 
> On 10-05-19 4:19 PM, "Joseph Salowey (jsalowey)" <[e-mail]>
> wrote:
> 
> > Hi Stefan,
> >
> > To me this sounds like a good approach.  I have some questions on
> > whether the hash chosen is dependent upon the cipher suite used
below.
> >
> >
> >> -----Original Message-----
> >> From: Stefan Santesson [mailto:[e-mail]]
> >> Sent: Wednesday, May 19, 2010 6:43 AM
> >> To: Stefan Santesson; [e-mail]; Joseph Salowey (jsalowey)
> >> Cc: [e-mail]
> >> Subject: Re: [TLS] Wrapping up cached info
> >>
> >> Not sure how I should interpret the silence?
> >>
> >> I guess it means that everyone agrees with me :)
> >>
> >> To repeat in short. Here is what I suggest based on the latest
> > traffic:
> >>
> >> 1) A client, caching information also caches what hash algorithm
was
> > used
> >> to
> >> calculate the finished message at the time of caching.
> >>
> > [Joe] Will this be the same as the hash function used in the PRF of
the
> > cipher suite?  It seems that using the same hash might make security
> > analysis a little easier.
> >
> >> 2) On repeated connections, the client indicate cached info by
sending
> > a
> >> hash of the cached object using the cached hash algorithm. (No use
of
> > FNV
> >> hash)
> >>
> >> 3) The server accepts by returning the received hash instead of the
> > cached
> >> data.
> >>
> > [Joe] In the event that a different cipher suite is used with a
> > different hash would the cached hash still be valid?
> >
> >> 4) The only hash agility provided is that the client will send a
hash
> >> algorithm identifier with the hash.
> >>
> > [Joe] This seems sufficient.
> >
> >> 5) The client MUST NOT send more than one hash per cached object,
and
> > MUST
> >> used the cached hash algorithm.
> >>
> >>
> >> This solves all issues raised (securely binds the cached data to
the
> >> finished calculation) and removes the need for hash agility
> >> Syntactically it just requires adding a hash identifier and
adjusting
> > the
> >> vector length for hash data.
> >>
> >> So I basically wander:
> >> - Would this be acceptable?
> >> - Who could NOT live with this solution?
> >> - Who think it is worth the effort to agree on a better solution,
and
> > why?
> >>
> >> Regards
> >>
> >>
> >>
> >>
> >> On 10-05-18 12:24 AM, "Stefan Santesson" <[e-mail]>
wrote:
> >>
> >>> As Martin pointed out to me privately, the hash used in the
finished
> >>> calculation becomes known to the client only after receiving the
> > serer
> >>> hello.
> >>>
> >>> It would therefore be natural for the client to use the hash
> > function
> >> used
> >>> to calculate the finished message at the time when the data was
> > cached.
> >>>
> >>> The client would then indicate which hash algorithm it used and
upon
> >>> acceptance, the server will honor the request.
> >>>
> >>> /Stefan
> >>>
> >>>
> >>> On 10-05-17 10:34 PM, "Stefan Santesson" <[e-mail]>
wrote:
> >>>
> >>>> Guys,
> >>>>
> >>>> Where I come from we have a say "don't cross the river to get to
> > the
> >> water".
> >>>> And to me this proposal to change the finished calculation is
just
> >> that.
> >>>>
> >>>> Look at it.
> >>>>
> >>>> The proposal is to bind the cached data by adding a hash of the
> > cached
> >> data
> >>>> to the finished calculation.
> >>>>
> >>>> The proposal is further to avoid hash agility by picking the hash
> >> algorithm
> >>>> used by TLS's Finished message computation.
> >>>>
> >>>>
> >>>> Now there are two ways to achieve this goal.
> >>>>
> >>>> 1) The crossing the river to get water approach:  Exchange FNV
> > hashes
> >> of the
> >>>> cached data in the handshake protocol exchange and then inject
> > hashes
> >> of the
> >>>> same data into the finished calculation through an alteration of
> > the
> >> TLS
> >>>> protocol.
> >>>>
> >>>>
> >>>> 2) The simple approach: Use the hash algorithm of the finished
> >> calculation
> >>>> to hash the cached data (according to the current draft).
> >>>>
> >>>>
> >>>> Alternative 2 securely bind the hashed data into the finished
> > message
> >>>> calculation without altering the algorithm.
> >>>>
> >>>> Alternative 2 requires at most a hash algorithm identifier added
to
> > the
> >>>> protocol, if at all. We don't need to add negotiation since we
> > always
> >> use
> >>>> the hash of the finished message calculation. Adding this
> > identifier
> >> would
> >>>> be the only change made to the current draft.
> >>>>
> >>>> Alternative 2 don't require additional security analysis. If the
> > hash
> >> used
> >>>> to calculate the finished message is broken, then we are screwed
> >> anyway.
> >>>>
> >>>> /Stefan
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On 10-05-17 9:16 PM, "Martin Rex" <[e-mail]> wrote:
> >>>>
> >>>>> Joseph Salowey wrote:
> >>>>>>
> >>>>>> I agree with Uri, that if you determine you need SHA-256 then
you
> >> should
> >>>>>> plan for hash agility.  TLS 1.2 plans for hash agility.
> >>>>>>
> >>>>>> What about Nico's proposal where a checksum is used to identify
> > the
> >>>>>> cached data and the actual handshake contains the actual data
> > hashed
> >>>>>> with the algorithm used in the PRF negotiated with the cipher
> > suite?
> >>>>>>
> >>>>>> This way we don't have to introduce hash agility into the
> > extension,
> >> but
> >>>>>> we have cryptographic hash agility where it matters in the
> > Finished
> >>>>>> computation.  Does it solve the problem?
> >>>>>
> >>>>> Yes, I think so.
> >>>>> This approach should solve the issue at the technical level.
> >>>>>
> >>>>> Going more into detail, one would hash/mac only the data that
got
> >>>>> actually replaced in the handshake, each prefixed by a (locally
> >> computed)
> >>>>> length field.
> >>>>>
> >>>>> -Martin
> >>>>> _______________________________________________
> >>>>> TLS mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/tls
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> TLS mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/tls
> >>>
> >>>
> >>
> >
>