-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/24/09 2:01 PM, Peter Saint-Andre wrote: > On 8/13/09 3:19 AM, Sergei Golovan wrote: >> On Thu, Aug 13, 2009 at 1:51 AM, Peter Saint-Andre<[email protected]> 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. > > Agreed. > >> 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 >> history. > > 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 > through untouched.
The XMPP Council discussed this issue in its meeting last week: http://logs.jabber.org/[email protected]/2009-09-02.html#14:05:29 http://logs.jabber.org/[email protected]/2009-09-02.html#14:08:38 I suggest that we add the following text to the Security Considerations of XEP-0203: *** Absent cryptographic signing of stanzas and parts of stanzas, it is possible for delayed delivery notations to be forged. For example, the originator of a message (or the originator's server) could include a notation that makes it appear as if delivery of the message was delayed by the recipient's server. The same is true of delayed delivery notations putatively added by a Multi-User Chat room, which could be forged by the message originator, the originator's server, the recipient's server, or the server that hosts the chatroom service. Although the recipient's server SHOULD discard a delayed delivery notation whose 'from' attribute matches the server's JabberID (or return a <not-acceptable/> error to the originator), this policy does not guard against forging of notations putatively from other entities (such as a chatroom hosted at a different trust domain). Therefore, a recipient SHOULD NOT rely on delayed delivery notations to provide a completely accurate representation of the delivery path or timing of a stanza it has received. *** Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqn9cgACgkQNL8k5A2w/vyklACaA5ucb1tyUWv+fm/GSuCcsFCF n/8An30Ky/REdcrDQzJGmiP1C8v3mmce =HJeW -----END PGP SIGNATURE-----
