Re: [TLS] Wrapping up cached info

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

Marsh Ray wrote:
> On 5/19/2010 10:02 AM, Michael D'Errico wrote:
> 
>> I think that the current draft might be too simple.
> 
> I am more concerned that it will become too complex!

I think avoiding any need for hashing and hash agility is worth it.

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

Sure, but if we end up with something that works for everything,
that's not a bad thing.

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

We might get it for free.

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

Not a new requirement.  Think certificate validity periods.

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

You might consider an expired certificate as valid?

With the timestamp approach, it would require an exact-match,
otherwise the items would be considered different.  An attacker
would have to be able to stop a server, change the time, and
restart it, all to get a cached datum to collide.  Wouldn't you
have much bigger problems than that?

Mike


> - 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
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>