Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Sam Whited]

On Mon, Oct 31, 2016 at 2:43 PM, Daniel Gultsch  wrote:
> So the 'author approval' we generally seek when trying to change an
> existing XEP is just being nice?

Yup, in this case I took the liberty of assuming Andy would be okay
with the olm updates since he's been busy lately.

—Sam



-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Daniel Gultsch]

2016-10-31 20:36 GMT+01:00 Dave Cridland :
> Once a XEP is a XEP, it's owned by the XSF, and not the author. Prior to
> that, it is not owned by the XSF, and the XSF has no opinion on the matter
> except that on submission as a XEP, any authors agree to transfer ownership,
> perfecting as required, to the XSF.


So the 'author approval' we generally seek when trying to change an
existing XEP is just being nice?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Dave Cridland]

Once a XEP is a XEP, it's owned by the XSF, and not the author. Prior to
that, it is not owned by the XSF, and the XSF has no opinion on the matter
except that on submission as a XEP, any authors agree to transfer
ownership, perfecting as required, to the XSF.

On 31 Oct 2016 19:02, "Daniel Gultsch"  wrote:

> 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.versch...@gmail.com>:
> > Hi Daniel,
> >
> > Thanks for the fast response.
> >
> > On 31 October 2016 at 12:58, Daniel Gultsch  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
> >> :
> >> > 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 
> >> > 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
> > 

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Daniel Gultsch]

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 :
> Hi Daniel,
>
> Thanks for the fast response.
>
> On 31 October 2016 at 12:58, Daniel Gultsch  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
>> :
>> > 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 
>> > 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
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Sebastian Verschoor]

Hi Daniel,

Thanks for the fast response.

On 31 October 2016 at 12:58, Daniel Gultsch  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 
> 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
___

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Daniel Gultsch]

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?).

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


2016-10-31 17:36 GMT+01:00 Sebastian Verschoor :
> 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  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] Proposed XMPP Extension: OMEMO Encryption

[XMPP Extensions Editor]

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
___

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Chris Ballinger]

The URIs will already be super long so I don't think saving a few bytes to
omit the sid is that important as far as overhead. Our db model for devices
is currently keyed to JID + deviceId, because we normally don't know
identityKey until the bundle is fetched. We could also prepend the 32-bit
sid to the binary payload data, and use base32 instead of hex to save a
character.

I think it's useful to have the sid because otherwise we'll have entries
floating around in our db without a sid, and then also entries floating
around without an identityKey from PEP, and we'll have to merge them during
the bundle fetching process which would be kinda weird and a lot harder
than just including the sid in the URI.



On Thu, Oct 27, 2016 at 12:17 PM, Daniel Gultsch  wrote:

> Hi Chris,
>
> is there a reason you are including the SID in the URL?
>
> If not I would just propose doing
>
> xmpp:fe...@allfools.lit?omemo=070c42a11644a78b2f6f56213be468
> 6374222895eb67b781abc44b860c47656c,e3898c2083b830a5fcb5e49632a344
> 2837f8e8a24bea2f39e37d632807c82871
>
> instead.
>
> Or maybe ?omemo=key=key2 but ?omemo=key,key2 safes some bytes
>
> cheers
> Daniel
>
> 2016-10-27 20:51 GMT+02:00 Chris Ballinger :
> > Hey, I'd like to propose an OMEMO addition to XMPP URIs so you can
> pre-share
> > the identityKey for each of your devices through another channel.
> Currently
> > OTR fingerprints in URIs are formatted like this:
> > http://xmpp.org/extensions/xep-0364.html#sect-idp672480
> >
> > xmpp:fe...@allfools.lit?otr-fingerprint=AEA4D503298797D4A4FC823BC1D245
> 24B4C54338
> >
> > Since each Device ID would need a separate entry, we'd need to do a
> prefix
> > mechanism:
> >
> > xmpp:fe...@allfools.lit?omemo-sid-24145=070c42a11644a78b2f6f56213be468
> 6374222895eb67b781abc44b860c47656c;omemo-sid-55126=
> e3898c2083b830a5fcb5e49632a3442837f8e8a24bea2f39e37d632807c82871
> >
> > We could also use Base32 (or URL safe Base64?) to shorten the links
> > slightly. Super long links are allowed on iOS, not sure about Android or
> > other platforms.
> >
> > On Fri, Oct 7, 2016 at 11:19 AM, Fabian Beutel 
> wrote:
> >>
> >> Maybe this is a good time to bring up a question regarding full stanza
> >> encryption [1]:
> >>
> >> Maybe we can include a mechanism for encrypting full stanzas (including
> >> IQs), not just Message's  elements? Or do you think a separate XEP
> >> building upon the defenitions of the current one would be better suited
> >> for that?
> >>
> >> I'm especially thinking about jingle negotiations that can leak a lot of
> >> meta data. Even in the case of "OMEMO Encrypted Jingle File Transfer"
> >> full stanza encryption prevents a lot of information leakage.
> >>
> >> Best regards,
> >> Fabian
> >>
> >> [1] I tried to bring up a similar discussion on OpenPGP recently, see
> >> https://mail.jabber.org/pipermail/standards/2016-September/031440.html
> >>
> >> On 01.10.2016 13:49, Daniel Gultsch wrote:
> >> > FYI: There is a pending PR [1] that rewrites the OMEMO XEP to use the
> >> > (well documented) Olm specification and also adds some minor
> >> > improvements that came up during the audit [2].
> >> >
> >> > cheers
> >> > Daniel
> >> >
> >> > [1]: https://github.com/xsf/xeps/pull/251
> >> > [2]: https://conversations.im/omemo/audit.pdf
> >> >
> >> > 2015-10-28 16:42 GMT+01:00 XMPP Extensions Editor :
> >> >> 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 XMPP 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
> ___
>
___
Standards mailing list
Info: 

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Daniel Gultsch]

