Re: [Standards] NEW: XEP-0359 (Unique and Stable Stanza IDs)
On 15 July 2015 at 16:12, Florian Schmaus wrote: > On 15.07.2015 10:12, Dave Cridland wrote: > > Can we add something into the security considerations for this document > > which discusses the exposure of the jid in "by", please? > > I had the same though, but then discarded adding such a consideration > because the only JIDs worth protecting are the ones of clients. And > those don't have a need to set the 'by' value. > > If you considered it, then it's a security consideration. ;-) More seriously, it exposes non-terminal jids in a manner that may or may not leak something to an attacker - it may not ever leak anything useful in the ways you've considered using it, but a protocol requiring id stamping of some intermediary that's otherwise not exposed could be problematic. > But, adding an explicit statement about (client) JID leaks can't hurt. > Noted for the next version bump of XEP-SID. > > - Florian > >
Re: [Standards] XEP-0359 (Unique and Stable Stanza IDs)
On 15.07.2015 14:27, Mickaël Rémond wrote: > I read the Unique and Stable Stanza Ids and what I miss is some > perspective on recommanded use case / implementation. XEP-SID is meant as building block for other XEPs. It's a re-useable extension for other extensions that need unique and stable message IDs, like MAM. > As a server developer, we indeed need Stanza ID in many contexts (Like > for example to undupe resend of messages that were not acked). You can solve *that* particular use case with conventional stanza IDs already. XEP-SID IDs primary focus is to identify a stanza over a infinite period of time. > However, what is a standard XMPP server expected to do with that XEP ? With the XEP alone: Nothing, besides obeying the business rules. Which basically comes down to: Don't strip XEP-SID's extension elements from stanzas. > Should it force stanza ID on every messages ? No > How does it interact with s2s ? I no way. > Should we discover support by other > server and remove the stanza on outgoing s2s packet when it is not > supported ? No - Florian signature.asc Description: OpenPGP digital signature
[Standards] Fwd: [Council] Minutes 2015-07-15
FYI > Begin forwarded message: > > From: Kevin Smith > Subject: [Council] Minutes 2015-07-15 > Date: 15 July 2015 16:15:37 BST > To: XMPP Council > Logs: http://logs.xmpp.org/council/2015-07-15/ > > 1) Roll call > Kev, Fippo, Dave, Lance, Matt present > > 2) http://xmpp.org/extensions/inbox/optimized-s2s.html > Accept as Experimental? > > All in favour. > > 3) Date of next meeting > > 2015-07-22 15:00Z > > 4) Any other business > > None. > > Fini
Re: [Standards] NEW: XEP-0359 (Unique and Stable Stanza IDs)
On 15.07.2015 10:12, Dave Cridland wrote: > Can we add something into the security considerations for this document > which discusses the exposure of the jid in "by", please? I had the same though, but then discarded adding such a consideration because the only JIDs worth protecting are the ones of clients. And those don't have a need to set the 'by' value. But, adding an explicit statement about (client) JID leaks can't hurt. Noted for the next version bump of XEP-SID. - Florian signature.asc Description: OpenPGP digital signature
Re: [Standards] NEW: XEP-0359 (Unique and Stable Stanza IDs)
On 15.07.2015 00:31, Lance Stout wrote: >> - Why put the client-id in the stanza-id ? > > It has been suggested (but not yet incorporated into 359) that client-id be > replaced by the simple lack of a 'by' attribute. (If no 'by' is present, the > entity that stamped the ID is the stanza sender, pending the support checks > that should be added in the security considerations that I mentioned on list > earlier.) I don't like the idea of having a special case where 'by' is omitted. Instead I consider transforming the 'client-id' from an attribute to an element. This makes the verification rules for the 'stanza-id' element simpler (e.g. only valid if id *and* by is set), while keeping the client-id feature. - Florian signature.asc Description: OpenPGP digital signature
Re: [Standards] XEP-0359 (Unique and Stable Stanza IDs)
Hello, (Sorry for the mistype on previous mail that send it prematurely) I read the Unique and Stable Stanza Ids and what I miss is some perspective on recommanded use case / implementation. As a server developer, we indeed need Stanza ID in many contexts (Like for example to undupe resend of messages that were not acked). However, what is a standard XMPP server expected to do with that XEP ? Should it force stanza ID on every messages ? How does it interact with s2s ? Should we discover support by other server and remove the stanza on outgoing s2s packet when it is not supported ? Should this only be implemented in component that need it (for example MUC) ? I think any clarification on the use case that the XEP covers would be welcome. Thanks ! -- Mickaël Rémond http://www.process-one.net On 14 Jul 2015, at 18:37, XMPP Extensions Editor wrote: Version 0.1 of XEP-0359 (Unique and Stable Stanza IDs) has been released. Abstract: This specification describes unique and stable IDs for stanzas.
Re: [Standards] XEP-0359 (Unique and Stable Stanza IDs)
Hello, I read the Unique and Stable Stanza I On 14 Jul 2015, at 18:37, XMPP Extensions Editor wrote: > Version 0.1 of XEP-0359 (Unique and Stable Stanza IDs) has been released. > > Abstract: This specification describes unique and stable IDs for stanzas.
Re: [Standards] NEW: XEP-0359 (Unique and Stable Stanza IDs)
Can we add something into the security considerations for this document which discusses the exposure of the jid in "by", please? Dave.
