Re: IQ Handling vulnerabilities

On Fri, Feb 7, 2014 at 10:57 AM, Kevin Smith <[email protected]> wrote:
> On Fri, Feb 7, 2014 at 3:50 PM, Dave Cridland <[email protected]> wrote:
>> On Fri, Feb 7, 2014 at 3:10 PM, Joe Hildebrand (jhildebr)
>> <[email protected]> wrote:
>>>
>>> On 2/7/14 2:46 AM, "Thijs Alkemade" <[email protected]> wrote:
>>>
>>> >The property we really want from ids is that predicting the next one(s)
>>> >given
>>> >some historic ones is hard.
>>>
>>> (as individual)
>>>
>>> I agree with everything you said to this point.  However, I think we need
>>> to strengthen this a little: we want to ensure predicting the next one(s)
>>> in *any* way is hard.
>>>
>>> Luckily using the from address also mitigates this need slightly for some
>>> of the use cases.
>>
>>
>> What are the attacks possible against an entity using predictable stanza
>> ids, but which otherwise acts properly (ie, checks to/from on responses,
>> etc)?
>>
>> I'm a bit confused - if an entity isn't checking the to/from of the
>> responses, then sure there's a slew of attacks possible. If it *also* has
>> predictable ids, then the attacks are easier - but they're the same attacks.
>> Aren't they?
>
> Yes and no. By far the biggest issue here is the stanza-faking one,
> and predictable ids are a part of what's needed to make the simplest
> attack, but aren't actually the broken bit.
>
> There are various unlikely (and arguably unimportant, I suppose)
> issues around being able to observe where in a stream a client is. As
> an incredibly contrived example, client A shows client B an id that
> means "You are the first person I'm sending a message to this session"
> and user A says to user B "I'm busy chatting to C in another window".
>

I'll note that cryptographically secure randomness comes with a cost.
With many operating systems (e.g., Linux) generating tons of truly
random IDs (/dev/random) will lead to a system constantly starved for
entropy (and no, /dev/urandom is not cryptographically secure in
Linux). If crypto-level randomness is not required, then your IDs are
predictable. It's harder than incrementing counters, but not by much.

If the problem here is that something simple like incrementing IDs
leak state across remote JIDs, then a simple solution is to use a
separate incrementing counter for separate remote JIDs. A CSPRNG is
unnecessary and expensive.

--
Waqas Hussain