[TLS] Wrapping up cached info

Stefan Santesson <stefan@aaa-sec.com> Mon, 17 May 2010 13:58 UTC

Return-Path: <stefan@aaa-sec.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id D43D83A69BB for <tls@core3.amsl.com>; Mon, 17 May 2010 06:58:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[AWL=-0.751, BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 10NrYViPK4XF for <tls@core3.amsl.com>; Mon, 17 May 2010 06:58:22 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se []) by core3.amsl.com (Postfix) with ESMTP id EC7DE3A682D for <tls@ietf.org>; Mon, 17 May 2010 06:58:19 -0700 (PDT)
Received: from s29.loopia.se (s34.loopia.se []) by s87.loopia.se (Postfix) with ESMTP id C6AA928D750 for <tls@ietf.org>; Mon, 17 May 2010 15:58:15 +0200 (CEST)
Received: (qmail 11955 invoked from network); 17 May 2010 13:58:10 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO []) (stefan@fiddler.nu@[]) (envelope-sender <stefan@aaa-sec.com>) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <tls@ietf.org>; 17 May 2010 13:58:10 -0000
User-Agent: Microsoft-Entourage/
Date: Mon, 17 May 2010 15:58:08 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: <tls@ietf.org>
Message-ID: <C8171810.ADE4%stefan@aaa-sec.com>
Thread-Topic: Wrapping up cached info
Thread-Index: Acr1yPqXX9nCr/2ZD02C5ih5zz1aVA==
In-Reply-To: <Pine.LNX.4.44.1005132018460.13071-100000@citation2.av8.net>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: [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: Mon, 17 May 2010 13:58:22 -0000

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.