[Standards] Proposed XMPP Extension: Stanza Content Encryption

Dave Cridland dave at cridland.net
Mon Jun 24 21:23:40 UTC 2019

On Mon, 24 Jun 2019 at 17:58, Georg Lukas <georg at op-co.de> wrote:

> * 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.
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190624/ce3ed177/attachment-0001.html>

More information about the Standards mailing list