Re: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call:

Marsh Ray <marsh@extendedsubset.com> Thu, 13 May 2010 14:42 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 CFBFB3A6B67 for <tls@core3.amsl.com>; Thu, 13 May 2010 07:42:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.875
X-Spam-Level:
X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_20=-0.74]
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 liJUTb2GutdM for <tls@core3.amsl.com>; Thu, 13 May 2010 07:42: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 239B93A6B65 for <tls@ietf.org>; Thu, 13 May 2010 07:42:37 -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 1OCZcI-0000zo-Th; Thu, 13 May 2010 14:42:27 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 3E7F56456; Thu, 13 May 2010 14:42:22 +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: U2FsdGVkX18m1z+vsXWZYX5xiDLM+fQoVd7mgm1n2m8=
Message-ID: <4BEC0FCF.9010302@extendedsubset.com>
Date: Thu, 13 May 2010 09:42:23 -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: Yoav Nir <ynir@checkpoint.com>
References: <20100510221531.GC9429@oracle.com> <201005111339.o4BDdoYQ009725@fs4113.wdf.sap.corp> <20100511152153.GF9429@oracle.com> <201005111803.o4BI3fhO006065@stingray.missi.ncsc.mil> <20100511190958.GR9429@oracle.com> <4BE9B0BC.2000101@extendedsubset.com> <20100511194620.GU9429@oracle.com> <4BE9B856.40000@extendedsubset.com> <20100511200728.GW9429@oracle.com> <4BE9CC88.6040103@extendedsubset.com> <87aas5sbzy.fsf@mocca.josefsson.org> <4BEABC2C.6090507@extendedsubset.com> <006FEB08D9C6444AB014105C9AEB133FB48F1B5ABA@il-ex01.ad.checkpoint.com>
In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB48F1B5ABA@il-ex01.ad.checkpoint.com>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Simon Josefsson <simon@josefsson.org>, "Kemp, David P." <DPKemp@missi.ncsc.mil>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call:
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: Thu, 13 May 2010 14:42:41 -0000

On 5/13/2010 2:15 AM, Yoav Nir wrote:
> I kind of fail to see where the discussion shifted. In fact we have
> NOT determined that *malicious* collision resistance is a concern.

I have determined that I am concerned about malicious collisions, until
I get a comfortable feeling that they're not a problem. It's certainly
not anyone else's job to make me feel a certain way, but I hope you
don't mind if I ask a bunch of questions.

We should also keep in mind that the extension only addresses two types
of cached data at this time, but could possibly later include more. If
security analysis needs to based on the particulars of a given cached
item type that should get written down somewhere in the draft.

> A client connects to a server and caches the credentials. Next time
> it connects to the *same* server,

The client may intend to connect to the same server, but we can't assume
it actually *is* connecting to the same server at this point in the
handshake. Proving that it actually is the same server is the #1 goal of
the handshake, and can't be considered a success until the Finished
message is checked.

> it shows an extension that proves
> knowledge of the credentials.

How does it do that?

The extension is sent in-the-clear so it's not a shared secret. I don't
see any signing operation either.

Without collision resistance, attacker may have arranged for the client
to cache something different with the same hash. Client and server may
be using the same hash to talk about different things.

> Assuming the credentials haven't
> changed, the server can skip sending the credentials, but still has
> to prove ownership by signing something or by decrypting the
> pre-master secret. So what could an attacker do?

Are we discussing only the certificate_chain caching right now?

There's also the trusted_cas type and any defined in the future (if in
fact this is a general extensible facility).

- Marsh