Re: [Standards] C2C TLS
On Monday 24 November 2008 11:57:28 Dirk Meyer wrote: > I point to Dave's answer in this matter. The state of the XEP is > "working" (I tested it) and client support is still missing. Compared to > only one client using ESessions, it isn't that bad. If only one client > implements ESessions after it is around for a longer time, it doesn't > look good for it. If the TLS based solution has no client support after > one year it was first published, I agree, it is also a failure. To be honest, C2C TLS occupies the same slot in my TODO list as ESessions once did. So, for me, the interest writing code for e2e encryption has almost nothing to do with the approach. I was just hoping that by the time I reach that slot, we will have decided on a safe protocol. This is actually the case for me with much of XMPP in general. I'm not necessarily waiting for protocols to get better. I'm just trying to get through my damn TODO list. :) -Justin
Re: [Standards] C2C TLS
See my other mail for additional information, I just want to answer your questions very quickly: Jonathan Schleifer wrote: > 1.) What is the current state of the XEP? Is it even a XEP now? Open a stream with either XEP-0174 or XEP-0247 and use starttls. To help you with that we have XEP-0250 and XEP-0189. > 2.) How many clients implement it? If any, which? I guess only my lib right now. > 3.) If there are clients, do they use direct connections or use > Jingle's inband mode? Right now only IBB, ICE-TCL will be implemented when it is ready > 4.) How was the SAS problem solved, if it was solved at all? If not, > how will it be solved? We only use what TLS provides. There is no SAS in TLS ATM, so no SAS support. TLS-SRP is your choice to authenticate someone. > 5.) How much work was it to implement it? Was it really "just 5 > minutes of work" as some said in the discussion before? We you only count XEP-0247 with an implementation that already had link-local support, than I needed about 1 hour to code it. XEP-0250 cost me some time to find a TLS lib that provides more than just X.509 certificates on Python level (openssl and gnutls support everything we need, but the Python bindings lack support for OpenGPG and SRP support). Implementing the XEP took about 3 hours of work. > 6.) I predicted that it will still take a long time until C2C TLS will > reach the state ESessions now has. To me, it seems my prediction was > right. Anything I overlooked? I point to Dave's answer in this matter. The state of the XEP is "working" (I tested it) and client support is still missing. Compared to only one client using ESessions, it isn't that bad. If only one client implements ESessions after it is around for a longer time, it doesn't look good for it. If the TLS based solution has no client support after one year it was first published, I agree, it is also a failure. Dirk -- Computer Science: solving today's problems tomorrow.
Re: [Standards] C2C TLS
Jonathan Schleifer wrote: > Am 24.11.2008 um 18:50 schrieb Dave Cridland: > >> C2C TLS has numerous carefully audited crypto implementations, and >> one (or two?) test client implementations. Now, arguably, it might >> well have more - I'm not sure how many of the existing XEP-0174 >> clients will simply use TLS if offered, which would count in at >> least some respects. > > Please name at least two implementation so I can test those :). I have one lib that implements XEP-0247 for server based communication and XEP-0174 for link-local communication. In both bases starttls is used. I also added XEP-0250 support to provide X.509 certificate or SRP support -- no OpenGPG authentication right now. This works for both XEP-0247 and XEP-0174. The lib is not yet released, but I can send it to you if you want to test a client against it. I also wanted to implement XEP-0189 for public key handling to use in XEP-0250, but I have some problems with ejabberd not providing the list of all published keys using PEP. So ATM you have to put all known certificates in a file for the client, that is no good solution. I plan to release my code for some time now, but writing down my PhD thesis consumes a lot of my time. And without a proper key handling it is not so much fun. > Well, what about SAS? I still can't see it. There is no SAS for TLS right now. TLS-SRP cames close to it (you have to know a password before opening the connection) and that is working for me. > And do they use jingle inband or direct connections? Right now only InBand, my client has no support for SOCKS5. > If they use direct connections, is NAT traversal implemented, using a > STUN server etc.? No, we have no XEP for that yet. I'm trying to figure out what we need when implementing ICE-TCP. This is off-topic right now, but I wonder if we need the complexity of ICE-TCP or if we can go an easier way. Dirk -- You might have mail.
Re: [Standards] C2C TLS
On Mon Nov 24 17:54:00 2008, Jonathan Schleifer wrote: Am 24.11.2008 um 18:50 schrieb Dave Cridland: C2C TLS has numerous carefully audited crypto implementations, and one (or two?) test client implementations. Now, arguably, it might well have more - I'm not sure how many of the existing XEP-0174 clients will simply use TLS if offered, which would count in at least some respects. Please name at least two implementation so I can test those :). For the crypto layer, any TLS library. These include OpenSSL, GNU TLS, as well as numerous others. For the C2C TLS protocol itself, this is just over a C2C XMPP session - are you saying that Gajim won't use TLS on a link local session if offered? If not, why not? If so, why does this not count? You know the answers to the remainder of your questions, or else can look them up in the archives. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
[Standards] Unified Cloud Interface (UCI) for XMPP
Hello Everyone, This is my first post to the XMPP standards list. A few months ago a number of us came together to create "The Cloud Computing Interoperability Forum". The purpose of this group is to discuss the creation of a common cloud computing interface. The group is made up of a some of the largest cloud related vendors and startups who all share the goal of cloud interoperability as well reducing cross cloud complexity. (http://groups.google.com/group/cloudforum) I'd like to take a moment to explain my cloud interoperability ideas. After various conversations, our concept is starting to take shape and is based on what I'm called the "unified cloud interface" (aka cloud broker). The cloud broker will serve as a common interface for the interaction with remote platforms, systems, networks, data, identity, applications and services. A common set of cloud definitions will enable vendors to exchange management information between remote cloud providers. The unified cloud interface (UCI) or cloud broker will be composed of a specification and a schema. The schema provides the actual model descriptions, while the specification defines the details for integration with other management models. UCI will be implemented as an extension to the Extensible Messaging and Presence Protocol (XMPP) specifically as a XMPP Extension Protocol or XEP. The unified cloud model will address both Platform as a service offerings such as Google App Engine, Azure and Force.com as well as infrastructure cloud platforms such as Amazon EC2. Ultimately this model will enable a decentralized yet extensible hybrid cloud computing environment with a focus on secure global asynchronous communication. Once we are in general agreement on the draft proposal, it will be submitted for approval by the Internet Engineering Task Force (IETF) for inclusion as a XMPP Extension and presented at the IEEE International Workshop on Cloud Computing (Cloud 2009) being held in May 18-21, 2009, in Shanghai, China. My draft is based on a combination of working being done in conjunction to XMPP, CIM, Xam and several other standardization efforts. Comments welcome. -- -- Reuven Cohen Founder & Chief Technologist, Enomaly Inc. blog > www.elasticvapor.com - Open Source Cloud Computing > www.enomaly.com
Re: [Standards] C2C TLS
Am 24.11.2008 um 18:50 schrieb Dave Cridland: C2C TLS has numerous carefully audited crypto implementations, and one (or two?) test client implementations. Now, arguably, it might well have more - I'm not sure how many of the existing XEP-0174 clients will simply use TLS if offered, which would count in at least some respects. Please name at least two implementation so I can test those :). Therefore, in many respects ESessions is already lagging behind C2C TLS without anyone actually having done any coding specifically toward it. Well, what about SAS? I still can't see it. And do they use jingle inband or direct connections? If they use direct connections, is NAT traversal implemented, using a STUN server etc.? -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] C2C TLS
Am 24.11.2008 um 18:44 schrieb Peter Saint-Andre: That proposal was replaced by e2e-streams.html during list discussion and then published as XEP-0246: Thanks. I'll have a read then. Any client already implementing it? I don't really see any specification of SAS in that. It's only mentioned. Will that be a different XEP? -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] C2C TLS
On Mon Nov 24 17:28:05 2008, Jonathan Schleifer wrote: 6.) I predicted that it will still take a long time until C2C TLS will reach the state ESessions now has. To me, it seems my prediction was right. Anything I overlooked? Yes, and it's called "The Point". ESessions has one crypto implementation and one client implementation. C2C TLS has numerous carefully audited crypto implementations, and one (or two?) test client implementations. Now, arguably, it might well have more - I'm not sure how many of the existing XEP-0174 clients will simply use TLS if offered, which would count in at least some respects. Therefore, in many respects ESessions is already lagging behind C2C TLS without anyone actually having done any coding specifically toward it. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] C2C TLS
� wrote: > It's still in inbox (no XEP number): > http://xmpp.org/extensions/inbox/xtls.html False. That proposal was replaced by e2e-streams.html during list discussion and then published as XEP-0246: http://xmpp.org/extensions/xep-0246.html /psa
Re: [Standards] C2C TLS
On Mon, Nov 24, 2008 at 6:28 PM, Jonathan Schleifer <[EMAIL PROTECTED]> wrote: > As the discussion was already month ago now and it was said there will be > many clients at the end of the year (which we have now), I wanted to ask a > few things: > > 1.) What is the current state of the XEP? Is it even a XEP now? > 2.) How many clients implement it? If any, which? > 3.) If there are clients, do they use direct connections or use Jingle's > inband mode? > 4.) How was the SAS problem solved, if it was solved at all? If not, how > will it be solved? > 5.) How much work was it to implement it? Was it really "just 5 minutes of > work" as some said in the discussion before? > 6.) I predicted that it will still take a long time until C2C TLS will reach > the state ESessions now has. To me, it seems my prediction was right. > Anything I overlooked? > > -- > Jonathan It's still in inbox (no XEP number): http://xmpp.org/extensions/inbox/xtls.html Nÿco -- Nicolas Vérité (Nÿco) mailto:[EMAIL PROTECTED] Jabber ID : xmpp:[EMAIL PROTECTED] http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/ Adhérez à l'April : http://april.org/
[Standards] C2C TLS
As the discussion was already month ago now and it was said there will be many clients at the end of the year (which we have now), I wanted to ask a few things: 1.) What is the current state of the XEP? Is it even a XEP now? 2.) How many clients implement it? If any, which? 3.) If there are clients, do they use direct connections or use Jingle's inband mode? 4.) How was the SAS problem solved, if it was solved at all? If not, how will it be solved? 5.) How much work was it to implement it? Was it really "just 5 minutes of work" as some said in the discussion before? 6.) I predicted that it will still take a long time until C2C TLS will reach the state ESessions now has. To me, it seems my prediction was right. Anything I overlooked? -- Jonathan PGP.sig Description: This is a digitally signed message part
