Re: [TLS] Wrapping up cached info

Marsh Ray <> Mon, 17 May 2010 17:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03BF23A6A51 for <>; Mon, 17 May 2010 10:50:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.432
X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I0GzLgAGNdOc for <>; Mon, 17 May 2010 10:50:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E32D83A68DC for <>; Mon, 17 May 2010 10:50:29 -0700 (PDT)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1OE4SL-000IZb-Ga; Mon, 17 May 2010 17:50:21 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id 16C836048; Mon, 17 May 2010 17:50:20 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX19uwu3j5m2pkI4kE2E1Sz7GK79Jq6+a6Rs=
Message-ID: <>
Date: Mon, 17 May 2010 12:50:20 -0500
From: Marsh Ray <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: Nicolas Williams <>
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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 17:50:31 -0000

On 5/17/2010 12:08 PM, Nicolas Williams wrote:
> On Mon, May 17, 2010 at 12:02:55PM -0500, Marsh Ray wrote:
>> It could perhaps be made to solve the problem, but IMHO it would require
>> so much additional complexity (aka attack surface) that it wouldn't be
>> worth it.
> Really?  It'd be a single extra message consisting of the hash of all
> the objects' data, concatenated in some canonical order (or maybe the
> hash of the XOR of the object data hashes, to avoid having to define a
> canonical order), that the first node to sent a Finished message would
> have to send, and which the other node would have to check.  Where's all
> that additional complexity, and how does it compare with the complexity
> of the protocol's security analysis as it stands now?

Try this: write up that "single extra message" in unambiguous RFC form.
The protocol message definition, the canonical order, server behavior,
client behavior, how to require per-server client caches when the server
hasn't yet been authenticated, etc. Security considerations for future
cached object types. Consider writing code to implement it including
test cases with actual checksum collisions.

Then put after it "... or we could just use a collision resistant hash

>> While I don't like to reject anything out-of-hand, injecting data into
> But you just did.

Sorry if it sounds that way. I didn't reject it, I said "It could
perhaps be made to solve the problem" and asked a bunch of pointed, but
answerable, questions. This is my way of saying that I could accept the
idea and inviting others to overcome those objections.

If I'd really wanted to reject it, I would have made just one
unanswerable objection like "I spoke to secret government cryptographers
who will not go on record and they said it was insecure" (again, this
did not happen just an example).

>> the calculation of the Finished messages raises a lot of concerns. The
> You mis-read.  Re-read.

Which part? I don't get it.

- Marsh