[Standards] Call for Experience: XEP-0203 (Delayed Delivery)
stpeter at stpeter.im
Mon Aug 24 20:01:07 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
On 8/13/09 3:19 AM, Sergei Golovan wrote:
> On Thu, Aug 13, 2009 at 1:51 AM, Peter Saint-Andre<stpeter at stpeter.im> wrote:
>> 1. Who has implemented XEP-0203? Please note that the protocol must be
>> implemented in at least two separate codebases (and preferably more).
> Tkabber uses XEP-0203 timestamps as well as XEP-0091 ones (203 is preferrable).
>> 2. Have developers experienced any problems with the protocol as defined
>> in XEP-0203? If so, please describe the problems and, if possible,
>> suggested solutions.
> There is oen problem with all current methods of delayed delivery
> indication. The problem is that any entity may easily forge message
> timestamp. If I send a message with added <delay
> xmlns='urn:xmpp:delay' stamp='2002-09-10T23:08:25Z'/> then my adressee
> will believe that this is an offline message which were stored on
> server (for several years).
> I'm not sure if it's a serious issue, but surely it worth at least
> security consideration notice.
> As for the solution, I could suggest that any server which routes the
> stanza should add a delay timestamp indicating when it reseived the
> message (with some additional attribute (e.g. router='jabber.org')
> similar to Received header in email.
Couldn't the sender include such a delay timestamp and thus try to fake
out the recipient? Without signed stanzas (or even parts of stanzas,
ick!) the recipient won't know which entity included the delay data.
> Stripping any delay element from
> all stanzas isn't a solution because they are used legitimately in MUC
The router could strip any delay data that includes its own address (or
return an error to the sender), but let any other delay data pass
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the Standards