To take a few steps back and give an overview of the issue at hand for
newcomers:
1) XMPP often uses (and the XMPP foundation strongly recommends) TLS
between client and server. Within server, the messages are in the
clear. Thus, it gives no secure channel between two end points. Also,
between two endpoints connecting to servers with TLS, there could be a
non-TLS connection server-to-server (S2S). So even with a TLS
connection between a client and a server, we can't assume that we have
security end-to-end. We need to set that up. This discussion is about
how to set up confidential and authenticated client-to-client
sessions, based on the this scenario.
2) XMPP has SASL authentication
3) Clients may be behind NAT, so even a client-to-client direct
session may need help from a server (proxy). This will have to be
considered.
4) Users are lazy. PGP and S/MIME hasn't been deployed much, even
though PGP has many strong followers in the technichal community. We
need a solution that users will use.
5) Not all clients are human. We need solutions, but maybe not one
solution, for
- human clients on some sort of computer
- bots with a delegation from a human (set-top-boxes)
- applications (XMPP is used as middleware)
6) Innovating new communication security frameworks is hard, requires
maintenance and costs a lot of money to test (as indicated by PSA).
Let's try to find existing solutions.
7) There are several security solutions defined in XMPP standards and
XEPs - using S/MIME, PGP, TLS and other solutions. We need to write a
"best practise document" that gives an overview of recommended
solutions for developers, also for system administrators.
I must have missed some bullets - please add, detract, rephrase :-)
/O
