[Standards] Proposed XMPP Extension: Stanza Content Encryption

Georg Lukas 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,
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.

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.


Georg
-- 
|| 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...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190624/7bb0dfdc/attachment.sig>


More information about the Standards mailing list