[Standards] XEP-0374: How to handle conflicting stanza elements?

Philipp Hörist philipp at hoerist.com
Sat Dec 9 11:40:42 UTC 2017


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 <daniel at gultsch.de>:

> 2017-12-09 10:20 GMT+01:00 Florian Schmaus <flo at geekplace.eu>:
> > 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: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20171209/be90983e/attachment.html>


More information about the Standards mailing list