Hi Chris,

is there a reason you are including the SID in the URL?

If not I would just propose doing

xmpp:fe...@allfools.lit?omemo=070c42a11644a78b2f6f56213be4686374222895eb67b781abc44b860c47656c,e3898c2083b830a5fcb5e49632a3442837f8e8a24bea2f39e37d632807c82871

instead.

Or maybe ?omemo=key=key2 but ?omemo=key,key2 safes some bytes

cheers
Daniel

2016-10-27 20:51 GMT+02:00 Chris Ballinger :
> Hey, I'd like to propose an OMEMO addition to XMPP URIs so you can pre-share
> the identityKey for each of your devices through another channel. Currently
> OTR fingerprints in URIs are formatted like this:
> http://xmpp.org/extensions/xep-0364.html#sect-idp672480
>
> xmpp:fe...@allfools.lit?otr-fingerprint=AEA4D503298797D4A4FC823BC1D24524B4C54338
>
> Since each Device ID would need a separate entry, we'd need to do a prefix
> mechanism:
>
> xmpp:fe...@allfools.lit?omemo-sid-24145=070c42a11644a78b2f6f56213be4686374222895eb67b781abc44b860c47656c;omemo-sid-55126=e3898c2083b830a5fcb5e49632a3442837f8e8a24bea2f39e37d632807c82871
>
> We could also use Base32 (or URL safe Base64?) to shorten the links
> slightly. Super long links are allowed on iOS, not sure about Android or
> other platforms.
>
> On Fri, Oct 7, 2016 at 11:19 AM, Fabian Beutel  wrote:
>>
>> Maybe this is a good time to bring up a question regarding full stanza
>> encryption [1]:
>>
>> Maybe we can include a mechanism for encrypting full stanzas (including
>> IQs), not just Message's  elements? Or do you think a separate XEP
>> building upon the defenitions of the current one would be better suited
>> for that?
>>
>> I'm especially thinking about jingle negotiations that can leak a lot of
>> meta data. Even in the case of "OMEMO Encrypted Jingle File Transfer"
>> full stanza encryption prevents a lot of information leakage.
>>
>> Best regards,
>> Fabian
>>
>> [1] I tried to bring up a similar discussion on OpenPGP recently, see
>> https://mail.jabber.org/pipermail/standards/2016-September/031440.html
>>
>> On 01.10.2016 13:49, Daniel Gultsch wrote:
>> > FYI: There is a pending PR [1] that rewrites the OMEMO XEP to use the
>> > (well documented) Olm specification and also adds some minor
>> > improvements that came up during the audit [2].
>> >
>> > cheers
>> > Daniel
>> >
>> > [1]: https://github.com/xsf/xeps/pull/251
>> > [2]: https://conversations.im/omemo/audit.pdf
>> >
>> > 2015-10-28 16:42 GMT+01:00 XMPP Extensions Editor :
>> >> 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 XMPP 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
___

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Chris Ballinger]

Hey, I'd like to propose an OMEMO addition to XMPP URIs so you can
pre-share the identityKey for each of your devices through another channel.
Currently OTR fingerprints in URIs are formatted like this:
http://xmpp.org/extensions/xep-0364.html#sect-idp672480

xmpp:fe...@allfools.lit
?otr-fingerprint=AEA4D503298797D4A4FC823BC1D24524B4C54338

Since each Device ID would need a separate entry, we'd need to do a prefix
mechanism:

xmpp:fe...@allfools.lit
?omemo-sid-24145=070c42a11644a78b2f6f56213be4686374222895eb67b781abc44b860c47656c;omemo-sid-55126=e3898c2083b830a5fcb5e49632a3442837f8e8a24bea2f39e37d632807c82871

We could also use Base32 (or URL safe Base64?) to shorten the links
slightly. Super long links are allowed on iOS, not sure about Android or
other platforms.

On Fri, Oct 7, 2016 at 11:19 AM, Fabian Beutel  wrote:

