Re: [xmpp] IQ Handling vulnerabilities

Alexander Holler <> Tue, 11 February 2014 15:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 95B911A01A8 for <>; Tue, 11 Feb 2014 07:15:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.208
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BE5HIA-pl16Q for <>; Tue, 11 Feb 2014 07:15:05 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DC4A91A0376 for <>; Tue, 11 Feb 2014 07:15:03 -0800 (PST)
Received: by (Postfix, from userid 65534) id B2036423C2E3; Tue, 11 Feb 2014 16:15:02 +0100 (CET)
Received: from eiche.ahsoftware ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 7A81D423C2E2 for <>; Tue, 11 Feb 2014 16:14:57 +0100 (CET)
Received: by eiche.ahsoftware (Postfix, from userid 65534) id 2B4417FA1B; Tue, 11 Feb 2014 16:14:56 +0100 (CET)
Received: from [IPv6:feeb::c685:8ff:fe12:175d] (unknown [IPv6:feeb::c685:8ff:fe12:175d]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by eiche.ahsoftware (Postfix) with ESMTPS id C23DC7F829; Tue, 11 Feb 2014 15:14:37 +0000 (UTC)
Message-ID: <>
Date: Tue, 11 Feb 2014 16:14:27 +0100
From: Alexander Holler <>
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 <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Cc: XMPP Working Group <>, Ben Campbell <>
Subject: Re: [xmpp] IQ Handling vulnerabilities
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Feb 2014 15:15:06 -0000

Am 11.02.2014 13:29, schrieb Dave Cridland:
> On Tue, Feb 11, 2014 at 12:23 PM, Alexander Holler <>wrote;wrote:
>> Hmm, in all these mails it was never be mentioned that IDs still have to
>> be unique over some time for one session. I'm not sure if such is given
>> with the above constructs. It might be very unlikely that the same ID will
>> appear twice, but someone has to take a deeper look at it when using such
>> constructs like above. Of course, in reality the window in time IDs must be
>> unique is rather small, but ...
> You'd need random collisions amongst cryptographically secure hashes.
> You're pretty safe.

I don't aggree. You are safe if you use the hash as intendend, but not
if you just use some part of the hash(-number) or hashes of hashes. I'm
not sure about how safe it is (in regard to collisions) if you look at
consequent hashes of hashes. I would assume that is not what
cryptographers do look for (primarily).

At least I can't remember to have seen some discussion if the series of
hash(hash(hash(...))) is collision free (that is imho quiet different
than hash(random); hash(random)). Of course, I'm not looking that often
at cryptographic papers, I usually prefer if cryptographers do such. ;)

> In practise, ids do not have to be unique anyway, even over a small window.
> Most MUC implementations preserve ids on broadcast, for instance, to no
> ill-effect.

How do you track responses if you don't have unique IDs? Unique IDs
might not be necessary for everything, but usually you are unable to
match a response to a request without having unique IDs in consequent
requests (of the same session).


Alexander Holler