Re: [TLS] Justification

Nicolas Williams <> Mon, 17 May 2010 15:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98FE83A698B for <>; Mon, 17 May 2010 08:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.294
X-Spam-Status: No, score=-5.294 tagged_above=-999 required=5 tests=[AWL=1.304, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b3PW6gnlxW6K for <>; Mon, 17 May 2010 08:53:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7F7283A6A8D for <>; Mon, 17 May 2010 08:52:09 -0700 (PDT)
Received: from ( []) by (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4HFpj41018506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 May 2010 15:51:49 GMT
Received: from ( []) by (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4HF8Hd2022296; Mon, 17 May 2010 15:51:44 GMT
Received: from by with ESMTP id 247244641274111497; Mon, 17 May 2010 08:51:37 -0700
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 May 2010 08:51:35 -0700
Date: Mon, 17 May 2010 10:51:24 -0500
From: Nicolas Williams <>
To: Stefan Santesson <>
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.4BF16616.00FB:SCFMA922111,ss=1,fgs=0
Cc: Simon Josefsson <>, "Kemp, David P." <>,
Subject: Re: [TLS] Justification
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:53:49 -0000

On Mon, May 17, 2010 at 05:35:24PM +0200, Stefan Santesson wrote:
> On 10-05-17 5:20 PM, "Nicolas Williams" <> wrote:
> > The key problem with this
> > extension is that the cached objects aren't bound into the handshake.
> > IMO regardless of how the cached object IDs are obtained, whether by
> > SHA-1 hashing, FNV-1a hashing, server-assigned IDs, or URIs, the object
> > data must be bound into the handshake.
> How can the cached data NOT be bound to the handshake if they are hashed
> with a secure hash which in turn are included in the finished calculation?

They are certainly NOT bound if we use FNV-1a, which is the proposal on
the table.

Plus, if we agree that we need this binding and we want to keep the
current proposal more or less as-is, then we'll need hash agility, which
complicates the protocol.

I'd rather we do something along these lines instead:

 - use FNV-1a (or whatever) to _name_ the objects by checksum;

 - locally hash all the objects' data using the (rather, a) hash
   function used by TLS's Finished message computation and add this hash
   as an input to the Finished message computation:

    - this could be done without modifying the Finished message
      computation by adding a message bearing the hash of all cached
      objects' data to be sent before the first Finished message (then,
      by virtue of being a handshake message, this new message will be
      bound into the Finished messages).

On collision the handshake then fails.  The client should cache
handshake failure information so that on retry it can forgo caching and
then detect collisions.