Re: [TLS] Wrapping up cached info

Nicolas Williams <Nicolas.Williams@oracle.com> Thu, 20 May 2010 16:22 UTC

Return-Path: <Nicolas.Williams@oracle.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 2C1743A6AA2 for <tls@core3.amsl.com>; Thu, 20 May 2010 09:22:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.122
X-Spam-Level:
X-Spam-Status: No, score=-4.122 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 xd9A3Cpri3tp for <tls@core3.amsl.com>; Thu, 20 May 2010 09:22:05 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id BAEBA3A69E1 for <tls@ietf.org>; Thu, 20 May 2010 09:22:04 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4KGLgUL031511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 May 2010 16:21:44 GMT
Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4KFxorE003346; Thu, 20 May 2010 16:21:40 GMT
Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 285116281274372498; Thu, 20 May 2010 09:21:38 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 May 2010 09:21:38 -0700
Date: Thu, 20 May 2010 11:21:32 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Yoav Nir <ynir@checkpoint.com>
Message-ID: <20100520162131.GO9605@oracle.com>
References: <C8178EA6.AE48%stefan@aaa-sec.com> <C819B76D.AF2B%stefan@aaa-sec.com> <006FEB08D9C6444AB014105C9AEB133FB48F1B5AE0@il-ex01.ad.checkpoint.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB48F1B5AE0@il-ex01.ad.checkpoint.com>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: acsinet15.oracle.com [141.146.126.227]
X-CT-RefId: str=0001.0A090202.4BF56199.011E:SCFMA922111,ss=1,fgs=0
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:22:07 -0000

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.

Nico
--