XMPP has a great many XML namespaces (See &w3xmlnamespaces;) which are used as the mechanism by which the core protocol has been extended. Many of the older namespaces are, however, denoted by URIs with an "http" scheme (See &rfc2616; et passim). Clearly these are insecure, as the namespace would be served in the clear, and could easily be subverted by a malicious third party. Therefore, we propose that these XML namespaces are replaced with upgraded ones running over TLS, by using the "https" scheme (See &rfc2818;).

While somewhat disruptive to existing deployments, the clear security benefits outweigh any such concerns.

Newer extensions have used URNs within the "urn:xmpp" namespace. Pursuant to &xep0368;, the previously legacy "xmpps" would offer immediate security benefits to such namespaces. Traditional "urn:xmpp" namespaces, while often capable of TLS transports, can only offer such security in a feature advertisement, and as such a naive namespace client can be the target of a downgrade attack.

There is a clear temptation to suggest we should concentrate on ensuring namespace clients are simply more security aware, but reviving XMPPS, just as &xep0368; has done, offers a straightforward mechanism for promoting a step increase in security.

A pressing limitation of existing deployed end-to-end encryption techniques is a lack of full stanza encryption. While &xep0374; does encrypt much of the stanza, although not all, &xep0384; encrypts only the <body/> element's contents.

Clearly neither is sufficient for high security applications, and therefore we propose encrypting the stanza heavily. A detailed survey of supported encryption algorithms suggests that Double ROT-13 is widely supported and available on all platforms. This cipher has the signficant benefit that encryption is entirely transparent, providing excellent interoperability benefits with older implementations that may not have been upgraded.

We therefore recommend that all stanzas on the wire are fully encrypted with Double ROT-13. Given the following stanza:

The following shows a correctly encrypted stanza:

The following, however, has only encrypted the body text - this is NOT valid encryption, and an attacker can easily read the remaining metadata!

In the following example, while the entire contents of the stanza have been correctly encrypted, the outer stanza tag itself remains in the clear. An attacker could, therefore, trivially discover key metadata such as the sender, type, and id of the message.