> Maybe this is a good time to bring up a question regarding full stanza
> encryption [1]:
>
> Maybe we can include a mechanism for encrypting full stanzas (including
> IQs), not just Message's  elements? Or do you think a separate XEP
> building upon the defenitions of the current one would be better suited
> for that?
>
> I'm especially thinking about jingle negotiations that can leak a lot of
> meta data. Even in the case of "OMEMO Encrypted Jingle File Transfer"
> full stanza encryption prevents a lot of information leakage.
>
> Best regards,
> Fabian
>
> [1] I tried to bring up a similar discussion on OpenPGP recently, see
> https://mail.jabber.org/pipermail/standards/2016-September/031440.html
>
> On 01.10.2016 13:49, Daniel Gultsch wrote:
> > FYI: There is a pending PR [1] that rewrites the OMEMO XEP to use the
> > (well documented) Olm specification and also adds some minor
> > improvements that came up during the audit [2].
> >
> > cheers
> > Daniel
> >
> > [1]: https://github.com/xsf/xeps/pull/251
> > [2]: https://conversations.im/omemo/audit.pdf
> >
> > 2015-10-28 16:42 GMT+01:00 XMPP Extensions Editor :
> >> 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 XMPP 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
___

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Fabian Beutel]

Maybe this is a good time to bring up a question regarding full stanza
encryption [1]:

Maybe we can include a mechanism for encrypting full stanzas (including
IQs), not just Message's  elements? Or do you think a separate XEP
building upon the defenitions of the current one would be better suited
for that?

I'm especially thinking about jingle negotiations that can leak a lot of
meta data. Even in the case of "OMEMO Encrypted Jingle File Transfer"
full stanza encryption prevents a lot of information leakage.

Best regards,
Fabian

[1] I tried to bring up a similar discussion on OpenPGP recently, see
https://mail.jabber.org/pipermail/standards/2016-September/031440.html

On 01.10.2016 13:49, Daniel Gultsch wrote:
> FYI: There is a pending PR [1] that rewrites the OMEMO XEP to use the
> (well documented) Olm specification and also adds some minor
> improvements that came up during the audit [2].
> 
> cheers
> Daniel
> 
> [1]: https://github.com/xsf/xeps/pull/251
> [2]: https://conversations.im/omemo/audit.pdf
> 
> 2015-10-28 16:42 GMT+01:00 XMPP Extensions Editor :
>> 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 XMPP 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
___

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Daniel Gultsch]

Hi,

2016-10-07 19:45 GMT+02:00 Chris Ballinger :
> OH, so there's nothing in the spec against having multiple identical `rid`.
> I was passing them back and forth to my application as 
> dictionaries assuming that rid should always be unique across all users and
> devices, which was the cause of my confusion about how to handle collisions
> when encrypting. Will have to fix that to use an array.

Yes. RIDs are not globally unique but only unique per account.

>
> So just to verify, is this logic correct? When sending a message, I'm
> iterating over all the devicesIds to send, if I see duplicate `rid` I just
> add them all to the list and keep going. When receiving `rid`, if there's
> dupes, I just jam them in all of the matching sessions until it works (or
> doesn't).

Yes when sending to groups (multiple recipients) you can have multiple
rids which are the same.
When sending to just on recipient that doesn't happen.

And yes you are correct with the decryption logic.

cheers
Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Chris Ballinger]

OH, so there's nothing in the spec against having multiple identical `rid`.
I was passing them back and forth to my application as
 dictionaries assuming that rid *should* always be unique across
all users and devices, which was the cause of my confusion about how to
handle collisions when encrypting. Will have to fix that to use an array.

So just to verify, is this logic correct? When sending a message, I'm
iterating over all the devicesIds to send, if I see duplicate `rid` I just
add them all to the list and keep going. When receiving `rid`, if there's
dupes, I just jam them in all of the matching sessions until it works (or
doesn't).



On Thu, Oct 6, 2016 at 11:47 PM, Daniel Gultsch  wrote:

> Hi,
>
> 2016-10-06 23:56 GMT+02:00 Chris Ballinger :
> >> I don't see any duplicate data here. The auth tag is moved from the
> >> end of the payload into the 'key'. Moved. Not copied.
> >
> > Although it's moved (not copied), it's still appended to each key, so you
> > have sizeof(authTag)*numKeys instead of just sizeof(authTag). Doesn't
> matter
> > too much, but it still adds to the overhead. For AE I don't see much of a
> > reason to further encrypt the auth tag, is there something that came up
> in
> > the audit about this?
>
> You are totally right about the duplication. I didn't think of that last
> night.
>
> Yes this is something that came up in the audit. It's not so much
> about the encryption of the auth tag but about the verification of the
> auth tag.
> If the auth tag is not verified (as it currently is in the
> conversations namespace) there is no link between an individual
> session and the payload.
> Every (trusted) device can modify the payload without the receiver
> noticing. By verifying the auth tag we can circumvent that.
>
> Last page(ish) of the audit I believe.
>
> Regarding your rid questions from earlier:
>
> Assume our device has id A. The source ID is B. There are multiple
> keys marked with rid=A. We grab the first of those keys marked A and
> try to decrypt them in our session with B. That fails because the key
> either isn't for us or was maliciously added. If decryption (in the
> signal session with B) fails we move on to the next key marked with
> rid=A.
> Signal is immune against 'garbage messages'. Trying to decrypt a wrong
> signal message in session B doesn't hurt the session. (Or if it would
> we would have a problem anyway)
>
> cheers
> Daniel
> ___
> 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] Proposed XMPP Extension: OMEMO Encryption

