Re: [xmpp] IQ Handling vulnerabilities

Alexander Holler <holler@ahsoftware.de> Tue, 11 February 2014 17:29 UTC

Return-Path: <holler@ahsoftware.de>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D911A06A2 for <xmpp@ietfa.amsl.com>; Tue, 11 Feb 2014 09:29:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.208
X-Spam-Level:
X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xj_oeDZK3HcM for <xmpp@ietfa.amsl.com>; Tue, 11 Feb 2014 09:29:04 -0800 (PST)
Received: from mail.ahsoftware.de (h1446028.stratoserver.net [85.214.92.142]) by ietfa.amsl.com (Postfix) with ESMTP id 049D31A063F for <xmpp@ietf.org>; Tue, 11 Feb 2014 09:29:04 -0800 (PST)
Received: by mail.ahsoftware.de (Postfix, from userid 65534) id AC4C1423C2A6; Tue, 11 Feb 2014 18:29:01 +0100 (CET)
Received: from eiche.ahsoftware (p57B23CD3.dip0.t-ipconnect.de [87.178.60.211]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ahsoftware.de (Postfix) with ESMTPSA id 40F2E423C29B for <xmpp@ietf.org>; Tue, 11 Feb 2014 18:28:52 +0100 (CET)
Received: by eiche.ahsoftware (Postfix, from userid 65534) id 654CA80503; Tue, 11 Feb 2014 18:28:49 +0100 (CET)
Received: from krabat.ahsoftware (unknown [IPv6:feee::5246:5dff:fe8b:95f8]) by eiche.ahsoftware (Postfix) with ESMTP id F11877F829; Tue, 11 Feb 2014 17:28:24 +0000 (UTC)
Message-ID: <52FA5DB5.50206@ahsoftware.de>
Date: Tue, 11 Feb 2014 18:28:21 +0100
From: Alexander Holler <holler@ahsoftware.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Dave Cridland <dave@cridland.net>
References: <CAOb_FnxS-dMT85N7LHj5M9JWk3pL85=ugrDqaT7j5d28HBr0Cw@mail.gmail.com> <CF194491.38AD3%jhildebr@cisco.com> <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <CF1A369C.38BE2%jhildebr@cisco.com> <CAKHUCzyCwKbmnUoXLHW=XzYbiFrcg-dQsDojGUnA-_r3qK+_Vg@mail.gmail.com> <CF1A4928-54B5-4A95-9A4B-0EC572A3CDBD@cisco.com> <CF1E56C5.38F45%jhildebr@cisco.com> <B671D7DA-CE9A-4A2C-8EDE-BF94F5F6FE82@xnyhps.nl> <52FA165B.8050901@ahsoftware.de> <CAKHUCzzhxKLbkNE=WjtP9S6XWm14-5e7Ut150x4k1akegm+1Qw@mail.gmail.com> <52FA3E53.3060009@ahsoftware.de> <0C2D606F-F718-4B07-A0A8-329C547D1BD8@xnyhps.nl> <52FA4D02.5050907@ahsoftware.de> <52FA5060.9040303@ahsoftware.de> <CAKHUCzyv1cMiZn9OkAXOeaMs-Ti8Z32K-gjygc1dMM9NVLqVPQ@mail.gmail.com>
In-Reply-To: <CAKHUCzyv1cMiZn9OkAXOeaMs-Ti8Z32K-gjygc1dMM9NVLqVPQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-15"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: XMPP Working Group <xmpp@ietf.org>
Subject: Re: [xmpp] IQ Handling vulnerabilities
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Feb 2014 17:29:06 -0000

Am 11.02.2014 18:06, schrieb Dave Cridland:
> On Tue, Feb 11, 2014 at 4:31 PM, Alexander Holler <holler@ahsoftware.de>wrote:
>
>> which I interpret such, that, besides using a hash from hash (so no new
>> source), the ID consists of just the first 10 characters of the 40 of a
>> sha1. And then you argument with the collision rate of sha1?
>>
>>
> Oh, I see what you mean now.
>
> Yes, on that model the collision would probably happen much sooner.
>
> It's a collision space of 2^40, though, so a birthday attack would hit
> after about 1.3 million stanzas by my calculations. The chance of this
> causing a problem seems pretty low.

Based on the assumption that a hash of a hash has the same collision 
space as the hash itself.

Since I'm long out of university and academics and I'm unfortunately 
quiet out of practice in dealing with maths (even if I liked to do so, 
but math isn't needed that often in real world computing than 
universities tend to teach), I'm not going into a discussion about how 
(un)likely it is that two consequent outputs of such a homegrewn 
algorithm (sorry for that term) are different.

I just wanted to raise awareness that whatever is used should still 
produce unique numbers (for a short period of time) and not just numbers 
which are unpredictable. It's easy to predict that a serial counter is 
unique for some time, but I don't see that when someone uses a series 
like whateverhash(whateverhash(...) and I wouldn't trust such without 
having a deeper look at it.

Regards,

Alexander Holler