Re: [TLS] Cached Info extension - Draft 01

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

Stefan Santesson wrote:
> 
> On 09-07-02 1:00 AM, "Martin Rex" <Martin.Rex at sap.com> wrote:
> > 
> > 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.
> 
> 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