Re: [TLS] Wrapping up cached info

Michael D'Errico <mike-list@pobox.com> Wed, 19 May 2010 17:34 UTC

Return-Path: <mike-list@pobox.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 083E03A6A50 for <tls@core3.amsl.com>; Wed, 19 May 2010 10:34:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.077
X-Spam-Level:
X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_20=-0.74]
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 7J83BHz9uJNm for <tls@core3.amsl.com>; Wed, 19 May 2010 10:34:40 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 8FCB63A69B2 for <tls@ietf.org>; Wed, 19 May 2010 10:34:40 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id B5EE2B4251; Wed, 19 May 2010 13:34:33 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=N+ffevLoow4W Yz/xOGOAX6UDPu4=; b=klG+lmwrZHyYu2PXPB7URiwS6erQ/aeV20Y8NIiMS091 ZcriYVQTKm/beIwS9A7eBoFTzxpH1F/Iyo3N4YKYc1Xi8IGwWFn0qr4KovNnpHVM HyxJ3nv3GjZkeds4nTigokLwU2N+L0RKCTyqfiEiSGSDPNBy5RHoHOGwDwS8jHw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=RK7tlS 2yiNK6RIbIiPYw7SzSBt1rOkRlREMoQeHUczw6K96paq9dZWWnF7uHZwh1RjTbFw K79U+Ba71877IJF8afrHwBigUMKLp6NMJg+WQngawy5vdqi3M+1gCgN/buzrkUs2 v9qX3PHosfxLaVr5Q8vQaC3+/T4tqlpzhzbNE=
Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 9D92DB424F; Wed, 19 May 2010 13:34:32 -0400 (EDT)
Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id C6173B424A; Wed, 19 May 2010 13:34:30 -0400 (EDT)
Message-ID: <4BF42125.9020600@pobox.com>
Date: Wed, 19 May 2010 10:34:29 -0700
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Marsh Ray <marsh@extendedsubset.com>
References: <C819B76D.AF2B%stefan@aaa-sec.com> <4BF3FD9C.3040206@pobox.com> <4BF40B4E.20702@extendedsubset.com>
In-Reply-To: <4BF40B4E.20702@extendedsubset.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: C91C51B8-636C-11DF-825D-D033EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com
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 17:34:42 -0000

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