Oh and I forgot: OpenPGP kind of solves the issue as it allows to bind encryption preferences to the key itself[1]. This may be worth taken into consideration.
Paul [1]: https://tools.ietf.org/html/rfc4880#section-5.2.3.7 On 20.06.19 13:17, Paul Schaub wrote: > Hi Philipp, Kim and Ivan, > > thank you for your feedback and input. > > It appears that XEP-0030 really doesn't fit in this situation, as it > cannot deal with offline devices and also doesn't really suite a > scenario where messages go to multiple receiving devices (carbons). > > This could be a strong indication towards not doing any fine grained > feature negotiation, which is unfortunate for testing out early > implementations (it makes getting started way harder). > > Maybe we can come up with a fix though. In case of OMEMO, the sender of > a message knows that the recipient has a device capable of OMEMO > encryption due to the fact, that that device published an OMEMO key > bundle in the first place. Same goes for OX. If the device that ends up > receiving the message is the same is another question of course ("It > appears that your device does not support OMEMO"...). > > XMPP probably lacks an offline feature detection mechanism, which > functions as a device registry where the sender can determine, which > features are supported by the devices of the recipient even if those are > offline. > > A hacky solution for now could be to publish an equivalent to a feature > announcement into a pubsub node. The sender could then query that node > and determine, which devices support which features. This is of course a > bad bad downgrade attack vector, but this - or a similar mechanism - > could be worth another thought. > > Btw: I heard that some clients are storing client side preferences > inside PubSub. Does anyone happen to know if - and if so, how different > devices are identified/differentiated? Maybe this mechanism could be > further extended? > > Paul > > On 18.06.19 11:03, Philipp Hörist wrote: >> Hi, >> >> Im not quite sure what you want to negotiate, but making any part of the >> encryption process depending on disco info of a online resource is a fail. >> >> Feature negotiation in encryption process is a fail in General. Its simply >> not needed, we have 2 encryption methods right now (OMEMO and PGP) that >> dont depend on any kind of negotiation and this works fine. One of them >> even having full stanza encryption. >> >> The whole encryption process must be possible while the recipient is >> offline, for the whole process. Feature negotiations also imply that there >> are multiple features to handle differently which makes implementation more >> complicated. You have to think about multiple resources online which would >> support different kind of features, and other resources offline where you >> dont even know the features, this is a nightmare i would not even start to >> implement. >> >> Regards >> Philipp >> >> >> >> >> >> Am Di., 18. Juni 2019 um 10:38 Uhr schrieb Paul Schaub < >> vanitasvi...@fsfe.org>: >> >>> Hi Florian! >>> >>> Am 17.06.19 um 17:58 schrieb Florian Schmaus: >>>> On 15.05.19 16:53, Paul Schaub wrote: >>>>> Thank you very much for your eager interest and numerous replies >>>>> *cough*, in other words, Thank you Florian for your reply :D >>>>> >>>>> I'm not quite sure, how exactly the process of negotiating expected >>>>> encrypted elements would look like. >>>> XEP-0030 features mostly. >>>> >>>>> I can see that this would >>>>> make it easier for adopters to gradually start implementing support for >>>>> one feature at a time (like start with support for <body/> encryption >>>>> and then successively add support for other elements as well), but at >>>>> the same time I feel like this could enable "downgrade" attacks and >>>>> would diminish the "encrypt *all* the sensitive things"-approach that I >>>>> aim for. >>>> The fact that you can gradual start implementing it is just one of the >>>> advantages. Another major advantage is that we can start implementing >>>> it *right now*. >>>> >>>> I can not stress the "get it implemented right now" as advantage >>>> enough. For one, it allows us to get implementation experience early, >>>> which is something other E2EE approaches did not, which contributed to >>>> their failure. But more importantly, we are able to reduce the >>>> percentage of unencrypted plaintext, which is still to high at the >>>> moment. >>>> >>>> After we have secured plaintext, we can take the next step and look >>>> into securing metadata. But one step after another. I want to raise >>>> the floor for privacy first, and then the ceiling. There is no reason >>>> why we should try to tackle everything in one rush (thanks to XMPPs >>>> extensiblity property). In fact, I believe this is actually harmful >>>> because it prevents us from deloying privacy solutions because of >>>> endless discussions, while there is still plaintext on the wire. >>>> >>>> Let us start with getting rid of unencrypted messages first, and then >>>> we can focus on the metadata. We certainly should keep downgrade >>>> attacks in mind, but I don't believe that this is an argument against. >>> >>> Fair points. I will look into XEP-0030 then to figure out how one could >>> implement the feature negotiation. >>> >>>> >>>>> An alternative approach that some people suggested would be to replace >>>>> the envelopes content element with a normal message stanza. That way >>>>> implementations could simply decrypt that stanza, check it for forbidden >>>>> elements and remove those and then feed the cleaned stanza back into the >>>>> XML stream. That way the client wouldn't have to reimplement listeners >>>>> for all the events. On the other hand, the client would probably want to >>>>> somehow mark the decrypted stanza as end-to-end encrypted. >>>> Injecting stanzas that where never send by the server into the clients >>>> processing chain is an approach that is sometimes mentioned. It may >>>> appears to be a nifty trick at first, but I believe this is not an >>>> good idea for the following reasons: >>>> >>>> First, your premise that the client would not have to reimplement >>>> listeners is wrong. You still want to carry around the information >>>> that the data was protected by some mechanism, as you need to pass >>>> that information up to the application. Otherwhise the application can >>>> not tell the difference between a protected chat state and an >>>> unprotected one. >>>> >>>> Let's take Chat State Notifications (CSN, xep85) for example. A library >>> may >>>> implement a listener/callback/hook once such a notificaiton arrives >>>> that looks like this: >>>> >>>> chatStateChange(Chat chat, ChatState chatState, Message message) >>>> >>>> Now with protected CSNs you most certainly want to extend the callback >>>> with the information wheter or not the CSN was protected or not: >>>> >>>> chatStateChange(Chat chat, ChatState chatState, Message message, >>>> SecurityInformation securityInformation) >>>> >>>> Which allows the user to retrieve the information about the used >>>> encryption protocol, if any, from the SecurityInformation >>>> object. Otherwhise the information is not available. >>>> >>>> Secondly it feigns events that never happend. Those constructs turn >>>> usually out to be error prone and fragile. Think for example of Stream >>>> Management: Now you have to ensure that those fake received stanzas are >>>> not counted. >>> >>> >>> Good points. Especially the Stream Management stuff is something I >>> haven't considered. >>> >>> Thank you for your insights :) >>> >>> _______________________________________________ >>> 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 _______________________________________________
