Re: [TLS] Wrapping up cached info

Ben Laurie <benl@google.com> Thu, 20 May 2010 16:40 UTC

Return-Path: <benl@google.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 24BEB3A685E for <tls@core3.amsl.com>; Thu, 20 May 2010 09:40:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.376
X-Spam-Level:
X-Spam-Status: No, score=-103.376 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 lJFmfQ8tZ4SF for <tls@core3.amsl.com>; Thu, 20 May 2010 09:40:06 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E6DBE3A67E5 for <tls@ietf.org>; Thu, 20 May 2010 09:40:04 -0700 (PDT)
Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id o4KGdv4m027954 for <tls@ietf.org>; Thu, 20 May 2010 09:39:57 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1274373598; bh=wFBjL/dZZwXiHVRqbrq93L2e2mY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=ciXknlSDV0xtBxXFIkQXQjfRiEeukvdcuY8CjjarJ06f6geNdCrWRt7CytekSLXn+ ra2B7tuVnbihXW0kb30pg==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=OCO+7H6Q+bneSiZUp3+W/XwCw5Pv+vvE1O29QgpFg5iNHYVPP1TlGXEIPNxJobLoM tpVi+WQdZj3/RrPrkN71g==
Received: from gwj23 (gwj23.prod.google.com [10.200.10.23]) by hpaq2.eem.corp.google.com with ESMTP id o4KGdtxR019234 for <tls@ietf.org>; Thu, 20 May 2010 09:39:56 -0700
Received: by gwj23 with SMTP id 23so11272gwj.3 for <tls@ietf.org>; Thu, 20 May 2010 09:39:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.65.4 with SMTP id n4mr1677554yba.63.1274373595173; Thu, 20 May 2010 09:39:55 -0700 (PDT)
Received: by 10.150.188.9 with HTTP; Thu, 20 May 2010 09:39:55 -0700 (PDT)
In-Reply-To: <20100520162131.GO9605@oracle.com>
References: <C8178EA6.AE48%stefan@aaa-sec.com> <C819B76D.AF2B%stefan@aaa-sec.com> <006FEB08D9C6444AB014105C9AEB133FB48F1B5AE0@il-ex01.ad.checkpoint.com> <20100520162131.GO9605@oracle.com>
Date: Thu, 20 May 2010 17:39:55 +0100
Message-ID: <AANLkTinVgRCvnJOOWZsaZVIJAe3Og7JHPF65t5brn0SO@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Nicolas Williams <Nicolas.Williams@oracle.com>
Content-Type: multipart/alternative; boundary=000e0cd5a1ba7394660487093962
X-System-Of-Record: true
Cc: "tls@ietf.org" <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: Thu, 20 May 2010 16:40:09 -0000

On 20 May 2010 17:21, Nicolas Williams <Nicolas.Williams@oracle.com> wrote:

> On Thu, May 20, 2010 at 07:42:03AM +0300, Yoav Nir wrote:
> > I still don't see why we need a secure cryptographic hash there as
> > well. There has still not been any outline of an attack even in the
> > presence of collisions.
>
> I'd rather use a more conservative procedure.  Given a lack of
> cryptographic protection of relevant protocol elements, it should be the
> proponents' job to provide the analysis showing that the missing
> protection does not create security problems.  Such an approach will
> result in more conservative protocol designs, but also it will result in
> lower review burden for reviewers.  Reviewer resources are finite;
> making efficient use of them is important.
>
> Providing unnecessary protection to such protocol elements is generally
> harmless from a security point of view (always, if we ignore traffic
> analysis issues, which we do in this context).  While not providing
> necessary protection to such protocol elements is a sure way to get into
> trouble.
>
> The burden of analysis may shift onto reviewers when a conservative
> protocol design presents significant performance or complexity
> trade-offs.  In this case we seem to have settled on a design (proposed
> by Stefan) that does not impose significant performance nor complexity
> costs and which does provide the cryptographic protection that some
> reviewers (yours truly included) have requested.  Sounds like a win-win
> to me.
>

+1.


>
> Nico
> --
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>