Re: [TLS] Wrapping up cached info

["Blumenthal, Uri - 0668 - MITLL" <[e-mail]>]

Stefan,

There is one problem.

If it turns out that you need SHA256 for security reasons - then you'll also
need algorithm agility because nobody can guarantee that SHA256 will hold
(remember - MD4, MD5, SHA1...? :-).

Also, do you care how many bits the hash outputs, and how many of those bits
you use? 

Let's provide the analysis and hope that it shows no security issues here.


On 5/17/10 09:58 , "Stefan Santesson" <[e-mail]> wrote:

> I would like to wrap up the discussion about cached info, if possible.
> 
> I have to admit that I'm stuck as editor. I have a draft that I think is
> done with a possible amendment to the security considerations and some
> additional informational references to FNV.
> 
> I don't think the discussion has shown that the security assumptions are
> wrong, I.e. That any alteration of cached data in the sense that the server
> and the client are in disagreement of what the cached data is, will lead to
> a handshake failure.
> 
> Threats are therefore reduced to inconveniences upon handshake failures (as
> far as discussion has showed.
> 
> However, there is still a possible alteration of the security properties of
> the finished calculation. That is, it is possible upon a FNV collision to
> disagree on the cached data without failing the finished calculation.
> 
> I can't see any practical exploit of this fact. If this is considered a
> blocking problem, then it is easiest solved by using a secure hash (SHA-256)
> which effectively restores the security properties of the finished
> calculation. This is best done by s/FNV/SHA-256. No agility.
> 
> I will not lead an effort to specify a variant of this protocol where the
> server provides the identifiers, either as any random identifier or in the
> form of a URI. If that is the desire of the WG, I will be happy to hand over
> editorship to anyone, assigned by the chairs, who wants to take over.
> 
> I request WG chair guidance on how to proceed, if at all with this document.
> 
> /Stefan
> 
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls