Re: [TLS] Wrapping up cached info

Marsh Ray <> Wed, 19 May 2010 16:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BC2E3A6C14 for <>; Wed, 19 May 2010 09:01:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.405
X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q6C3t+QnRYG0 for <>; Wed, 19 May 2010 09:01:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 401D33A6B89 for <>; Wed, 19 May 2010 09:01:26 -0700 (PDT)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1OElhu-000C2O-Oy for; Wed, 19 May 2010 16:01:18 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id C537C6048 for <>; Wed, 19 May 2010 16:01:17 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX1/VLMOjrd+p5kdSsaC3g1cIg64e/3yIRzg=
Message-ID: <>
Date: Wed, 19 May 2010 11:01:18 -0500
From: Marsh Ray <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
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-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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:

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

> 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
>> 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" <> 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" <> 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" <> 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 mailing list
>> _______________________________________________
>> TLS mailing list
> _______________________________________________
> TLS mailing list