Subject: [xmpp] IQ Handling vulnerabilities

From: Kevin Smith <[email-masked]>
Date: Thu, 6 Feb 2014 11:26:30 +0000

Hi folks,
  Discussion in the XSF and at the recent XMPP Summit has shown that
there are widespread issues with handling of iq responses in XMPP
software. This is probably something we need to consider handling.

The basis of this is that many libraries/clients
a) Only check the id of an iq error/result, not the sender, to check
it matches one they've sent (Very Wrong)
b) Use predictably generated ids for stanzas (ill-advised, but not
strictly wrong)
c) Use known resource strings (bad, but not strictly wrong)

In conjunction, this leads to various obvious attacks with differing
levels of severity, but for the sake of enumerating some, with some
good fortune with timing against a vulnerable client you can: Fake
contacts', or even their own, vcards; fake their roster so they think
people have 'unfriended' them, or that they have already added someone
unknown; deny capabilities discovery; make them think their server
doesn't have a MUC service; and the list goes on and on.

We certainly need to call this out explicitly in 3920ter, We might
want to publish something in the interim.

/K

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 6 Feb 2014 21:58:45 +0000

(as individual)

I think this is a very important issue.  I'm worried about the security
impact, and I think we need to give good guidance.

(as co-chair)

Who else thinks we need to work on this?

Can we start with an individual I-D that lays out the problem and
solution?  That would allow us to make good decisions about what the next
step would be.  Kev, that might be pretty quick for you to write...

On 2/6/14 3:26 AM, "Kevin Smith" <[email-masked]> wrote:

>_______________________________________________
>xmpp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/xmpp
>

-- 
Joe Hildebrand

---

From: Philipp Hancke <[email-masked]>
Date: Thu, 06 Feb 2014 23:06:54 +0100

> software. This is probably something we need to consider handling.

This is something the WG should do.

> it matches one they've sent (Very Wrong)

Well, http://xmpp.org/rfcs/rfc6120.html#stanzas-semantics-iq says
	the interaction is tracked by the requesting entity through use
	of the 'id' attribute.
That's easy to to get wrong :-/

> b) Use predictably generated ids for stanzas (ill-advised, but not

We need to fix the advice given in
http://xmpp.org/rfcs/rfc6120.html#stanzas-attributes-id

---

From: Matt Miller <[email-masked]>
Date: Thu, 6 Feb 2014 15:14:22 -0700

On 2/6/14, 2:58 PM, Joe Hildebrand (jhildebr) wrote:
> (as individual)
> 
> I think this is a very important issue.  I'm worried about the
> security impact, and I think we need to give good guidance.
> 
> (as co-chair)
> 
> solution?  That would allow us to make good decisions about what
> the next step would be.  Kev, that might be pretty quick for you to
> write...
> 
> 
> 
>> Hi folks, Discussion in the XSF and at the recent XMPP Summit has
>> shown that there are widespread issues with handling of iq
>> responses in XMPP software. This is probably something we need to
>> consider handling.
>> 
>> The basis of this is that many libraries/clients a) Only check
>> the id of an iq error/result, not the sender, to check it matches
>> one they've sent (Very Wrong) b) Use predictably generated ids
>> for stanzas (ill-advised, but not strictly wrong) c) Use known
>> resource strings (bad, but not strictly wrong)
>> 
>> In conjunction, this leads to various obvious attacks with
>> differing levels of severity, but for the sake of enumerating
>> some, with some good fortune with timing against a vulnerable
>> client you can: Fake contacts', or even their own, vcards; fake
>> their roster so they think people have 'unfriended' them, or that
>> they have already added someone unknown; deny capabilities
>> discovery; make them think their server doesn't have a MUC
>> service; and the list goes on and on.
>> 
>> We certainly need to call this out explicitly in 3920ter, We
>> might want to publish something in the interim.
>> 
>> /K _______________________________________________ xmpp mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/xmpp
>> 
> 
> 

I agree this is an important issue that needs to be addressed.  I
think someone submitting an I-D is a fine starting point.

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 06 Feb 2014 15:30:22 -0700

> This is something the WG should do.

Agreed.

> That's easy to to get wrong :-/

I'd say that the text there is descriptive, not prescriptive. The new 
I-D (to update 6120 and then be incorporated into 6120bis) would define 
acceptable behavior from a security point of view.

> http://xmpp.org/rfcs/rfc6120.html#stanzas-attributes-id

Yes, that too - probably we'd want to say that 'id' values ought to be 
random (e.g., UUIDs).

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

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ben Campbell <[email-masked]>
Date: Thu, 6 Feb 2014 17:22:09 -0600

