Re: [TLS] Cached Info extension - Draft 01

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

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