On Mon, 24 Jun 2019 at 17:58, Georg Lukas <[email protected]> wrote: > * Jonas Schäfer <[email protected]> [2019-06-19 17:00]: > > Title: Stanza Content Encryption > > This was long overdue. > > Some ideas for consideration: > > 1. I'd like to see certain fields of the <content/> being REQUIRED, > especially: > > - the from address > - maybe, possibly, the recipient address(es) > - a <time> (or <delay>) element > - the @id / origin-id > > The @id can be used for deduplication of the content, from/to can be > used to check whether an encrypted message was forwarded by an attacker > and the <delay> element ensures that replay attacks become visible. > > I'm assuming these comments aren't likely to become blocking?
I was actually wondering whether the right solution was to have a <forwarded/> element (XEP-0297) containing a copy of the stanza - that would then include from, to, id, etc, and we could stuff a delay in there too, either inside the stanza or outside the forwarded inside the content. Feels more reuse-y. > 2. In an encryption protocol idea that I briefly entertained, I was > pondering about actually embedding a regular XMPP <message> stanza > inside the encrypted container, with the from and to addresses being > bare JIDs of the respective parties. This _might_ make the XML parsing / > stanza reinjection part of things more straight-forward, but I'm not > going to die on this hill. > > I should totally read your entire message before replying to the first section. :-) > > 3. From §9: > > > After verifying the integrity of the <content/> element, the recipient > > needs to make sure that no blacklisted elements are found within the > > payload. Any forbidden elements MUST be dropped before the message is > > processed any further. > > I would prefer aborting the processing altogether instead of dropping > individual elements. In the context of security, a protocol is more > robust if it properly rejects unexpected border cases. > > As I noted, I don't think there's any harm in having (for example) hint included inside the encryption. I cannot think of a single attack that including additional encrypted data would usefully cause. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
