Re: [Standards] MAM and Pubsub
On 3 Feb 2015 11:58, Goffi go...@goffi.org wrote: Having a node attribute is defined in 313 as specifying you want to search a pubsub archive instead of another type of archive. I don't see the confusion. It's explained in XEP-0313, but I think it's a bad idea to use common terminology to associate MAM with an other XEP, without namespace. If tomorrow a XEP uses this same terminology of node, it will starts to be confusing. No, you're not. Consider you have a node to which someone has published with the same item id repeatably, e.g. id='myitem'. MAM will allow you to recover previous versions of that particular item, whereas 60 does not. OK, but that doesn't prevent of showing pubsub namespace somewhere. Or at least something less generic than node Letting this one settle in for a bit. Delegation is a tough problem to do properly without breaking things, especially if the namespace delegated has relations to other specs. We can work around this in namespace delegation by adding an attribute check in addition to namespace check, that would be better than sending back the traffic to the server, even if it complicate the XEP. I would still be more happy with an other attribute name to link MAM and PubSub. I think this would affect disco, for example, as well? Goffi
Re: [Standards] MAM and Pubsub
On 03/02/2015 15:46, Dave Cridland wrote: We can work around this in namespace delegation by adding an attribute check in addition to namespace check, that would be better than sending back the traffic to the server, even if it complicate the XEP. I would still be more happy with an other attribute name to link MAM and PubSub. I think this would affect disco, for example, as well? Yes you're right. Delegation manage disco nesting, but if we add an attribute filter, that means that part of MAM can be managed by the server, and part of it by the managing entity. For MAM it's not really a big deal (there is only one feature: 'urn:xmpp:mam:0', so we'll add this one anyway), but if we start to filter on attributes for multi-features XEP, it will be quickly messy. I don't know if a generic attribute filtering would be really useful anyway, it's maybe better to restrict this to MAM if we go this way. An other point is that if a server announce urn:xmpp:mam:0, that means that it manages MAM for message/ *AND* PEP, right ? There is no way to advertise only message/ support or only PEP support. I really think there is something wrong here.
Re: [Standards] OTR
Hello everybody, referring to commit: https://github.com/winfried/XMPP-OTR/commit/76a5cf06a3728e042740c0e30ba535e55b2613a8 I know it's still work in progress, but I want to start from there to say my two cents. I think encrypting the whole stanza can be avoided in some cases. Also, the only stanza type that has sense to be encrypted with OTR is message/. Therefore, I'd distinguish between two specific cases: * encryption of message body: just include the encrypted message body in the otr/ element as a child of message/ * encryption of whole stanza (for other purposes or for complex messages): encrypt the whole stanza and encapsulate the OTR content in an otr/ element as a child of message/ The only problem here is how to recognise the encrypted data? Is it a text body or a stanza? Maybe we can use a type attribute to otr/, revealing more metadata? Or maybe we could add a header to the encrypted data: -8--- Content-type: text/plain message body -8--- -8--- Content-type: application/xmpp+xml message ... /message What do you think? On Tue, Feb 3, 2015 at 11:07 AM, Winfried Tilanus winfr...@tilanus.com wrote: On 03-02-15 11:03, Ralph Meijer wrote: Sure it will be short. However, some notes on limitations and security considerations would also need to be added. If only to make it easier to compare against other e2e proposals. If you want to make a start with a XEP, that's appreciated. https://github.com/winfried/XMPP-OTR If you give me your github name, I will give you write access ;-) Winfried -- Daniele
Re: [Standards] OTR
On 2015-02-03 11:07, Winfried Tilanus wrote: On 03-02-15 11:03, Ralph Meijer wrote: Sure it will be short. However, some notes on limitations and security considerations would also need to be added. If only to make it easier to compare against other e2e proposals. If you want to make a start with a XEP, that's appreciated. https://github.com/winfried/XMPP-OTR If you give me your github name, I will give you write access ;-) I have an early draft I started on for Current OTR Usage in XMPP but I've been busy with other things. It has some of the issues we have with it written down, which needs to be word-smithed to something more formal. Might be useful as a starting point. -- Kim Zash Alvefur Title: XEP-: Current OTR Usage in XMPP XEP-: Current OTR Usage in XMPP Abstract: This document outlines the current usage of OTR for encrypted messaging. Author: Kim Alvefur Copyright: 1999 - 2014 XMPP Standards Foundation. SEE LEGAL NOTICES. Status: ProtoXEP Type: Historical Version: 0.1 LastUpdated: 2013-12-20 WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at http://xmpp.org/extensions/ and announced on the standards@xmpp.org mailing list. Table of Contents 1. Introduction2. Negotiation3. Encrypting4. Security Considerations5. Other Known Issues6. IANA Considerations7. XMPP Registrar Considerations AppendicesA: Document InformationB: Author InformationC: Legal NoticesD: Relation to XMPPE: Discussion VenueF: Requirements ConformanceG: NotesH: Revision History 1. Introduction The Jabber community has long acknowledged the need for privacy and security features in a well-rounded instant messaging system. Unfortunately, finding a consensus solution to the problem of end-to-end encryption is still not really solved. Lots of people are using Off-the-Record Communication [1]. This specification documents OTR as it is used in XMPP today. This document is not intended to present a standard, because more complete solutions are being investigated. 2. Negotiation Negotiation and encrypted content goes over normal message/ stanzas in the body/ child. Example 1. Requests to start OTR message to='reat...@jabber.org/jarl' from='pgmill...@jabber.org/wj_dev2' body?OTRv23? If you can read this, you don't support OTR./body /message 3. Encrypting Example 2. An encrypted message stanza message to='reat...@jabber.org/jarl' from='pgmill...@jabber.org/wj_dev2' body?OTR:AAEDTmdnbnB4IG5nIHFuamEhCg==./body /message It is considered polite to include an unencrypted message body/, but this is not possible in OTR due to the use of the body/ for carrying the encrypted payload. 4. Security Considerations The method described herein has the following security issues: No encryption of complete stanzas Non-body payloads are not secured Anything else? 5. Other Known Issues In addition to the security considerations listed above, there are several other known issues with this method: Gets messy with multiple resources or Message Carbons (XEP-0280) [2]. Not integrated with XMPP. Does not work with Offline messages or archives. (Some may consider this a good thing) 6. IANA Considerations This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [3]. 7. XMPP Registrar Considerations This document requires no interaction with the XMPP Registrar. Appendices Appendix A: Document Information Series: XEP Number: Publisher: XMPP Standards Foundation Status: ProtoXEP Type: Historical Version: 0.1 Last Updated: 2013-12-20 Approving Body: XMPP CouncilDependencies: XMPP Core, OTR spec? Supersedes: None Superseded By: None Short Name: otr This document in other formats: XML PDF Appendix B: Author Information Kim Alvefur Email: z...@zash.se JabberID: z...@zash.se Appendix C: Legal Notices CopyrightThis
Re: [Standards] OTR
Some clients do weird stuff like encoding XHTML-IM (which is probably not a good idea at all). Also a XEP should give some advices on what to allow, saying that history should be disabled by default, this kind of things. Also there is an OTR space-based discovery system which should be useless in XMPP (except if you use OTR with gateway/legacy networks). Maybe a XEP should explain what to do, if we need to announce there somewhere with XMPP discovery, etc. On 03/02/2015 10:37, Florian Schmaus wrote: Isn't documenting the current OTR usage in XMPP simply message … body … put OTR stuff here … /body /message where OTR stuff is defined at https://otr.cypherpunks.ca/Protocol-v2-3.1.0.html (I think most implementations use OTR v2) and https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html So OTR is IM protocol-agnostic. You can see how OTR tries to negotiate using whitespaces at the end of String within the /body element at https://github.com/python-otr/gajim-otr/issues/9#issue-40676864 I'm also not sure if, not only because it's IM protocol-agnostic, OTR would be a good fit for IoT. Some research in this direction would sure be interesting. - Florian
Re: [Standards] MAM and Pubsub
Having a node attribute is defined in 313 as specifying you want to search a pubsub archive instead of another type of archive. I don't see the confusion. It's explained in XEP-0313, but I think it's a bad idea to use common terminology to associate MAM with an other XEP, without namespace. If tomorrow a XEP uses this same terminology of node, it will starts to be confusing. No, you're not. Consider you have a node to which someone has published with the same item id repeatably, e.g. id='myitem'. MAM will allow you to recover previous versions of that particular item, whereas 60 does not. OK, but that doesn't prevent of showing pubsub namespace somewhere. Or at least something less generic than node Letting this one settle in for a bit. Delegation is a tough problem to do properly without breaking things, especially if the namespace delegated has relations to other specs. We can work around this in namespace delegation by adding an attribute check in addition to namespace check, that would be better than sending back the traffic to the server, even if it complicate the XEP. I would still be more happy with an other attribute name to link MAM and PubSub. Goffi
Re: [Standards] OTR
Wiadomość napisana przez Daniele Ricci daniele.ath...@gmail.com w dniu 3 lut 2015, o godz. 12:20: The only problem here is how to recognise the encrypted data? Is it a text body or a stanza? Maybe we can use a type attribute to otr/, revealing more metadata? Or maybe we could add a header to the encrypted data: I don’t understand. If client receives messageotr… then it will decrypt data and expect that result of decryption is stanza (or maybe other element allowed in XMPP Stream), then client will process received and decrypted element like any other received elements. Look at https://tools.ietf.org/html/draft-miller-xmpp-e2e-02 (4.3. Example - Securing a Message). The same idea. -- Bartosz Małkowski Tigase Polska xmpp:bmal...@malkowscy.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] OTR
Of course, I was just talking about a deterministic way of describing the encrypted data - and to save bandwidth. Anyway the point of metadata leakage is valid. We (as in XMPP) do what we can and we encrypt what we can. Anonymity was never the scope of XMPP. Daniele On 3 Feb 2015 12:59, Bartosz Małkowski bmalkow...@tigase.pl wrote: Wiadomość napisana przez Daniele Ricci daniele.ath...@gmail.com w dniu 3 lut 2015, o godz. 12:20: The only problem here is how to recognise the encrypted data? Is it a text body or a stanza? Maybe we can use a type attribute to otr/, revealing more metadata? Or maybe we could add a header to the encrypted data: I don’t understand. If client receives messageotr… then it will decrypt data and expect that result of decryption is stanza (or maybe other element allowed in XMPP Stream), then client will process received and decrypted element like any other received elements. Look at https://tools.ietf.org/html/draft-miller-xmpp-e2e-02 (4.3. Example - Securing a Message). The same idea. -- Bartosz Małkowski Tigase Polska xmpp:bmal...@malkowscy.net
[Standards] GSoC 2015
Hi folks, A decision will need to be made soon (by Board) whether we try out for GSoC 2015 as the XSF or not. It’d be helpful to know Very Soon if we have interested mentors and projects available, so if folks are involved in running open-source XMPP projects and are able to commit the time to and interested in mentoring GSoC students this year, can they please let me know ~=now, please? Private reply to this mail is fine. If we have a number of people interested in principle, we can try to get an ideas page set up etc. etc. /K
Re: [Standards] OTR
If you're interested in looking beyond the XMPP bowl there has been very similar discussion in the post-XMPP messaging list: https://moderncrypto.org/mail-archive/messaging/2015/001309.html Multiple devices and key synchronization https://moderncrypto.org/mail-archive/messaging/2015/001354.html Key rotation On Tue, Feb 03, 2015 at 11:07:40AM +0100, Winfried Tilanus wrote: https://github.com/winfried/XMPP-OTR I think the XMPP/OTR/Tor combination is what people are using *today* because you have to start somewhere and the other options (TorChat or Retroshare via Tor) aren't as mature. Yet I think the XMPP community should REALLY REALLY acknowledge that the metadata issue IS more important than the forward secrecy aspect and that applying a bit of Tor on the way to the server is NOT a sufficient solution. As George Danezis expressed it in his 31c3 presentation, social graphs tent to be isomorphic. No matter how well you pseudonymize your identity via Tor, the people you add to your roster are going to be similar to the ones you already added to other social graphs. The 2009 paper de-anonymizing social networks shows how an attacker can correlate social graphs. So if a five eyes state agency wants to know everyone's identities on jabber.org or jabber.ccc.de, it either needs to obtain access to the server data base, or apply plenty of traffic shaping over a period of time, to extract that graph - then compare it to existing intelligence such as the Facebook, Twiter or e-mail social network graphs. In other words, no matter how much OTR and Tor we throw at it, the fact that XMPP uses federated servers will always put our metadata at risk. Federation has also failed us ideologically: Each time a federated protocol becomes popular, cloud offerings turn out to be the most efficient, scalable and easy to adopt for the masses. Thus federated protocols such as SMTP and XMPP have been a slippery slope leading into centralized cloud dependency - legitimizing platforms such as Gmail and G-Talk. Even Facebook Chat. If you want to do the world some good, help us work on a distributed, end-to-end encrypted and forward secret technology that builds upon agnostic anonymizing relay nodes rather than federated servers. An architecture that keeps the social graph completely on the devices of the users rather than replicating it into the network infrastructure. You may find this thread interesting. It discusses the possibilities of implementing a one-to-many messaging system into the backbone of Tor: https://lists.torproject.org/pipermail/tor-talk/2014-December/036251.html Cryptographic social networking project Concluding, please use XMPP for things it is appropriate for... don't try to do privacy with it. It's a battle we can't win. -- E-mail is public! Talk to me in private using Tor. torify telnet loupsycedyglgamf.onion DON'T SEND ME irc://loupsycedyglgamf.onion:67/lynX PRIVATE EMAIL http://loupsycedyglgamf.onion/LynX/OR FACEBOOGLE
Re: [Standards] OTR
On Tue, Feb 03, 2015 at 02:22:33PM +0100, Ralph Meijer wrote: I think everyone in our community knows that XMPP, as currently designed, has no simple mechanism to obscure who's communicating with whom. Going into more detail, federation as in e-mail or XMPP has this problem in both extremes: if everyone is running their own server (instead of a cloud service that could be compromised by a government agency), the number of people associated with such a server is likely to be low, making it easier to find out who's behind it. Thanks for the ack, Ralph. However, that is just one threat model, one that someone may or may not find important enough to fix. Efforts to address other threat models (like secrecy of messages themselves) are not suddenly worthless if you can't hide who's communicating. Also, documenting current practise still seems a great idea, to me. The problem here is that far too many people are investing time in the old communications model, be it applying crypto to SMTP or XMPP. And yet should one day, against the odds of disinterest or distraction, an actually functional distributed communications network arise, serving a better job at both messaging and social networking than even the cloud systems, how much does it matter, that SMTP or XMPP are safe from the perspective of some lesser threat models? It reminds me a bit of all the effort that went into digital fax technology. With my ISDN router came the ability to send fax directly from the word processor and to receive fax in text form thanks to automatic OCR. Yet, all the world switched to e-mail anyway. Why should they stick to a fax system even if it was fully integrated into the computing experience? Also, what lesser threat models can make sense? The exercise of democracy depends on constitutional freedoms like Secrecy of Correspondence and Freedom of Association (= metadata protection). With technology that has within only twenty years turned all democratic populations on Earth into fully surveillable and predictable populace, can there be any more important threat model? What's the use for a Syrian dissident that Google is on her side if in ten years later all her activity data can be handed over to the then possibly pro-Western government of Syria? I know these people are better served with something now than too late, but that's what they already have. The next thing they need is something that defends metadata - the foundation for forming a political opposition, the essential capacity of renewal of democracy. If we leave metadata up for grabs, we are co-responsible for a slippery slope towards global dismantlement of democracies. It doesn't take any evil conspiracies - it's the technology enabling and leading the way to hell. That's why I suggest you should not spend further years trying to get at so-called low-hanging fruit which each time ends up not hanging low at all (multi-end OTR is such a case) while there are new paradigms of Internet technology out there, waiting to be fleshed out and given a chance to protect humanity from itself. That stuff needs people like you. -- E-mail is public! Talk to me in private using Tor. torify telnet loupsycedyglgamf.onion DON'T SEND ME irc://loupsycedyglgamf.onion:67/lynX PRIVATE EMAIL http://loupsycedyglgamf.onion/LynX/OR FACEBOOGLE
[Standards] Membership Application period Q2 2015
I have created the membership application page for Q2 2015 at: http://wiki.xmpp.org/web/Membership_Applications_Q2_2015 The following XSF members have to reapply: * Yusuke Doi * Wayne Franklin * Artur Hefczyc * Wojciech Kapcia * Ben Langfeld * Arc Riley * Kevin Smith * Paul Witty * Andrzej Wójcik * Florian Zeitz * Martin Hewitt feel free to recruit new XSF members and push the message to other channels. Regards, Alex -- Alexander Gnauck xmpp:gna...@jabber.org
Re: [Standards] OTR
On 03.02.2015 10:04, Dave Cridland wrote: On 2 Feb 2015 18:49, Peter Saint-Andre - yet pe...@andyet.net mailto:pe...@andyet.net wrote: On 2/2/15 5:22 AM, Hund, Johannes wrote: Since it was undisclosed that even the NSA seems to have problems breaking into OTR [1], it gained a lot of attention it seems and thus does a good deal in supporting XMPP as a choice for applications with high requirements in privacy and security as its often the case for IoT applications. OTR secures only the character data of the XMPP body/ element within message stanzas. That's appropriate for IM but doesn't really help with things like IoT (which often use extended namespaces). Exactly, and this is the kind of thing I was hoping that documenting the current OTR usage in XMPP would show clearly. Isn't documenting the current OTR usage in XMPP simply message … body … put OTR stuff here … /body /message where OTR stuff is defined at https://otr.cypherpunks.ca/Protocol-v2-3.1.0.html (I think most implementations use OTR v2) and https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html So OTR is IM protocol-agnostic. You can see how OTR tries to negotiate using whitespaces at the end of String within the /body element at https://github.com/python-otr/gajim-otr/issues/9#issue-40676864 I'm also not sure if, not only because it's IM protocol-agnostic, OTR would be a good fit for IoT. Some research in this direction would sure be interesting. - Florian signature.asc Description: OpenPGP digital signature
Re: [Standards] OTR
On 3 Feb 2015 09:37, Florian Schmaus f...@geekplace.eu wrote: On 03.02.2015 10:04, Dave Cridland wrote: On 2 Feb 2015 18:49, Peter Saint-Andre - yet pe...@andyet.net mailto:pe...@andyet.net wrote: On 2/2/15 5:22 AM, Hund, Johannes wrote: Since it was undisclosed that even the NSA seems to have problems breaking into OTR [1], it gained a lot of attention it seems and thus does a good deal in supporting XMPP as a choice for applications with high requirements in privacy and security as its often the case for IoT applications. OTR secures only the character data of the XMPP body/ element within message stanzas. That's appropriate for IM but doesn't really help with things like IoT (which often use extended namespaces). Exactly, and this is the kind of thing I was hoping that documenting the current OTR usage in XMPP would show clearly. Isn't documenting the current OTR usage in XMPP simply message … body … put OTR stuff here … /body /message That's certainly the core of it, though the devil is usually in the details. I suspect there's all sorts of weird stuff with multiple resources, for instance, and html, and... where OTR stuff is defined at https://otr.cypherpunks.ca/Protocol-v2-3.1.0.html (I think most implementations use OTR v2) and https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html So OTR is IM protocol-agnostic. You can see how OTR tries to negotiate using whitespaces at the end of String within the /body element at https://github.com/python-otr/gajim-otr/issues/9#issue-40676864 I'm also not sure if, not only because it's IM protocol-agnostic, OTR would be a good fit for IoT. Some research in this direction would sure be interesting. - Florian It'd be nice to have a document which held our consensus view on what OTR in XMPP protects against, and what it fails to protect against, and how one implements it. Currently it's one of those things that everybody knows, and I'm willing to admit that I am not everybody. Dave.
Re: [Standards] MAM and Pubsub
On 03/02/15 11:05, Goffi wrote: G'day, I have an issue that I mentioned in Brussel to Matthew with using MAM (XEP-0313) for PubSub (XEP-0060)/PEP (XEP-0163). Today to query a PubSub node with MAM, we need to do (according to section 4): iq to='pubsub.shakespeare.lit' type='set' id='juliet1' query xmlns='urn:xmpp:mam:0' queryid='f28' node='fdp/submitted/capulet.lit/sonnets' /iq I don't think it's a good way for the following reasons: 1) only the node attribute allow to know that we are doing a query on pubsub. What if someday something called also node is used in an other XEP ? Having a node attribute is defined in 313 as specifying you want to search a pubsub archive instead of another type of archive. I don't see the confusion. 2) pubsub namespace doesn't appear anywhere. In my opinion it's more a pubsub request than a MAM request (we query a pubsub service, we just want to filter the results), so the pubsub namespace should appear. No, you're not. Consider you have a node to which someone has published with the same item id repeatably, e.g. id='myitem'. MAM will allow you to recover previous versions of that particular item, whereas 60 does not. 3) as we have no pubsub namespace, it is a big problem to delegate it with XEP-0355. That means that instead of just delegating pubsub, we need to delegate all MAM traffic, including messages, and then send them back to server (which is not possible yet). Lot of useless traffic and complications. Letting this one settle in for a bit. Delegation is a tough problem to do properly without breaking things, especially if the namespace delegated has relations to other specs. Edwin
Re: [Standards] OTR
On February 3, 2015 10:37:14 AM WAT, Florian Schmaus f...@geekplace.eu wrote: On 03.02.2015 10:04, Dave Cridland wrote: On 2 Feb 2015 18:49, Peter Saint-Andre - yet pe...@andyet.net mailto:pe...@andyet.net wrote: On 2/2/15 5:22 AM, Hund, Johannes wrote: Since it was undisclosed that even the NSA seems to have problems breaking into OTR [1], it gained a lot of attention it seems and thus does a good deal in supporting XMPP as a choice for applications with high requirements in privacy and security as its often the case for IoT applications. OTR secures only the character data of the XMPP body/ element within message stanzas. That's appropriate for IM but doesn't really help with things like IoT (which often use extended namespaces). Exactly, and this is the kind of thing I was hoping that documenting the current OTR usage in XMPP would show clearly. Isn't documenting the current OTR usage in XMPP simply message … body … put OTR stuff here … /body /message where OTR stuff is defined at https://otr.cypherpunks.ca/Protocol-v2-3.1.0.html (I think most implementations use OTR v2) and https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html So OTR is IM protocol-agnostic. You can see how OTR tries to negotiate using whitespaces at the end of String within the /body element at https://github.com/python-otr/gajim-otr/issues/9#issue-40676864 I'm also not sure if, not only because it's IM protocol-agnostic, OTR would be a good fit for IoT. Some research in this direction would sure be interesting. - Florian Sure it will be short. However, some notes on limitations and security considerations would also need to be added. If only to make it easier to compare against other e2e proposals. If you want to make a start with a XEP, that's appreciated. -- ralphm
[Standards] MAM and Pubsub
G'day, I have an issue that I mentioned in Brussel to Matthew with using MAM (XEP-0313) for PubSub (XEP-0060)/PEP (XEP-0163). Today to query a PubSub node with MAM, we need to do (according to section 4): iq to='pubsub.shakespeare.lit' type='set' id='juliet1' query xmlns='urn:xmpp:mam:0' queryid='f28' node='fdp/submitted/capulet.lit/sonnets' /iq I don't think it's a good way for the following reasons: 1) only the node attribute allow to know that we are doing a query on pubsub. What if someday something called also node is used in an other XEP ? 2) pubsub namespace doesn't appear anywhere. In my opinion it's more a pubsub request than a MAM request (we query a pubsub service, we just want to filter the results), so the pubsub namespace should appear. 3) as we have no pubsub namespace, it is a big problem to delegate it with XEP-0355. That means that instead of just delegating pubsub, we need to delegate all MAM traffic, including messages, and then send them back to server (which is not possible yet). Lot of useless traffic and complications. So I guess either PubSub namespace should appear somewhere, or an other way should be used to filter items on PubSub/PEP. Thanks Goffi
