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