Re: [TLS] Wrapping up cached info

Marsh Ray <marsh@extendedsubset.com> Mon, 17 May 2010 18:15 UTC

Return-Path: <marsh@extendedsubset.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFB2C3A6AD3 for <tls@core3.amsl.com>; Mon, 17 May 2010 11:15:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.418
X-Spam-Level:
X-Spam-Status: No, score=-0.418 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-a+NgvnKgB0 for <tls@core3.amsl.com>; Mon, 17 May 2010 11:15:32 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id CF1EA3A6AC1 for <tls@ietf.org>; Mon, 17 May 2010 11:15:07 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1OE4qB-000E48-9h; Mon, 17 May 2010 18:14:59 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id F1B0B6048; Mon, 17 May 2010 18:14:56 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/Z9KuM8l+0KMsrprDQlkwD4+Yj6CMjpS4=
Message-ID: <4BF187A0.3090408@extendedsubset.com>
Date: Mon, 17 May 2010 13:14:56 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: Ben Laurie <benl@google.com>
References: <C816DA05.66DF%uri@ll.mit.edu> <4BF168A3.40409@extendedsubset.com> <AC1CFD94F59A264488DC2BEC3E890DE50A67C326@xmb-sjc-225.amer.cisco.com> <4BF176BF.8020000@extendedsubset.com> <20100517170810.GY9429@oracle.com> <AANLkTimyy-PoErKMSAnpjT3bZGi_GN2t4h61XsZNtqY_@mail.gmail.com>
In-Reply-To: <AANLkTimyy-PoErKMSAnpjT3bZGi_GN2t4h61XsZNtqY_@mail.gmail.com>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [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 18:15:34 -0000

On 5/17/2010 12:17 PM, Ben Laurie wrote:
> 
> Why is agility a problem, though - could we not say that any hash that is
> currently required as a signature hash can be used, and identify the hash in
> the extension message?

Sure we could, but is it worth the cost?

Client Hello and Server Hello offer one shot to negotiate the use of
caching and the identifiers being used. Having it also negotiate the
hash algorithm at the same time raises the difficulty a bit!

As I see it, here are some challenges raised by hash agility:

1. TLS implementations will have to implement all the schemes or risk
interoperability issues or at least missed caching opportunities.

2. Probably just one scheme will be used in practice anyway. It's likely
not to be the most secure of the defined choices. The other schemes may
get little testing.

3. Clients and servers will be required to maintain multiple hashes for
every cacheable object.

4. Clients will likely have to send multiple hash formats until it sees
what kinds the specific target server can work with.

5. The "cross-hashfn collision" attack must now be considered. E.g. a
preimage of one hash fn could collide with a value from another, unless
the algorithm id is somehow incorporated into the hash value itself.

6. Bad guy may be able to influence client and server to use his choice
of hash functions for caching. He could inject phony failures for
example. This could create a "weakest link" situation where the attacker
can choose the weakest hash function among all supported alternatives.

All in all, good clean fun. :-) I just don't want a reflexive "gotta
have agility" to make the proposal inelegant and unwieldy so it has
trouble gaining widespread acceptance.

- Marsh