Hi Daniel, Thanks for the fast response.
On 31 October 2016 at 12:58, Daniel Gultsch <dan...@gultsch.de> wrote: > Hi Sebastian, > > you should be acknowledged in the acknowledge section of the XEP. > However 'Section 7' didn't change between the audit and now. It > remained the same ever since the original version of the XEP. > > However credit is definitely due if only for the GCM auth tag thing. > (Actually could you look over how this is handled right now and if > this addresses the issues voiced in the audit?). > I believe that encrypting and authenticating the tag/key-tuple within the Olm session as described in Section 4.5 of the XEP fixes the issue described in Section 2.2.3 (message authentication) of the audit: adding the tag to the Olm payload disables the attacker to authenticate arbitrary messages. However, Section 4.6 of the XEP (Sending a key) also includes a tag in the payload. I am not sure where the tag comes from? In fact, I believe that this tag can simply be left out: the randomly generated key *is* the full message content and is already authenticated by the Olm session. > > Section 6 only talks about the library level though. The very next > sentence says that OMEMO should do it's own trust model. > > cheers > Daniel > Cheers, Sebastian > > 2016-10-31 17:36 GMT+01:00 Sebastian Verschoor < > sebastian.versch...@gmail.com>: > > Dear editors, > > > > I have a question regarding Section 6, which states: > > "it may be desirable to have the library consider all keys trusted, > > effectively disabling its trust management" > > The paragraph right below (in Section 7) then describes an attack that > can > > occur if a device simply trusts all devices. These paragraphs appear to > > contradict each other. > > > > Furthermore, the attack described in the first paragraph of Section 7 is > > precisely the attack that was described in the security audit of the > OMEMO > > protocol (See Section 2.2.3 of https://conversations.im/omemo/audit.pdf). > I > > believe that a reference to that audit (or another form of > acknowledgement) > > is in order here. > > > > Best regards, > > Sebastian > > > > ps. Full disclaimer: I am the author of the mentioned security audit. > > > > > > On 31 October 2016 at 11:24, XMPP Extensions Editor <edi...@xmpp.org> > wrote: > >> > >> The XMPP Extensions Editor has received a proposal for a new XEP. > >> > >> Title: OMEMO Encryption > >> > >> Abstract: This specification defines a protocol for end-to-end > encryption > >> in one-on-one chats that may have multiple clients per account. > >> > >> URL: http://xmpp.org/extensions/inbox/omemo.html > >> > >> The council will decide in the next two weeks whether to accept this > >> proposal as an official XEP. > >> > >> _______________________________________________ > >> 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 > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
