Re: [TLS] Cached Info extension - Draft 01

[Martin Rex <Martin.Rex at sap.com>]

Stefan Santesson wrote:
> 
> Because no one has presented a scenario where any attacker could benefit
> from a week hash to launch any realistic attack.
> 
> The worst thing an attacker can accomplish by tampering with data exchange,
> is to cause the handshake to fail, which then, in the worst scenario, will
> force the parties to do a new handshake without caching.
> 
> Unless the attacker has a way to convince the parties to accept some fake
> data that has never been part of a real successful handshake, then the
> attacker has no way to capitalize on the fact that a collision is found.

This roughly describes my own view on this issue when the caching
proposal was initially resurrected based on the fast-track idea.

I've since changed my mind.

Although I still don't see any problems with this so far, a more
conservative approach might be better.  As long as a state-of-the-art
hash algorithm is used to hash the cached real data, and that hash
value is part of the SSL handshake, we are _not_ changing the
cryptographic properties of the handshake beyond assumptions that
are generally believed to be safe.


Time-stamping is based on a hashing(signing) over a hash value,
xml-signatures use a hashing(signing) over one or more hash values,
and doesn't PKCS7/CMS uses hashing(signing) over a hash value as well?


If the real data is no longer part of the SSL handshake, but instead
either a weak hash or even a static "cache handle", then there is
a change in the cryptographic properties of the SSL handshake using
cached handshake data and the full handshake with the real data.


By using a strong hash and hash agility, the caching extension can
maintain the same cryptographic properties as the full handshake
(at least in a fashion that seems to be common for many cryptograhic
 protocols), so I am much less worried about things that I may have
missed in assessing the security impact when there is no more
cryptographic binding of the real data to the cache-using
TLS handshake.


-Martin