Re: [Standards] 2017-06-28 Council Meeting
Hey all, ## OMEMO-NEXT - Council to seek a new author - Sam and vanitasvitae ask if Andy has officially asked to step down - daniel suggests that certain council members are concerned with the way he collects feedback, so he might be asked to step down either way - Kev says he also was under the impression that Andy just wanted to step down Council will ask Andy how he feels, and then seek new authors if appropriate. now that we have a "current usage" specification of OMEMO, I would like to briefly discuss my plans regarding the future of the protocol. As far as I'm concerned, "current usage" OMEMO mainly serves the purpose of taking off the pressure in regards to the specification/implementation mismatch situation. As such, I don't think much more energy should be poured into developing it further. I would like to "backport" some of the clarifying edits from my ODR proposal into "current usage" OMEMO, but only insofar as they do describe the current situation. Other than that, I think we can all agree that straight-up signal-protocol is not the way forward. Developing "OMEMO-next" to plan for a long-term future certainly makes sense to me. As others have said, there are a number of points where OMEMO can be improved, but which are not necessarily all things we can do "right now". Hammering out what that would look like gives us something to strive for, and might help to bring about the necessary changes sooner than later. In my view, it would make the most sense if this effort were lead by someone that is actively involved with OMEMO development somewhere. This is bound to be a substantial and complex evolution, and it has the best chances if it's spearheaded by someone that has a stake in its success. I can not fulfill such a role at this time, so I'm all for getting someone else on board to help out with this effort. To be clear: I am not planning on resigning from OMEMO altogether. I am still interested in working on the protocol, and I will help out wherever I can. I just can't shoulder the responsibility for pushing a proposal through this process by myself right now. Additionally, I do also think there is still a place for evolving OMEMO in the medium term. There are concrete things we can do right now that would improve the protocol, and I don't think it's wise to postpone all further improvements until "OMEMO-next". Some of these are reflected in my ODR proposal, and some are being worked out by others at the moment. So until "OMEMO-next" gets here, we should continue improving OMEMO where we can. As I said, there's already some stuff in the pipeline, and I will submit further revisions as they are finalized. Cheers, Andy ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO and Olm
Hey all,
it has been brought to my attention that my recent silence on this
matter is being perceived as "unresponsiveness", so I guess I should
clear up a few things.
I haven't commented on this issue in a while because I don't feel I have
anything significant to add at this point. Most of the arguments have
been made (by me and others) months ago, and nothing significant has
changed. I generally try to refrain from repeating things others have
already said, especially on mailing lists, and I guess I just wasn't
aware that that's exactly what the XSF process required me to do in this
case. Sorry about that. So let me try to sum up where we stand right now.
First, for a bit of additional background, I suppose I should clear up
the misconception that (under my proposed changes) OMEMO would be
"moving away from OLM". As far as I'm concerned, OMEMO wasn't ever
actually on OLM. Due to the poor standardization of signal-protocol at
the time, we changed the spec to using OLM, but this was never actually
implemented. There were plans to switch over, but before anyone got
around to putting in the (not insignificant amount of) work, the
standardization issues with signal-protocol resolved themselves (in
particular, the whole "any implementation would be a derivative of ours
and hence bound by the GPL" thing isn't true anymore, as there is a
complete spec that's placed in the public domain). So as far as we were
aware at the time, the singular roadblock that prevented us from
standardizing on signal-protocol back in the day was gone, and there was
no longer a strong argument for proceeding with this changeover, which
would've meant a lot of effort for existing implementations at basically
no concrete benefit.
Hence, the main impetus driving me to work up a new revision was to
*move the spec back in line with the real world*, not some kind of
"political" move or anything of the sort as has been insinuated on this
list. We've had an increasing number of developers interested in
implementing OMEMO for different clients, and it's really dumb to have
to tell everybody to ignore what the standard (that you yourself wrote)
says.
So what I care about is resolving this situation in a way that actually
helps people. I want people to be able to implement this protocol
without reading others' code or asking around which parts of a spec to
ignore and which ones to follow. Staying in this limbo, as was suggested
on this list at some point ("it's experimental, you can just stay on
your private namespace for now") is in my opinion antithetical to the
whole idea of even having a standard in the first place.
As far as I can tell, switching to OLM does not help anyone. I am not
aware of any individual, organization, or company that is interested in
implementing OMEMO but *can't* due to licensing issues. The original
criticism of lacking specification is resolved. The spec is public
domain, and it contains everything you need to roll your own library.
But apparently, the goalposts have moved, and we now also require a
permissively licensed implementation.
Yes, it's true that there's currently no such thing for XEdDSA, but is
this actually a concrete problem for anyone? As far as I'm aware, this
has always been a purely hypothetical debate. If I'm wrong here, please
speak up! In any case, when it comes down to it, implementing this
yourself really isn't that complex. You can re-use existing EdDSA code,
all you need to do is write the key conversion code yourself, for which
there is pseudo-code in the standard, which maps fairly directly to
well-known mathematical primitives, for which you can also re-use
existing code. The main novel idea in XEdDSA is resolving an ambiguity
in the conversion by forcing a sign bit to 0, and that's about it. Your
code doesn't have to be constant-time and if you do it wrong, the
signature just won't verify. I agree that it's never ideal to have to do
stuff like this yourself, but this also isn't quite as "playing with
fire" as some folks are making it out to be. In any case, I really doubt
that this is the one big thing that would hinder such hypothetical
implementors from adopting OMEMO.
To make a long story short, I remain unconvinced that switching to OLM
makes sense at this point. The way I see it, moving forward with that
amounts to preventing some inconvenience for an entirely hypothetical
set of implementors at the cost of screwing over an entire existing,
working ecosystem.
It's easy to throw around things like "it's experimental, so we can mess
with it however we like and client devs will just have to deal with it",
especially if you have no skin in the game. But for the stakeholders who
are actually working on and using the technology, stuff like this is a
huge deal. OMEMO is a pretty successful and established protocol at this
point, and to be honest I just don't see the major implementations
switching over any t
Re: [Standards] OMEMO (XEP-0384) use of X3DH / XEdDSA
Hi Remko, So, I'm wondering whether it wouldn't make more sense to not carry the Signal legacy around in OMEMO, use Ed25519 keys as identity keys, and adapt X3DH to use these for creating an initial shared secret (with the same properties). The rest of the protocol can stay the same, since these keys can be converted to Curve25519. You raise a valid point. I agree that this construction seems cleaner from a purely theoretical standpoint. However, I expect that implementors will want to use signal-protocol implementations for the cryptographic heavy lifting anyway. In fact several aspects of OMEMO are designed with this in mind, and to make reusing their code as easy as possible. All current implementations of OMEMO that I'm aware of are using signal protocol code. In that sense, changing this would actually make implementation quite a bit harder and probably less secure, because then people would have to reach down into the guts of the library and start patching things. It can be done, but it's not a small undertaking, and I'm not sure it's worth it. Implementations of the signal protocol are available for many platforms, and they work really well. Both the signal protocol and OMEMO have undergone audits. I really don't want to change things here unless there are *very* good reasons to do so, and I don't currently see how this quirk would seriously hinder actual implementations. Not to mention that doing this would make the migration to the new version significantly more painful, as all of our users would have to generate new keys. Cheers, Andy ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO (XEP-0384) Crypto Questions/Remarks
Hi Remko, thanks for taking a look. Should AES-GCM be considered as an AEAD scheme instead of AES-CBC+HMAC? As far as I can tell, it is more convenient to use, and more efficient (but I'm no crypto expert, maybe there are other reasons against/for it). We're using AES-CBC/HMAC in ODR, because it's what other double ratchets are using as well, most notably signal protocol. This means implementors can reuse that code without touching the crypto. We've decided to also use it for the payload encryption, because this way you won't need several different implementations for your crypto code. You can just use whatever ships with your double ratchet implementation. GCM also isn't quite as easily available on some platforms as we'd like, whereas CBC and HMAC are pretty much ubiquitous. > Another question that pops up: the envelope now contains the > different message headers as XML attributes. However, these headers > need to be authenticated by the AEAD algorithm. So, the entire header > needs to be serialized so it can be passed to the AEAD algorithm, and > it's not defined how this has to be done. Yes, very good point. Thanks. I'll fix this. Cheers, Andy ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO (XEP-0384) Crypto Questions/Remarks
On 03/29/2017 12:31 PM, Remko Tronçon wrote: Hi, I have a few outstanding questions/remarks about the crypto protocol part of OMEMO: - The XEP says it uses the Olm protocol, but it also mentions signed pre-keys (which I assume are about X3DH, which Olm doesn't use). Either the X3DH bits should be removed, or we should document our 'fork' of the Olm protocol that uses X3DH. - Olm doesn't send the previous chain length with its messages. This makes it impossible to know whether or not there have been skipped message keys that need to be stored. Is this something we should add, is out-of-order messages something we don't need to deal with? Note that sending the previous chain length *is* part of the original Double Ratchet spec. - The XEP uses AES-128GCM for encryption of the payload. The payload itself is (I assume) an Olm encrypted message. Olm uses a combination of AES-CBC for encryption and HMAC-SHA256 for authentication. For consistency, can/should we replace the Olm encrypted message format with AES-GCM as well for both authentication and encryption? - Is there a specific reason for going with AES-128GCM instead of AES-256GCM? I'm asking for practical purposes, because some opinionated crypto libs such as NaCl and LibSodium only have the latter. Might be easier for implementations if AES-256GCM is taken. thanks, Remko Hi Remko, to make a long story short, a new revision of the spec has been in the works for quite a while now and I just submitted the draft.[1] It should resolve all of these questions. Cheers, Andy [1] https://github.com/xsf/xeps/pull/460 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed changes to OMEMO's use of PEP
Hi, thanks for giving us your side of the story, Tim. See https://xmpp.org/extensions/xep-0060.html#owner-configure. This behavior can be fixed by setting pubsub#deliver_payloads to false in the 'urn:xmpp:omemo:0' node configuration. The clients will then only get a small notification and not the whole bundle anymore, it can then retrieve the bundle manually if he needs it. Again here we are relying on features that already exists. I can complete my pull request to enforce this behavior on node creation. So I guess you'd just get empty s with the id being the OMEMO device id then? That's nice. Is this supported everywhere? This proposal is also internally inconsistent. Some of the prescribed behavior makes no sense under this new architecture (e.g. there is no point in explicitly fetching bundles anymore). It is also lacking business rules describing how to handle the issues I raised above. See above. Where? This change would imply quite a few internal incosistencies. Most importantly, you haven't addressed the problem of what happens when the server doesn't support multiple items per node, or doesn't support as many entries as you need. You just kinda hand waved it as "people are working on it", but tbh that's not nearly good enough. So it just stops working then, right? A *ton* of people are using this protocol already, many of whom you'd be breaking this for. Even if this eventually makes it into releases of every major server software, operators out in the wild don't always update immediately to the newest version of everthing. In fact, it's actually really hard to get them to. I know I'm repeating myself here, but you're not really acknowledging the very real consequences this change will have for a lot of users. This *will* break things, there's no way around it. So in the mean time, what are we supposed to tell users? Change servers? And all of this for what? A change that doesn't actually fix any real problems? IMO you really need to come up with a better justification for this than that it "feels more correct". That's not good enough. Again a totally agree with you and your solution seems to be a perfect way to figure out this problem for now. But, with my proposal, I'd like to make this XEP future proof (afaik the Prosody team is planning to implement the missing behavior in their future release) and only relies on existing XEPs (PEP and Pubsub) techniques to makes the results more coherent and simple. I don't really see how this change simplifies anything in any meaningful way. You still have to do all the same checks on the client that you had to do before. So what are we future proofing against here, exactly? What future effects are you anticipating that will break the current mechanism? Also, I saw that the current OMEMO implementations (in Gajim and Conversations for now) are relying on the historical namespace 'eu.siacs.conversations.axolotl' that will break the day they move to the one defined in the official XEP. Because this can takes a bit of time I prefer to address those architectural concerns now better than having to redefine it when we will have proper servers supports. In my view these are completely separate issues. One is something we have control over, because it's on the client. The other we don't, because the blocker are existing server deployments. If a user has a problem it's significantly easier to tell them to update their software, than to get their server operator to deploy updates. So I don't think it's sensible to say this needs to be done before the new OMEMO version comes out. Your change would be delaying the new version, because it couldn't be adopted before there is widespread support in existing server deployments for it. The main point of my pull request is to try to keep XMPP coherent and relies on existing XEPs. If it brings implementations and support issues, we can fix it on the servers and clients, if there is something unclear in the PEP XEP, we can also talk about it and try to figure out why we have different point of views on this part of the extension. It's easy for you to say "we can fix it on the clients and the servers" if you don't have any users that will be impacted by this. Getting existing server deployments to upgrade is just not that easy. Make no mistake, this will take time. So even if we were to go this way, the timeline until we could in good conscience actually enable this change in the client is on the order of many, many months. Because I'm not about to break the protocol for my users. So at that point, I have to ask myself, if we're already in this for the long haul, why not actually do it right, i.e. explicit server support? I'm still not convinced that's really needed, because experience tells me this isn't really a problem that needs fixing, but it's obviously the much better solution. If you actually wanted to "future proof" OMEMO, this is what y
Re: [Standards] Proposed changes to OMEMO's use of PEP
Hi, I'm curious which server-side support for OMEMO you have in mind. Care to elaborate? So there are a few things about the PEP-based approach that are not ideal. The devicelist contention that the proposed change aims to address is really only one example of several scenarios where the client has to carefully manage the data in PEP by itself because the server doesn't act as anything more than a key/value store for our purposes. It would be cool if we could have the server enforce some of the business logic for us, so that the client doesn't have to. Basically, the server would not only manage the devicelist more intelligently but also actually act like a X3DH key server[1]. Mostly, this would just entail offering more "atomic" primitives than is possible with PEP, e.g. publishing prekeys individually rather than having to overwrite the entire bundle. It would also only hand out any prekey once, so no two initiators could end up using the same prekey to build a session with the responder. The server could also assign device ids to new clients to prevent collisions there. Having some server-side constraints like this in place just makes life easier for the clients. Some details would still have to be figured out, like whether we want the server to require some kind of proof from the client that it's actually "allowed" to publish/modify the data (signatures with the identity key or something?), or how to handle removing stale devices. But in essence, server-assisted OMEMO wouldn't look all that different from what we have currently at all. So as you can see, this wouldn't actually be a very complicated thing to implement, it's really just a few different IQ get/sets and some simple constraint checks. The bigger issue is going to be deployment, which is of course why we went with PEP in the first place... [1] https://whispersystems.org/docs/specifications/x3dh/#roles ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Proposed changes to OMEMO's use of PEP
Hey all,
this topic has been discussed at the summit and in other venues before,
and now a proposal to abolish the devicelist and move all bundles into
separate items in a single PEP node has been submitted. I have raised my
concerns in those abstract discussions in the past, but now we have
something concrete we can discuss.
https://github.com/xsf/xeps/pull/458/files
While I recognize that the way we've been using PEP is somewhat
unorthodox, I see several severe issues with this newly proposed approach.
Most importantly, this change effectively relies on OPTIONAL/MAY
behavior in PEP. PEP/pubsub do not mandate that the server has to keep
around more than one item per node. Therefore, this change will limit
the number of OMEMO devices a user can have active at the same time to
the maximum number of items per PEP node as supported by the server,
which in the general case has to be assumed to be 1. The devicelist is
an absolutely essential component of OMEMO, and it *has to* work
properly. Without it, we not only lose multi-device, but have to deal
with severe reliability issues related to whichever device(s) happen(s)
to be currently announced or not (i.e. messages only arriving at random,
possibly frequently changing subsets of devices without the user being
able to control this at all)
Furthermore, by eliminating the indirection via a separate devicelist
node and subscribing to all bundles directly, a significant increase in
traffic overhead is to be expected. Any time a bundle changes, all
contacts will receive the entire bundle. This happens frequently in
OMEMO. For example, whenever a new session is established, according to
the XEP, the responder SHOULD change their bundle (removing the used-up
prekey). Clients might also rotate their signed prekey regularly. Any
time these things happen, all OMEMO-enabled contacts (and other own
devices) will receive the full bundle. Note that in most cases, these
clients don't care at all about these events. The only times a client
would actually want to be passively informed about changes is when
devices are newly created or removed entirely, which is the vast
minority of these events. (For reference, bundles with the suggested
number of prekeys (100) are around 9-10kb in size.)
This proposal is also internally inconsistent. Some of the prescribed
behavior makes no sense under this new architecture (e.g. there is no
point in explicitly fetching bundles anymore). It is also lacking
business rules describing how to handle the issues I raised above.
In theory, this change does eliminate contention on the devicelist.
Currently, announcing a device requires updating the devicelist to add
the new device, while retaining all old ones in the same item
("read-update-write"), so there might be a situation where devices
overwrite one another if they both attempt to announce themselves at the
same time. But this really isn't as big of an issue as it may seem at
first. First of all, the odds of this happening are very slim. Devices
are not created anew or removed entirely very often in regular use.
There's also a really simple fix for this in the current XEP already:
clients MUST check that their own device is included in the list
whenever they receive an update for their own devicelist, and if not,
add themselves again. We've been doing it this way for 1.5 years now,
and not once has this caused a problem. But more importantly, this
behaviour needs to be in the XEP regardless of this change, because
clients have to ensure that they are currently announced at all times
anyway, because there are numerous other reasons why a device might have
been removed. So it's not like the proposed change would even simplify
anything here.
What's more though, as I described above, the proposed change "fixes"
this theoretical problem at the cost of possibly introducing contention
on the bundles, which is actually a much worse problem. If the server
can't retain several bundles at the same time, this is not something
that the clients can fix by simply publishing again. Best case: you lose
multi-device entirely, and whichever device has last published a bundle
is the only one that can use OMEMO at any moment in time. Worst case:
clients keep overwriting one another in order to re-announce themselves
ad infinitum.
In summary, I understand that the current behavior can seem strange at
first, and I'm certainly not opposed to improving this in some way, I
really don't think this proposal is the way to go here. It breaks the
protocol. If anything, we should maybe think about adding explicit
server-side support for OMEMO. I would be interested to hear what the
wider XMPP community thinks.
Cheers,
Andy
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] Proposed XMPP Extension: OMEMO Encryption
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 ___
