[TLS] Possible alternative to current cached info draft

[Michael D'Errico <[e-mail]>]

It just hit me that we might be able to do caching in a different
way, similar to the http If-Modified-Since header (and ETag -- see
the last paragraph).

The server would keep track of the time at which its certificate
chain (or CA list) was configured.  This could be determined by
looking at the modification time in the filesystem, or even just
by keeping track of when the server was started or was told to
reconfigure itself.

A connecting client would tell the server, "I have a certificate
chain with this timestamp," and the server would either respond
saying that the timestamp matches the current chain, or not.  If
it matched, the certificate message sent by the server would be
empty.

A client that has never connected to a server would request the
server's timestamps by sending an empty extension.  The server
would respond with the current type/timestamp pairs it supports.

When reconnecting, the client lists its type/timestamp pairs and
the server responds with its list.  Any timestamps that matched
would cause the server to omit the data.

But probably we'd also need to have id's for the objects similar
to the ETag header to disambiguate things, especially when the
server handles more than one virtual domain.  The server could
generate those either using a hash (no agility needed) or some
other way, with the only requirement being that the type-id-
timestamp triple would need to be unique.

Mike



Stefan Santesson wrote:
> I would like to wrap up the discussion about cached info, if possible.
> 
> I have to admit that I'm stuck as editor. I have a draft that I think is
> done with a possible amendment to the security considerations and some
> additional informational references to FNV.
> 
> I don't think the discussion has shown that the security assumptions are
> wrong, I.e. That any alteration of cached data in the sense that the server
> and the client are in disagreement of what the cached data is, will lead to
> a handshake failure.
> 
> Threats are therefore reduced to inconveniences upon handshake failures (as
> far as discussion has showed.
> 
> However, there is still a possible alteration of the security properties of
> the finished calculation. That is, it is possible upon a FNV collision to
> disagree on the cached data without failing the finished calculation.
> 
> I can't see any practical exploit of this fact. If this is considered a
> blocking problem, then it is easiest solved by using a secure hash (SHA-256)
> which effectively restores the security properties of the finished
> calculation. This is best done by s/FNV/SHA-256. No agility.
> 
> I will not lead an effort to specify a variant of this protocol where the
> server provides the identifiers, either as any random identifier or in the
> form of a URI. If that is the desire of the WG, I will be happy to hand over
> editorship to anyone, assigned by the chairs, who wants to take over.
> 
> I request WG chair guidance on how to proceed, if at all with this document.
> 
> /Stefan