Re: [TLS] Wrapping up cached info

Nicolas Williams <> Thu, 20 May 2010 16:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C1743A6AA2 for <>; Thu, 20 May 2010 09:22:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.122
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xd9A3Cpri3tp for <>; Thu, 20 May 2010 09:22:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BAEBA3A69E1 for <>; Thu, 20 May 2010 09:22:04 -0700 (PDT)
Received: from ( []) by (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 ( []) by (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4KFxorE003346; Thu, 20 May 2010 16:21:40 GMT
Received: from by with ESMTP id 285116281274372498; Thu, 20 May 2010 09:21:38 -0700
Received: from (/ 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 <>
To: Yoav Nir <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: []
X-CT-RefId: str=0001.0A090202.4BF56199.011E:SCFMA922111,ss=1,fgs=0
Cc: "" <>
Subject: Re: [TLS] Wrapping up cached info
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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.