Re: [TLS] Wrapping up cached info

Marsh Ray <marsh@extendedsubset.com> Wed, 19 May 2010 16:01 UTC

Return-Path: <marsh@extendedsubset.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BC2E3A6C14 for <tls@core3.amsl.com>; Wed, 19 May 2010 09:01:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.405
X-Spam-Level:
X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6C3t+QnRYG0 for <tls@core3.amsl.com>; Wed, 19 May 2010 09:01:28 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 401D33A6B89 for <tls@ietf.org>; Wed, 19 May 2010 09:01:26 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1OElhu-000C2O-Oy for tls@ietf.org; Wed, 19 May 2010 16:01:18 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C537C6048 for <tls@ietf.org>; Wed, 19 May 2010 16:01:17 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/VLMOjrd+p5kdSsaC3g1cIg64e/3yIRzg=
Message-ID: <4BF40B4E.20702@extendedsubset.com>
Date: Wed, 19 May 2010 11:01:18 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: tls@ietf.org
References: <C819B76D.AF2B%stefan@aaa-sec.com> <4BF3FD9C.3040206@pobox.com>
In-Reply-To: <4BF3FD9C.3040206@pobox.com>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Wrapping up cached info
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 May 2010 16:01:32 -0000

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" <stefan@aaa-sec.com> 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" <stefan@aaa-sec.com> 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" <mrex@sap.com> 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
>>>>> TLS@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>
>>>> _______________________________________________
>>>> TLS mailing list
>>>> TLS@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls