Re: [TLS] Wrapping up cached info

[Marsh Ray <[e-mail]>]

On 5/19/2010 10:02 AM, Michael D'Errico wrote:
> Stefan Santesson wrote:
>> Not sure how I should interpret the silence?
>>
>> I guess it means that everyone agrees with me :)
> 
> Then by that logic everyone also agrees with me to use http caching
> as the model!

Then by that logic, everyone agrees with everyone. Problem solved!

HTTP caching:
http://tools.ietf.org/html/rfc2616#section-13

> Seriously, I think that the current draft might be too simple.

I am more concerned that it will become too complex!

> For
> example, consider caching the list of certificate_authorities in a
> CertificateRequest message.  A web application might have several
> different lists of certificate_authorities based on what the resource
> is and who is trying to access it.

Web servers can certainly be configured that way.

> If cached-info can only cache one
> object of any particular type, then it will not be very helpful for
> such an application.

Can we agree on the explicit non-requirement that the solution must work
for everything?

> Also, exactly how would you hash the Diffie-Hellman parameters in a
> ServerKeyExchange message?  You can't just hash the message since it
> also contains a unique Ys which changes frequently if not every
> handshake.

Should we even try?

> Allowing the server to instead name the objects, and keep track of
> timestamps for each object, allows you to handle these two cases.

Go read the specs and mailing lists for HTTP caching. (I bet you have
already :-)

Having names, timestamps, invalidation rules, etc can introduce a little
bit of complexity.

http://www.google.com/search?q=squid+cache+weird+problem
http://www.google.com/search?q=squid+cache+strange+problem

> In
> the multiple-CA-list example above, the server might have USER and
> ADMIN lists.  If it can't be sure when exactly those lists were
> created, the timestamp can simply be when the server was started or
> when it last read its configuration.

Does this introduce a new requirement for clients and/or servers to
maintain an accurate clock?

What failure modes are possible when a clock is not accurate?

- Marsh




> When the server forces the client to renegotiate when accessing a
> protected resource as an ADMIN for example, the server's cached info
> extension would contain:
> 
>     type=cert_req_ca_list,name=ADMIN,timestamp=20100519123456789
> 
> When requesting a less-sensitive, but not public resource, the server
> would send:
> 
>     type=cert_req_ca_list,name=USER,timestamp=20100519123456789
> 
> If the client's cached-info extension contained an exact match, then
> the server would omit that data from the handshake.
> 
> This is sort of like cipher suite selection.  The client sends a list
> of possible matches and the server selects one from the list.  It
> differs in that there might be no match, in which case the server just
> sends the info for the object it decided to send in the handshake.
> 
> I'm sure there are more details to be worked out, but I think it would
> be a good idea to entertain this approach.
> 
> Mike
> 
> 
> 
>> To repeat in short. Here is what I suggest based on the latest traffic:
>>
>> 1) A client, caching information also caches what hash algorithm was
>> used to
>> calculate the finished message at the time of caching.
>>
>> 2) On repeated connections, the client indicate cached info by sending a
>> hash of the cached object using the cached hash algorithm. (No use of FNV
>> hash)
>>
>> 3) The server accepts by returning the received hash instead of the
>> cached
>> data.
>>
>> 4) The only hash agility provided is that the client will send a hash
>> algorithm identifier with the hash.
>>
>> 5) The client MUST NOT send more than one hash per cached object, and
>> MUST
>> used the cached hash algorithm.
>>
>>
>> This solves all issues raised (securely binds the cached data to the
>> finished calculation) and removes the need for hash agility
>> Syntactically it just requires adding a hash identifier and adjusting the
>> vector length for hash data.
>>
>> So I basically wander:
>> - Would this be acceptable?
>> - Who could NOT live with this solution?
>> - Who think it is worth the effort to agree on a better solution, and
>> why?
>>
>> Regards
>>  
>>
>>
>>
>> On 10-05-18 12:24 AM, "Stefan Santesson" <[e-mail]> wrote:
>>
>>> As Martin pointed out to me privately, the hash used in the finished
>>> calculation becomes known to the client only after receiving the serer
>>> hello.
>>>
>>> It would therefore be natural for the client to use the hash function
>>> used
>>> to calculate the finished message at the time when the data was cached.
>>>
>>> The client would then indicate which hash algorithm it used and upon
>>> acceptance, the server will honor the request.
>>>
>>> /Stefan
>>>
>>>
>>> On 10-05-17 10:34 PM, "Stefan Santesson" <[e-mail]> wrote:
>>>
>>>> Guys,
>>>>
>>>> Where I come from we have a say "don't cross the river to get to the
>>>> water".
>>>> And to me this proposal to change the finished calculation is just
>>>> that.
>>>>
>>>> Look at it.
>>>>
>>>> The proposal is to bind the cached data by adding a hash of the
>>>> cached data
>>>> to the finished calculation.
>>>>
>>>> The proposal is further to avoid hash agility by picking the hash
>>>> algorithm
>>>> used by TLS's Finished message computation.
>>>>
>>>>
>>>> Now there are two ways to achieve this goal.
>>>>
>>>> 1) The crossing the river to get water approach:  Exchange FNV
>>>> hashes of the
>>>> cached data in the handshake protocol exchange and then inject
>>>> hashes of the
>>>> same data into the finished calculation through an alteration of the
>>>> TLS
>>>> protocol.
>>>>
>>>>
>>>> 2) The simple approach: Use the hash algorithm of the finished
>>>> calculation
>>>> to hash the cached data (according to the current draft).
>>>>
>>>>
>>>> Alternative 2 securely bind the hashed data into the finished message
>>>> calculation without altering the algorithm.
>>>>
>>>> Alternative 2 requires at most a hash algorithm identifier added to the
>>>> protocol, if at all. We don't need to add negotiation since we
>>>> always use
>>>> the hash of the finished message calculation. Adding this identifier
>>>> would
>>>> be the only change made to the current draft.
>>>>
>>>> Alternative 2 don't require additional security analysis. If the
>>>> hash used
>>>> to calculate the finished message is broken, then we are screwed
>>>> anyway.
>>>>
>>>> /Stefan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 10-05-17 9:16 PM, "Martin Rex" <[e-mail]> wrote:
>>>>
>>>>> Joseph Salowey wrote:
>>>>>> I agree with Uri, that if you determine you need SHA-256 then you
>>>>>> should
>>>>>> plan for hash agility.  TLS 1.2 plans for hash agility.
>>>>>>
>>>>>> What about Nico's proposal where a checksum is used to identify the
>>>>>> cached data and the actual handshake contains the actual data hashed
>>>>>> with the algorithm used in the PRF negotiated with the cipher suite?
>>>>>>
>>>>>> This way we don't have to introduce hash agility into the
>>>>>> extension, but
>>>>>> we have cryptographic hash agility where it matters in the Finished
>>>>>> computation.  Does it solve the problem?
>>>>> Yes, I think so.
>>>>> This approach should solve the issue at the technical level.
>>>>>
>>>>> Going more into detail, one would hash/mac only the data that got
>>>>> actually replaced in the handshake, each prefixed by a (locally
>>>>> computed)
>>>>> length field.
>>>>>
>>>>> -Martin
>>>>> _______________________________________________
>>>>> TLS mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>
>>>> _______________________________________________
>>>> TLS mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls