[Standards] LAST CALL: XEP-0359 (Unique and Stable Stanza IDs)
holger at zedat.fu-berlin.de
Wed Nov 14 12:16:03 UTC 2018
* Georg Lukas <georg at op-co.de> [2018-11-14 12:47]:
> * Holger Weiß <holger at zedat.fu-berlin.de> [2018-11-14 10:41]:
> > * Georg Lukas <georg at op-co.de> [2018-11-13 18:29]:
> > > §3 point 2 should probably be changed from
> > >
> > > | Stanza ID generating entities, which encounter a <stanza-id/> element
> > > | where the 'by' attribute matches the 'by' attribute they would otherwise
> > > | set, MUST delete that element even if they are not adding their own
> > > | stanza ID.
> > >
> > > to
> > >
> > > | Entities which receive a stanza with a <stanza-id/> element
> > > | where the 'by' attribute matches the entiy's own JID, MUST delete that
> > > | element even if they are not adding their own stanza ID.
> > I guess the former wording was chosen deliberately to avoid the
> > ambiguity about who exactly the "entities wich receive a stanza" might
> > be. §3, point 7 says: "For one-on-one messages the assigning entity is
> > the account. In groupchats the assigning entity is the room." With
> > your wording, readers might assume the entity is the server itself.
> Maybe then the wording needts to be "where the 'by' attribute matches a
> JID that the entity is responsible for"? I just want to prevent somebody
> injecting stanzas into my administrative domain with one of my JIDs.
So this isn't just about wording but about semantics? I.e., you want
the XEP to mandate the server to strip all stanza IDs with by=$JID,
where $JID is any user or server JID the server feels responsible for?
In that case we'd disagree. The XEP should only mandate stripping of
stanzas for those JIDs on which the server announces XEP-0359 support,
which is what the current wording is trying to do. Any other JIDs are
out of scope.
> On the other hand you could argue that the entity is the user's account,
> running on the server.
Yes, as I quoted above, that's what §3 point 7 argues. I just think the
term "entity" is quite ambigous and it's important to be precise in
security-relevant spec clauses such as this one.
More information about the Standards