[Standards] Proposed XMPP Extension: OMEMO Encryption

Daniel Gultsch daniel at gultsch.de
Mon Oct 31 19:01:38 UTC 2016


While I'm not the original author of this XEP and I don't want to take
credit for the original work I guess I'll be taking over maintaining
this XEP in the future. I'm primarily thinking about the required
'author approval' for the case when someone else wants to contribute
to the XEP.

Is there an official path for taking over 'ownership' of a XEP? If not
I guess since OMEMO is not a XEP yet I could just settle this with
Andreas Straub in private and just add myself as a co-author?

cheers
Daniel

2016-10-31 18:56 GMT+01:00 Sebastian Verschoor <sebastian.verschoor at gmail.com>:
> Hi Daniel,
>
> Thanks for the fast response.
>
> On 31 October 2016 at 12:58, Daniel Gultsch <daniel at 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.verschoor at 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 <editor at 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-unsubscribe at xmpp.org
>> >> _______________________________________________
>> >
>> >
>> >
>> > _______________________________________________
>> > Standards mailing list
>> > Info: https://mail.jabber.org/mailman/listinfo/standards
>> > Unsubscribe: Standards-unsubscribe at xmpp.org
>> > _______________________________________________
>> >
>> _______________________________________________
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: Standards-unsubscribe at xmpp.org
>> _______________________________________________
>
>
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>


More information about the Standards mailing list