moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-03 06:22:16 -05:00
Code Issues Releases Wiki Activity

Remove remnant TODOs and add acknowledgements

Browse Source
This commit is contained in:
vanitasvitae 2017-10-09 15:36:23 +02:00
parent 83624c9f94
commit 02b04c80bd
No known key found for this signature in database
GPG Key ID: 62BEE9264BF17311
1 changed files with 26 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
xep-0391.xml
View File

@ -1,6 +1,6 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY secret "&lt;secret/&gt;">
<!ENTITY security "&lt;security/&gt;">
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
@ -16,7 +16,7 @@
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XEP-0234</spec>
<spec>XEP-0166</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -37,6 +37,17 @@
<email>vanitasvitae@riseup.net</email>
<jid>vanitasvitae@jabberhead.tk</jid>
</author>
<revision>
<version>0.1.1</version>
<date>2017-10-09</date>
<initials>vv</initials>
<remark>
<p>Remove remnant TODO section</p>
<p>Remove mentionings about key seralization (handled by extensions)</p>
<p>Fix typos</p>
<p>Add acknowledgements</p>
</remark>
</revision>
<revision>
<version>0.1</version>
<date>2017-09-27</date>
@ -74,7 +85,7 @@
<tr>
<td>Transport Secret</td>
<td>TS</td>
<td>Serialization of TK and TI.</td>
<td>Tuple formed of TK and TI.</td>
</tr>
<tr>
<td>Envelope Element</td>
@ -85,16 +96,18 @@
</section1>
<section1 topic='Principle' anchor='principle'>
<p>Lets assume Romeo wants to initiate an encrypted Jingle session with Juliet. Prior to the Jingle session initiation, an already existing, established and (ideally) authenticated end-to-end encryption session between Romeo and Juliet MUST exist. This session is needed to transfer the Transport Secret from Romeo to Juliet.</p>
<p>When this precondition is met, Romeo initially generates a transport key (TK) and associated initialization vector (IV). These will later be used by the sender to encrypt, and respectively by the recipient to decrypt data that is exchanged. This protocol defines a set of usable <link url='#ciphers'>ciphers</link> from which Romeo might choose. TK and IV are serialized to create the transport secret (TS).</p>
<p>Next Romeo uses her established encryption session with Juliet to encrypt TS. The resulting envelope element (EE) will be part of the Jingle session initiation as child of the JET &secret; element.</p>
<p>When Juliet receives Romeos session request, she decrypts EE to retrieve TS, from which she can deserialize TK and IV. Now she and Romeo can go on with the session negotiation. Once the session is established, data can be encrypted and exchanged. Both parties MUST keep a copy of TS in cache until the Jingle session is ended.</p>
<p>When this precondition is met, Romeo initially generates a transport key (TK) and associated initialization vector (IV). These will later be used by the sender to encrypt, and respectively by the recipient to decrypt data that is exchanged. This protocol defines a set of usable <link url='#ciphers'>ciphers</link> from which Romeo might choose. TK and IV together form the transport secret (TS).</p>
<p>Next Romeo uses his established encryption session with Juliet to encrypt TS. The resulting envelope element (EE) will be part of the Jingle session initiation as child of the JET &security;
element.</p>
<p>When Juliet receives Romeos session request, she decrypts EE to retrieve TS, from which she can obtain TK and IV. Now she and Romeo can go on with the session negotiation. Once the session is
established, data can be encrypted and exchanged. Both parties MUST keep a copy of TS in cache until the Jingle session is ended.</p>
</section1>
<section1 topic='Encrypted Jingle File Transfer using JET' anchor='jft'>
<p>&xep0234; has the disadvantage, that transmitted files are not encrypted (aside from regular TLS transport encryption), which means that intermediate nodes like XMPP/proxy server(s) have access to the transferred data. Considering that end-to-end encryption becomes more and more important to protect free speech and personal expression, this is a major flaw that needs to be addressed.</p>
<p>In order to initiate an encrypted file transfer, the initiator includes a JET &secret; in the Jingle file transfer request.</p>
<p>In order to initiate an encrypted file transfer, the initiator includes a JET &security; element in the Jingle file transfer request.</p>
<section2 topic='File Offer'>
<p>In this scenario Romeo wants to send an encrypted text file over to Juliet. First, he generates a fresh AES-256 transport key and IV. TK and IV are serialized into TS which is then encrypted using Romeos end-to-end-encryption session with Juliet.</p>
<p>In this scenario Romeo wants to send an encrypted text file over to Juliet. First, he generates a fresh AES-256 transport key and IV. In this case TK and IV are serialized into TS which is then encrypted using Romeos end-to-end-encryption session with Juliet.</p>
<p>The resulting envelope element (EE) is sent as part of the security element along with the rest of the jingle stanza over to Juliet.</p>
<example caption="Romeo initiates an encrypted file offer"><![CDATA[
<iq from='romeo@montague.example/dr4hcr0st3lup4c'
@ -243,24 +256,20 @@
<th>Type</th>
<th>Length (bits)</th>
<th>Parameters</th>
<th>Serialization</th>
</tr>
<tr>
<td>urn:xmpp:ciphers:aes-128-gcm-nopadding:0</td>
<td>AES</td>
<td>128</td>
<td>Key: 128, IV: 96</td>
<td>GCM/NoPadding</td>
<td>128BitKey::96BitIV</td>
</tr>
<tr>
<td>urn:xmpp:ciphers:aes-256-gcm-nopadding:0</td>
<td>AES</td>
<td>256</td>
<td>Key: 256, IV: 96</td>
<td>GCM/NoPadding</td>
<td>256BitKey::96BitIV</td>
</tr>
</table>
<p>The column 'serialization' describes, how the key and iv are serialized. "::" means plain concatenation of byte arrays.</p>
</section1>
<section1 topic='Determining Support' anchor='support'>
@ -292,17 +301,8 @@
<p>The responder MUST check, whether the envelope element belongs to the initiator to prevent MitM attacks</p>
</section1>
<section1 topic='Open Questions'>
<p>This is only a rough draft and there is still a ton of questions left to be answered. Here is a small non-exhaustive list of things I can think of:</p>
<ul>
<li>How exactly are interrupted transfers resumed? How (long) are keys/IVs cached?</li>
<li>May it be desirable to split data into chunks?</li>
<li>Please add to this list :)</li>
</ul>
</section1>
<section1 topic='TODO'>
<ul>
<li>Split up the protocol into encryption method specific sub protocols (jet-omemo, jet-ox...)</li>
</ul>
<section1 topic='Acknowledgements' anchor='acknowledgements'>
<p>Big thanks to Florian Schmaus for mentoring my Google Summer of Code project, which resulted in this protocol. Also thanks to Andrey Gursky, Daniel Gultsch, Dave Cridland, Goffi, Jonas Wielicki and Sam Whited for their input and feedback.</p>
</section1>
</xep>