Hi, Yeah im also for something strict that is easy to implement.
so ignore everything except for a whitelist all 0359 elements because we want to deduplicate before decryption body, because of fallback when we cant decrypt EME (XEP-0380) also when we are not able to decrypt delay, although i dont know what daniel needs this for before decryption. regards Philipp 2017-12-09 12:06 GMT+01:00 Daniel Gultsch <[email protected]>: > 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] > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
