On Mon, Dec 15, 2008 at 05:06:40PM +0000, Dave Cridland wrote: > On Mon Dec 15 15:46:16 2008, Peter Saint-Andre wrote: >> Recently I've been chatting with some folks off-list about end-to-end >> encryption. I've concluded that while it is possible to set up an >> end-to-end XML stream (XEP-0246) using Jingle (XEP-0247) and then >> upgrade that stream to encrypted using STARTTLS, we don't need that >> complexity because you already have a reliable connection to the other >> person: it's called XMPP (there's nothing to negotiate here and no >> need >> for SOCKS5 Bytestreams or ICE-TCP or any of that madness, just use >> XMPP >> for the transport). Therefore I suggest that we simplify e2e by using >> something very close to the original XTLS proposal to set up, use, and >> tear down and XTLS tunnel. I've outlined the protocol below. > > Okay, so the gain here is that we lose the Jingle negotiation, > effectively, and mandate something roughly equivalent to IBB. > > The downside is that we lose the ability to go direct from client to > client should we need to, and one reason for doing so would be for > efficiency. (There are others, independent of encryption).
As Dirk pointed out to me, if your client already supports link-local communications and generic Jingle negotation, then the end-to-end streams + STARTTLS stuff is easier because you just need to reuse existing code. How many such clients are there? > As I see it, there are two ways of approaching cryptography in XMPP: > > 1) We concentrate on getting an efficient, but basic, end-to-end > encryption protocol, which is easy to write and deploy. I'm firmly > convinced that the XEP-0247 approach is right here - it's allowing us to > get the transport right, the authentication right, and all using > existing crypto libraries as much as possible. I just don't see any real > likelyhood of clients not being able to use Jingle, given XEP-0234 etc. > In this scenario, the server isn't involved at all, and the scope for > cryptography is narrow. Simpler is better. We want encryption that is widely deployed. The harder we make it, the less likely it'll get into the clients of our users. > 2) We concentrate on getting a full-featured cryptography suite in > place, akin to S/MIME and ESS in email. In this scenario, the server may > well be involved, discarding bad packets, verifying signatures, and we'd > be aiming to support things like MUC and PubSub. This is not going to be > possible with TLS, we need to go to things like XML-dsig, and involve > triple-wrapping and other fun things. Non-starter. > I don't see which this proposal is addressing. Implementability and deployability. Perfect security doesn't do anyone any good if it isn't implemented and deployed.
