Difference between revisions of "Sprints/2020 March Duesseldorf"

From XMPP WIKI
Jump to navigation Jump to search
(→‎Contact: Update room info)
 
(34 intermediate revisions by 5 users not shown)
Line 3: Line 3:
== Goal ==
== Goal ==
This Sprint is focussed on creating the next iteration of the OMEMO XEP.
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
* <pre>urn:xmpp:omemo:1</pre>
=== 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 ===
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 ==
Line 10: Line 67:
== Contact ==
== Contact ==


Join us in the chatroom: xmpp:xmpp-sprint@chat.cluxia.eu?join
Join us in the chatroom: [xmpp:sprints@joinjabber.org?join sprints@joinjabber.org] ([https://chat.joinjabber.org/#/guest?join=sprints web])
 
Also accessible via https://chat.cluxia.eu/anon/#xmpp-sprint


== Venue ==
== Venue ==
Line 25: Line 80:
== Accommodation ==
== Accommodation ==


* TBD
Wyndham Garden Düsseldorf City Centre Königsallee


== Attendees ==
== Attendees ==
Line 56: Line 111:
| Marvin W.
| Marvin W.
| [[User:Larma|larma]]
| [[User:Larma|larma]]
| <nowiki>urn:xmpp:omemo:1</nowiki>
| no
|
|
| no
|-
| Klaus
| klaus
|
| yes
|
|
|}
|}

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

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
Retrieved from "https://wiki.xmpp.org/web/index.php?title=Sprints/2020_March_Duesseldorf&oldid=14605"