[Daniel Gultsch]

Hi,

2016-10-06 23:56 GMT+02:00 Chris Ballinger :
>> I don't see any duplicate data here. The auth tag is moved from the
>> end of the payload into the 'key'. Moved. Not copied.
>
> Although it's moved (not copied), it's still appended to each key, so you
> have sizeof(authTag)*numKeys instead of just sizeof(authTag). Doesn't matter
> too much, but it still adds to the overhead. For AE I don't see much of a
> reason to further encrypt the auth tag, is there something that came up in
> the audit about this?

You are totally right about the duplication. I didn't think of that last night.

Yes this is something that came up in the audit. It's not so much
about the encryption of the auth tag but about the verification of the
auth tag.
If the auth tag is not verified (as it currently is in the
conversations namespace) there is no link between an individual
session and the payload.
Every (trusted) device can modify the payload without the receiver
noticing. By verifying the auth tag we can circumvent that.

Last page(ish) of the audit I believe.

Regarding your rid questions from earlier:

Assume our device has id A. The source ID is B. There are multiple
keys marked with rid=A. We grab the first of those keys marked A and
try to decrypt them in our session with B. That fails because the key
either isn't for us or was maliciously added. If decryption (in the
signal session with B) fails we move on to the next key marked with
rid=A.
Signal is immune against 'garbage messages'. Trying to decrypt a wrong
signal message in session B doesn't hurt the session. (Or if it would
we would have a problem anyway)

cheers
Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Sam Whited]

On Thu, Oct 6, 2016 at 3:24 PM, Chris Ballinger  wrote:
> Daniel:
>> I think we should just store the last time we received a message from a
>> device and if that age is above a certain threshold we should stop sending
>> messages to that device. A date in PEP can be manipulated by the server
>> admin.
>
> I like that idea.

Me too, I take back my earlier (out-of-band) statement that if we're
going to have an expiration time we should also have an "issued at"
time. This way is better.


> Sam:
>
>> In XMPP at least this is already covered by doing a disco#info on the
>> device
>
> Oh good call. I see what Daniel was saying about users being tricked by
> nicknames though, so maybe it is best to omit it.

Agreed.

—Sam



-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Daniel Gultsch]

Hi Chris,

2016-10-06 22:24 GMT+02:00 Chris Ballinger :
>> The current PR clarifies that though by putting it in the . The key
>> length is specified to be 16 bytes and the auth tag is just the rest.
>
> Ah ok. Still not sure why the auth tag is appended to the key now instead of
> the payload. Seems like a lot of duplicated data for no real security
> benefit.

I don't see any duplicate data here. The auth tag is moved from the
end of the payload into the 'key'. Moved. Not copied.

The reason is that everything in the  gets verified through
libsignal. Thus we will verify the auth tag with libsignal and that in
turn will verify the payload.

(I'm gonna answer the rid question another time when it's not the
middle of the night because I need to think about that some more)

cheers
daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Chris Ballinger]

Daniel:

> The current PR clarifies that though by putting it in the . The key
length is specified to be 16 bytes and the auth tag is just the rest.

Ah ok. Still not sure why the auth tag is appended to the key now instead
of the payload. Seems like a lot of duplicated data for no real security
benefit.

> I think we should just store the last time we received a message from a
device and if that age is above a certain threshold we should stop sending
messages to that device. A date in PEP can be manipulated by the server
admin.

I like that idea.

> For now I'd say if decryption fails try the next matching rid.

The issue isn't with decryption failure, it's that you could encrypt to the
wrong session when there's a (malicious?) deviceId collision. For example
in a MUC, someone could make take their trusted
deviceId/session/fingerprint and republish it under another deviceId that
collides with someone else in the MUC, causing one of the members to no
longer be able to decrypt messages to their deviceId, depending on how
collisions are handled. The behavior depends on your trust logic and
collision handling, which should probably be mentioned in the XEP.

Sam:

> In XMPP at least this is already covered by doing a disco#info on the
device

Oh good call. I see what Daniel was saying about users being tricked by
nicknames though, so maybe it is best to omit it.


On Sat, Oct 1, 2016 at 4:49 AM, Daniel Gultsch  wrote:

> FYI: There is a pending PR [1] that rewrites the OMEMO XEP to use the
> (well documented) Olm specification and also adds some minor
> improvements that came up during the audit [2].
>
> cheers
> Daniel
>
> [1]: https://github.com/xsf/xeps/pull/251
> [2]: https://conversations.im/omemo/audit.pdf
>
> 2015-10-28 16:42 GMT+01:00 XMPP Extensions Editor :
> > 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 XMPP 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
___

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Daniel Gultsch]

FYI: There is a pending PR [1] that rewrites the OMEMO XEP to use the
(well documented) Olm specification and also adds some minor
improvements that came up during the audit [2].

cheers
Daniel

[1]: https://github.com/xsf/xeps/pull/251
[2]: https://conversations.im/omemo/audit.pdf

