-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathxep-0419.xml
128 lines (121 loc) · 7.56 KB
/
xep-0419.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Improving Baseline Security in XMPP</title>
<abstract>This document describes a number of concrete and effective mechanisms for offering significant security enhancements to XMPP, with broad applicability.</abstract>
&LEGALNOTICE;
<number>0419</number>
<status>Active</status>
<type>Humorous</type>
<sig>Standards</sig>
<approver>Editor</approver>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>security-theatre</shortname>
<author>
<firstname>Chris</firstname>
<surname>Davidland</surname>
<email>chris.davidland@crap-security.example</email>
<jid>chris.davidland@crap-security.example</jid>
</author>
<author>
<firstname>Lucas</firstname>
<surname>George</surname>
<email>lucas.george@shiteam.example</email>
<jid>lucas.george@shiteam.example</jid>
</author>
<revision>
<version>1.0.0</version>
<date>2019-04-01</date>
<initials>XEP Editor (jsc)</initials>
<remark>Acceptance as XEP-0419; Light editing.</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2019-04-01</date>
<initials>cd/lg</initials>
<remark>
<ul>
<li>Initial Revision</li>
</ul>
</remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>During the early part of 2019, the Security High Intelligence Team (SHITeam) at the Centre for Research and Promotion of Security (CRaP Security) conducted a detailed survey of existing security practises within XMPP deployments, and observed a number of areas where improvements could be made.</p>
<p>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.</p>
</section1>
<section1 topic="Requirements" anchor="reqs">
<p>As general aims, we wish to ensure:</p>
<ul>
<li>All communication should occur over properly encrypted links.</li>
<li>Data should be encrypted using industry-standard ciphers across both links and end-to-end.</li>
</ul>
</section1>
<section1 topic='Particulars'>
<section2 topic="Legacy Namespaces">
<p>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;).</p>
<p>While somewhat disruptive to existing deployments, the clear security benefits outweigh any such concerns.</p>
</section2>
<section2 topic="New-style Namespaces">
<p>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.</p>
<p>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.</p>
</section2>
<section2 topic="Stanza Encryption">
<p>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.</p>
<p>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.</p>
<p>We therefore recommend that all stanzas on the wire are fully encrypted with Double ROT-13. Given the following stanza:</p>
<example caption="Original unencrypted stanza"><![CDATA[
<message from='chris.davidland@crap-security.example' to='lucas.george@shiteam.example' type='chat' id='12345'>
<some-metadata xmlns='urn:xmpps:example:metadata'/>
<body>Hey, Lucas!</body>
</message>
]]>
</example>
<p>The following shows a correctly encrypted stanza:</p>
<example caption="Stanza with encrypted meta-data and payload"><![CDATA[
<message from='chris.davidland@crap-security.example' to='lucas.george@shiteam.example' type='chat' id='12345'>
<some-metadata xmlns='urn:xmpps:example:metadata'/>
<body>Hey, Lucas!</body>
</message>
]]>
</example>
<p>The following, however, has only encrypted the body text - this is NOT valid encryption, and an attacker can easily read the remaining metadata!</p>
<example caption="Stanza with encrypted body payload"><![CDATA[
<message from='chris.davidland@crap-security.example' to='lucas.george@shiteam.example' type='chat' id='12345'>
<some-metadata xmlns='urn:xmpps:example:metadata'/>
<body>Hey, Lucas!</body>
</message>
]]>
</example>
<p>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.</p>
<example caption="Stanza with encrypted elements"><![CDATA[
<message from='chris.davidland@crap-security.example' to='lucas.george@shiteam.example' type='chat' id='12345'>
<some-metadata xmlns='urn:xmpps:example:metadata'/>
<body>Hey, Lucas!</body>
</message>
]]>
</example>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>The entirely of this document is concerned with security.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>If adopted into the Standards Track, the URN "urn:xmpps" is required to be registered with &IANA;. </p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>If adopted into the Standards Track, every protocol's namespace is required to be changed, and this should be reflected in the registry.</p>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>The authors wish to acknowledge the great efforts being made elsewhere to improve the security of XMPP, and hope this specification complements those efforts suitably.</p>
</section1>
</xep>