[Standards-JIG] UPDATED: JEP-0027 (Current Jabber OpenPGP Usa ge)

Ian Paterson ian.paterson at clientside.co.uk
Tue Mar 16 22:56:16 UTC 2004


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

Yes.

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

> > If the message sender does not specify a resource then the
> > message could be replayed to the second client.
> >
> > Perhaps the message IDs should be stored on the server, not
> > locally on the client.
>
> I thought of this too, but then couldn't a malicious server enable replay
> attacks by simply not providing the ID list to other resources?
> I don't see a good solution for this one...

Good point. :)

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

There would be no "replay to different clients with the same resource"
issue, no "clock synchronisation" issue, and no need to save anything to
disk. (In general, all the message IDs from the session could be stored in
memory.)

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.




More information about the Standards mailing list