Re: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call:

"Brian Smith" <> Wed, 12 May 2010 14:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 57B083A6CA1 for <>; Wed, 12 May 2010 07:42:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F7YeNrfttq8A for <>; Wed, 12 May 2010 07:42:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EA28028C2BC for <>; Wed, 12 May 2010 07:26:52 -0700 (PDT)
Received: from T60 (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id E9893509DD for <>; Wed, 12 May 2010 10:26:35 -0400 (EDT)
From: "Brian Smith" <>
To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Date: Wed, 12 May 2010 09:26:36 -0500
Message-ID: <003601caf1df$24068ad0$6c13a070$>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHHMro8BXdqp6B5/qHhToooO2CPmgFmW+YJAjUmb1cBpAvaegHc4ZdyAZ8bmowBonugeAHLA4UDAW9AI3oCX1cKLwJX6SjDAjZV8Kg=
Content-Language: en-us
Subject: Re: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call:
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: Wed, 12 May 2010 14:42:42 -0000

Simon Josefsson wrote:
> Marsh Ray <> writes:
> > Alternatively, if we determine that indeed the
> > non-collision-resistance of the hash function is the root of all
> > remaining concerns that would be very positive. We could solve them
> > all in one stroke with s/FNV-1a/SHA-256/g.
> If collision-resistance is a required property (I'm not convinced yet), I
believe we
> need hash agility for the possibility that SHA-256 is weak.

In that case, it would be better to consider a new design that follows the
session ID / server-public-key-id design, where the server provides a
cryptographically secured (by TLS) opaque identifier (format totally
unspecified) for the cached data that the client can then use in subsequent

Somebody earlier in this thread made a good point that you rarely need this
caching extension if you make good use of session resumption. I think it may
be much better to consider extensions to session resumption that make it
safe(r) to keep sessions open indefinitely (many weeks/months/years).
Perhaps we just need a new extension that says "use this ticket to create a
session using the same server certificate and/or client cert CA list that
was used when the session ticket was created."