Re: [TLS] First TLS cached information draft posted

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

Martin,

It may be that I misunderstand you because it is not clear to me what you
would like to do instead.

If you would spell out the ideal protocol flow exactly as you would prefer
it, what would it be like?

/Stefan

On 09-06-16 5:29 PM, "Martin Rex" <Martin.Rex at sap.com> wrote:

> Stefan Santesson wrote:
>> 
>> This CachedObject stucture may contain any number of hashes. This might be
>> hashes using different algorithms over the same object or it may be hashes
>> of the same kind over different objects (e.g. multiple acceptble certs). It
>> is just an unordered list of hashes.
>> 
>> The server now takes the data it intended to send. And compute the hash over
>> that data with as many algorithms it can out of the algorithms used by the
>> client. If one of the received hashes matches one of the generated hashes,
>> the match is accepted and the server will return one of the matching hashes
>> as acceptance of the cache (data replacement).
> 
> To me, this sounds more complex that I think it should be.
> 
> I think the server should neither have to compute and neither have
> to check the hash values for all hash algorithms for which the client
> sent hashes. (which implies that the client has to send hash
> values consistently for all items and all hash algorithms that
> it wants to offer.
> 
> The server should reply in the ServerHello extension for which items
> and which hash algorithm (of those poposed by the client) it supports
> substituting the real data with the replacement (the hash
> value in the current proposal).
> 
> The server should not have to compute and compare multiple hash
> values over the real value when composing the handshake message
> affected by the diet, and neither should the client have to
> compare the substituted value to the hash values of more than
> one hash algorithm (when the client proposed multiple values
> for the same item with different hash algs.
> 
> 
> -Martin