2015-10-28 16:42 GMT+01:00 XMPP Extensions Editor :
> 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 XMPP 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
___

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Fedor Brunner]

The specification uses AES-128 in Galois/Counter Mode (GCM), please
upgrade to AES-256. Or use ChaCha20 and Poly1305.
https://tools.ietf.org/html/rfc7539


"Bottom line: 128-bit AES keys are not comparable in security to 255-bit
elliptic-curve keys. Is 2^255−19 big enough? Yes. Is 128-bit AES safe?
Unclear."

https://blog.cr.yp.to/20151120-batchattacks.html
https://cr.yp.to/papers.html#bruteforce

Andreas Straub:
> Hey all,
> 
> since I haven't really responded to this yet on the list and recently
> there has been some discussions on the topic in the XSF MUC, I thought
> I'd give a short update. (This actually turned out much longer than I
> intended so skip to the second to last paragraph for a summary if you're
> pressed for time)
> 
>>> To get the ball rolling, I’ll play devil’s advocate for a bit here: it is
>>> impossible to implement OMEMO from scratch by the current documentation 
>>> alone.
>>> “Axolotl” has no standard, and it appears Open Whisper Systems has no
>>> intention of writing one. The few bits of documentation and blog posts that 
>>> we
>>> have are not enough to implement it and are outdated or wrong in some 
>>> places.
> 
> To give some context to those that haven't been following this in
> detail, there are two different versions of the TextSecure protocol that
> are currently relevant, v2 and v3. Axolotl was introduced in v2, v1 was
> OTR-based. There is publicly-available documentation of the
> cryptography[1] and wire protocol[2] used in v2. These are not exactly a
> standard, but do describe the protocol pretty clearly.
> 
> Currently, the OMEMO ProtoXEP mandates use of v3. v3 introduced some
> variations on the underlying cryptography, along with corresponding
> changes of the wire protocol. Neither of those things are publically
> documented anywhere to the best of my knowledge. For this reason there
> has been some justifiable resistance towards OMEMO. I agree that this is
> a problem, and in light of this fact, I understand hesitation to proceed
> with standardization of OMEMO in its current form.
> 
> I don't think that getting the Open Whisper Systems people to write up a
> spec of v3 for us is realistic, and I wouldn't feel comfortable with
> writing up this spec myself. What I propose is that we change the OMEMO
> spec to REQUIRE conforming implementations to support v2. We would
> further make it OPTIONAL to support v3 as well, as many client
> developers will likely re-use existing implementations of axolotl, most
> of which support both versions.
> 
> The scenario of interest is establishing a new session. Let's say Alice
> wants to talk to Bob. Alice can discover whether Bob supports v3 by
> checking whether a signedPreKeyPublic and corresponding
> signedPreKeyPublicSignature are present in Bob's published preKeyBundle
> as these items were added in v3 (We might also explicitly announce v3
> support in the XML here, I don't really feel strongly about this either
> way, although I don't think it's necessary). If Alice supports v3, and
> so does Bob, they can use v3 to establish their connection. If Alice
> supports v3, but Bob doesn't, Alice will realize this and fall back to
> v2. If Alice doesn't support v2, regardless of whether Bob does or not,
> Alice will simply ignore the signedPreKeyPublic and signature as she
> isn't aware of them, and establish a v2 session. Therefore, in this
> scheme we obtain automatic, transparent version negotiation (of sorts)
> for free.
> 
> As a side-note on the cryptographic differences/benefits introduced with
> v3, there's not any documentation I could find that states the intent
> behind the changes. I won't speculate or make educated guesses as to the
> precise reasons at this time, but I will say that in any case, v3 does
> not appear to be less secure than v2, so allowing its use in an OPTIONAL
> fashion shouldn't decrease the security of the protocol. Further,
> distrusting clients can always chose not to announce support for it if
> they're dissatisfied with its unspecified nature.
> 
> In conclusion, we can (mostly) resolve the standardization issues with
> axolotl using the previously described change, with no immediately
> obvious downsides. I would be interested in hearing some feedback on
> whether those parties previously dissatisfied with OMEMO for this reason
> agree that using v2 is a workable solution to the specification dilemma.
> In that case I would draw up the necessary alterations to the ProtoXEP.
> I would further be interested in opinions on the issue of whether the
> documentation that is available on v2 is deemed sufficient for an
> independent implementation, and if not, in what manners it is lacking,
> so please take a look!
> 
> Additionally, there hasn't been much discussion about this on the list,
> so if there are any further grievances with OMEMO in its current state,
> please make yourselves heard, and maybe we can resolve those as well. :)
> 
> Cheers,
> Andy
> 
> 
> ---
> [1] 

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Fabian Beutel]

On 12.04.2016 20:18, Dave Cridland wrote:
> There is, however, "olm", from the Matrix folk. This is a direct copy of
> Axolotl, except done as a decent spec and with (I think) a
> liberally-licensed reference implementation. Should be fully compatible
> with Signal's.
> 
> If we can (nominally) switch to Olm, I'm actually quite happy with this
> spec (given the current absence of any proxy re-encryption stuff).

