Re: [TLS] First TLS cached information draft posted

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

Simon Josefsson wrote:
> 
> First, this paragraph:
> 
>    Servers that receive an extended client hello containing a
>    "cached_information" extension, MAY indicate that they support one or
>    more of the cached information objects by including an extension of
>    type "cached_information" in the (extended) server hello, which SHALL
>    contain at least one CachedObject received from the client.
> 
> The intention here appears under-specified.  What does it mean if the
> client sent two CachedObject's and the server just returned one of them?
> One plausible interpretation would be that the server did not support
> the hash/type-combination that were not returned.  Enforcing that
> interpretation is needed to resolve my second concern.
> 
> I suggest to add a sentence:
> 
>    The CachedObject's returned by the server MUST include the types the
>    server supports and has accepted to replace with cached data.

I don't know whether I correctly understand the suggestion
that you're making.  But I'm very unhappy with one possible
interpretation that I see in your poposal.

Having the TLS server indicate for which objects its TLS implementation
supports the caching _in_principle_ is fine with me.

Requiring the server to already know the hash values of
parts the contents of future SSL handshake messages, specifically
the to-be-cached data at the time when composing the ServerHello
handshake message is something I would definitely not like.

The impact on implementations of TLS should be as small as possible.
To me, a requirement for a TLS server to precompute hashes over
parts of future handshake messages during ServerHello looks like
a significant additional burden, and personally, I do not yet see
any benefit this might provide.


-Martin