Re: [TLS] Wrapping up cached info

Stefan Santesson <stefan@aaa-sec.com> Wed, 19 May 2010 14:34 UTC

Return-Path: <stefan@aaa-sec.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 ACE243A68CC for <tls@core3.amsl.com>; Wed, 19 May 2010 07:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.343
X-Spam-Level:
X-Spam-Status: No, score=-1.343 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 Oi1ShV9epEAd for <tls@core3.amsl.com>; Wed, 19 May 2010 07:34:40 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.94.112]) by core3.amsl.com (Postfix) with ESMTP id DA8E93A69F6 for <tls@ietf.org>; Wed, 19 May 2010 07:34:36 -0700 (PDT)
Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 7FC002919CB for <tls@ietf.org>; Wed, 19 May 2010 16:32:07 +0200 (CEST)
Received: (qmail 16418 invoked from network); 19 May 2010 14:32:01 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.8]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <jsalowey@cisco.com>; 19 May 2010 14:32:01 -0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Wed, 19 May 2010 16:32:00 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>, <mrex@sap.com>
Message-ID: <C819C300.AF39%stefan@aaa-sec.com>
Thread-Topic: [TLS] Wrapping up cached info
Thread-Index: Acr2AF8iO6bF6i2yM0up48R7QWj7GQAD0o9pAFJeyFwAAPJioAAAxyPM
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE50A67CBEF@xmb-sjc-225.amer.cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: tls@ietf.org
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 14:34:41 -0000

The thought is that you would apply the same rules as you do when choosing
hah for the finished calculation.

To the extent that choice is dependent on the prf, then choice of this hash
will also be dependent on the prf.

There is no reason to chose any different hash algorithm than the one used
for the finished calculation since the security aspects of this is tied to
the finished calculation anyway. That is, you can't do better than the hash
of the finished calculation, and if you pick the same hash, you can't do
worse. Analysis is therefore easy.

Since the hash chosen to calculate the finished message is known only after
receiving the server hello, the client have to choose the one used on a
previous handshake, i.e. The one when the data was cached.

Yes, I think it would be OK for the server to not accept the choice of a
hash algorithm if it is less secure than the one used in the finished
calculation, but I see no reason to demand it. It could be left to the
server to decide based on local policy, but I would not object to require
the server to reject the cached data if that is the general preference.

/Stefan








On 10-05-19 4:19 PM, "Joseph Salowey (jsalowey)" <jsalowey@cisco.com> wrote:

> Hi Stefan,
> 
> To me this sounds like a good approach.  I have some questions on
> whether the hash chosen is dependent upon the cipher suite used below.
> 
> 
>> -----Original Message-----
>> From: Stefan Santesson [mailto:stefan@aaa-sec.com]
>> Sent: Wednesday, May 19, 2010 6:43 AM
>> To: Stefan Santesson; mrex@sap.com; Joseph Salowey (jsalowey)
>> Cc: tls@ietf.org
>> Subject: Re: [TLS] Wrapping up cached info
>> 
>> Not sure how I should interpret the silence?
>> 
>> I guess it means that everyone agrees with me :)
>> 
>> 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.
>> 
> [Joe] Will this be the same as the hash function used in the PRF of the
> cipher suite?  It seems that using the same hash might make security
> analysis a little easier.
> 
>> 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.
>> 
> [Joe] In the event that a different cipher suite is used with a
> different hash would the cached hash still be valid?
> 
>> 4) The only hash agility provided is that the client will send a hash
>> algorithm identifier with the hash.
>> 
> [Joe] This seems sufficient.
> 
>> 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
>>> 
>>> 
>> 
>