Sounds very reasonable and indeed, at least on first sight, the spec
does look pretty clear.

It would be interesting to actually test the compatibility with the
Signal protocol, though, and to hear some feedback from people who have
implemented OMEMO so far...

Best regards,
Fabian
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Dave Cridland]

And it'd have helped if I'd put the URI:
https://matrix.org/docs/spec/olm.html

On 12 April 2016 at 19:18, Dave Cridland  wrote:

>
>
> On 12 April 2016 at 17:08, Fabian Beutel  wrote:
>
>> Hey everyone,
>>
>> as I'm currently trying to implement OMEMO out of curiosity, I wanted to
>> bring up a few points that might be of interest to the discussion:
>>
>> 1. There still seems to be no real protocol specification, but there has
>> been a "whitepaper" by Whatsapp [1] that describes the protocol used,
>> which is not suitable as a standards specification but is a nice
>> introduction for understanding the protocol - if anyone is interested.
>>
>>
> There is, however, "olm", from the Matrix folk. This is a direct copy of
> Axolotl, except done as a decent spec and with (I think) a
> liberally-licensed reference implementation. Should be fully compatible
> with Signal's.
>
> If we can (nominally) switch to Olm, I'm actually quite happy with this
> spec (given the current absence of any proxy re-encryption stuff).
>
>
>> 2. A minor issue, but as you probably know, the people from
>> OpenWhisperSystems have renamed their protocol from Axolotl to Signal
>> and seem to be eager to push these changes throughaut their repositories.
>> An updated OMEMO proposal should probably reflect that change, as
>> references to Axolotl may become less clear when the Signal-people
>> remove all appearences of the old name.
>>
>> 3. There have been discussions on this list to use v2 of the Axolotl
>> protocol. However, it seems that the OWS people have removed support for
>> v2 from most of their libraries ([2] for the Java lib, [3] for the C
>> lib). That could indeed be a problem if v2 would be the default version,
>> as probably most people will want to rely on the reference
>> implementations...
>>
>> Best regards,
>> Fabian
>>
>>
>> [1] https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf
>> [2]
>>
>> https://github.com/WhisperSystems/libsignal-protocol-java/commit/87b5b940fbf9624ad0302721f6e54d7e5250df70
>> [3]
>>
>> https://github.com/WhisperSystems/libsignal-protocol-c/commit/57d85a0dc81a4e6d59ac20633a08040f57a29ddb
>> ___
>> Standards mailing list
>> Info: http://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> ___
>>
>
>
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Dave Cridland]

On 12 April 2016 at 17:08, Fabian Beutel  wrote:

> Hey everyone,
>
> as I'm currently trying to implement OMEMO out of curiosity, I wanted to
> bring up a few points that might be of interest to the discussion:
>
> 1. There still seems to be no real protocol specification, but there has
> been a "whitepaper" by Whatsapp [1] that describes the protocol used,
> which is not suitable as a standards specification but is a nice
> introduction for understanding the protocol - if anyone is interested.
>
>
There is, however, "olm", from the Matrix folk. This is a direct copy of
Axolotl, except done as a decent spec and with (I think) a
liberally-licensed reference implementation. Should be fully compatible
with Signal's.

If we can (nominally) switch to Olm, I'm actually quite happy with this
spec (given the current absence of any proxy re-encryption stuff).


> 2. A minor issue, but as you probably know, the people from
> OpenWhisperSystems have renamed their protocol from Axolotl to Signal
> and seem to be eager to push these changes throughaut their repositories.
> An updated OMEMO proposal should probably reflect that change, as
> references to Axolotl may become less clear when the Signal-people
> remove all appearences of the old name.
>
> 3. There have been discussions on this list to use v2 of the Axolotl
> protocol. However, it seems that the OWS people have removed support for
> v2 from most of their libraries ([2] for the Java lib, [3] for the C
> lib). That could indeed be a problem if v2 would be the default version,
> as probably most people will want to rely on the reference
> implementations...
>
> Best regards,
> Fabian
>
>
> [1] https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf
> [2]
>
> https://github.com/WhisperSystems/libsignal-protocol-java/commit/87b5b940fbf9624ad0302721f6e54d7e5250df70
> [3]
>
> https://github.com/WhisperSystems/libsignal-protocol-c/commit/57d85a0dc81a4e6d59ac20633a08040f57a29ddb
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Fabian Beutel]

Hey everyone,

as I'm currently trying to implement OMEMO out of curiosity, I wanted to
bring up a few points that might be of interest to the discussion:

1. There still seems to be no real protocol specification, but there has
been a "whitepaper" by Whatsapp [1] that describes the protocol used,
which is not suitable as a standards specification but is a nice
introduction for understanding the protocol - if anyone is interested.

2. A minor issue, but as you probably know, the people from
OpenWhisperSystems have renamed their protocol from Axolotl to Signal
and seem to be eager to push these changes throughaut their repositories.
An updated OMEMO proposal should probably reflect that change, as
references to Axolotl may become less clear when the Signal-people
remove all appearences of the old name.

