Re: [xmpp] IQ Handling vulnerabilities

Thijs Alkemade <> Fri, 07 February 2014 10:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 48F111A020B for <>; Fri, 7 Feb 2014 02:47:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.44
X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.535] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dw3qGZs5AvW0 for <>; Fri, 7 Feb 2014 02:47:07 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6968A1A0033 for <>; Fri, 7 Feb 2014 02:47:07 -0800 (PST)
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 6D78E20AE8; Fri, 7 Feb 2014 11:46:57 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1391770017; bh=xGShtPzAHB15O3jTybPxwGA9J2HhYF8gVPay1THR6iY=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=j9+aPmQJUd3IGNYhC9tTTkq2cJSfoQQV3zCNl02r0NX0MwAEDI1As75i618xb4fiC PEsejTyB5ZK92TJHqEL1T+H41CkaWG7KfxDLz71MoKhZ8h5fR0yp/xgt6+fyXGaY+K 3/4xVQcP0qgSwmpq4j9n2byYyewvIXk168M9ffZ4=
Content-Type: multipart/signed; boundary="Apple-Mail=_5745AD70-9C7B-4CCE-9539-679BED716C1B"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Thijs Alkemade <>
In-Reply-To: <>
Date: Fri, 7 Feb 2014 11:46:55 +0100
Message-Id: <>
References: <> <> <>
To: Ben Campbell <>
X-Mailer: Apple Mail (2.1827)
Cc: XMPP Working Group <>
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: Fri, 07 Feb 2014 10:47:09 -0000

On 6 feb. 2014, at 23:30, Peter Saint-Andre <> wrote:

>>> b) Use predictably generated ids for stanzas (ill-advised, but not
>>> strictly wrong)
>> We need to fix the advice given in
> Yes, that too - probably we'd want to say that 'id' values ought to be random (e.g., UUIDs).

Well, actually...

The property we really want from ids is that predicting the next one(s) given
some historic ones is hard. That is not a guarantee UUIDs give by definition.
The time based UUIDs (version 1) obviously don't have this property, but also
randomly generated UUIDs (version 4) may be generated with any PRNG, even
linear congruential ones. In fact, the Security Considerations of RFC 4122
cover this:

   Do not assume that UUIDs are hard to guess; they should not be used
   as security capabilities (identifiers whose mere possession grants
   access), for example.  A predictable random number source will
   exacerbate the situation.

I'm afraid that suggesting to use UUIDs will cause people to still not check
the 'from' attribute, but to assume their UUIDs are impossible to predict by
others. I think it would be better advise to grab 8 or 16 bytes from a CSPRNG
and hex-encode/base64-encode/SHA1-hash that.

> Who's volunteering to write this up? Maybe Thijs?

Yes, I would be willing to do this.