Re: [TLS] Cached Info extension - Draft 01

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

I might be missing something, but I'm not sure I get the problem.

One difficulty I have is that I don't see, and never have seen, the reason
to provide different levels of hash algorithms for a usage that does not
require a strong hash.

But even if the client decides to do this, the server can pick any of the
hashes as the return value. That hash is long and random enough to work as a
perfectly unambiguous identifier of a successfully replaced cached object,
and is long and random enough to reduce the chance of accidental collisions
of any kind to totally negligible probabilities.

Maybe we should sit down in Stockholm and come up with a solution that
hopefully makes everyone happy.

/Stefan


On 09-06-24 2:41 PM, "Martin Rex" <Martin.Rex at sap.com> wrote:

> Simon Josefsson wrote:
>> 
>> Stefan Santesson <stefan at aaa-sec.com> writes:
>> 
>>> It was not my intention to kill off this discussion with this new draft.
>>> 
>>> I¹m wandering whether the silence is a sign of agreement, vacation or just a
>>> giving up that the author will ever listen to reasonable arguments...
>> 
>> I still prefer Martin's proposal to add framing, but could live with
>> your approach.
>> 
>> A mild problem that I don't think is fully covered yet is the complexity
>> in transition to new hashes -- clients will forever need to send SHA-1
>> hashes to the server, it seems, to ensure interoperability?  Or should
>> the document contain some text that explains that servers should pick
>> the "preferred" hash it supports, and that clients should cache that
>> choice for future use?  Additional text would then be needed to explain
>> that if clients try the new hash later on, and it doesn't work, it
>> should revert back to SHA-1 in case the server software was changed to
>> not support the other hash.  This aspects doesn't feel completely baked
>> yet to me.
> 
> 
> How about extending the ClientHello and ServerHello extension
> with a pure negotiation of the supported Hash algorithms?
> 
> So that in the first request, when the client does not have any cached
> data (and no hash values to propose), only the hash algorithm is
> "negotiated", plus the data elements for which the server supports
> caching in principle?
> 
> This way, the client can learn which hash algorithm the server
> supports before filling his cache, and the client can also abstain
> from caching for servers that do not support the extension at all
> and abstain from caching particular handshake data, for which the
> server does not support caching.
> 
> 
> -Martin