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

Daniel Gultsch daniel at gultsch.de
Sat Dec 9 11:06:06 UTC 2017


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


More information about the Standards mailing list