From 7db1c6b1dcd96b3d9e211d96761786423126e108 Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Mon, 1 Apr 2019 18:09:02 +0200 Subject: [PATCH] Proto-XEP: Improving Baseline Security in XMPP --- inbox/baseline-security.xml | 121 ++++++++++++++++++++++++++++++++++++ 1 file changed, 121 insertions(+) create mode 100644 inbox/baseline-security.xml diff --git a/inbox/baseline-security.xml b/inbox/baseline-security.xml new file mode 100644 index 00000000..6fa1bd11 --- /dev/null +++ b/inbox/baseline-security.xml @@ -0,0 +1,121 @@ + + + %ents; + ]> + + +
+ Improving Baseline Security in XMPP + This document describes a number of concrete and effective mechanisms for offering significant security enhancements to XMPP, with broad applicability. + &LEGALNOTICE; + XXXX + ProtoXEP + Humorous + Standards + + XMPP Core + + + + security-theatre + + Chris + Davidland + chris.davidland@crap-security.example + chris.davidland@crap-security.example + + + Lucas + George + lucas.george@shiteam.example + lucas.george@shiteam.example + + + 0.0.1 + 2019-04-01 + cd/lg + +
    +
  • Initial Revision
    • +
+ + +
+ + +

During the early part of 2019, the Security High Intelligence Team at the Centre for Research and Promotion of Security conducted a detailed survey of existing security practises within XMPP deployments, and observed a number of areas where improvements could be made.

+

After a period of intensive development, we present our findings, along with concrete, proven mechanisms for dramatically uplifting security within XMPP software and deployments, to the community.

+ + + +

As general aims, we wish to ensure:

+
    +
  • All communication should occur over properly encrypted links.
    • +
  • Data should be encrypted using industry-standard ciphers across both links and end-to-end.
    • +
+ + + + +

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:

+ + + Hey, Lucas! + +]]> + +

The following shows a correctly encrypted stanza:

+ + + Hey, Lucas! + +]]> + +

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

+ + + Hey, Lucas! + +]]> + +

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.

+ + + Hey, Lucas! + +]]> + + + + +

The entirely of this document is concerned with security.

+ + + +

If adopted into the Standards Track, the URN "urn:xmpps" is required to be registered with &IANA;.

+ + + +

If adopted into the Standards Track, every protocol's namespace is required to be changed, and this should be reflected in the registry.

+ + + +

The authors wish to acknowledge the great efforts being made elsewhere to improve the security of XMPP, and hope this specification complements their efforts suitably.

+ + +