From bfe58edcbaa4d6050a5c1a26a8ea2184f3e7c9b3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 26 Jan 2021 16:48:48 +0100 Subject: [PATCH] Accept inbox/omemo-media-sharing.xml as XEP-0454 --- xep-0454.xml | 93 ++++++++++++++++++++++++++++++++++++++++++++++++++++ xep.ent | 1 + 2 files changed, 94 insertions(+) create mode 100644 xep-0454.xml diff --git a/xep-0454.xml b/xep-0454.xml new file mode 100644 index 00000000..f261795e --- /dev/null +++ b/xep-0454.xml @@ -0,0 +1,93 @@ + + +%ents; +]> + + +
+ OMEMO Media sharing + An informal way of sharing media files despite limitations in the OMEMO encryption + &LEGALNOTICE; + 0454 + Experimental + Historical + Standards + Council + + XEP-0363 + XEP-0384 + + + + NOT_YET_ASSIGNED + + Daniel + Gultsch + daniel@gultsch.de + daniel@gultsch.de + + + 0.1.0 + 2021-01-26 + XEP Editor (jsc) + Accepted by vote of Council on 2021-01-13. + + + 0.0.2 + 2021-01-10 + egp + +
    +
  • Resubmitted on the Historical track.
  • +
  • Added a section on IANA considerations.
  • +
+
+
+ + 0.0.1 + 2018-05-31 + dg +

First draft.

+
+
+ +

&xep0384;, despite already being deployed in multiple clients, currently suffers from the limitation of only being able to encrypt the message body. The current strategy for a mid term solution is to gather experience on stanza content encryption by implementing &xep0373; and then later apply the gathered knowledge to OMEMO. However end users are demanding working, end-to-end encrypted media sharing right now. For that reason client developers came up with a temporary work around that that utilizes &xep0363; and puts the resulting URL and a symmetric key in the body of an OMEMO message. This XEP describes the technical details of the work around.

+
+ +
    +
  • OMEMO Media Sharing should be relatively easy to implement in clients that already support OMEMO and HTTP File Upload
  • +
  • Reutilize the same encryption mode, namely AES-256 in GCM mode, that is already used by OMEMO.
  • +
  • Use a relatively strict syntax to communicate the URL, the key and an optional thumbnail so receiving clients can easily differentiate it from regular messages.
  • +
+
+ +

An entity wishing to share an end-to-end encrypted file first generates a 32 byte random key and a 12 byte random IV. After successfully requesting a slot for HTTP upload the file can be encrypted with AES-256 in Galois/Counter Mode (GCM) on the fly while uploading it via HTTP. The authentication tag MUST be appended to the end of the file.

+

To share the file the entity converts the HTTPS URL, the key and the IV to an aesgcm:// URL. Both IV and key are converted to their hex representation of 24 characters and 64 characters respectively and concatenated for a total of 88 characters (44 bytes). The IV comes first followed by the key. The resulting string is put in the anchor part of the aesgcm URL.

+ +

Note: HTTP Upload has transport encryption as a MUST. Non HTTPS URLs MUST not be converted to the aesgcm URL scheme.

+

The resulting aesgcm URL is encrypted as an OMEMO message and send to the recipient(s).

+
+ +

The sending entity MAY also generate a thumbnail as a JPEG data uri and include that in the same message. The aesgcm:// and the data:image/jpep, are seperated by a new line character. The message SHOULD NOT include anything else. The JPEG thumbnail SHOULD be kept small (approximately 5KiB) to not run into into stanza size limitations. As a result the resulting thumbnail is considered to only be a very blury, very rough representation of the image.

+ +
+ +

The parser on the receiving end should be very strict and only display OMEMO message as shared media that contain a valid aesgcm URL or a valid aesgcm URL followed by a valid data uri seperated by a single new line character.

+

Traditional media sharing with HTTP Upload uses &xep0066; to repeat the URL from the body and thereby communicating that the URL is in fact meant as media attchment as opposed a clickable link. For the aesgcm URL scheme no such annotation is necessary as aesgcm URLs are considered unique enough and are never supposed to stand alone in a message.

+
+ +

When requesting the HTTP Upload slot and attempting on the fly encryption the requesting entity MUST take into account that the encrypted file size is larger then the original file due to the block mode of AES and the appended authentication tag. Most crypto libraries should have a method to calculate the size of the resulting file.

+
+ +

A aesgcm URL MUST never be linkified and clients MUST NOT offer another direct way for users to open them in a browser as this could leak the anchor with the encryption key to the server operator. This is also the reason the aesgcm URL was choosen in the first place to prevent users from accidentally opening a HTTP URL in the browser.

+
+ +

The aesgcm scheme is not registered at the IANA, and it probably shouldn’t be as it is mostly a hack in order to work around the limitations of &xep0384; version 0.3.0 with regards to the extensibility, as this extension could only encrypt the <body/> of a message.

+
+
diff --git a/xep.ent b/xep.ent index 6f5b3252..fc025927 100644 --- a/xep.ent +++ b/xep.ent @@ -1618,3 +1618,4 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates Stanza Multiplexing (XEP-0451) XEP-0451: Stanza Multiplexing <https://xmpp.org/extensions/xep-0451.html>." > MUC Mention Notifications (XEP-0452) XEP-0452: MUC Mention Notifications <https://xmpp.org/extensions/xep-0452.html>." > DOAP usage in XMPP (XEP-0453) XEP-0453: DOAP usage in XMPP <https://xmpp.org/extensions/xep-0453.html>." > +OMEMO Media sharing (XEP-0454) XEP-0454: OMEMO Media sharing <https://xmpp.org/extensions/xep-0454.html>." >