28
edits
Difference between revisions of "Sprints/2020 March Duesseldorf"
Jump to navigation
Jump to search
Sprints/2020 March Duesseldorf (view source)
Revision as of 15:53, 8 March 2020
, 15:53, 8 March 2020no edit summary
Vanitasvitae (talk | contribs) |
|||
| (28 intermediate revisions by 5 users not shown) | |||
| Line 6: | Line 6: | ||
=== Detailed TODO === | === Detailed TODO === | ||
* Come up with a (rough?) threat model | |||
** What does OMEMO protect against? | |||
** What are the limitations? | |||
** What can an attacker, eg. the server, do to hinder encrypted communication? | |||
* 12-byte IVs | * 12-byte IVs | ||
* Restructure PEP usage to use '''one''' device node with multiple items (One item for each device); Maintain index node? (so we have something to +notify on) | * Restructure PEP usage to use '''one''' device node with multiple items (One item for each device); Maintain index node? (so we have something to +notify on) | ||
* Describe usage of OMEMO in MUCs (MUST be non-anonymous, RECOMMENDED to be members-only, …) | * Describe usage of OMEMO in MUCs (MUST be non-anonymous, RECOMMENDED to be members-only, …) | ||
* PEP access model SHOULD (or RECOMMENDED) to be open (explain security consequences of that.) | * PEP access model SHOULD (or RECOMMENDED) to be open (explain security consequences of that.) | ||
* Link device IDs to the JID in stanzas to avoid the struggles implied by possible ID clashes | |||
* Specify user-defined labels for devices/OMEMO identities to simplify key management | |||
* Maybe a different way to generate device IDs that is guaranteed to create non-clashing IDs | |||
* Describe in more detail how devices get activated inactivated (message from a device, or PEP event, what ever comes last) | * Describe in more detail how devices get activated inactivated (message from a device, or PEP event, what ever comes last) | ||
* Ratchet Length Counter to determine stale devices. | * Describe how to opt-out of OMEMO again. | ||
* Ratchet Length Counter to determine stale devices. This includes automatic sending of empty messages (ping messages) to forward the ratchet. | |||
* Describe optional ''server please give me one pre-key+idenity key and then remove the pre key'' protocol | * Describe optional ''server please give me one pre-key+idenity key and then remove the pre key'' protocol | ||
* Shorter element names for elements that are often repeated | * Shorter element names for elements that are often repeated | ||
* Complete session by sending key transport message upon receiving a prekey message. | * Complete session by sending key transport message upon receiving a prekey message. | ||
* | * Stop using protobuf and build XML instead? (problem: need unique serialization method) | ||
** XMLENC? | |||
* Describe behaviour of recovering from broken session. | |||
* Clear up the one-time pre key thing | |||
* SCE | |||
** The security and business rules of 0420 are confusing and don’t communicate the potential impacts very well. I think those need to be rewritten before start to implement it and potentially end up in dangerous situations. | |||
* Do not silently discard '''any''' messages. | |||
* Require servers to persist PEP nodes | |||
* <pre>urn:xmpp:omemo:1</pre> | |||
=== Responsibilities === | === Responsibilities === | ||
* '''Daniel:''' <del>PEP</del>, custom PreKey upload and download protocol, <del>labels</del>, <del>group chats</del>, <del>fix 'list' -> 'devices'</del>, <del>create '<keys jid="foo">' wrapper</del>, <del>recovery from broken sessions</del>. | |||
* '''Tim & Andy:''' <del>Figure out what we need to redefine; and redefine it. OTPK behaviour cleanup.</del> | |||
* '''Paul:''' Mention threat model in Requirements (for example Trust Management is out of scope), SCE integration | |||
* '''Klaus & Marvin:''' <del>active, inactive</del>, <del>staleness</del>, <del>opt-out</del> | |||
=== Process === | === Process === | ||
Since multiple people are going to work on multiple parts of the XEP simultaneously we probably need a git and commit early and often. Other and better ideas welcome. | Since multiple people are going to work on multiple parts of the XEP simultaneously we probably need a git and commit early and often. Other and better ideas welcome. | ||
Idea by Syndace: | |||
I'm hosting a ShareLaTeX instance, which allows you to collaboratively work on the same LaTeX document at the same time, including a history of changes etc. | |||
We could write the XEP there and later port it into the required XML structure. | |||
As an alternative I also host a HackMD instance, which is the same thing but for Markdown documents. | |||
HackMD: https://hackmd.syndace.com/1gH8-kmpTEyagUfqDYOZyQ | |||
=== Resources === | |||
* [https://xmpp.org/extensions/xep-0384.html Current OMEMO Specification] | |||
* [https://signal.org/docs/specifications/doubleratchet/ Double Ratchet Specification] | |||
* [https://signal.org/docs/specifications/x3dh/ Extended Triple Diffie Helmann Handshake (X3DH)] | |||
* [https://signal.org/docs/specifications/xeddsa/ XEdDSA Signature Scheme] | |||
== Dates and Times == | == Dates and Times == | ||