Re: [TLS] First TLS cached information draft posted

[Stefan Santesson <[e-mail]>]

I think I have to try to clarify this

The client send a cached_information extension which contains a list of
CachedObject structures.

Each ChachedObject element contains:

- type identifier (CachedInformationType type)
- a list of hash values (CachedInformationHash hashes)

Each CachedInformationHash contains:

- Algorithm identifier (HashAlgorithm hash)
- Hash value (opaque hash_value)



There are a number of issues that need to be specified or clarified in the
draft:

1) Is it allowed to send over multiple CachedObject elements containing the
same type identifier?

Proposed answer = No (you can already include multiple hashes for each type)


2) What should the server return in its server hello message for each
acceptable CachedObject?

Alternative 1 = The CachedObject element, exactly as it was received by the
client (with all hashes)

Alternative 2 = The CachedObject element, but only containing the
CachedInformationHash elements that is recognize and support.

Proposed answer = Alternative 1 (This allows the server to say YES in
principle without analyzing the hash values at the time of Hello exchange)


3) Is the server REQUIRED to honor its support of a CachedObject by
replacing the identified handshake data with a received hash?

Proposed answer = NO (for reasons raised by Martin)


4) What does the server send as replacement for the replaced handshake data?

Proposed answer = One opaque hash_value (without hash type identifier) that
was received by the client, which MUST contain a valid hash over the
replaced data.



Do you agree?

/Stefan



On 09-06-06 3:17 AM, "Stefan Santesson" <[e-mail]> wrote:

> 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" <[e-mail]> 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
> 
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls