Re: [TLS] New Cached info draft

[Stefan Santesson <[e-mail]>]

On 10-03-30 7:30 PM, "Brian Smith" <[e-mail]> wrote:
> It is good to keep the maximum size of extensions small so that the server
> can allocate and reuse fixed-size buffers that are as small as possible. I
> don't see the use for allowing multiple values per information type, but at
> least I think a small cap on the total size of the extension_data (say, 1KB)
> would be useful. There's no need for a server to waste resources to support
> clients that send dozens, hundreds, or thousands of digests.
> 

I think that is a good limitation. Suggesting:

      struct {
           CachedInformationType type;
           opaque digest_value<0..8>;
      } CachedObject;

      struct {
           CachedObject cached_info<1..1024>;
      } CachedInformation;



> AFAICT, there's nothing in the draft that says that the client should use
> this information in any way. As long as the client is free to ignore the
> server-sent digest_values when present, it doesn't hurt. But, I don't see
> how it really helps either. It's better to keep the syntax as simple as
> possible.
> 

It could help the client to update it's cache and retire no-longer supported
cached items.

This could be clarified in the text. E.g. That if the server return digest
values, it MUST return all supported digest values in order to allow the
client update it's current set of valid cached objects.


> Again, it is best to require that the server explicitly list the information
> types for which it supports caching. It costs the server basically nothing
> to provide the few extra bytes, and it is very useful information for the
> client to have.
> 

I'm open to include such requirement. Do others agree?

/Stefan