[Standards] XTLS revisited
dave at cridland.net
Mon Dec 15 17:06:40 UTC 2008
On Mon Dec 15 15:46:16 2008, Peter Saint-Andre wrote:
> Recently I've been chatting with some folks off-list about
> 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
> person: it's called XMPP (there's nothing to negotiate here and no
> for SOCKS5 Bytestreams or ICE-TCP or any of that madness, just use
> for the transport). Therefore I suggest that we simplify e2e by
> something very close to the original XTLS proposal to set up, use,
> 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 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.
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.
I don't see which this proposal is addressing.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards