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 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.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
