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

Stefan Santesson <stefan@aaa-sec.com> Tue, 13 July 2010 19:19 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 7F2523A69B3 for <tls@core3.amsl.com>; Tue, 13 Jul 2010 12:19:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.419
X-Spam-Level:
X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[AWL=0.830, 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 RM4mBVVgHPeE for <tls@core3.amsl.com>; Tue, 13 Jul 2010 12:19:21 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.94.112]) by core3.amsl.com (Postfix) with ESMTP id 9BC103A6A83 for <tls@ietf.org>; Tue, 13 Jul 2010 12:19:20 -0700 (PDT)
Received: from s128.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 5F4B841909A for <tls@ietf.org>; Tue, 13 Jul 2010 21:19:36 +0200 (CEST)
Received: (qmail 64546 invoked from network); 13 Jul 2010 19:19:27 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.5]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <mike-list@pobox.com>; 13 Jul 2010 19:19:27 -0000
User-Agent: Microsoft-Entourage/12.25.0.100505
Date: Tue, 13 Jul 2010 21:19:27 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: Michael D'Errico <mike-list@pobox.com>
Message-ID: <C86288DF.C908%stefan@aaa-sec.com>
Thread-Topic: [TLS] New cached-info draft 09 posted
Thread-Index: AcsiwE9RnoebCv0p4Emmt6gKf75ZFA==
In-Reply-To: <4C3CA4FA.3050206@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: Tue, 13 Jul 2010 19:19:22 -0000

Michael,

You are absolutely right and I was totally wrong.

In order to preserve the security properties of TLS 1.1 and below we would
have to use a combo which is not compatible with the current syntax.

Using the PRF seems however to have a similar problem. You would have to
indicate which PRF you are using, and if TLS 1.2 PRF is used, what hash
algorithm to use. That doesn't feel trivial either.

/Stefan




On 10-07-13 7:40 PM, "Michael D'Errico" <mike-list@pobox.com> wrote:

> Stefan Santesson wrote:
>> 
>> 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?
> 
> I'm not sure if you were disagreeing with me, so I'll clarify.  My point
> was that this struct:
> 
>        struct {
>             CachedInformationType type;
>             HashAlgorithm hash;
>             opaque hash_value<1..255>;
>        } CachedObject;
> 
> uses HashAlgorithm from RFC 5246.  There is no value for the MD5/SHA-1
> combo hash used in TLS 1.0 and 1.1, so we need to pick something that
> has an identifier.
> 
> Mike