On Wed, 19 Jun 2019 at 16:00, Jonas Schäfer <jo...@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.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
