Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
Am 19.11.13 20:56, schrieb Philipp Hancke: [...] Having no federation at least doesn't introduce yet another huge possibility for security problems and as long as you own the source code and aren't forced to use anybody's specific offering it is highly inadeguate to call such a software a silo. In case others are not yet aware: #youbroketheinternet is not only explicitly opposed to federation but not even interested in interoperability with federated communication networks. There is the hypothesis that any federated network tends to cluster around a number of large nodes. E.g. for XMPP this would be gmail, jabber.org, jabber.ccc.de (applause to their efforts on making themselves unreliable!), ... Interdomain federation is hard, especially delivering the same user experience as between users on the same domain. I understand the rationale. I just don't agree with it. I don't agree with it either. What you end up having is silos that typically consist of proprietary technology with limited usability for the wider Internet user community. The benefits of XMPP are interoperability, the open standards process, and the large number of XMPP providers you can choose from. If you don't like one located in the US then pick it from some other country. If don't like any of them setup your own.
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
It really depends what threats you are concerned about, Steffen. I briefly looked at a Mumble project, which uses IM over Tor, when it was mentioned on the IETF perpass list. Here were my thoughts: http://www.ietf.org/mail-archive/web/perpass/current/msg00215.html Ciao Hannes Am 18.11.13 13:38, schrieb Steffen Larsen: Hi, On 18 Nov 2013, at 13:07, Andreas Kuckartz a.kucka...@ping.de wrote: Simon Tennant: IMHO, e2e security would probably make more sense as a XEP and working group that has the time to zoom into all the implementation details. Can that be solved by an XEP ? What about this IETF draft? (I still have to read it) End-to-End Object Encryption and Signatures for the Extensible Messaging and Presence Protocol (XMPP) draft-miller-xmpp-e2e-06 https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e/ There exist people who mention XMPP as belonging to faulty technologies for which they want to create alternatives: http://youbroketheinternet.org/ And I try to find out what can be done to improve XMPP regarding security and privacy. Well you can “always” run XMPP on top of TOR if you like that, if it is the S2S routing that bothers you. :-) Cheers, Andreas On 18 November 2013 10:30, Andreas Kuckartz a.kucka...@ping.de mailto:a.kucka...@ping.de wrote: Peter Saint-Andre some time ago wrote: On 7/16/13 4:27 AM, Carlo v. Loesch wrote: Since XMPP isn't suitable for keeping meta-data private I would presume that e2e privacy is out of scope for this mailing list, really. True. Where would the topic e2e privacy for XMPP be in scope ? Cheers, Andreas /Steffen
Re: [Standards] Status of XEP-xxxx: Sensor-over-XMPP
Hi all, I was actually wondering myself about the status of XMPP SIP usage for sensors. I dropped Peter a mail a month ago to hear more about the deployment situation. It seems that if there are implementations then they are using HTTP. Ciao Hannes On Dec 17, 2012, at 5:47 PM, Matthew Wild wrote: On 17 December 2012 12:35, Peter Waher peter.wa...@clayster.com wrote: Hello, I’m writing to you to, to ask about the status of the following document: http://xmpp.org/extensions/inbox/sensors.html I’m interested in developing extensions for allowing sensor data communication and IoT, among other things. We have multiple applications using XMPP and sensors. Before proposing an extension by ourselves, I’ve been waiting to find colleagues working in the same area, so we could propose an extension together, this increasing the probability for it to become useful. What is the status of the above mentioned document? Is it set in stone, or is it possible to work on it, redefine parts of it, etc., in order for it to become more general and suitable also to our needs? Are you able to invite other authors to partake in the development of this proposed extension? It was rejected by the council at its meeting 2011-04-27: http://mail.jabber.org/pipermail/council/2011-May/003164.html Nathan posted his reasoning here: http://mail.jabber.org/pipermail/standards/2011-May/024545.html - and the discussion continued here: http://mail.jabber.org/pipermail/standards/2011-May/024547.html No new version was submitted as far as I know, and I know of no public implementations of the protocol (that's not to say there aren't any of course...). Regards, Matthew
Re: [Standards] XMPP OAuth2 login at Google
Here is my impression: Since the community OAuth specification allowed the usage of PLAIN without TLS there is most likely still a lot of code out there that uses it without any confidentiality protection (which is obviously very insecure). (Btw, the current XMPP OAuth XEP is also insecure...) While the OAuth 1.0 mandated TLS before it got published as an RFC I could imagine that deployments have not paid attention to that tiny detail. On 09/17/2012 10:10 PM, Randy Turner wrote: PLAIN is going to be deprecated, even though TLS is pretty much ubiquitous? Randy Ralph Meijer ral...@ik.nu wrote: On 2012-09-13 19:20, Peter Saint-Andre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/11/12 4:24 PM, Lance Stout wrote: It's a bit annoying that they add an extra attribute to the auth / element, because it adds a special case to check in what would ideally be a fully generic implementation. Fortunately, it doesn't seem to be required for now. Namespaced attributes can also be problematic, and as an author of RFC 6648 I really don't like the name X-OAUTH2. One hopes that they might eventually migrate to the standardized mechanism being defined at the IETF: http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ In this light, the fact that X-GOOGLE-TOKEN and PLAIN will be deprecated soonish [1] is very interesting. I'd hope we can convince them to do this the standard way before clients have to implement their botched version. [1] http://googledevelopers.blogspot.nl/2012/09/adding-oauth-20-support-for-imapsmtp.html -- ralphm
Re: [Standards] XMPP OAuth2 login at Google
Hi Randy, the issue about the browser interaction is that the SSO mechanisms for the Web* have not standardized the authentication part. Since there is so much Web deployment out there and folks have an interest to work with existing deployment. However, there is a window of opportunity here: there is currently an effort ongoing to standardize a new HTTP authentication mechanism. Additionally, there is the (maybe a bit theoretical) chance to make use of ABFAB (another IETF effort, see http://tools.ietf.org/html/draft-ietf-abfab-arch-03). Does this make sense to you? Ciao Hannes *: For the mobile world (if you consider 3GPP specifications) then there is a way to use WebSSO procedures without the interactive browser interaction. On 09/18/2012 06:22 AM, Randy Turner wrote: I would like to emphasize the earlier point….it would be nice if we had a solution that did NOT require an interactive browser procedure. Randy On Sep 17, 2012, at 5:21 PM, Randy Turner rtur...@amalfisystems.com wrote: What about a combination...OpenID Connect ? Peter Saint-Andre stpe...@stpeter.im wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/17/12 3:00 PM, Ivan Martinez wrote: I'm currently considering wether to use OAuth2 or OpenID2 in my server. Which one do you think will be more adopted as a user authentication mechanism in XMPP servers?. Which companies are planing to use each of them?. IMHO it is much more likely that people will implement and deploy OAuth2 than OpenID for XMPP authentication. /psa -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBXlNAACgkQNL8k5A2w/vwhhgCfdakf/6wV7D+shOKcerR6bcTP YFYAoI60RJcxNcz3Uj7X0kA1CWfz9pot =0TLT -END PGP SIGNATURE-
Re: [Standards] XMPP OAuth2 login at Google
On 09/18/2012 08:21 PM, Peter Saint-Andre wrote: (Btw, the current XMPP OAuth XEP is also insecure...) Calling it current is a bit of a stretch.:) It was deferred for inactivity quite some time ago. At this point, any use of OAuth in XMPP would likely be based on the SASL mechanism. I didn't know. I even thought that it covered an entirely different use case, namely between two endpoints rather than between the end host and the XMPP server (whatever the right XMPP terminology here is).
Re: [Standards] XMPP OAuth2 login at Google
The choices are: * OAuth SASL http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-08 IMHO it would work fine with OpenID Connect since OpenID Connect is based on OAuth 2.0. * OpenID SASL http://tools.ietf.org/html/rfc6616 * SAML SASL http://tools.ietf.org/html/rfc6595 http://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-ec-03 The answer will depend on the type of systems you want to inter-work with. Ciao Hannes On 09/18/2012 03:21 AM, Randy Turner wrote: What about a combination...OpenID Connect ? Peter Saint-Andre stpe...@stpeter.im wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/17/12 3:00 PM, Ivan Martinez wrote: I'm currently considering wether to use OAuth2 or OpenID2 in my server. Which one do you think will be more adopted as a user authentication mechanism in XMPP servers?. Which companies are planing to use each of them?. IMHO it is much more likely that people will implement and deploy OAuth2 than OpenID for XMPP authentication. /psa -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBXlNAACgkQNL8k5A2w/vwhhgCfdakf/6wV7D+shOKcerR6bcTP YFYAoI60RJcxNcz3Uj7X0kA1CWfz9pot =0TLT -END PGP SIGNATURE-
Re: [Standards] XMPP OAuth2 login at Google
On 09/18/2012 08:51 PM, Peter Saint-Andre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/18/12 11:25 AM, Hannes Tschofenig wrote: On 09/18/2012 08:21 PM, Peter Saint-Andre wrote: (Btw, the current XMPP OAuth XEP is also insecure...) Calling it current is a bit of a stretch.:) It was deferred for inactivity quite some time ago. At this point, any use of OAuth in XMPP would likely be based on the SASL mechanism. I didn't know. Well, Hannes, you can't know everything. ;-) hmmm. I even thought that it covered an entirely different use case, namely between two endpoints rather than between the end host and the XMPP server (whatever the right XMPP terminology here is). True, but it seems that few people are interested in those use cases (e.g., using OAuth for authorization to join a chatroom). I had gotten the impression that XEP 235 http://xmpp.org/extensions/xep-0235.html was motivated by the Yahoo FireEagle work. My understanding that the usage was really end-to-end rather from the end host to the first hop. From a security point of view that makes a huge difference. So, XEP 235 wasn't really secure usage of OAuth in XMPP to begin with and that may have motivated them to change it. I am saying this because I went through the same design exercise with the SAML SIP work. There, however, we ran into lots of problems with the way how SBCs prevent any useful security mechanism to work. Ciao Hannes
Re: [Standards] Schemas in XEPs
Hi Bala, Here is my view: 1) the schema never expresses all constraints since it is not powerful enough to describe them. For simpler tasks it is not useful to describe all constraints in a schema since otherwise the schema becomes unreadable. 2) nobody! validates instance documents (in a protocol) when receiving messages against the schema (since you have to do the input validation anyway). 2) when you extend the schema, which is a core concept in protocol design to design them with extension points, then in almost all of the cases I have seen validation does not work anymore because the extended schema is not validated, i.e. it verifies as correct. Even worse, since most people are not super skilled with writing XML schemas their protocol design is essentially guided with what they are able to express in the XML schema. Ciao Hannes On Dec 9, 2011, at 8:05 PM, Bala Pitchandi wrote: I strongly disagree that XSD (RelaxNG or any other way of specifying the structure of the XML messages) is a waste of time. If you don't have a schema, you'll either end up implementing all the validation manually or worse crash on invalid input. XSD parser-validators (they exist) do all that work for you, and are optimized to do that. Without a schema, all we have is the text and examples which could be interpreted in many ways by how they are written and how they are understood by the reader. Requiring a schema also forces the XEP authors to think hard and come up with a design that's structured, extensible (Yes, XSD schemas can be made extensible). -- Bala -Original Message- From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On Behalf Of Hannes Tschofenig Sent: Friday, December 09, 2011 12:36 PM To: XMPP Standards Subject: Re: [Standards] Schemas in XEPs Hi Dave, Over the time I have gotten the impression that an XML schema is really a waste of time. It creates the illusion that there is something that provides help (to implementers and to those who read the specification) but in reality it doesn't. Working on different specifications I later thought that the problem is with the readability and extensibility of the XML schema and then we switched to Relax NG in some IETF working groups. That turned to be a mistake as well. When it comes to extensibility a Relax NG schema is equally bad. The extensibility mechanism of XML would prevent you from getting any meaningful validation anyway. So, validation isn't useful because more or less everything validates (after you add the extension points everywhere). So, I believe we are doing fine without XML schema but with lots of examples. Implementers just look at examples. Maybe you could therefore recommend not to use XML schemas (or Relax NG schemas). Ciao Hannes On Dec 9, 2011, at 6:24 PM, Dave Cridland wrote: On Thu Dec 8 23:13:38 2011, Matthew A. Miller wrote: I'd like to point out that all of our XML Schemas are non-normative. They're provided for informational use, and ought not be considered the absolute record of authority. What follows is my understanding; we should probably have this documented somewhere (a Tao Of XSF XEP?): - The schemas in XEPs are not normative. - We do, however, try to keep them aligned properly with the text, and will accept bug reports with gratitude. - The schemas in RFCs *are* normative. - The IETF does, however, accept errata should they not match the text or the intent. So in both cases, we'd expect the schemas to be right, and welcome fixes; technically, though, there's a distinction in normativeness (normativity?) between RFC and XEP. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Schemas in XEPs
Peter, provide more details. And, explain what you mean by schema checking? Ciao Hannes On Dec 9, 2011, at 8:10 PM, Peter Saint-Andre wrote: In addition, I know of at least one large deployment community that performs active schema-checking for XMPP traffic. Those folks would like it if our schemas were normative, I'd bet. :)
Re: [Standards] Schemas in XEPs
Hi Dave, Over the time I have gotten the impression that an XML schema is really a waste of time. It creates the illusion that there is something that provides help (to implementers and to those who read the specification) but in reality it doesn't. Working on different specifications I later thought that the problem is with the readability and extensibility of the XML schema and then we switched to Relax NG in some IETF working groups. That turned to be a mistake as well. When it comes to extensibility a Relax NG schema is equally bad. The extensibility mechanism of XML would prevent you from getting any meaningful validation anyway. So, validation isn't useful because more or less everything validates (after you add the extension points everywhere). So, I believe we are doing fine without XML schema but with lots of examples. Implementers just look at examples. Maybe you could therefore recommend not to use XML schemas (or Relax NG schemas). Ciao Hannes On Dec 9, 2011, at 6:24 PM, Dave Cridland wrote: On Thu Dec 8 23:13:38 2011, Matthew A. Miller wrote: I'd like to point out that all of our XML Schemas are non-normative. They're provided for informational use, and ought not be considered the absolute record of authority. What follows is my understanding; we should probably have this documented somewhere (a Tao Of XSF XEP?): - The schemas in XEPs are not normative. - We do, however, try to keep them aligned properly with the text, and will accept bug reports with gratitude. - The schemas in RFCs *are* normative. - The IETF does, however, accept errata should they not match the text or the intent. So in both cases, we'd expect the schemas to be right, and welcome fixes; technically, though, there's a distinction in normativeness (normativity?) between RFC and XEP. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] [jdev] Fwd: XMPP in the browser -- your thoughts?
Aren't there XMPP implementations in the browser already out there? Example: Strophe http://code.stanziq.com/strophe/ So, what are you guys planning to do on top of it?
Re: [Standards] NEW: XEP-0279 (Server IP Check)
FYI: STUN and TURN are two separate mechanisms. What are the requirements for the client when Jingle is used? Pedro Melo wrote: Hi, On Sat, Mar 6, 2010 at 5:01 AM, Evgeniy Khramtsov xramt...@gmail.com wrote: There is already STUN support in ejabberd :P For me it is unclear why we need another way to discover client's public ip, that's why I'm asking Because I already have a XMPP stack, and if I can get away without having to include a TURN stack, thats a win on my book. Besides, this is a trivial XEP. The C2S already has your IP address, so its easier to ask your server for it. Bye,
Re: [Standards] GPS accuracy in XEP-0080
It would have been good to align this work with the other location based activities that are going on. GML seems to be the main standard in this field. For civic location there are also standards to look at. Any interest in alignment? Ciao Hannes Peter Saint-Andre wrote: Currently, XEP-0080 defines the accuracy of GPS readings in minutes of arc (via the error/ element). Joe Hildebrand and I talked about this recently and decided that it would be preferable to define accuracy in meters, as is done in IMPS (Wireless Village) and other protocols. Therefore we propose to deprecate the error/ element and define a new accuracy/ element. The SVN diff from 1.6rc1 to 1.6rc2 is here: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0080.xml?%40diffMode=u%40diffWrap=sr1=2275r2=2317u=3ignore=k= Or: http://is.gd/3soR You can read the rendered document here: http://xmpp.org/extensions/tmp/xep-0080-1.6.html Peter
