Subject: Re: [TLS] Cached Info extension - Draft 01

From: Florian Weimer <[email-masked]>
Date: Wed, 01 Jul 2009 07:11:17 +0000

* Stefan Santesson:

> One difficulty I have is that I don't see, and never have seen, the reason
> to provide different levels of hash algorithms for a usage that does not
> require a strong hash.

Why do you think this doesn't need a strong hash?

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Martin Rex <[email-masked]>
Date: Thu, 2 Jul 2009 00:01:05 +0200 (MEST)

Stefan Santesson wrote:
> 
> I might be missing something, but I'm not sure I get the problem.

I'll try to elaborate on my idea, inspired by Simons "mild problem".

The scheme of the current proposal, when and how does a client learn
that a server supports caching (and for which handshake data), and
what hash algorithm the server supports looks mildly awkward and
requires guessing, i.e. trial-and-error.

We could improve the entire proposal in the following fashion:

ClientHelloExtension:  allow&recommend the client to send the extension
without actual hash values on first connect to a server.

ServerHelloExtension:  have the server indicate for which handshake
data it supports caching in principle, and with which hash algorithm

With this scheme, the client can learn even before creating cache
entries whether the server supports caching of that handshake data
at all--or wether it will be entirely pointless to cache such data
and announce hashes for it in future requests to the same server.

And the client can also learn which hash algorithm the server supports
before creating actually receiving the data for the first time and
creating the cache entry, so it will be unnecessary for the client
to ever use more than one hash algorithm to compute a hash value
for cached data.

A client may decide to create negative cache entries for a server,
so that it will not bother asking the server (through ClientHelloExtension)
for caching support for a certain amount of time (like an hour)
during successive requests.  Such an approach will cut down on
client side cache size and handshake network bandwidth.

The current optimistic/probabilistic approach of the client trying to
cache first and then propose to use it can and should be avoided.
There can be situations where making assumptions and trial-and-error
about server features might be OK or even necessary, but IMHO, this
tls caching extension does not seem to be a situation where such
an approach is adequate.

Btw. we are defining a caching mechanism here, so there should be
a small amount of guidance on cache management.  The above idea
should facilitate cache management somewhat.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 02 Jul 2009 00:29:33 +0200

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.

/Stefan

---

From: Martin Rex <[email-masked]>
Date: Thu, 2 Jul 2009 01:00:53 +0200 (MEST)

> 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

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 02 Jul 2009 08:15:43 +0200

Martin,

> cached handshake data and the full handshake with the real data.

I don't believe this conclusion is correct.

The handshake will proceed exactly as it would have if the real data was
exchanged, preserving the cryptographic properties of a full handshake with
the original data.

This is true with only one exception. It changes the data used to calculate
the finished message. With cached data, the finished message is calculated
over the "weak" hashes instead of the original data.

For this to be turned into an attack, you have to make it plausible that one
could force two different TLS sessions to produce colliding finished
messages through a "weak" caching hash. This can't be the case if the hash
algorithm used to calculate the finished message is solid.

---

From: Martin Rex <[email-masked]>
Date: Thu, 2 Jul 2009 18:33:49 +0200 (MEST)

> I don't believe this conclusion is correct.

I think you might be misreading my conclusion.

I think that we're cryptographically safe in modyfying the handshake
by making a strong (agile) hash value over the original data part
of the handshake instead.  This is even safe for handling errors.

If we drop the cryptographic binding of the original data in
the handshake, we might create problems that we haven't thought
of so far, and the architecure becomes brittle to handling errors.
Without the cryptographic binding, cache poisoning will become
feasible.  The (server) endpoint identification that many/most
clients currently perform is so ridiculously weak that I'm
worried about cache poisoning.  And how about caching of
handshake data from incomplete TLS-handshakes that are
incomplete, common and non-malicious?  (like when a server
requests a client cert, the client doesn't send one, and the
server terminates the handshake with a fatal alert?
Without the cryptographic binding of the original data to
the cache-using handshake, we should probably need to explicitly
prohibit caching there. 

For the TLS extension client certificate URL the previously optional
hash over the client cert was made mandatory.  I think that it is
a sensible action to play safe and to try to maintain the
cryptographic binding to the full SSL handshake by including
a strong agile hash value over the original handshake data
when the original data is omitted or replaced by a weak reference.

-Martin