Re: [TLS] [POSSIBLE SPAM] Re: Collisions (Re: Consensus Call: FNV vs SHA1)

Marsh Ray <marsh@extendedsubset.com> Tue, 11 May 2010 22:02 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 61ADF3A6A88 for <tls@core3.amsl.com>; Tue, 11 May 2010 15:02:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.449
X-Spam-Level:
X-Spam-Status: No, score=-0.449 tagged_above=-999 required=5 tests=[AWL=-0.450, 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 HjHmOKG9zLjV for <tls@core3.amsl.com>; Tue, 11 May 2010 15:02:07 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 9D88D3A69DE for <tls@ietf.org>; Tue, 11 May 2010 15:02:04 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1OBxWT-000MZV-OI; Tue, 11 May 2010 22:01:53 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 9556A631D; Tue, 11 May 2010 22:01:52 +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+J5Z8+anPK/Vi9LLrYmLRv2Kx3k1U3pOg=
Message-ID: <4BE9D3D2.8070009@extendedsubset.com>
Date: Tue, 11 May 2010 17:01:54 -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: "Kemp, David P." <DPKemp@missi.ncsc.mil>
References: <87bpcn4cy6.fsf@mocca.josefsson.org> <C80E5AA0.AB38%stefan@aaa-sec.com><87bpcm3m2w.fsf@mocca.josefsson.org> <4BE9A1BD.9010905@extendedsubset.com> <201005112120.o4BLKLRL016765@stingray.missi.ncsc.mil>
In-Reply-To: <201005112120.o4BLKLRL016765@stingray.missi.ncsc.mil>
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] [POSSIBLE SPAM] Re: Collisions (Re: Consensus Call: FNV vs SHA1)
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: Tue, 11 May 2010 22:02:08 -0000

On 5/11/2010 4:16 PM, Kemp, David P. wrote:
> The security analysis should focus on the bizarre Finished message
> calculation rather than on the hash algorithm.  The essence of caching
> is that cached data has the same effect as transmitted data, only faster
> :-).  Section 4 violates that assumption:
> 
>    "The handshake protocol will proceed using the cached data as if it
>    was provided in the handshake protocol. The Finished message will
>    however be calculated over the actual data exchanged in the handshake
>    protocol."

It is definitely a mismatch, but I think it's the simplest and least
inconsistent of the possible ways it could be defined.

> If the Finished message is not calculated as if the data were actually
> transmitted, then it cannot ensure the integrity of that data.

Not as easily and directly, but it can if we can prove either:

A. the values transmitted are perfect equivalents for the values used, or

B. a mismatch (no matter how carefully engineered by the attacker) can
not make a semantic difference to any reasonable application code other
than what would result from an ordinary Finished verify failure.

> Strike
> the second sentence and the problem goes away.

And you gain a harder one in return...

> The transmitter has to
> perform Finished calculations on the original datastream, then
> post-process it to substitute hashes where possible.  The receiver first
> has to expand hashes into data, and then perform handshake operations
> including Finished calculations.

But these things happen at different layers of the protocol.

The Finished messages are calculated on the handshake layer as carried
by the record layer (IIRC this includes the HandshakeType and length
bytes). Currently it can be implemented by keeping a running hash of the
bytes without actually buffering them in memory. That code shouldn't
need to change at all.

Operations like iterating a list of TAs to find a client cert or
validating a server cert are typically going to be performed at a higher
layer in the code that probably already has similar function defined for
processing those items.

If you needed to calculate a Finished message by retroactively modifying
the handshake data stream, it would be harder. You would have to do
things like fix up length fields (potentially recursing up multiple
layers). That would certainly make introducing new
CachedInformationTypes more disruptive. It would also effectively
require implementations to buffer everything until all substitutions
were resolved.

That's why I think the draft does it the best way.

- Marsh