2017-12-09 10:20 GMT+01:00 Florian Schmaus <[email protected]>: > Hi Daniel, > > On 08.12.2017 20:29, Daniel Gultsch wrote: >> XEP-0374 states that »The child elements of the OpenPGP content >> element's <payload/> can be seen as stanza extension elements which >> are encrypted and signed. After the <openpgp/> element and the >> including <signcrypt/>, element was verified, they SHOULD be processed >> similar as if they had been direct extension elements of the stanza.« >> >> My interpretation is that this means that both! the regular stanza >> elements as well as the encrypted stanza elements will be processed. >> How do we make sure that they are not in conflict to each other; and >> or the 'outer' stanza elements can be used to manipulate the inner >> stanzas. >> >> A quick example from the top of my head; What if an attacker sneaks in >> a <replaced id="some-previous-id"/> in the 'outer'/unecrypted stanza. >> >> Or what if the outer as well as the inner stanza contain an origin-id. >> Which one counts? Do the inner elements always overwrite the outer? >> Should I not process any of the outer elements at all? What about a >> stanza-id in the outer part? >> >> What about SIMS and other message references in the outer stanza? I >> think one can find a lot of XEPs, which, included in the outer stanza >> will have some influence on the inner stanza that may or may not be >> desirable in a XEP that's about security. > > Exactly. That is why we deliberately underspecified this part because we > wanted to first gain experience from implementing it.
I would have appreciated at least a warning or a TODO or some kind of acknowledgment from the authors that they recognize this potential security problem and are working on a solution. Otherwise this XEP reads like 'Oh shit this is a security nightmare waiting to happen'. Furthermore I recognize that an 'Experimental' XEP is not meant for production use; given the history of the XSF where a lot of so called experimental XEPs are in production use I think a warning would be in order to not put the XEP - as is - into production use. > A first impression may be that the issue seems to be simply solved if we > say that elements within the <openpgp/> protection domain have > precedence, or even override, the ones in the outer stanza. > > But there are examples where both elements are "valid". The prime > example is a <body/> element in the outer stanza which contains a text > explaining that the message is encrypted. In your example the outer body is only valid until the inner body has been parsed. Afterwards it is no longer need. Thus a wording like 'ignore all outer elements when processing the inner once' would not hurt in that example. Do you have other/better example where a very strict 'ignore all elements outside' would not work? > Eventually I believe that we can find a sensible solution for this. We > just have to find a good wording that we put into the specification(s). > Note that OX consists of a base specification XEP and application > profiles (currently only one: The OX-IM XEP). My idea is to put generic > rules into OX, which then can be extended by profile specific rules in > the profile XEP. Complex rules (spread across multiple XEPs even) are a nightmare when it comes to security. I still propose a 'ignore everything' with a very, very limited whitelist (I can only think of stanza-id and maybe delay) > But before we do that, we really should first get some implementations > experience. It appears that you are at least considering working on an > implementation. Honestly not until these security issues are resolved. Trial and error is not really my cup of tea when it comes to something security related. Ether we can all agree on 'ignore everything outside' or I'm afraid there won't be a 'sensible' solution. Because complex white and black lists aren't future proof for upcoming XEPs that might 'leak' information about the inner elements or can help to manipulate them. I'm sorry if I'm coming of as too negative here. I like the idea of having a 'full-stanza'/no-forward secrecy/put your key in the cloud solution to E2EE. I wouldn't be writing long emails if I had no investment/interest in this XEP. But I have to convey how important it is to have very strict rules on inner elements vs outer elements. This can not be an afterthought. cheers Daniel _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
