Difference between revisions of "Sprints/2020 March Duesseldorf"

Jump to navigation Jump to search
→‎Contact: Update room info
(→‎Contact: Update room info)
 
(23 intermediate revisions by 5 users not shown)
Line 6: Line 6:
=== Detailed TODO ===
=== 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
* 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)
* 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)
Line 20: Line 24:
* Complete session by sending key transport message upon receiving a prekey message.
* Complete session by sending key transport message upon receiving a prekey message.
* Stop using protobuf and build XML instead? (problem: need unique serialization method)
* Stop using protobuf and build XML instead? (problem: need unique serialization method)
** XMLENC?
* Describe behaviour of recovering from broken session.
* Describe behaviour of recovering from broken session.
* Clear up the one-time pre key thing
* Clear up the one-time pre key thing
* SCE
* SCE
* Talk about possible interactions with MattJ's ideas, including
** 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.
** a mechanism to transfer data from one device to another during setup (e.g. using a QR-Code)
* Do not silently discard '''any''' messages.
** a list of all devices a JID has
* Require servers to persist PEP nodes
* <pre>urn:xmpp:omemo:1</pre>


=== Responsibilities ===
=== Responsibilities ===


Who does what. TBD
* '''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 39: 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 46: 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 ==
416

edits

Navigation menu