> step would be.  Kev, that might be pretty quick for you to write...

(As the other co-chair)

I think an individual I-D is the right way to go here, even if it just lays out the problem. (But solutions are also good!)

Thanks!

Ben.

---

From: Thijs Alkemade <[email-masked]>
Date: Fri, 7 Feb 2014 11:46:55 +0100

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

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

Thijs

---

From: Alexander Holler <[email-masked]>
Date: Fri, 07 Feb 2014 12:23:24 +0100

> c) Use known resource strings (bad, but not strictly wrong)

Just to make it clear, the real problem here is neither the IDs nor the 
resources, but not checking the sender of the reply.

If the sender would be checked, random IDs would only protect against 
sniffing/injecting packets into a stream or against malicious servers. 
The first (sniffing/injecting) is already protected by using encryption 
and the second (malicious servers) doesn't make much sense at all, 
because a client has to trust it's server.

One of the reasons why clients don't check the sender part seems to be 
that it wasn't clear what the sender of a reply is, if the IQ query was 
without an explicit 'to' attribute.

A simple rule for clients could be to check that the JID of IQ replies 
where the origin should be the connected server is either the JID of the 
server (no node, no resource) or the received bare JID (stripping a 
possible resource) is the bare JID of the client.

Regards,

Alexander Holler

---

From: Kevin Smith <[email-masked]>
Date: Fri, 7 Feb 2014 12:21:09 +0000

> resources, but not checking the sender of the reply.

There are three issues here. They have different severities, as I
noted initially, and not checking the sender of a reply is the one
that is completely and fundamentally broken. That doesn't preclude
that the other two are also issues (which we may or may not decide
need addressing right now - although I'm of the opinion that while
writing a document explaining the issues, explaining all three would
be worthwhile).  The most egregious of the vulnerabilities involve
having all three present.

We've known the from checking to be an issue for at least three years
(that's the first record I could easily find of discussing the
problem), but how widespread that problem is is news. Using
predictable ids and resources is well known.

(There's an additional point to be made about checking the from of
roster pushes, although I believe this to be a less widespread
problem)

> One of the reasons why clients don't check the sender part seems to be that
> it wasn't clear what the sender of a reply is, if the IQ query was without
> an explicit 'to' attribute.

I'd assert that the correct handling is clear, just that it seems to
go unnoticed for some reason - but why we're in the state of needing
to say something about this seems less important than what we now say.

> A simple rule for clients could be to check that the JID of IQ replies where
> the origin should be the connected server is either the JID of the server
> (no node, no resource) or the received bare JID (stripping a possible
> resource) is the bare JID of the client.

The rules here are clear. If a client sends a stanza without a 'to',
the server is to handle it as if it was sent to the bare JID of the
client's session. The server replying with the server JID is a bug.

/K

---

From: Kevin Smith <[email-masked]>
Date: Fri, 7 Feb 2014 12:22:32 +0000

> step would be.  Kev, that might be pretty quick for you to write...

I'm happy to do it, or happy for Thijs to. Will discuss out of band.

/K

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Fri, 7 Feb 2014 15:10:58 +0000

On 2/7/14 2:46 AM, "Thijs Alkemade" <[email-masked]> wrote:

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

-- 
Joe Hildebrand

---

From: Dave Cridland <[email-masked]>
Date: Fri, 7 Feb 2014 15:50:51 +0000

> Luckily using the from address also mitigates this need slightly for some

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?

I'm not saying that we shouldn't generally recommend unpredictable ids - it
seems relatively simple and causes little harm - but cryptographically
secure ones seems overkill, and I'm always nervous of imposing unneeded
drains on the entropy store of a system.

Also, I've mentioned this elsewhere, but I'll mention it here too: much of
the XMPP community seems focussed on clients exhibiting this class of bug,
and attacks against those clients. I strongly suspect that not all servers
are immune to this, and the attacks on servers are likely to be just as
fascinating.

Dave.

---

From: Kevin Smith <[email-masked]>
Date: Fri, 7 Feb 2014 15:57:24 +0000

On Fri, Feb 7, 2014 at 3:50 PM, Dave Cridland <[email-masked]> wrote:
> On Fri, Feb 7, 2014 at 3:10 PM, Joe Hildebrand (jhildebr)
> 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".

> are immune to this, and the attacks on servers are likely to be just as

Yes, it's clear that the document needs to cover this.

/K

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Fri, 7 Feb 2014 16:13:16 +0000

I have a couple of ludicrous s2s attacks on mind, but more important I think is doing what

Mobile/terse. DYAC.

