Re: [TLS] Wrapping up cached info

"Blumenthal, Uri - 0668 - MITLL" <> Mon, 17 May 2010 15:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7FE6D28C180 for <>; Mon, 17 May 2010 08:37:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.819
X-Spam-Status: No, score=-4.819 tagged_above=-999 required=5 tests=[AWL=-0.821, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K-FAoXUkmQKF for <>; Mon, 17 May 2010 08:37:00 -0700 (PDT)
Received: from (MX1.LL.MIT.EDU []) by (Postfix) with ESMTP id 57C673A6D30 for <>; Mon, 17 May 2010 08:33:50 -0700 (PDT)
Received: from ( by (unknown) with ESMTP id o4HFXWN9031401; Mon, 17 May 2010 11:33:34 -0400
From: "Blumenthal, Uri - 0668 - MITLL" <>
To: Stefan Santesson <>, "" <>
Date: Mon, 17 May 2010 11:33:25 -0400
Thread-Topic: [TLS] Wrapping up cached info
Thread-Index: Acr1yPqXX9nCr/2ZD02C5ih5zz1aVAADU+YL
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-Entourage/
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-17_02:2010-02-06, 2010-05-17, 2010-05-17 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1005170091
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: Mon, 17 May 2010 15:37:01 -0000


There is one problem.

If it turns out that you need SHA256 for security reasons - then you'll also
need algorithm agility because nobody can guarantee that SHA256 will hold
(remember - MD4, MD5, SHA1...? :-).

Also, do you care how many bits the hash outputs, and how many of those bits
you use? 

Let's provide the analysis and hope that it shows no security issues here.

On 5/17/10 09:58 , "Stefan Santesson" <> wrote:

> I would like to wrap up the discussion about cached info, if possible.
> I have to admit that I'm stuck as editor. I have a draft that I think is
> done with a possible amendment to the security considerations and some
> additional informational references to FNV.
> I don't think the discussion has shown that the security assumptions are
> wrong, I.e. That any alteration of cached data in the sense that the server
> and the client are in disagreement of what the cached data is, will lead to
> a handshake failure.
> Threats are therefore reduced to inconveniences upon handshake failures (as
> far as discussion has showed.
> However, there is still a possible alteration of the security properties of
> the finished calculation. That is, it is possible upon a FNV collision to
> disagree on the cached data without failing the finished calculation.
> I can't see any practical exploit of this fact. If this is considered a
> blocking problem, then it is easiest solved by using a secure hash (SHA-256)
> which effectively restores the security properties of the finished
> calculation. This is best done by s/FNV/SHA-256. No agility.
> I will not lead an effort to specify a variant of this protocol where the
> server provides the identifiers, either as any random identifier or in the
> form of a URI. If that is the desire of the WG, I will be happy to hand over
> editorship to anyone, assigned by the chairs, who wants to take over.
> I request WG chair guidance on how to proceed, if at all with this document.
> /Stefan
> _______________________________________________
> TLS mailing list