1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-12 02:42:16 -05:00

Remove remnant TODOs and add acknowledgements

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

View File

@ -1,6 +1,6 @@
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [ <!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY secret "&lt;secret/&gt;"> <!ENTITY security "&lt;security/&gt;">
<!ENTITY % ents SYSTEM 'xep.ent'> <!ENTITY % ents SYSTEM 'xep.ent'>
%ents; %ents;
]> ]>
@ -16,7 +16,7 @@
<sig>Standards</sig> <sig>Standards</sig>
<approver>Council</approver> <approver>Council</approver>
<dependencies> <dependencies>
<spec>XEP-0234</spec> <spec>XEP-0166</spec>
</dependencies> </dependencies>
<supersedes/> <supersedes/>
<supersededby/> <supersededby/>
@ -37,6 +37,17 @@
<email>vanitasvitae@riseup.net</email> <email>vanitasvitae@riseup.net</email>
<jid>vanitasvitae@jabberhead.tk</jid> <jid>vanitasvitae@jabberhead.tk</jid>
</author> </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> <revision>
<version>0.1</version> <version>0.1</version>
<date>2017-09-27</date> <date>2017-09-27</date>
@ -74,7 +85,7 @@
<tr> <tr>
<td>Transport Secret</td> <td>Transport Secret</td>
<td>TS</td> <td>TS</td>
<td>Serialization of TK and TI.</td> <td>Tuple formed of TK and TI.</td>
</tr> </tr>
<tr> <tr>
<td>Envelope Element</td> <td>Envelope Element</td>
@ -85,16 +96,18 @@
</section1> </section1>
<section1 topic='Principle' anchor='principle'> <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>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>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 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>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;
<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> 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>
<section1 topic='Encrypted Jingle File Transfer using JET' anchor='jft'> <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>&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'> <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> <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[ <example caption="Romeo initiates an encrypted file offer"><![CDATA[
<iq from='romeo@montague.example/dr4hcr0st3lup4c' <iq from='romeo@montague.example/dr4hcr0st3lup4c'
@ -243,24 +256,20 @@
<th>Type</th> <th>Type</th>
<th>Length (bits)</th> <th>Length (bits)</th>
<th>Parameters</th> <th>Parameters</th>
<th>Serialization</th>
</tr> </tr>
<tr> <tr>
<td>urn:xmpp:ciphers:aes-128-gcm-nopadding:0</td> <td>urn:xmpp:ciphers:aes-128-gcm-nopadding:0</td>
<td>AES</td> <td>AES</td>
<td>128</td> <td>Key: 128, IV: 96</td>
<td>GCM/NoPadding</td> <td>GCM/NoPadding</td>
<td>128BitKey::96BitIV</td>
</tr> </tr>
<tr> <tr>
<td>urn:xmpp:ciphers:aes-256-gcm-nopadding:0</td> <td>urn:xmpp:ciphers:aes-256-gcm-nopadding:0</td>
<td>AES</td> <td>AES</td>
<td>256</td> <td>Key: 256, IV: 96</td>
<td>GCM/NoPadding</td> <td>GCM/NoPadding</td>
<td>256BitKey::96BitIV</td>
</tr> </tr>
</table> </table>
<p>The column 'serialization' describes, how the key and iv are serialized. "::" means plain concatenation of byte arrays.</p>
</section1> </section1>
<section1 topic='Determining Support' anchor='support'> <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> <p>The responder MUST check, whether the envelope element belongs to the initiator to prevent MitM attacks</p>
</section1> </section1>
<section1 topic='Open Questions'> <section1 topic='Acknowledgements' anchor='acknowledgements'>
<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> <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>
<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> </section1>
</xep> </xep>