Sprints/2020 March Duesseldorf

Goal
This Sprint is focussed on creating the next iteration of the OMEMO XEP.

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
 * 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, …)
 * 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 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
 * Shorter element names for elements that are often repeated
 * 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.
 * Talk about possible interactions with MattJ's ideas, including
 * a mechanism to transfer data from one device to another during setup (e.g. using a QR-Code)
 * a list of all devices a JID has
 * Do not silently discard broken messages.

Responsibilities
Who does what. TBD

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.

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

 * Current OMEMO Specification
 * Double Ratchet Specification
 * Extended Triple Diffie Helmann Handshake (X3DH)
 * XEdDSA Signature Scheme

Dates and Times
Saturday, March 7th - Sunday, March 8th 2020

Contact
Join us in the chatroom: xmpp:xmpp-sprint@chat.cluxia.eu?join

Also accessible via https://chat.cluxia.eu/anon/#xmpp-sprint

Venue
Chaosdorf Hüttenstraße 25 40215 Düsseldorf

http://www.openstreetmap.org/node/1213625556 https://wiki.chaosdorf.de/XMPP_OMEMO_Sprint_2020

Accommodation
Wyndham Garden Düsseldorf City Centre Königsallee