moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 18:22:24 -05:00
Code Issues Releases Wiki Activity

XEP-0384: update requirements

Browse Source
This commit is contained in:
sualko 2020-03-08 15:29:51 +01:00
parent 94c8f01e53
commit b0efdf0648
1 changed files with 21 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
xep-0384.xml
View File

@ -132,12 +132,27 @@
</section2> </section2>
</section1> </section1>
<section1 topic='Requirements' anchor='reqs'> <section1 topic='Requirements' anchor='reqs'>
<ul> <p>It is a result of XMPPs federated nature that a message may pass more than just one server. Therefore it is in the users interest to secure their communication from any intermediate host. End-to-end encryption is an efficient way to protect any data exchanged between sender and receiver against passive and active attackers such as servers and network nodes.</p>
<li>Provide forward secrecy</li> <p>OMEMO is an end-to-end encryption protocol based on the Double Ratchet specified in section <link url="#protocol-double_ratchet">Double Ratchet</link>. It provides the following guarantees under the threat model described in the next section:</p>
<li>Ensure chat messages can be deciphered by all (capable) clients of both parties</li> <ul>
<li>Be usable regardless of the participants' online statuses</li> <li>Confidentiality: Nobody else except sender and receiver is able to read the content of a message.</li>
<li>Provide a method to exchange auxilliary keying material. This could for example be used to secure encrypted file transfers.</li> <li>Perfect forward secrecy: A compromised long-term key does not compromise any previous message exchange.</li>
</ul> <li>Authentication: Every peer is able to authenticate the sender or receiver of a message, even if the details of the authentication process is out-of-scope for this specification.</li>
<li>Immutability: Every peer can ensure that a message was not changed by any intermediate node.</li>
<li>Plausible deniability: No participant can proof who created a specific message.</li>
<li>Asynchronicity: The usability of the protocol does not depend on the online status of any participant.</li>
</ul>
<p>Omemo is not intended to protect against the following use cases:</p>
<ul>
<li>An attacker has access to your device.</li>
<li>You lost your device and an attacker can read messages on your notification screen.</li>
<li>Any kind of denial-of-service attack.</li>
<li>tbc</li>
</ul>
<section2 topic='Threat Model' anchor='reqs-threat-model'>
<p>The OMEMO protocol protects against passive and active attackers which are able to read, modify, replay, delay and delete messages.</p>
<p>tbc</p>
</section2>
</section1> </section1>
<section1 topic='Glossary' anchor='glossary'> <section1 topic='Glossary' anchor='glossary'>
<section2 topic='General Terms' anchor='glossary-general'> <section2 topic='General Terms' anchor='glossary-general'>