On Feb 7, 2014, at 7:50 AM, "Dave Cridland" <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Feb 7, 2014 at 3:10 PM, Joe Hildebrand (jhildebr) <[email-masked]<mailto:[email-masked]>> wrote:

(as individual)

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?

I'm not saying that we shouldn't generally recommend unpredictable ids - it seems relatively simple and causes little harm - but cryptographically secure ones seems overkill, and I'm always nervous of imposing unneeded drains on the entropy store of a system.

Also, I've mentioned this elsewhere, but I'll mention it here too: much of the XMPP community seems focussed on clients exhibiting this class of bug, and attacks against those clients. I strongly suspect that not all servers are immune to this, and the attacks on servers are likely to be just as fascinating.

Dave.

---

From: Waqas Hussain <[email-masked]>
Date: Fri, 7 Feb 2014 11:39:55 -0500

> 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

---

From: Alexander Holler <[email-masked]>
Date: Sat, 08 Feb 2014 13:06:28 +0100

> client's session. The server replying with the server JID is a bug.

The rules are only clear for the current RFC 6120, but not for that 
obsolet RFC 3120, which I assume was the base for most available 
XMPP-servers (and many clients).

Regards,

Alexander Holler

---

From: Alexander Holler <[email-masked]>
Date: Sat, 08 Feb 2014 13:17:15 +0100

> and user A says to user B "I'm busy chatting to C in another window".

I would call that information leaks but not vulnerabilities. So 
predictable IDs and resource names might lead to some information leaks, 
but not checking the from is a vulnerability.

Regards,

Alexader Holler

---

From: Ben Campbell <[email-masked]>
Date: Sat, 8 Feb 2014 13:38:56 -0600

(As Chair)

Just a reminder that the draft deadline for IETF 89 is Feb 14. That's coming up soon.

The absence of a draft would not prevent us from discussing this issue at the meeting, but the presence of a draft would help :-)

Thanks!

Ben.

---

From: Thijs Alkemade <[email-masked]>
Date: Sun, 9 Feb 2014 15:13:34 +0100

> 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…

The least far-fetched scenario I can think of: you're offering a file transfer
to someone's MUC room nick. The person disconnects, someone else takes their
nick and intercepts the file transfer by guessing the 'id' that was used. This
is also a scenario where a per-address counter will not protect you. (Though a
better fix is probably to cancel all pending queries to participants when you
see them disappear from the room...)

> Also, I've mentioned this elsewhere, but I'll mention it here too: much of the XMPP community seems focussed on clients exhibiting this class of bug, and attacks against those clients. I strongly s…

I'm trying to think of a situation where the server sends a iq 'get' to the
client, but I don't really know any. A lot of iq 'set's, where the server
informs the client of something (and probably doesn't really care whether that
results in an 'error' or 'result'), but nothing where the server wants to know
something from the client. Could you give an example?

Thijs

---

From: Waqas Hussain <[email-masked]>
Date: Sun, 9 Feb 2014 10:01:12 -0500

> something from the client. Could you give an example?

disco#info requests for PEP, though in this case Prosody happily uses
a single constant id for all requests, only using the sender's JID and
subscription status.
MUC is another when it proxies IQ requests (vCards, private IQs), and
for vCards Prosody encodes a bunch of information in the id for
verification.

A quick search through prosody-modules found implementations of
XEP-0309: Service Directories and XEP-268: Incidents Handling
listening for IQ results.

--
Waqas Hussain

---

From: Kevin Smith <[email-masked]>
Date: Sun, 9 Feb 2014 16:56:25 +0000

> something from the client. Could you give an example?

There's a fun one where the server sends a ping to the client to check
for inactivity. If another client can keep a dead session alive,
that's quite interesting.

/K

---

From: Dave Cridland <[email-masked]>
Date: Sun, 9 Feb 2014 19:30:57 +0000

> see them disappear from the room...)
Ah! Nice one.

FWIW, it's possible to hide a offline/online event by DOSsing the original
server then spoofing it, which is hard work but practical given DNS spoofed
dialback.

Also, there's a bunch of MUC-replacement attacks, I suspect, that don't
involve having to predict a stanza id.

> > I'm not saying that we shouldn't generally recommend unpredictable ids -
> it seems relatively simple and causes little harm - but cryptographically
> > Also, I've mentioned this elsewhere, but I'll mention it here too: much
> of the XMPP community seems focussed on clients exhibiting this class of
> bug, and attacks against those clients. I strongly suspect that not all
> servers are immune to this, and the attacks on servers are likely to be
> just as fascinating.
>
As Waqas says, there's a bunch of cases. It gets worse if the server is
running optimization-related intercepts, such as disco caching, I suspect.
I think there are interesting cases around an XMPP-level file-transfer
proxy (for anti-virus, or SI/Jingle translation) for example.

I'd hope Kev's example is way off, though - I suspect that servers ignore
the XEP-0199 reply stanza and just look for activity on the socket.

Dave.

---

From: Kevin Smith <[email-masked]>
Date: Sun, 9 Feb 2014 22:04:37 +0000

> the XEP-0199 reply stanza and just look for activity on the socket.

I would hope so, too - but given some of the things we've seen on the
client side in the last couple of weeks, I don't think it's
unreasonable to suspect there might be servers with as severe
problems. Whether we can find the vulnerabilities or not, though,
doesn't reduce the need to document the issues, I think.

/K

---

From: Thijs Alkemade <[email-masked]>
Date: Mon, 10 Feb 2014 13:12:27 +0100

> doesn't reduce the need to document the issues, I think.

I’ve submitted an I-D about this issue here, to help discussion at IETF 89:

http://datatracker.ietf.org/doc/draft-alkemade-xmpp-iq-validation/

Regards,
Thijs

---

From: Ashley Ward <[email-masked]>
Date: Mon, 10 Feb 2014 13:05:26 +0000

> http://datatracker.ietf.org/doc/draft-alkemade-xmpp-iq-validation/

Just wondering if it's possible to use a stronger section title than “Recommendations”, or is that standard IETF I-D heading wording?

—
Ash

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Feb 2014 09:38:23 -0700

> Just wondering if it's possible to use a stronger section title than “Recommendations”, or is that standard IETF I-D heading wording?

We can call it whatever we want. :-)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Feb 2014 09:40:29 -0700

> http://datatracker.ietf.org/doc/draft-alkemade-xmpp-iq-validation/

Hi Thijs,

The document looks good to me. I'll review it in more detail after I 
submit the ~10 I-Ds I need to update this week. :-)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave Cridland <[email-masked]>
Date: Mon, 10 Feb 2014 16:44:01 +0000

> submit the ~10 I-Ds I need to update this week. :-)
That's just showing off. ;-)

---

From: Ashley Ward <[email-masked]>
Date: Mon, 10 Feb 2014 16:48:05 +0000

> We can call it whatever we want. :-)

Cool. The only thing I was thinking is that “Recommendation” already has a meaning in this context, but there’s actually some important MUSTs in there.

Saying that I can’t think of a good alternative title though!

—
Ash

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Feb 2014 09:58:14 -0700

On 2/10/14, 9:44 AM, Dave Cridland wrote:
> On Mon, Feb 10, 2014 at 4:40 PM, Peter Saint-Andre <[email-masked]
> <mailto:[email-masked]>> wrote:
>

That's just letting you know that my response times might be slow this 
week. :-)

Peter

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 10 Feb 2014 17:15:20 +0000

>I have a couple of ludicrous s2s attacks on mind, but more important I

Yes, well that was even more terse than normal.  I was going to say
something about generating less-guessable IDs that don't eat up much
entropy.  For example:

start = sha1(crytpo_rand())
start+1 = sha1(start)

would probably do nicely.

-- 
Joe Hildebrand

---

From: Thijs Alkemade <[email-masked]>
Date: Mon, 10 Feb 2014 20:25:36 +0100

> would probably do nicely.

Uhm. Maybe this email is missing a line again, but if you use those values as
'id's directly, they will not be unpredictable at all, as anyone who receives
an <iq/> can generate the rest of the chain.

However, if you make sure the 'id' values are only half the hashes, it should
be unpredictable unless an attacker is willing to spend an insane amount of
work.

So:

...

id1 = start[0:10]
id2 = start+1[0:10]
…

Thijs

---

From: Thijs Alkemade <[email-masked]>
Date: Mon, 10 Feb 2014 20:25:36 +0100

So:

id1 = start[0:10]
id2 = start+1[0:10]
…

Thijs

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 10 Feb 2014 19:33:31 +0000

>start = sha1(crytpo_rand())

Or add a nonce to each round:

nonce = crytpo_rand()
start = sha1(nonce + crytpo_rand())
start+1 = sha1(nonce + start)

Regardless, there exist solutions.

-- 
Joe Hildebrand

---

From: Dave Cridland <[email-masked]>
Date: Mon, 10 Feb 2014 20:22:22 +0000

> Regardless, there exist solutions.

At the risk of diving into what's quite clearly a bit of a bikeshed at this
point...

