[Standards-JIG] UPDATED: JEP-0027 (Current Jabber OpenPGP Usa ge)
justin-keyword-jabber.093179 at affinix.com
Wed Mar 17 00:32:47 UTC 2004
On Tuesday 16 March 2004 2:56 pm, Ian Paterson wrote:
> > This would appear to be a problem in my current spec if you
> > logout and login
> > from even the same client/resource within the timeframe. The
> > client would
> > need to cache all the jid/id/timestamp mappings to disk.
> > New question: what if the client or client machine crashes and is
> > unable to
> > record a proper logout time?
> Same answer. Save all received message IDs to disk locally. A garbage
> collector deletes them as they become ten minutes old.
Ah hah, yes.
> Hmmm. Lots of replay problems. Time to take a step back and brainstorm...
> What about if we forget offline messages for a moment...
> If we specify that, where possible, messages should be sent to a specific
> online resource. Then the client could simply choose a large random
> resource suffix at login (e.g. WORK_4hf74judju - most people use the
> default resource anyway).
This won't work if the recipient's full JID doesn't include a resource, such
as a non-client entity. Less obtrusive might be to include such a session ID
in the presence packet, but then this requires presence to be delivered. (Of
course, these problems fall under the "offline message" case which you say we
should forget for a moment).
> For offline messages (those sent to no resource or to a different
> resource), the client could simply warn the user what time the message was
> sent and that it may be a replay.
Unfortunately this is just not acceptable (not if we can solve it, I mean).
It seems the main problem remaining is the resource issue, and the problem
comes from the sender using either no resource or the wrong resource. If we
accept such packets, then we are vulnerable to replay. If we don't accept
such packets, then we lose out on the server's ability to redirect messages
to different resources. On top of this, restricting messages to be addressed
to full JIDs means essentially losing offline message support, as the sender
won't know which resources he can send to.
I'm very tempted to just ignore the replay problem and leave that issue up to
something like JEP-0116, but maybe we can solve this. I think we're going to
need some careful and protected interaction between all the resources via the
server, in such a way that a server DoS would not enable an attack. This
does sound quite impossible, but I'll think about it and reply...
More information about the Standards