Re: [TLS] First TLS cached information draft posted

[Simon Josefsson <[e-mail]>]

Stefan Santesson <[e-mail]> writes:

> 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)

Right.

> 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)

Agreed.

There is a follow-on question here:

Is it allowed to send over multiple CachedObject elements containing the
same type identifier and same hash algorithm but different hash values?

The options and consequences are:

No: This is the simplest.  In this case, I don't see a reason for the
server to send back the same hash value the client sent -- so the Hash
value field would be removed in the server response, to save some more
space.

Yes: This allows clients to send hashes for multiple variants of the
cached information.  For example, the client may have received two
different server certificates in the past, and may want to offer caching
of both.

The Yes case seems complex but there could be use cases for it.  If you
didn't think of this, I'd prefer to disallow it.

> 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)

I don't see any value in duplicating the hash values here though?

> 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)

I understand Martin's concern, but how would a client know whether data
was replaced or not?  How would the client know which hash algorithm is
used?

> 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.

I think we need to include the hash algorithm too.  You cannot infer
which hash algorithm is used based on the length only.

I don't think it is reliable to optionally replace data.  Hash values
can be made to look like valid ASN.1, and the client would have to guess
whether the server replaced the value or not.

/Simon

>
>
> 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