Re: [TLS] TLS Fast-Track resurrected?

["Joseph Salowey (jsalowey)" <jsalowey at cisco.com>]

> 
> > If an identifier unrelated to the actual data on-the-wire is used, 
> > then client and server have no proof they're really refering to 
> > exactly the same data.  If the is/gets out-of-sync for whatever 
> > reason, the fast-tracked handshake using data-unrelated identifiers 
> > will fail, and the client will have to (a) retry and (b) apply 
> > heuristics whether a failure could be related to out-of-sync data 
> > references by the unrelated identifier and the client will have to 
> > OMIT the fast-track proposal from the next handshake in order to 
> > recover -- otherwise the client will be stuck in an endless error 
> > loop.
> 
> This is a good argument for hashing.  But then the question 
> becomes which hash function to use.  I'm sure that today MD5 
> would cause concern, though for this purpose there's no need 
> for a cryptographic hash function.  You could argue that 
> SHA-1 would be acceptable today.
> But what about in 2 years, 5 years, or more?
> 
[Joe] This illustrates the point that EKR was making at the SAAG meeting
in the IETF meeting.  This may be a case where a hash function is
useful, but the properties of a cryptographic hash function are not
needed.  He proposed defining a non cryptographic hash function (such as
a CRC) for this purpose to clearly delineate between cases that require
the properties of a cryptographic hash and those that don't.  We
typically do a poor job of documenting what properties we need from a
hash function (cryptographic or otherwise) so it is often difficult to
say how a particular flaw in a hash function effects a particular usage.


If you choose to use a hash function you should determine what
properties you are relying upon, select an appropriate algorithm and
document the required properties. 

_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls