[Standards] Proposed XMPP Extension: Stanza Content Encryption
georg at op-co.de
Mon Jun 24 16:58:05 UTC 2019
* Jonas Schäfer <jonas at wielicki.name> [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,
- 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.
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.
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.
|| http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++
|| gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ ||
|| Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? ||
++ IRCnet OFTC OPN ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Standards