3. There have been discussions on this list to use v2 of the Axolotl
protocol. However, it seems that the OWS people have removed support for
v2 from most of their libraries ([2] for the Java lib, [3] for the C
lib). That could indeed be a problem if v2 would be the default version,
as probably most people will want to rely on the reference
implementations...

Best regards,
Fabian


[1] https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf
[2]
https://github.com/WhisperSystems/libsignal-protocol-java/commit/87b5b940fbf9624ad0302721f6e54d7e5250df70
[3]
https://github.com/WhisperSystems/libsignal-protocol-c/commit/57d85a0dc81a4e6d59ac20633a08040f57a29ddb
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Thijs Alkemade]

> On 23 dec. 2015, at 20:18, Andreas Straub  wrote:
> 
>>> 
>>> To get the ball rolling, I’ll play devil’s advocate for a bit here: it is
>>> impossible to implement OMEMO from scratch by the current documentation 
>>> alone.
>>> “Axolotl” has no standard, and it appears Open Whisper Systems has no
>>> intention of writing one. The few bits of documentation and blog posts that 
>>> we
>>> have are not enough to implement it and are outdated or wrong in some 
>>> places.
> 
> To give some context to those that haven't been following this in
> detail, there are two different versions of the TextSecure protocol that
> are currently relevant, v2 and v3. Axolotl was introduced in v2, v1 was
> OTR-based. There is publicly-available documentation of the
> cryptography[1] and wire protocol[2] used in v2. These are not exactly a
> standard, but do describe the protocol pretty clearly.
> 
> Currently, the OMEMO ProtoXEP mandates use of v3. v3 introduced some
> variations on the underlying cryptography, along with corresponding
> changes of the wire protocol. Neither of those things are publically
> documented anywhere to the best of my knowledge. For this reason there
> has been some justifiable resistance towards OMEMO. I agree that this is
> a problem, and in light of this fact, I understand hesitation to proceed
> with standardization of OMEMO in its current form.
> 
> I don't think that getting the Open Whisper Systems people to write up a
> spec of v3 for us is realistic, and I wouldn't feel comfortable with
> writing up this spec myself. What I propose is that we change the OMEMO
> spec to REQUIRE conforming implementations to support v2. We would
> further make it OPTIONAL to support v3 as well, as many client
> developers will likely re-use existing implementations of axolotl, most
> of which support both versions.
> 
> The scenario of interest is establishing a new session. Let's say Alice
> wants to talk to Bob. Alice can discover whether Bob supports v3 by
> checking whether a signedPreKeyPublic and corresponding
> signedPreKeyPublicSignature are present in Bob's published preKeyBundle
> as these items were added in v3 (We might also explicitly announce v3
> support in the XML here, I don't really feel strongly about this either
> way, although I don't think it's necessary). If Alice supports v3, and
> so does Bob, they can use v3 to establish their connection. If Alice
> supports v3, but Bob doesn't, Alice will realize this and fall back to
> v2. If Alice doesn't support v2, regardless of whether Bob does or not,
> Alice will simply ignore the signedPreKeyPublic and signature as she
> isn't aware of them, and establish a v2 session. Therefore, in this
> scheme we obtain automatic, transparent version negotiation (of sorts)
> for free.
> 
> As a side-note on the cryptographic differences/benefits introduced with
> v3, there's not any documentation I could find that states the intent
> behind the changes. I won't speculate or make educated guesses as to the
> precise reasons at this time, but I will say that in any case, v3 does
> not appear to be less secure than v2, so allowing its use in an OPTIONAL
> fashion shouldn't decrease the security of the protocol. Further,
> distrusting clients can always chose not to announce support for it if
> they're dissatisfied with its unspecified nature.
> 
> In conclusion, we can (mostly) resolve the standardization issues with
> axolotl using the previously described change, with no immediately
> obvious downsides. I would be interested in hearing some feedback on
> whether those parties previously dissatisfied with OMEMO for this reason
> agree that using v2 is a workable solution to the specification dilemma.
> In that case I would draw up the necessary alterations to the ProtoXEP.
> I would further be interested in opinions on the issue of whether the
> documentation that is available on v2 is deemed sufficient for an
> independent implementation, and if not, in what manners it is lacking,
> so please take a look!

Even for v2 I'm not convinced the existing documentation is enough to
implement it. For example, the hashing algorithm used for the HKDF steps is
not documented in either link you provided (sure, it's probably SHA-256, but
it's an important detail). The documentation is also rather hard to follow,
has irrelevant sections (SMS fragmentation) and lacks in argumentation for
their choices.

I would still prefer if some people wrote a specification for (or based on)
axolotl that's self-contained and declared the authority for interop. OTR is
11 years old, so we really should aim to write something that can stand for a
multiple decades. If at some point Whisper Systems stops updating libaxolotl
and the repositories disappear and a new security issue is discovered then we
still need to be able to understand it and investigate how to fix it. The Olm
specification [1] is pretty close to what I would like to see (the level of
detail, not the 

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Andreas Straub]

Hey all,

since I haven't really responded to this yet on the list and recently
there has been some discussions on the topic in the XSF MUC, I thought
I'd give a short update. (This actually turned out much longer than I
intended so skip to the second to last paragraph for a summary if you're
pressed for time)

