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

"Kemp, David P." <DPKemp@missi.ncsc.mil> Tue, 11 May 2010 21:22 UTC

Return-Path: <DPKemp@missi.ncsc.mil>
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 2D27B3A6A40 for <tls@core3.amsl.com>; Tue, 11 May 2010 14:22:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.154
X-Spam-Level:
X-Spam-Status: No, score=-4.154 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
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 hDsuPX67R2lx for <tls@core3.amsl.com>; Tue, 11 May 2010 14:22:16 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id 04FB63A6942 for <tls@ietf.org>; Tue, 11 May 2010 14:20:38 -0700 (PDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 11 May 2010 17:16:34 -0400
Message-ID: <201005112120.o4BLKLRL016765@stingray.missi.ncsc.mil>
In-Reply-To: <4BE9A1BD.9010905@extendedsubset.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [POSSIBLE SPAM] Re: [TLS] Collisions (Re: Consensus Call: FNV vs SHA1)
Thread-Index: AcrxOCxXY5CzAmJJSbG2pEgds3u+TwAEXShA
References: <87bpcn4cy6.fsf@mocca.josefsson.org> <C80E5AA0.AB38%stefan@aaa-sec.com><87bpcm3m2w.fsf@mocca.josefsson.org> <4BE9A1BD.9010905@extendedsubset.com>
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: <tls@ietf.org>
X-OriginalArrivalTime: 11 May 2010 21:21:34.0000 (UTC) FILETIME=[EE86C300:01CAF14F]
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 21:22:18 -0000

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

If the Finished message is not calculated as if the data were actually
transmitted, then it cannot ensure the integrity of that data.  Strike
the second sentence and the problem goes away.  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.

Dave



-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
Marsh Ray
Sent: Tuesday, May 11, 2010 2:28 PM
To: Simon Josefsson
Cc: tls@ietf.org
Subject: [POSSIBLE SPAM] Re: [TLS] Collisions (Re: Consensus Call: FNV
vs SHA1)
Importance: Low

On 5/11/2010 2:59 AM, Simon Josefsson wrote:
> 
> I'm thinking about two scenarios:
> 
>  1) the undetectable modification of the list of acceptable CA names
>     cause the client to select and use an unintended certificate.
> 
>  2) where multiple server certificates can be used to successfully
>     establish the key.  That can happen if two certificates use the
same
>     public key.  Once connected, the client will not know the server
by
>     the same identity (certificate) as the server believe the client
>     used.

Frankly, this scares the hell out of me.

I admit now that part of why I supported the simple 'hashtable' function
was to ensure that this aspect got thoroughly analyzed.

> This is not an problem in the sense that an attacker gains some
benefit
> (for 1 the client chose to proceed with the certificate

Hmm, this could enable an attacker to influence the client to choose a
client cert using different information than the server thought he sent,
and in a way which doesn't break the Finished hashes?

Let's say I have separate "administrator" and "normal user" client
certs, both recognized by a server. Could mitm trick me into authing
with the admin cert even if the server app didn't intend to ask for it?

Note MS IIS has a feature for client-cert-to-user mapping, so
theoretically that could end up running code with different actual user
permissions.

> and for 2 the
> attacker needs to know the private key of the server): instead I'm
> pointing at a semantic problem because, with the extension, the
> historically true invariant that the client, after handshake, will
know
> which certificate the server used, does not hold strongly.
> 
> This doesn't necessarily have to affect the document in any way, but
it
> is an interesting property.

Historically, it has turned out to be notoriously difficult to put
limits on the effects of a violated security guarantee. We may not be so
familiar with all the dependencies and assumptions made in the original
analysis that we can run through them backwards.

I recommend we walk through the security analysis on this again from
scratch. This time with extra focus on an attacker who can trivially
craft collisions.

Also, we should look into how this might interact with running multiple
servers on the same IP address (and same stack) using SNI. Sometimes
things that are secure in isolation do not produce a secure system when
composed.

- Marsh
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls