Re: [TLS] Justification

[Nicolas Williams <[e-mail]>]

On Thu, May 13, 2010 at 08:23:33PM -0400, Dean Anderson wrote:
> I rather thought the objective of caching was to have faster startup by
> having to move less data around, particularly when its already been
> moved before. But I haven't been following the extension too closely. 
> 
> I am only concerned when I see suggestions that 'http be used to get TLS
> data. I'm not sure whether to those were serious or tongue-in-cheek.  

First, HTTP already is used to get what you might call TLS data, such as
CRLs.

Second, I only want to assign URIs to cacheable TLS data, not so much
make it fetchable via URIs.  This is a variant of my earlier suggestion
of server-side object IDs; this variant can result in efficient caching
of the same objects used by many servers (e.g., certification chains).

> HTTP secured by and depends on TLS, so you can't draw on HTTP to solve
> HTTP-TLS-HTTP without looping or creating security holes.

You clearly didn't read what I'd written.  The key problem with this
extension is that the cached objects aren't bound into the handshake.
IMO regardless of how the cached object IDs are obtained, whether by
SHA-1 hashing, FNV-1a hashing, server-assigned IDs, or URIs, the object
data must be bound into the handshake.  Given such binding then it
doesn't matter how you retrieve these objects (which are, for the most
part, public data).

Nico
--