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 any messages.

Responsibilities

Daniel: PEP, custom PreKey upload and download protocol, labels, group chats

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

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

Attendees

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