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 _______________________________________________
