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 _______________________________________________
