Re: [TLS] Wrapping up cached info

Marsh Ray <marsh@extendedsubset.com> Mon, 17 May 2010 15:34 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 ECEAB3A6A98 for <tls@core3.amsl.com>; Mon, 17 May 2010 08:34:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.48
X-Spam-Level:
X-Spam-Status: No, score=-0.48 tagged_above=-999 required=5 tests=[AWL=-0.481, 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 2-euY02LSlJy for <tls@core3.amsl.com>; Mon, 17 May 2010 08:34:40 -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 EB3FF3A6D3C for <tls@ietf.org>; Mon, 17 May 2010 08:30:46 -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 1OE2H8-000D9F-2S; Mon, 17 May 2010 15:30:38 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id EAC3E6048; Mon, 17 May 2010 15:30:35 +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: U2FsdGVkX19uc5B0yNhctJ5Ogj8TmUjbyyj0eezScpY=
Message-ID: <4BF1611C.3090005@extendedsubset.com>
Date: Mon, 17 May 2010 10:30:36 -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: Stefan Santesson <stefan@aaa-sec.com>
References: <C8171810.ADE4%stefan@aaa-sec.com>
In-Reply-To: <C8171810.ADE4%stefan@aaa-sec.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 15:34:41 -0000

On 5/17/2010 8:58 AM, Stefan Santesson wrote:
> I would like to wrap up the discussion about cached info, if possible.

For the record, I think this could be a really useful extension that
saves huge amounts of aggregate bandwidth and latency in specific
circumstances.

It would be a shame for it to be dropped basically just because of the
lack of obvious choice of a hash function at the current time.

> 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.

Specifically:

1. Bad guy can, without detection, cause the client to consider a
different set of options when selecting a client certificate. He could
cause the client to be unable to select a client certificate when it
should, or cause it to select a different one than it would have. This
is clearly an unanticipated semantic change for application code and may
introduce a vulnerability somewhere.

2. Bad guy can cause a collision to be cached an indefinite length of
time and thus arrange for a failure to occur at some point in a future
handshake, possibly as a drive-by without even being a MitM. Since
recovery from failure requires coordination between the TLS stack and
the application managing the underlying transport, it's impractical for
this WG to gauge the likely success of the reconnect. This represents an
escalation of the attacker's capability over the status quo.

3. Much of this draft is written as if a generic facility is proposed,
yet the security analysis is only addressing the two specific cases. Any
future object types would need their own analysis concerning the lack of
collision resistance, or perhaps they would need yet another mechanism.

> 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.

+1

This also has the effect of "binding the cached objects' data into the
handshake" as Nico had wanted, without modifications to the calculation
of the Finished messages.

- Marsh