Sprints/2020 March Duesseldorf

Jump to navigation Jump to search


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 any messages.
  • Require servers to persist PEP nodes
  • urn:xmpp:omemo:1


  • Daniel: PEP, custom PreKey upload and download protocol, labels, group chats, fix 'list' -> 'devices', create '<keys jid="foo">' wrapper
  • Tim & Andy: Figure out what we need to redefine; and redefine it.
  • Paul: Mention threat model in Requirements (for example Trust Management is out of scope), SCE integration
  • Klaus & Marvin: active, inactive, staleness, opt-out


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


Dates and Times

Saturday, March 7th - Sunday, March 8th 2020


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

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


Hüttenstraße 25
40215 Düsseldorf

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


Wyndham Garden Düsseldorf City Centre Königsallee


Name (optional) Nickname Sprint project(s) booked comments
Paul Schaub vanitasvitae Revolutionize E2EE yes
Tim Henkes Syndace guess what! yep
Daniel Gultsch iNPUTmice TWOMEMO yes
Marvin W. larma urn:xmpp:omemo:1 no
Klaus klaus yes