Re: [TLS] New Cached info draft

["Brian Smith" <[e-mail]>]

Marsh Ray wrote:
> On 3/31/2010 10:52 AM, Michael D'Errico wrote:
> > I haven't been able to totally keep up with the progress of this draft
> > or to follow the discussion, but I think it's a bad idea to
> > artificially limit the size of anything to 1024 bytes.

> I think in this case it's saying there can be a maximum of 1024 entries in
the list,
> each of which can take up to 9 bytes (with a one byte length). So the
receiver of
> this structure is only obligated to store (or ignore) (2 + (1 + 8)*1024)
bytes of
> data.

No, Mike is right and I was wrong; <1024> means "1024 bytes," not "1024
entries.

> > If somebody wants to use small fixed-size buffers, then they can check
> > the length of the vector to see if it will fit.  If it won't fit, then
> > they have to deal with it somehow.
> 
> What ends up happening in the absence of a defined limit is that products
will
> either be subject to a DOS, or different limits will be imposed by
different
> products which harms interoperability.

Also, there are interoperability problems with fragmented ClientHellos so
the pragmatic total maximum size of a ClientHello is 2^14 bytes. 

Is 1024 bytes is an appropriate limit? Maybe not. First, I think we should
discuss whether/why it is sub-optimal to cache just the most recently
received value of each information item. Then I think it would become clear
whether or not it makes sense for the client to send dozens or hundreds or
more hashes in its ClientHello.

I can see that it might be useful for the client to cache one value of each
cached information item that were obtained during initial (unauthenticated,
unencrypted) handshakes plus another set of values per client certificate
that were obtained during renegotiation following client authentication.
However, in that case, the server probably wouldn't want the client to leak
the hash of its second certificate in subsequent initial (unauthenticated,
unencrypted) handshakes. It seems something about this should be added to
the security considerations of the draft.

If there are other cases where it seems useful to have the client send
multiple hashes for the same information item, then those cases should also
be discussed before publication so that the security properties of that
those kind of usages can be analyzed. For example, I think it is a big
privacy problem to send a digest of a value obtained from one server to
another server.

I think the author, Stefan Santesson, seems to know of some cases where
caching more than one value is useful. Stefan, it would be very helpful if
you could explain when it would be sub-optimal to send only one value per
information item in the ClientHello, and when/why it is not a
security/privacy problem to send a hash to a server that hadn't previously
sent you the value from which that hash was created.

Regards,
Brian