[Security] client-to-client security :: Summary and todo's
pavlix at pavlix.net
Sat Aug 23 10:01:18 CDT 2008
On Sat, 23 Aug 2008 16:03:47 +0200
Dirk Meyer <dmeyer at tzi.de> wrote:
> Jonathan Schleifer wrote:
> > Well, I think we shouldn't use Jingle at all for transfering
> > encrypted messages. It just adds too much complexity IMO and I
> > don't always want a direct connection. Of course, I could use IBB,
> > but do we really need Jingle to transfer it in our XMPP stream? The
> > answer is clearly no.
> YOUR answer is clearly no, my answer is YES
My answer is clearly YES too.
Jingle is not as much complexity as the crypto stuff and there is no
apparent reason to have e2e sessions over login sessions instead of
direct sessions when not necessary.
> > Plus, server admins might block IBB to save traffic, because they
> > don't want for example Jingle Video traffic transfered in-band and
> > thus disable Jingle IBB.
This is the problem of the admins.
> If an admin blocks IBB because a user could use it transfer a video,
> he would also block encrypted messages because you could hide an IBB
> with the video in it.
> The solution here is to limit the IBB rate to let's say
> 100kBit/s. This is no fun for videos. And IIRC server already do
I second this.
> > I'm therefore for not using Jingle as a transport layer, but have
> > some transport layer for c2c encryption only.
If Jingle is not good enough, you could improve/replace it by something
else. If it is, why not use it?
> IF you can give me an example how to verify that you can not open an
> IBB in an encrypted stream I would agree. But since we have
> IP-over-DNS and other funny things it would take me about 30 minutes
> to code IP over encrypted c2c. I already have some code using SOCKS
> over XMPP messages, I only need to add encryption.
Jabber & Mail: pavlix(at)pavlix.net
More information about the Security