Jonathan Schleifer wrote:
Am 20.08.2008 um 19:43 schrieb Peter Saint-Andre:That is a very big if.What would be the problem with contacting Google?
I posted that to this list. Did you not read what I said?
TLS has undergone many many years of cryptanalysis, hacking attempts, and incremental improvement. One crytpanalysis does not make a secure protocol.Yeah, but that would be a start. Stating it is not several years old and thus can't be good is very, very conservative. We could also say Jabber can't be good because it's not as old, tested and used as IRC…
Non sequitur.
Excuse me, but we already "play around" with TLS libs -- unless you hadn't noticed, that's how we do channel encryption right now, and every Jabber client under the sun already supports it. It's very attractive to use the same underlying technology for encryption of c2s, s2s, and e2e streams (whether the latter are link-local or happen over TCP, XMPP, or whatever).I was talking about c2c here.
And that makes a big difference how?
Jonathan, you don't seem to be listening very well. I suggest that you stop beating the ESessions drum for just a little while and take a bit of a break to reflect on ekr's posts, read the relevant specs, and think seriously about how we could have e2e pretty much *today* in all clients using TLS-over-XMPP, reuse *any* existing TLS library, and incrementally add new features (e.g., SAS) to TLS if we need them (thus benefiting the entire Internet community).Let me summarize: * There is no client using it.
There is one client using ESessions, so ESessions has *infinitely* more implementations. That must be good.
As to TLS encryption of XML streams, Dirk has support for it in his Python code and gloox has some preliminary support (but that was experimental, back when we were first talking about "XTLS"). However, I grant that none of that code is deployed yet.
* There is not even a XEP for it yet.
Sure there is. See XEP-0246 and XEP-0247.
* Clients would need to be able to handle a second stream, that is inside another stream.* Some clients may need a lot of changes for that.
And they won't need a lot of changes for ESessions? Please.
So, how could we have that today? Today, we already HAVE ESessions. :)
You do in Gajim. I don't in Psi, Adium, Exodus, Trillian, Pidgin, or any other codebase. But all of those codebases support TLS and most of them are adding Jingle support, thus enabling negotiation of end-to-end streams, then you just upgrade the stream via STARTTLS. That seems like a lot less work than building ESessions support into all the clients (and no it's not as easy as dropping in a library, because you know that's not how Gajim functions today -- Brendan's C lib is just a promise, not a reality).
Or maybe we just all need to use Gajim?
I assume it's at least half a year until we have the FIRST client to implement it.
Shall we bet on that?
And then we will the the real world problems that you don't think of in theory, whereas ESessions is already in use in the real world.
And deployment of TLS is merely theoretical? Yes it is for end-to-end XML streams (so far), but it's not for client-to-server streams or server-to-server streams, and extending that model to e2e streams seems quite reasonable.
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
