[Standards] XMPP Council Minutes 2018-06-06

Georg Lukas georg at op-co.de
Fri Jun 22 16:36:10 UTC 2018


> http://logs.xmpp.org/council/2018-06-06/#15:01:24

> 3) Proposed XMPP Extension: OMEMO Media sharing - https://xmpp.org/extensions/inbox/omemo-media-sharing.html

This is a horrible protocol. Seriously. Still, it is better to have a
horrible protocol documented than to pass it on as tribal knowledge, so
I'm not going to -1 this on *formal* grounds. I have no hard feelings
regarding whether this should be "Informational" or "Historical" or just
a page on our wiki.

However, I have some objections on the protocol spec itself, in the
order of severity:

- the receiving side needs to determine whether the message contains "a
  valid aesgcm URL". While "contain" is not the same as "consist of",
  the question alone of what is a valid URL requires significant
  research and implementation effort. I already see implementations
  handling this by `if body.startsWith("aesgcm://")`
- The spec fails to address the typical failure scenarios:
  - what if the aesgcm URL is invalid?
  - what if the HTTP request fails permanently (file deleted)
  - what if the decryption of the downloaded file fails
  (that said, there is really no description for how to do the receiving
  side, besides of determining URL validity)
- The authentication tag size is not specified
- it is not clear from this spec whether key size and IV size are
  parameters to AES-GCM chosen by the XEP author or inherent properties
  of AES-GCM
- it is not defined what an "OMEMO message" is, I had to read that up in
  0384, where it is not formally defined either

The first three are my reasons for -1ing this XEP, but as there are
multiple other -1s, I'm not sure what you'll make of it.

> 4) Proposed XMPP Extension: Ephemeral Messages - https://xmpp.org/extensions/inbox/ephemeral-messages.html

-1 because I'm really not convinced of the need for a dedicated
<ephemeral> element around the body (and how to handle other elements of
the <message>), and because this interfaces poorly with multi-client
scenarios. The latter is not per-se a problem of this XEP, but of the
sad state of Hints and the practical irrelevance of <no-permanent-store/>


Georg
-------------- 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/20180622/5cba4f28/attachment.sig>


More information about the Standards mailing list