I wondered whether there's value in going a step further. What if an entity
constructed ids based on a random per-session key, the original "to" value,
and a suitable salt (which itself need not be cryptographically random),
such that the id was the salt followed by a (truncated, probably) HMAC
result as follows:

id = salt + hmac(salt + to, session-key)[0:10]

That way, on receipt of such an id in an iq response or error, the sender
could validate the id somewhat securely?

I suspect a single session-key is a little simplistic; but that's easy to
adapt.

The advantage here isn't really in the <iq/> case we've been mostly
discussing, but the other cases of a returned id - since we don't want to
track outbound directed presence, or message, ids for an arbitrary length
of time. (I assume).

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 10 Feb 2014 20:56:28 +0000

> track outbound directed presence, or message, ids for an arbitrary length
Just to summarize a chat I had with Joe on this; neither of us can
immediately think of any attack based on bounced presence or message, but
no doubt Thijs will ruin my complacency. There's no need, even if such an
attack exists, to actually mandate a particular format or generation
strategy, of course - there's no interop need here - but a recommendation
along the lines of XEP-0185 might be useful.

Dave.

---

From: Alexander Holler <[email-masked]>
Date: Tue, 11 Feb 2014 13:23:55 +0100

> start = sha1(crytpo_rand())

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

Regards,

Alexander Holler

---

From: Dave Cridland <[email-masked]>
Date: Tue, 11 Feb 2014 12:29:42 +0000

On Tue, Feb 11, 2014 at 12:23 PM, Alexander Holler <[email-masked]>wrote:

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

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.

Dave.

---

From: Alexander Holler <[email-masked]>
Date: Tue, 11 Feb 2014 16:14:27 +0100

> You'd need random collisions amongst cryptographically secure hashes.

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. ;)

> Most MUC implementations preserve ids on broadcast, for instance, to no

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

Regards,

Alexander Holler

---

From: Thijs Alkemade <[email-masked]>
Date: Tue, 11 Feb 2014 16:33:26 +0100

> at cryptographic papers, I usually prefer if cryptographers do such. ;)

You're not going to stumble upon a SHA-1 collision by accident. Even if you do
"hashes of hashes". The esitmated cost of an intentional SHA-1 collision is
still at least $1M:
https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html

If you do happen to find one, congratulations, you are now famous. Nobody has
published a SHA-1 collision yet.

Collisions in 'id's is also not very relevant. In any XMPP client, there will
be a finite list of 'id's for which it still expects a reply (outstanding
queries, unacked messages). Checking against each of those is trivial.

Thijs

---

From: Alexander Holler <[email-masked]>
Date: Tue, 11 Feb 2014 17:17:06 +0100

> published a SHA-1 collision yet.

Sorry, but you haven't understood what I've written.

Alexander Holler

---

From: Alexander Holler <[email-masked]>
Date: Tue, 11 Feb 2014 17:31:28 +0100

> Sorry, but you haven't understood what I've written.

Just to be a bit more verbose, e.g. your proposal was to use

id1 = start[0:10]
id2 = start+1[0:10]

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?

Alexander Holler

---

From: Dave Cridland <[email-masked]>
Date: Tue, 11 Feb 2014 17:06:47 +0000

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

Dave.

---

From: Alexander Holler <[email-masked]>
Date: Tue, 11 Feb 2014 18:28:21 +0100

> 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

---

From: Alexander Holler <[email-masked]>
Date: Tue, 11 Feb 2014 18:59:06 +0100

> having a deeper look at it.

To play with that hash of hash, is it possible that the hash of a hash 
is the hash itself? If that ever happens your system will have a 
problem, so how likely is that? And in the proposed solution it's a bit 
more difficult, because only the higher 5 bytes of the 20 bytes long 
hash are used. At least for me, the answer to that isn't obvious.

Regards,

Alexander Holler

---

From: Alexander Holler <[email-masked]>
Date: Tue, 11 Feb 2014 19:48:22 +0100

> hash are used. At least for me, the answer to that isn't obvious.

To become completely offtopic, one could formalize that question to how 
the possibility is that

sha1^n(x) = sha1(x) for 2 < n <= 100

(if you need that 100  IDs in series are unique) and furthermore you 
have to look at the upper 5 bytes. I'm not sure if that is what 
cryptographers usually do look at if they check hash algorithms. So 
argueing with whatever they found out about sha1 doesn't look obvious to me.

Regards,

Alexander Holler

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Fri, 14 Feb 2014 05:27:30 +0000

(as chair)
Yes, let's call that off-topic.

(as individual)
I don't believe we have to specify an algorithm, since there are no
interoperability consequences.

-- 
Joe Hildebrand