Re: [TLS] Wrapping up cached info

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

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
> >
> >
>