Re: [TLS] First TLS cached information draft posted

[Stefan Santesson <stefan at aaa-sec.com>]

Martin,

I liked Simon's suggestion as he expressed my original thought that the
Server would know beforehand the hashes for acceptable information objects.

However, what you suggest actually makes sense to me.

I also found another minor error as the draft refer to hash_value (single
hash) when I should refer to the "hashes" (multiple hash) element.

We have to think through the concept of sending over multiple hashes and
what the appropriate response from the server is.

1) The server accepts replacement in principle, but does not know at the
time of sending the server hello if any of the hashes match.

2) The server accepts one or more hashes from the client hello (for one
object type) and includes the hashes it accepts in the server hello

3) The server accepts one or more hashes from the client hello (for one
object type) but includes only 1 (the preferred one) hash for that object
type in the server hello.

Once we can agree on this, I will update and submit a new version of the
draft.

/Stefan




On 09-06-05 10:55 PM, "Martin Rex" <Martin.Rex at sap.com> wrote:

> 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