Difference between revisions of "Sprints/2020 March Duesseldorf"
Jump to navigation
Jump to search
Vanitasvitae (talk | contribs) |
(→Contact: Update room info) |
||
| (19 intermediate revisions by 5 users not shown) | |||
| Line 6: | Line 6: | ||
=== Detailed TODO === | === Detailed TODO === | ||
* Come up with a (rough?) | * Come up with a (rough?) threat model | ||
** What does OMEMO protect against? | ** What does OMEMO protect against? | ||
** What are the limitations? | ** What are the limitations? | ||
| Line 28: | Line 28: | ||
* Clear up the one-time pre key thing | * Clear up the one-time pre key thing | ||
* SCE | * 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. | ** 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 === | ||
| Line 46: | Line 51: | ||
We could write the XEP there and later port it into the required XML structure. | 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. | 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 == | ||
| Line 53: | Line 67: | ||
== Contact == | == Contact == | ||
Join us in the chatroom: xmpp: | Join us in the chatroom: [xmpp:sprints@joinjabber.org?join sprints@joinjabber.org] ([https://chat.joinjabber.org/#/guest?join=sprints web]) | ||
== Venue == | == Venue == | ||
Latest revision as of 09:59, 11 April 2023
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.
- Do not silently discard any messages.
- Require servers to persist PEP nodes
urn:xmpp:omemo:1
Responsibilities
- Daniel:
PEP, custom PreKey upload and download protocol,labels,group chats,fix 'list' -> 'devices',create '<keys jid="foo">' wrapper,recovery from broken sessions.
- Tim & Andy:
Figure out what we need to redefine; and redefine it. OTPK behaviour cleanup.
- 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: sprints@joinjabber.org (web)
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 |