[Standards] Proposed XMPP Extension: Stanza Content Encryption

Dave Cridland dave at cridland.net
Mon Jun 24 15:42:18 UTC 2019


On Wed, 19 Jun 2019 at 16:00, Jonas Schäfer <jonas at wielicki.name> wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Stanza Content Encryption
> Abstract:
> The Stanza Content Encryption (SCE) protocol is intended as a way to
> allow clients to securely exchange arbitrary extension elements using
> different end-to-end encryption schemes.
>
> URL: https://xmpp.org/extensions/inbox/xep-sce.html
>
>
This seems like a problem worth solving, and this seems like it's the right
first step.

I'd like to see, ultimately, every E2EE mechanism we have standardized on
using a single definition of what elements can be encrypted and what format
the encrypted message has, and this seems to be a good step along the path
toward providing such a definition.

Non-blocking comments follow (no need to address these before publication,
or, indeed, at all):

1) I'm a little thrown by the <envelope/> element. It's an element which
has no actual definition of content beyond "Your encryption mechanism
decides what goes here". There's no definition of where it goes, either -
§6 implies it goes in place of the <payload/> element for OMEMO, but that's
about it. It feels to me as if each E2EE mechanism would have to define
this itself, and that raises the question of whether this element even
needs a definition in this document.

2) This document is very light on definitions - I think it's fairly obvious
what the elements are, but it doesn't go out of its way to eliminate the
guesswork.

3) I don't think the "decrypt" pathway is quite right. I think it's:

Pre) A client MUST have a policy on which elements must be encrypted, and
which MAY be encrypted. Clients need not consider if any elements MUST NOT
be encrypted during decrypt.

a) From the original stanza, remove any elements which are (by policy) set
to be always encrypted.

b) From the <content/> element, copy any metadata to the stanza, marking as
encrypted. Where the metadata exists, a client MAY ignore (and discard) the
original, or MAY emit an error (for example, if the "to" or "from" address
mismatches, this might generate an error).

c) From the <payload/> element, copy any elements to the stanza (marking as
encrypted). Again, if the elements exist, a client MAY ignore (and discard)
the original, add the new one alongside, or generate an error. (An example
is that is a security label differs, a client MAY choose to trust its
server and use the original, ignore it and use the encrypted version, or
check to see if the different label is a valid transformation via
equivalent policy matching).

This differed from your suggestion because a hint really doesn't matter if
it *is* encrypted as well - it's just useless to the server there. But if
another metadata element were present unencrypted *and* encrypted, it might
be rather important - as the security label example shows. Equally, things
like <delay/> get added by intermediaries, and those are fine except for
any delay stamp from the originating client.

This also means that §8 is only for encryption, probably isn't a
"blacklist" as such, and is probably OK being a rule of thumb.

In any case, these all feel like things we can sort out when it has a
number.

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


More information about the Standards mailing list