>> To get the ball rolling, I’ll play devil’s advocate for a bit here: it is
>> impossible to implement OMEMO from scratch by the current documentation 
>> alone.
>> “Axolotl” has no standard, and it appears Open Whisper Systems has no
>> intention of writing one. The few bits of documentation and blog posts that 
>> we
>> have are not enough to implement it and are outdated or wrong in some places.

To give some context to those that haven't been following this in
detail, there are two different versions of the TextSecure protocol that
are currently relevant, v2 and v3. Axolotl was introduced in v2, v1 was
OTR-based. There is publicly-available documentation of the
cryptography[1] and wire protocol[2] used in v2. These are not exactly a
standard, but do describe the protocol pretty clearly.

Currently, the OMEMO ProtoXEP mandates use of v3. v3 introduced some
variations on the underlying cryptography, along with corresponding
changes of the wire protocol. Neither of those things are publically
documented anywhere to the best of my knowledge. For this reason there
has been some justifiable resistance towards OMEMO. I agree that this is
a problem, and in light of this fact, I understand hesitation to proceed
with standardization of OMEMO in its current form.

I don't think that getting the Open Whisper Systems people to write up a
spec of v3 for us is realistic, and I wouldn't feel comfortable with
writing up this spec myself. What I propose is that we change the OMEMO
spec to REQUIRE conforming implementations to support v2. We would
further make it OPTIONAL to support v3 as well, as many client
developers will likely re-use existing implementations of axolotl, most
of which support both versions.

The scenario of interest is establishing a new session. Let's say Alice
wants to talk to Bob. Alice can discover whether Bob supports v3 by
checking whether a signedPreKeyPublic and corresponding
signedPreKeyPublicSignature are present in Bob's published preKeyBundle
as these items were added in v3 (We might also explicitly announce v3
support in the XML here, I don't really feel strongly about this either
way, although I don't think it's necessary). If Alice supports v3, and
so does Bob, they can use v3 to establish their connection. If Alice
supports v3, but Bob doesn't, Alice will realize this and fall back to
v2. If Alice doesn't support v2, regardless of whether Bob does or not,
Alice will simply ignore the signedPreKeyPublic and signature as she
isn't aware of them, and establish a v2 session. Therefore, in this
scheme we obtain automatic, transparent version negotiation (of sorts)
for free.

As a side-note on the cryptographic differences/benefits introduced with
v3, there's not any documentation I could find that states the intent
behind the changes. I won't speculate or make educated guesses as to the
precise reasons at this time, but I will say that in any case, v3 does
not appear to be less secure than v2, so allowing its use in an OPTIONAL
fashion shouldn't decrease the security of the protocol. Further,
distrusting clients can always chose not to announce support for it if
they're dissatisfied with its unspecified nature.

In conclusion, we can (mostly) resolve the standardization issues with
axolotl using the previously described change, with no immediately
obvious downsides. I would be interested in hearing some feedback on
whether those parties previously dissatisfied with OMEMO for this reason
agree that using v2 is a workable solution to the specification dilemma.
In that case I would draw up the necessary alterations to the ProtoXEP.
I would further be interested in opinions on the issue of whether the
documentation that is available on v2 is deemed sufficient for an
independent implementation, and if not, in what manners it is lacking,
so please take a look!

Additionally, there hasn't been much discussion about this on the list,
so if there are any further grievances with OMEMO in its current state,
please make yourselves heard, and maybe we can resolve those as well. :)

Cheers,
Andy


---
[1] https://github.com/trevp/axolotl/wiki
[2] https://github.com/WhisperSystems/Signal-Android/wiki/ProtocolV2

___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: OMEMO Encryption

[Kevin Smith]

On 13 Nov 2015, at 14:54, Thijs Alkemade  wrote:
> Hi all,
> 
> To get the ball rolling, I’ll play devil’s advocate for a bit here: it is
> impossible to implement OMEMO from scratch by the current documentation alone.
> “Axolotl” has no standard, and it appears Open Whisper Systems has no
> intention of writing one. The few bits of documentation and blog posts that we
> have are not enough to implement it and are outdated or wrong in some places.
> 
> We had a new XEP a few weeks ago which people said was unacceptable because it
> referred a NATO document that wasn’t publicly available, but now we have a XEP
> that depends on a GPLv3 licensed library. To me, both things a similarly
> problematic. Sure, the authors may be highly praised cryptographers, but I
> don’t think we should trust them blindly enough to build a specification on
> their work without being able to verify it, especially as it is very security
> sensitive.
> 
> What can we do about this?

Presumably we need to lobby them to publish a spec in some (stable/free) manner 
so that we’re able to use it in a XEP.

/K

[Standards] Proposed XMPP Extension: OMEMO Encryption

[XMPP Extensions Editor]

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 XMPP Council will decide in the next two weeks whether to accept this 
proposal as an official XEP.