Re: [TLS] New cached-info draft 09 posted

Stefan Santesson <stefan@aaa-sec.com> Mon, 12 July 2010 21:47 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 9F91E3A6A62 for <tls@core3.amsl.com>; Mon, 12 Jul 2010 14:47:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.227
X-Spam-Level:
X-Spam-Status: No, score=-1.227 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 11rHo3MIXQ2H for <tls@core3.amsl.com>; Mon, 12 Jul 2010 14:47:23 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.94.112]) by core3.amsl.com (Postfix) with ESMTP id 3321A3A6A0A for <tls@ietf.org>; Mon, 12 Jul 2010 14:47:23 -0700 (PDT)
Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 1BD2C3E5F02 for <tls@ietf.org>; Mon, 12 Jul 2010 23:45:13 +0200 (CEST)
Received: (qmail 24063 invoked from network); 12 Jul 2010 21:45:07 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.9]) (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 <mike-list@pobox.com>; 12 Jul 2010 21:45:07 -0000
User-Agent: Microsoft-Entourage/12.25.0.100505
Date: Mon, 12 Jul 2010 23:45:04 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: Michael D'Errico <mike-list@pobox.com>
Message-ID: <C8615980.C7C6%stefan@aaa-sec.com>
Thread-Topic: [TLS] New cached-info draft 09 posted
Thread-Index: AcsiC3yQ3x+w9+iNlUiaL5YCS58R9Q==
In-Reply-To: <4C3A6CE4.3030601@pobox.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] New cached-info draft 09 posted
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: Mon, 12 Jul 2010 21:47:24 -0000

Replying to the whole thread by replying to the original message.

I don't see the benefit of using a hash that is stronger than the hash
function used to generate the finished message.

We only need an identifier. The only security requirement identified after a
very long debate is that we want to make sure that we preserve the security
properties of the Finished message. That we do if we use the same hash
function.

We had a very long debate about this and we finally reached an agreement.
Can we stick with it or do we have to redesign this over and over again?

/Stefan


On 10-07-12 3:16 AM, "Michael D'Errico" <mike-list@pobox.com> wrote:

> Is the goal for cached-info to only work with TLS 1.2 and later?  If
> not, then I think there is a problem using the Finished hash function.
> In TLS 1.0 and 1.1, both MD5 and SHA-1 are used in the PRF to compute
> the verify_data.
> 
> That could be fixed by saying that SHA-1 is used for TLS 1.0 and 1.1.
> 
> Mike
> 
> 
> 
> Stefan Santesson wrote:
>> All,
>> 
>> I have submitted a new cached info draft 09
>> http://tools.ietf.org/html/draft-ietf-tls-cached-info-09
>> 
>> Diff:
>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-cached-info-09.txt
>> 
>> This draft should reflect the agreed resolutions to all issues discussed on
>> the list.
>> 
>> The material changes are:
>> - The use of FNV is removed and replaced with a requirement to use the hash
>> algorithm (for each cached object) that was used to calculate the Finished
>> message of the handshake from which the data was cached.
>> 
>> - A hash algorithm identifier is added to the CachedObject structure to
>> identified the hash algorithm
>> 
>> - The options of the server has been reduced to either provide an empty
>> extension or to specify specific supported cached objects.
>> 
>> - The security consideration has been updated with respect to the discussion
>> concerning use of hash algorithms and with respect to cached information
>> from encrypted handshakes.