Trust Pot Pourri

…shortcomings may be corrected without great difficulties using ingenuity and pragmatism…

Beyond the announcement, the proposal put together by Peter to strengthen “trust” in XMPP leaves me perplex. Under the surface, the document looks like a hastily assembled “pot pourri” of ideas that have been laying around XMPP for some time. The document certainly provides a good inventory of the XMPP technologies available today the area of security. But I believe many of the described shortcomings may be corrected without great difficulties, by just using a good dose of ingenuity and pragmatism.

• On the server side, I believe the major task would be convincing and educating many more Certificate Authorities to include the XMPP specifics into their server certificates. It is somewhat frustrating when you discuss with CAs and find out they do not conceive a server certificate outside a web server certificate, and a client certificate beyond a browser of mail client certificate.
• Support for SASL External and TLS already exist in many open source servers, beside the commercial ones. Again, I do not think we have a technical issue to implement secure links between federated XMPP server, but rather a matter of organization and agreement to use these SASL/TLS instead of dialbacks. The weight of legacy maybe?
• It maybe interesting to use a phased approach to reach the ultimate secure federation. In a first phase, SASL/TLS could be applied with web server certificates. Then later, when real XMPP certificates become widely available, they will be substituted. But, I believe supporting web certificates and the associated SASL checking is a must, as certain commercial CA may delay on purpose providing real XMPP certificates. We must also account for corporations or agencies that would use open source XMPP servers with certificates from these CAs.
• As discussed earlier, the number of end-to-end encryption implementations in XMPP is negligeable. I have described how the current "encrypted sessions" method, which is an XMPP implementation of the Off-the-Record messaging , goes beyond what is necessary to ensure a very good end-to-end encryption. In particular, I find the section related to “offline secure session” superfluous. It also introduce higher risks of key being compromised than a version dedicated to “online secure sessions” only. The JEP-0116 specification is an excellent starting point, but would greatly benefit from being simplified. After all, hasn’t XMPP always wanted to be associated with simplicity?
• I am convinced every XMPP server can become a repository for public keys. XMPP already allows a number of “personal” data to be published through Personal Eventing Protocol and other means. I do not really see what major difficulty there would be in extending these existing mechanisms for public keys publishing on the users’ home XMPP server. In my opinion, this would be an easy first step in creating the infrastructure required when stanzas signatures will be introduced.

I am more sceptical when the document describes “greater reliability of client-to-server and server-to-server connections” as a component of increasing an XMPP network’s trust. Reliability is important, but unless we do word plays, this is a matter of risk assessment, not a matter of trust. I am not convinced XMPP suffers in that area when compared to other public IM protocols. XMPP is certainly not suffering in the comparison to SIP/SIMPLE. In this protocol, un-delivered messages trigger an error. But the protocol does not provide a way to recover after an error. This is left to the implementation… Applications of XMPP beyond IM may certainly require and benefit from high reliability, but the examples given in the document fail to convince me this could greatly increase my trust in the XMPP network.

Similarly, I understand that administrators would benefit from a better monitoring of distributed XMPP servers. But, presenting this as an important factor to increase the trust of an XMPP network is probably exaggerated. In real life, when an application provides reliable services, end users will be attracted to use it. As soon as the service starts to degrade, they will move away. They will not need statistics about uptime, they know who is providing best services by word of mouth. Statistics are for administrators and marketers… Statistics on uptime do not re-enforce trust, they provide justifications. From a technology stand point, creating a binding of SNMP inside XMPP could present an interesting challenge. But I do not believe XMPP will quickly displace other network monitoring technologies. That said, if the “monitoring” only consist in performing authenticated login scripts against a list of servers, using a simple scenario for Tsung will provide a quick and easy answer… As the results can also be easily archived, we would only need a graphical interface to present the statistics.

…a trust reputation system will require more than a $5000 budget…

I have left the “reputation system” for the end. Obviously providing a “reputation system” is very fashionable these days… Believe me, that will require a little more than a $5000 budget. But it is late, and I’ll come back to this very interesting subject later.

Technorati Tags: XMPP, Jabber, Security, Trust, Antecipate