Re: [TLS] Wrapping up cached info

[Michael D'Errico <[e-mail]>]

It is better than server-assigns-name because a server doesn't
need to keep track of names in stable storage if that's not
convenient for it.  It can instead create a convenient name (which
doesn't even need to be a hash of the object) and use the time at
which the server was launched as the timestamp.

The combination of name and timestamp provides a lot of flexibility
for the server since it could use a unique name for something, e.g.
MODP-1536 for the 1536-bit IKE DH parameters, or a combination of a
name and a timestamp.  The timestamp could be based off of the file
modification time of a certificate for instance.  Or the server can
just use the time it last loaded its configuration as the timestamp
to avoid any possible clashes with previous names.

Also there is no need for hashing at all and thus no hash agility.
I think that alone makes this worth considering.

Mike



Joseph Salowey (jsalowey) wrote:
> This approach seems equivalent to the server assigns name approach that
> has been brought up several times previously and not received enough
> support to replace the current mechanism.  In addition, it doesn't seem
> to solve the issue of how to hash the objects that the working group is
> currently struggling with.  
> 
> Joe
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Michael D'Errico
>> Sent: Wednesday, May 19, 2010 8:03 AM
>> To: Stefan Santesson
>> Cc: [e-mail]
>> Subject: Re: [TLS] Wrapping up cached info
>>
>> 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!
>>
>> Seriously, I think that the current draft might be too simple.  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.  If cached-info can only cache one
>> object of any particular type, then it will not be very helpful for
>> such an application.
>>
>> 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.
>>
>> Allowing the server to instead name the objects, and keep track of
>> timestamps for each object, allows you to handle these two cases.  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.
>>
>> 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
>