Re: [Standards] XEP-0384: OMEMO Encryption - Feedbacks and proposals
On 09/01/2017 11:24, Dave Cridland wrote: On 6 January 2017 at 08:36, Jaussoin Timothée wrote: Hi, I'm currently in the process of implementing end-to-end encryption in my project. I naturally had a look at the freshly published XEP-0384: OMEMO Encryption and I have some feedbacks to give on it. 1. Usage of Olm After some talks with members of the community it seems that this protocol was selected for two reasons : it was quite well documented (for the crypto part) and didn't have legal concerns. I was quite disappointed by the library provided by Matrix for this protocol (https://matrix.org/git/olm/about/). The Javascript version of it needs to be generated from the C/C++ code using a tool called emscripten (https://kripken.github.io/emscripten-site/index.html) that is actually not packaged on Debian (only a very old version from 2014 is available for sid) and seems to rely on a forked version of LLVM. Also I couldn't find any clear/simple documentation that could help me with the integration of the library in a project (like we can have for libsignal here https://github.com/WhisperSystems/libsignal-protocol-javascript). Feel free to write a better library. Axolotl/Signal doesn't have this option without someone setting lawyers on you. That's why we had to switch away from it. 2. XMPP environment integration I also had some concerns regarding the integration and coherence with the current XMPP XEPs and syntax. 2.1. OMEMO nodes name syntax Having node names that use the camelCase syntax is not something that I've encountered since the vCard tag in XEP-0054: vcard-temp. I'd prefer to stick with the kebab-case (lower-case-dash-separated syntax) like we have in the rest of the XEPs. What do you think? Cosmetic, so this is not a hill to die upon, but all things being equal I'd prefer consistency. 2.2. Current usage of PEP This feedback is related to the previous message that I sent on this ML regarding XEP-0163: Personal Eventing Protocol a couple of days ago (see https://mail.jabber.org/pipermail/standards/2017-January/031811.html). The current usage of PEP is, for me, not optimal and overly complex. Having a list of devices that needs to be synchronized on a node and their related bundles on some others brings race-conditions issues (actually mentioned in the Example 2.) and forces the clients to implement extra checks to ensure that everything is properly synchronized. Proposal : I propose to simply publish the bundles on several items in one unique "urx:xmpp:omemo:0" node. Each item ID will be the device ID. To discover the device ID list a simple http://jabber.org/protocol/disco#items query would then be sufficient and will rely on existing PEP/Pubsub implementations (client and server wise). Furthermore, each client could be instantly notified when a device has been added or retracted from the list. A similar behavior has already been standardized in XEP-0277: Microblogging over XMPP. This would seem a better design, indeed. This seems to already work with servers like Metronome and ejabberd (not Prosody for now) and should not cause issues with existing OMEMO implementations that are still based on Axolotl and using the eu.siacs.conversations.axolotl namespace. Regards, Timothée Jaussoin aka edhelas ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___ Hi again, Do you think it's a good idea to propose a Pull Request for those changes? I can work on this in the upcoming days. Also, even if I'm not coming physically to the Summit I'll join you using video-conferencing and I'm planning to present my feedbacks. See https://wiki.xmpp.org/web/Summit_21#Agenda on Friday. Regards, Timothée Jaussoin ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0384: OMEMO Encryption - Feedbacks and proposals
On 6 January 2017 at 08:36, Jaussoin Timothée wrote: > Hi, > > I'm currently in the process of implementing end-to-end encryption in my > project. I naturally had a look at the freshly published XEP-0384: OMEMO > Encryption and I have some feedbacks to give on it. > > 1. Usage of Olm > > After some talks with members of the community it seems that this protocol > was selected for two reasons : it was quite well documented (for the crypto > part) and didn't have legal concerns. > > I was quite disappointed by the library provided by Matrix for this protocol > (https://matrix.org/git/olm/about/). The Javascript version of it needs to > be generated from the C/C++ code using a tool called emscripten > (https://kripken.github.io/emscripten-site/index.html) that is actually not > packaged on Debian (only a very old version from 2014 is available for sid) > and seems to rely on a forked version of LLVM. > > Also I couldn't find any clear/simple documentation that could help me with > the integration of the library in a project (like we can have for libsignal > here https://github.com/WhisperSystems/libsignal-protocol-javascript). > Feel free to write a better library. Axolotl/Signal doesn't have this option without someone setting lawyers on you. That's why we had to switch away from it. > 2. XMPP environment integration > > I also had some concerns regarding the integration and coherence with the > current XMPP XEPs and syntax. > > 2.1. OMEMO nodes name syntax > > Having node names that use the camelCase syntax is not something that I've > encountered since the vCard tag in XEP-0054: vcard-temp. I'd prefer to stick > with the kebab-case (lower-case-dash-separated syntax) like we have in the > rest of the XEPs. What do you think? > Cosmetic, so this is not a hill to die upon, but all things being equal I'd prefer consistency. > 2.2. Current usage of PEP > > This feedback is related to the previous message that I sent on this ML > regarding XEP-0163: Personal Eventing Protocol a couple of days ago (see > https://mail.jabber.org/pipermail/standards/2017-January/031811.html). > > The current usage of PEP is, for me, not optimal and overly complex. Having > a list of devices that needs to be synchronized on a node and their related > bundles on some others brings race-conditions issues (actually mentioned in > the Example 2.) and forces the clients to implement extra checks to ensure > that everything is properly synchronized. > > Proposal : > > I propose to simply publish the bundles on several items in one unique > "urx:xmpp:omemo:0" node. Each item ID will be the device ID. > > To discover the device ID list a simple > http://jabber.org/protocol/disco#items query would then be sufficient and > will rely on existing PEP/Pubsub implementations (client and server wise). > Furthermore, each client could be instantly notified when a device has been > added or retracted from the list. > > A similar behavior has already been standardized in XEP-0277: Microblogging > over XMPP. > This would seem a better design, indeed. > This seems to already work with servers like Metronome and ejabberd (not > Prosody for now) and should not cause issues with existing OMEMO > implementations that are still based on Axolotl and using the > eu.siacs.conversations.axolotl namespace. > > Regards, > > Timothée Jaussoin aka edhelas > > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0384: OMEMO Encryption - Feedbacks and proposals
Hi forenjunkie and thanks for your feedback. I do agree with your feedback, indeed my proposal was just to do it in a more proper way using a publication patterns already defined in 0060. Regards, Timothée On 06/01/2017 16:27, forenjunkie wrote: Hi, I see no downside with your proposal, but the upsides are not as plenty as you described. 1. every client gets notified already if a update to the device list is made, otherwise OMEMO would not work half of the time 2. there is no code that is added *only* to prevent the race condition, a device has always be aware of all device ids that are published, and also has to have the ability to delete the whole device list. So in any case you need code that sees if your own device id is not in the list anymore, and can add itself to the devicelist again. this code is additionally also what prevents the race condition. I dont know if its easier to just overwrite the list like we do now, or delete all items of a node. It still maybe a cleaner implementation, im not very knowledgeable on pupsub/pep. Am 06.01.2017 um 09:36 schrieb Jaussoin Timothée: The current usage of PEP is, for me, not optimal and overly complex. Having a list of devices that needs to be synchronized on a node and their related bundles on some others brings race-conditions issues (actually mentioned in the Example 2.) and forces the clients to implement extra checks to ensure that everything is properly synchronized. Proposal : I propose to simply publish the bundles on several items in one unique "urx:xmpp:omemo:0" node. Each item ID will be the device ID. To discover the device ID list a simple http://jabber.org/protocol/disco#items query would then be sufficient and will rely on existing PEP/Pubsub implementations (client and server wise). Furthermore, each client could be instantly notified when a device has been added or retracted from the list. A similar behavior has already been standardized in XEP-0277: Microblogging over XMPP. This seems to already work with servers like Metronome and ejabberd (not Prosody for now) and should not cause issues with existing OMEMO implementations that are still based on Axolotl and using the eu.siacs.conversations.axolotl namespace. Regards, Timothée Jaussoin aka edhelas ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0384: OMEMO Encryption - Feedbacks and proposals
Hi, I see no downside with your proposal, but the upsides are not as plenty as you described. 1. every client gets notified already if a update to the device list is made, otherwise OMEMO would not work half of the time 2. there is no code that is added *only* to prevent the race condition, a device has always be aware of all device ids that are published, and also has to have the ability to delete the whole device list. So in any case you need code that sees if your own device id is not in the list anymore, and can add itself to the devicelist again. this code is additionally also what prevents the race condition. I dont know if its easier to just overwrite the list like we do now, or delete all items of a node. It still maybe a cleaner implementation, im not very knowledgeable on pupsub/pep. Am 06.01.2017 um 09:36 schrieb Jaussoin Timothée: The current usage of PEP is, for me, not optimal and overly complex. Having a list of devices that needs to be synchronized on a node and their related bundles on some others brings race-conditions issues (actually mentioned in the Example 2.) and forces the clients to implement extra checks to ensure that everything is properly synchronized. Proposal : I propose to simply publish the bundles on several items in one unique "urx:xmpp:omemo:0" node. Each item ID will be the device ID. To discover the device ID list a simple http://jabber.org/protocol/disco#items query would then be sufficient and will rely on existing PEP/Pubsub implementations (client and server wise). Furthermore, each client could be instantly notified when a device has been added or retracted from the list. A similar behavior has already been standardized in XEP-0277: Microblogging over XMPP. This seems to already work with servers like Metronome and ejabberd (not Prosody for now) and should not cause issues with existing OMEMO implementations that are still based on Axolotl and using the eu.siacs.conversations.axolotl namespace. Regards, Timothée Jaussoin aka edhelas ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0384: OMEMO Encryption - Feedbacks and proposals
Hi, I'm currently in the process of implementing end-to-end encryption in my project. I naturally had a look at the freshly published XEP-0384: OMEMO Encryption and I have some feedbacks to give on it. 1. Usage of Olm After some talks with members of the community it seems that this protocol was selected for two reasons : it was quite well documented (for the crypto part) and didn't have legal concerns. I was quite disappointed by the library provided by Matrix for this protocol (https://matrix.org/git/olm/about/). The Javascript version of it needs to be generated from the C/C++ code using a tool called emscripten (https://kripken.github.io/emscripten-site/index.html) that is actually not packaged on Debian (only a very old version from 2014 is available for sid) and seems to rely on a forked version of LLVM. Also I couldn't find any clear/simple documentation that could help me with the integration of the library in a project (like we can have for libsignal here https://github.com/WhisperSystems/libsignal-protocol-javascript). 2. XMPP environment integration I also had some concerns regarding the integration and coherence with the current XMPP XEPs and syntax. 2.1. OMEMO nodes name syntax Having node names that use the camelCase syntax is not something that I've encountered since the vCard tag in XEP-0054: vcard-temp. I'd prefer to stick with the kebab-case (lower-case-dash-separated syntax) like we have in the rest of the XEPs. What do you think? 2.2. Current usage of PEP This feedback is related to the previous message that I sent on this ML regarding XEP-0163: Personal Eventing Protocol a couple of days ago (see https://mail.jabber.org/pipermail/standards/2017-January/031811.html). The current usage of PEP is, for me, not optimal and overly complex. Having a list of devices that needs to be synchronized on a node and their related bundles on some others brings race-conditions issues (actually mentioned in the Example 2.) and forces the clients to implement extra checks to ensure that everything is properly synchronized. Proposal : I propose to simply publish the bundles on several items in one unique "urx:xmpp:omemo:0" node. Each item ID will be the device ID. To discover the device ID list a simple http://jabber.org/protocol/disco#items query would then be sufficient and will rely on existing PEP/Pubsub implementations (client and server wise). Furthermore, each client could be instantly notified when a device has been added or retracted from the list. A similar behavior has already been standardized in XEP-0277: Microblogging over XMPP. This seems to already work with servers like Metronome and ejabberd (not Prosody for now) and should not cause issues with existing OMEMO implementations that are still based on Axolotl and using the eu.siacs.conversations.axolotl namespace. Regards, Timothée Jaussoin aka edhelas ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
