From b06ddd6b8cbd822c83663ba4debc5d2a7be716d9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Poisson?= Date: Sun, 9 Oct 2022 22:33:55 +0200 Subject: [PATCH 1/6] Add ProtoXEP: OpenPGP for XMPP Pubsub Specifies an OpenPGP for XMPP (XEP-0373) profile for the pubsub use case. --- inbox/pubsub-encryption.xml | 203 ++++++++++++++++++++++++++++++++++++ 1 file changed, 203 insertions(+) create mode 100644 inbox/pubsub-encryption.xml diff --git a/inbox/pubsub-encryption.xml b/inbox/pubsub-encryption.xml new file mode 100644 index 00000000..539c3e07 --- /dev/null +++ b/inbox/pubsub-encryption.xml @@ -0,0 +1,203 @@ + + +%ents; +]> + + +
+ OpenPGP for XMPP Pubsub + Specifies an OpenPGP for XMPP (XEP-0373) profile for the pubsub use case. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + XEP-0001 + XEP-0004 + XEP-0060 + XEP-0373 + XEP-0374 + + + + oxps + + Jérôme + Poisson + goffi@goffi.org + goffi@jabber.fr + + + 0.0.1 + 2022-10-09 + jp +

First draft.

 + +
+ +

&xep0060; and &xep0163; are widely used XMPP features. However, items are published in plain text, making them readable by server administrators or anybody having administrator level access on the pubsub/PEP services.

+

Although this is not a problem for data intended to be published publicly, there are many cases where it may be desirable to make the data inaccessible to anybody but the selected recipients, or in other words to end-to-end encrypt the data.

+

This specification aims to provide an easy way to e2e encrypt items of a pubsub node, and to share access with other entities. It is compatible with all existing pubsub/PEP features, which makes it possible to use securily features such a geolocation, private blogs, private calendar events, data forms, etc. This specification is based on &xep0373;.

+ + +

The design goals of this XEP are:

+
    +
  • work with basic standard pubsub/PEP service, no extra feature needed;
    • +
  • be generic and work with any protocol using pubsub: once decrypted, the items should be parsable as if they were plain text;
    • +
  • be able to share with other entities the means to decipher the elements;
    • +
  • be able to easily share the means of decrypting items with new entities, even after the items have been published;
    • +
  • be able to modify the means of decryption to make the new elements inaccessible to certain entities even if they have had access to the previous elements;
    • +
+ + +
    +
  • e2ee: end-to-end encryption
    • +
  • Shared Secret: a cryptographically strong random string used to symmetrically encrypt items
    • +
  • Encrypted Node: pubsub node whose items are end-2-end encrypted using this protocol.
    • +
+ + +

To encrypt a pubsub node, each item is symmetrically encrypted with a shared secret using OpenPGP symmetric encryption. The secret is shared with other entities using e2e encrypted messages with &xep0374;. If an entity's access is revoked or a shared secret may have been compromised, a new shared secret is generated and new items are encrypted with it.

+ + + + +

Juliet wants to create a private blog (using &xep0277;) that she only share with her confidante and her lover. To make sure that her family, who manages her XMPP server, can't read the content, she want to use end-to-end encryption.

+

To do so, her client generates a "shared secret" by generating a cryptographically strong key that will be used to symmetrically encrypt new items. This key MUST be associated with an ID, which MUST be an unique sequence of characters usable in an XML attribute. She will later share this key with entities allowed to access the blog as explained below.

+

From now on, all items that Juliet publishes on the node SHOULD be symmetrically encrypted with the shared secret by using OpenPGP symmetric encryption.

+

To publish an encrypted item, an <encrypted/> element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace MUST be used as payload. This element MUST contain a 'secret' attribute whose value is the ID of the shared secret used. The content of the element is a base64 encoded Symmetric-Key Encrypted Session Key Packet as specified at RFC 4880 § 5.3 (in a similar way as secret key backup is encoded in XEP-0373). The encrypted content is the item payload that would normally be used.

+

The encrypted node SHOULD have a "whitelist" access model as specified in &xep0060;. Juliet's client ensure that either by creating a new node with suitable access model, or by changing the access model of existing node.

+ + + + + + + + + + +]]> + + + + +

Now that Juliet has started to publish encrypted items on a blog, she wants to share the secret key with her confidante and her lover. To do so she uses a e2ee &MESSAGE; stanza as specified in &xep0374;, in which she encrypt a <shared-secret/> element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace. This element MUST have the following attributes:

+
    +
  • a 'timestamp' attribute whose value is the datetime of the shared key generation. Datetime format is specified in &xep0082;.
    • +
  • a 'jid' attribute with bare JID of the pubsub/PEP service;
    • +
  • a 'node' attribute with the name of the encrypted node;
    • +
  • an 'id' attribute with the ID of the shared secret;
    • +
  • if the key is revoked (due to shared secret rotation), it must have a 'revoked' attribute with the value "true".
    • +
+

The <shared-secret/> SHOULD have a 'type' attribute whose value is the pubsub#type that the node would have if it were plain text (i.e. the semantic type information of decrypted data in the node, usually the namespace of the decrypted payload).

+

The content of the <shared-secret/> element MUST be the base64 encoded shared secret.

+

Entities MUST always use the most recently generated shared secret to encrypt new items (the 'timestamp' attribute is used to check generation date and time).

+ +

+ Following example only show the <shared-secret> payload, as it is normally put as an encrypted payload of <openpgp/> element of a &xep0374; message. +

+ + + + ]]> + +

note: we use a &xep0374; &MESSAGE; instead of PEP or Pubsub to transmit the shared secret for several reasons:

+
    +
  • Shared secret would have to be encrypted for all entities allowed to decrypt the items, and re-encrypted each time there is a new entity. While acceptable for a small number of entities, this doesn't scale as well as separated &MESSAGE;;
    • +
  • The item containing the shared secret would need to keep all previous shared secrets in case of secret rotation (see below). At some point, there would be a risk to reach stanza maximum size limit of one server;
    • +
  • Using a well-known pubsub node or pubsub item id would mean than the location of the encrypted shared secret would be known. While not enough to get the secret, that's better to hide it in encrypted messages flow;
    • +
+ + + +

If there is any doubt about the compromise of a shared secret or if access to the encrypted node is revoked for an entity, the shared secret SHOULD BE rotated.

+

To rotate a key, a &xep0374; message must be sent to all people which got the shared secret, with an encrypted <revoke/> element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace, which MUST have an 'id' attribute whose value is the shared secret ID. Optionally, the <revoke/> element MAY have one or more <reason/> child element(s) which contain a human readable message explaining the reason of the revocation. The <reason/> element MAY contain an 'xml:lang' attribute with the language code of the text, and there MAY be several <reason/> elements if and only if they have distinct xml:lang. A revoked key MUST NOT be used to encrypt new items.

+

Then a new shared secret MUST be generated and transmitted to all participants (excluding those who have seen their access revoked) as explained in Transmit Shared Secret.

+

Note that if an entity's access is revoked, it SHOULD also be removed from the node's whitelist (if "whitelist" has been used as access model as recommended).

+

+ Following example only show the <revoke/> payload, as it is normally put as an encrypted payload of <openpgp/> element of a &xep0374; message. +

+ + Revoked access from an entity + + ]]> +

Items published before the key rotation SHOULD NOT be re-encrypted as it would be resource intensive, and revoked entities may have made a copy.

+

When access to the shared secret is granted to a new entity, all previously used keys SHOULD be transmitted (with their 'revoked' attribute set to "true" as explained in Transmit Shared Secret.) along with the currently used shared secret. This allows the new entity to decrypt the items encrypted with the old keys. The <shared-secret/> elements can either be sent in the same encrypted payload of a single &xep0374; &MESSAGE;, or split into multiple encrypted &MESSAGE;, it's up to the implementation to decide which is better (keep in mind that too many shared secrets in a single message may reach the maximum stanza size limit at some point, even if this limit is not likely to be reached for most usual cases).

+ + + + + + +

When &xep0470; are used, the attachment node SHOULD have the same access model (i.e. whitelist as recommended in Security Considerations) as the encrypted node, with authorized entities synchronized (this should be done automatically for fully compliant services). The items published to attachment node itself MUST be encrypted using this protocol. Due to validity check of attachment items, the encrypted element MUST be a child of a XEP-0470's <attachments/> element, instead of being the <item/> payload as usual. Note that this will prevent the summary feature to work with encrypted elements, and the end-user client will have to do the summary itself, this is an inevitable trade-off when using e2ee.

+

The "pubsub#type" of an encrypted item is always "urn:xmpp:openpgp:pubsub:0", thus no information is leaked on the content of the node, and all encrypted node can easily be retrieved by using &xep0462;.

+

Note that encrypted items MAY be mixed with plain text items: for instance if a blog is public, but some of its items are private. However the proper handling of this use case is out of scope of this specification.

+

To transmit the shared secret, an other e2e encryption algorithm than &xep0374; MAY be used as long as the elements containing the secret are end-to-end encrypted. For instance, &xep0384; (version 2 or more) with &xep0420; could be used. As OpenPGP is necessary to decrypt items, &xep0374; seems the most appropriate choice.

+ + + +

If a client supports the protocol specified in this XEP, it MUST advertise it by including the "urn:xmpp:openpgp:pubsub:0" discovery feature in response to a &xep0030; information request:

+ + + +]]> + + + ... + + ... + +]]> + + + +
    +
  • To limit the surface of attack, the access model of an encrypted node should be set to "whitelist" and only people having the shared key should be allowed to retrieve encrypted items.
    • +
  • If the shared key is compromised, or a user access is revoked, the key MUST be rotated. However, only new items are encrypted with the new key, any previous item should be considered as compromised too.
    • +
  • Sometimes client may use metadata to construct item ID, this is notably the case for some &xep0277; implementation, as the resulting item ID is used to generate user friendly URLs. To avoid metadata leakage, clients SHOULD NOT derivate the item ID from any data of the item when pubsub encryption is used.
    • +
  • Some protocols define prefixes for nodes, this is for instance the case for XEP-0277 Comments. If the prefix is not essential to make the feature work (which is the case for XEP-0277 comments), the client SHOULD NOT use the usual prefix to avoid leaking informations on the content of the node. The prefix defined in &xep0470; MUST be used as usually, as it is essential to retrieve the attachment node, and it's generic and thus doesn't leak information on the node content.
    • +
  • To decrypt archives and future items, clients most probably cache plain text version of items, and shared secret. If one device with access to an encrypted node is compromised, all items from the node should be considered compromised, and shared secret should be rotated.
    • +
  • For the same reason, client SHOULD encrypt data at rest (even if the device is stolen, data should not be accessible without some cryptographic key).
    • +
  • Note that only the shared key sender is authenticated (by &xep0374;), not the items publishers, meaning that encrypted items could be published by anybody in possession of the shared secret. Pubsub items authentication will be treated in a separated XEP.
    • +
+ + + +

TODO

+ + +

TODO

+ + +

TODO

+ + +

+ + From e403e4e84e80867cf3747eb7c1ffb9195cee3158 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Poisson?= Date: Mon, 10 Oct 2022 14:13:47 +0200 Subject: [PATCH 2/6] protoXEP OpenPGP for XMPP Pubsub: version 0.0.2 Remove useless reference to XEP-0374 + acknowledgements --- inbox/pubsub-encryption.xml | 33 ++++++++++++++++++--------------- 1 file changed, 18 insertions(+), 15 deletions(-) diff --git a/inbox/pubsub-encryption.xml b/inbox/pubsub-encryption.xml index 539c3e07..49cf46de 100644 --- a/inbox/pubsub-encryption.xml +++ b/inbox/pubsub-encryption.xml @@ -20,7 +20,6 @@ XEP-0004 XEP-0060 XEP-0373 - XEP-0374 @@ -31,6 +30,12 @@ goffi@goffi.org goffi@jabber.fr + + 0.0.2 + 2022-10-10 + jp +

Remove useless references to XEP-0374 + acknowledgements

 + 0.0.1 2022-10-09 @@ -41,7 +46,7 @@

&xep0060; and &xep0163; are widely used XMPP features. However, items are published in plain text, making them readable by server administrators or anybody having administrator level access on the pubsub/PEP services.

Although this is not a problem for data intended to be published publicly, there are many cases where it may be desirable to make the data inaccessible to anybody but the selected recipients, or in other words to end-to-end encrypt the data.

-

This specification aims to provide an easy way to e2e encrypt items of a pubsub node, and to share access with other entities. It is compatible with all existing pubsub/PEP features, which makes it possible to use securily features such a geolocation, private blogs, private calendar events, data forms, etc. This specification is based on &xep0373;.

+

This specification aims to provide an easy way to e2e encrypt items of a pubsub node, and to share access with other entities. It is compatible with all existing pubsub/PEP features, which makes it possible to use securily features such a geolocation, private blogs, private calendar events, data forms, etc.

The design goals of this XEP are:

@@ -61,7 +66,7 @@ -

To encrypt a pubsub node, each item is symmetrically encrypted with a shared secret using OpenPGP symmetric encryption. The secret is shared with other entities using e2e encrypted messages with &xep0374;. If an entity's access is revoked or a shared secret may have been compromised, a new shared secret is generated and new items are encrypted with it.

+

To encrypt a pubsub node, each item is symmetrically encrypted with a shared secret using OpenPGP symmetric encryption. The secret is shared with other entities using e2e encrypted messages with &xep0373;. If an entity's access is revoked or a shared secret may have been compromised, a new shared secret is generated and new items are encrypted with it.

 @@ -91,7 +96,7 @@ -

Now that Juliet has started to publish encrypted items on a blog, she wants to share the secret key with her confidante and her lover. To do so she uses a e2ee &MESSAGE; stanza as specified in &xep0374;, in which she encrypt a <shared-secret/> element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace. This element MUST have the following attributes:

+

Now that Juliet has started to publish encrypted items on a blog, she wants to share the secret key with her confidante and her lover. To do so she uses a e2ee &MESSAGE; stanza by using a <signcrypt/> as specified in XEP-0373 "Exchanging OpenPGP Encrypted and Signed Data". The encrypted payload of the <signcrypt/> MUST contain a <shared-secret/> element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace. This element MUST have the following attributes:

  • a 'timestamp' attribute whose value is the datetime of the shared key generation. Datetime format is specified in &xep0082;.
  • a 'jid' attribute with bare JID of the pubsub/PEP service;
    • @@ -104,9 +109,9 @@

    Entities MUST always use the most recently generated shared secret to encrypt new items (the 'timestamp' attribute is used to check generation date and time).

    - Following example only show the <shared-secret> payload, as it is normally put as an encrypted payload of <openpgp/> element of a &xep0374; message. + Following example only show the <shared-secret/> element, as it is normally put as an encrypted payload of &xep0373; <signcrypt/> payload.

    - ]]> -

    note: we use a &xep0374; &MESSAGE; instead of PEP or Pubsub to transmit the shared secret for several reasons:

    +

    note: we use &MESSAGE; instead of PEP or Pubsub to transmit the shared secret for several reasons:

    • Shared secret would have to be encrypted for all entities allowed to decrypt the items, and re-encrypted each time there is a new entity. While acceptable for a small number of entities, this doesn't scale as well as separated &MESSAGE;;
    • The item containing the shared secret would need to keep all previous shared secrets in case of secret rotation (see below). At some point, there would be a risk to reach stanza maximum size limit of one server;
      • @@ -128,20 +133,19 @@

      If there is any doubt about the compromise of a shared secret or if access to the encrypted node is revoked for an entity, the shared secret SHOULD BE rotated.

      -

      To rotate a key, a &xep0374; message must be sent to all people which got the shared secret, with an encrypted <revoke/> element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace, which MUST have an 'id' attribute whose value is the shared secret ID. Optionally, the <revoke/> element MAY have one or more <reason/> child element(s) which contain a human readable message explaining the reason of the revocation. The <reason/> element MAY contain an 'xml:lang' attribute with the language code of the text, and there MAY be several <reason/> elements if and only if they have distinct xml:lang. A revoked key MUST NOT be used to encrypt new items.

      +

      To rotate a key, a &MESSAGE; must be sent to all people which got the shared secret. The &MESSAGE; MUST contain a XEP-0373 <signcrypt/> element whose payload is an encrypted <revoke/> element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace, which MUST have an 'id' attribute whose value is the shared secret ID. Optionally, the <revoke/> element MAY have one or more <reason/> child element(s) which contain a human readable message explaining the reason of the revocation. The <reason/> element MAY contain an 'xml:lang' attribute with the language code of the text, and there MAY be several <reason/> elements if and only if they have distinct xml:lang. A revoked key MUST NOT be used to encrypt new items.

      Then a new shared secret MUST be generated and transmitted to all participants (excluding those who have seen their access revoked) as explained in Transmit Shared Secret.

      Note that if an entity's access is revoked, it SHOULD also be removed from the node's whitelist (if "whitelist" has been used as access model as recommended).

      - Following example only show the <revoke/> payload, as it is normally put as an encrypted payload of <openpgp/> element of a &xep0374; message. + Following example only show the <revoke/> element, as it is normally put as an encrypted payload of &xep0373; <signcrypt/> payload.

      - Revoked access from an entity ]]>

      Items published before the key rotation SHOULD NOT be re-encrypted as it would be resource intensive, and revoked entities may have made a copy.

      -

      When access to the shared secret is granted to a new entity, all previously used keys SHOULD be transmitted (with their 'revoked' attribute set to "true" as explained in Transmit Shared Secret.) along with the currently used shared secret. This allows the new entity to decrypt the items encrypted with the old keys. The <shared-secret/> elements can either be sent in the same encrypted payload of a single &xep0374; &MESSAGE;, or split into multiple encrypted &MESSAGE;, it's up to the implementation to decide which is better (keep in mind that too many shared secrets in a single message may reach the maximum stanza size limit at some point, even if this limit is not likely to be reached for most usual cases).

      - +

      When access to the shared secret is granted to a new entity, all previously used keys SHOULD be transmitted (with their 'revoked' attribute set to "true" as explained in Transmit Shared Secret.) along with the currently used shared secret. This allows the new entity to decrypt the items encrypted with the old keys. The <shared-secret/> elements can either be sent in the same encrypted payload of a single &MESSAGE;, or split into multiple encrypted &MESSAGE;, it's up to the implementation to decide which is better (keep in mind that too many shared secrets in a single message may reach the maximum stanza size limit at some point, even if this limit is not likely to be reached for most usual cases).

       @@ -150,7 +154,6 @@

      When &xep0470; are used, the attachment node SHOULD have the same access model (i.e. whitelist as recommended in Security Considerations) as the encrypted node, with authorized entities synchronized (this should be done automatically for fully compliant services). The items published to attachment node itself MUST be encrypted using this protocol. Due to validity check of attachment items, the encrypted element MUST be a child of a XEP-0470's <attachments/> element, instead of being the <item/> payload as usual. Note that this will prevent the summary feature to work with encrypted elements, and the end-user client will have to do the summary itself, this is an inevitable trade-off when using e2ee.

      The "pubsub#type" of an encrypted item is always "urn:xmpp:openpgp:pubsub:0", thus no information is leaked on the content of the node, and all encrypted node can easily be retrieved by using &xep0462;.

      Note that encrypted items MAY be mixed with plain text items: for instance if a blog is public, but some of its items are private. However the proper handling of this use case is out of scope of this specification.

      -

      To transmit the shared secret, an other e2e encryption algorithm than &xep0374; MAY be used as long as the elements containing the secret are end-to-end encrypted. For instance, &xep0384; (version 2 or more) with &xep0420; could be used. As OpenPGP is necessary to decrypt items, &xep0374; seems the most appropriate choice.

      @@ -184,7 +187,7 @@
    • Some protocols define prefixes for nodes, this is for instance the case for XEP-0277 Comments. If the prefix is not essential to make the feature work (which is the case for XEP-0277 comments), the client SHOULD NOT use the usual prefix to avoid leaking informations on the content of the node. The prefix defined in &xep0470; MUST be used as usually, as it is essential to retrieve the attachment node, and it's generic and thus doesn't leak information on the node content.
    • To decrypt archives and future items, clients most probably cache plain text version of items, and shared secret. If one device with access to an encrypted node is compromised, all items from the node should be considered compromised, and shared secret should be rotated.
    • For the same reason, client SHOULD encrypt data at rest (even if the device is stolen, data should not be accessible without some cryptographic key).
      • -
    • Note that only the shared key sender is authenticated (by &xep0374;), not the items publishers, meaning that encrypted items could be published by anybody in possession of the shared secret. Pubsub items authentication will be treated in a separated XEP.
      • +
    • Note that only the shared key sender is authenticated (by &xep0373;'s <signcrypt/>), not the items publishers, meaning that encrypted items could be published by anybody in possession of the shared secret. Pubsub items authentication will be treated in a separated XEP.
    @@ -198,6 +201,6 @@

    TODO

    -

    +

    Thanks to Tim Henkes for his advices and NLNet foundation/NGI0 Discovery for funding.

     From bdadbb1fca5b5d5867159812f365b4934bb1c865 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Poisson?= Date: Mon, 10 Oct 2022 23:21:30 +0200 Subject: [PATCH 3/6] protoXEP OpenPGP for XMPP Pubsub: version 0.0.3 - Base64 is not needed for the key (it's a passphrase) - Specify that as least on should be encrypted for sender other devices - Recommend minimum length for shared secret --- inbox/pubsub-encryption.xml | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) diff --git a/inbox/pubsub-encryption.xml b/inbox/pubsub-encryption.xml index 49cf46de..bca34fb3 100644 --- a/inbox/pubsub-encryption.xml +++ b/inbox/pubsub-encryption.xml @@ -30,6 +30,18 @@ goffi@goffi.org goffi@jabber.fr + + 0.0.3 + 2022-10-10 + jp + +
      +
    • Base64 is not needed for the key (it's a passphrase)
      • +
    • Specify that as least on &MESSAGE; should be encrypted for sender other devices
      • +
    • Recommend minimum length for shared secret
      • +
    +     +     0.0.2 2022-10-10 @@ -72,7 +84,7 @@

    Juliet wants to create a private blog (using &xep0277;) that she only share with her confidante and her lover. To make sure that her family, who manages her XMPP server, can't read the content, she want to use end-to-end encryption.

    -

    To do so, her client generates a "shared secret" by generating a cryptographically strong key that will be used to symmetrically encrypt new items. This key MUST be associated with an ID, which MUST be an unique sequence of characters usable in an XML attribute. She will later share this key with entities allowed to access the blog as explained below.

    +

    To do so, her client creates a "shared secret" by generating a cryptographically strong key that will be used to symmetrically encrypt new items. This key MUST be associated with an ID, which MUST be an unique sequence of characters usable in an XML attribute. She will later share this key with entities allowed to access or publish on the blog as explained below.

    From now on, all items that Juliet publishes on the node SHOULD be symmetrically encrypted with the shared secret by using OpenPGP symmetric encryption.

    To publish an encrypted item, an <encrypted/> element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace MUST be used as payload. This element MUST contain a 'secret' attribute whose value is the ID of the shared secret used. The content of the element is a base64 encoded Symmetric-Key Encrypted Session Key Packet as specified at RFC 4880 § 5.3 (in a similar way as secret key backup is encoded in XEP-0373). The encrypted content is the item payload that would normally be used.

    The encrypted node SHOULD have a "whitelist" access model as specified in &xep0060;. Juliet's client ensure that either by creating a new node with suitable access model, or by changing the access model of existing node.

    @@ -105,7 +117,8 @@
  • if the key is revoked (due to shared secret rotation), it must have a 'revoked' attribute with the value "true".

The <shared-secret/> SHOULD have a 'type' attribute whose value is the pubsub#type that the node would have if it were plain text (i.e. the semantic type information of decrypted data in the node, usually the namespace of the decrypted payload).

-

The content of the <shared-secret/> element MUST be the base64 encoded shared secret.

+

The content of the <shared-secret/> element MUST be the shared secret (i.e. the passphrase used to symmetrically encode items).

+

She send messages with the encrypted shared secret to her nurse, Romeo and herself (so her other devices get the shared secret too).

Entities MUST always use the most recently generated shared secret to encrypt new items (the 'timestamp' attribute is used to check generation date and time).

@@ -119,7 +132,7 @@ id='1234-abcd-5678-efgh' type='http://www.w3.org/2005/Atom' > - + ZSRD5lK9mz-5VHNyu2N1XLiJZ8I87jkv85ceZkVrOGA ]]> @@ -151,8 +164,10 @@ +

The shared secret and revocation SHOULD be generated by node owner.

+

&MESSAGE; with encrypted <shared-secret/> or <revoke/> elements MUST be sent to everybody who must have access to the node. At least one of the encrypted payload SHOULD be encrypted for the sender themselves (either by sending the &MESSAGE; directly to the sender, or to decrypt a copy received with &xep0280;), so other devices of the sender can get the shared secret too.

When &xep0470; are used, the attachment node SHOULD have the same access model (i.e. whitelist as recommended in Security Considerations) as the encrypted node, with authorized entities synchronized (this should be done automatically for fully compliant services). The items published to attachment node itself MUST be encrypted using this protocol. Due to validity check of attachment items, the encrypted element MUST be a child of a XEP-0470's <attachments/> element, instead of being the <item/> payload as usual. Note that this will prevent the summary feature to work with encrypted elements, and the end-user client will have to do the summary itself, this is an inevitable trade-off when using e2ee.

-

The "pubsub#type" of an encrypted item is always "urn:xmpp:openpgp:pubsub:0", thus no information is leaked on the content of the node, and all encrypted node can easily be retrieved by using &xep0462;.

+

The "pubsub#type" of an encrypted item is always "urn:xmpp:openpgp:pubsub:0", thus no information is leaked on the content of the node, and all encrypted nodes can easily be retrieved by using &xep0462;.

Note that encrypted items MAY be mixed with plain text items: for instance if a blog is public, but some of its items are private. However the proper handling of this use case is out of scope of this specification.

 @@ -188,6 +203,7 @@
  • To decrypt archives and future items, clients most probably cache plain text version of items, and shared secret. If one device with access to an encrypted node is compromised, all items from the node should be considered compromised, and shared secret should be rotated.
  • For the same reason, client SHOULD encrypt data at rest (even if the device is stolen, data should not be accessible without some cryptographic key).
  • Note that only the shared key sender is authenticated (by &xep0373;'s <signcrypt/>), not the items publishers, meaning that encrypted items could be published by anybody in possession of the shared secret. Pubsub items authentication will be treated in a separated XEP.
    • +
  • The shared secret should be long enough to avoid brute force attacks. A secret of at least 32 characters is recommended.
    • From e6e6cba2e5337c6afe0c284d1762e0c8f8bd2880 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Poisson?= Date: Wed, 12 Oct 2022 00:22:47 +0200 Subject: [PATCH 4/6] protoXEP OpenPGP for XMPP Pubsub: version 0.0.4 add a security note to indicate that and sender must be checked. --- inbox/pubsub-encryption.xml | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/inbox/pubsub-encryption.xml b/inbox/pubsub-encryption.xml index bca34fb3..42e6a02d 100644 --- a/inbox/pubsub-encryption.xml +++ b/inbox/pubsub-encryption.xml @@ -30,6 +30,16 @@ goffi@goffi.org goffi@jabber.fr + + 0.0.4 + 2022-10-12 + jp + +
      +
    • add a security note to indicate that <shared-secret/> and <revoke/> sender must be checked.
      • +
    +     +     0.0.3 2022-10-10 @@ -196,6 +206,7 @@
      +
    • When receiving a <shared-secret/> or a <revoke/> element, the receiving client MUST ensure that the signing sender is the same as the one for all known shared secrets of this pubsub node. This prevents a malicious actor for misleading the client into using a non-legitimate secret.
    • To limit the surface of attack, the access model of an encrypted node should be set to "whitelist" and only people having the shared key should be allowed to retrieve encrypted items.
    • If the shared key is compromised, or a user access is revoked, the key MUST be rotated. However, only new items are encrypted with the new key, any previous item should be considered as compromised too.
    • Sometimes client may use metadata to construct item ID, this is notably the case for some &xep0277; implementation, as the resulting item ID is used to generate user friendly URLs. To avoid metadata leakage, clients SHOULD NOT derivate the item ID from any data of the item when pubsub encryption is used.
      • From 19a87bfc38ed271d5a39f1b8c3664563d3150336 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Poisson?= Date: Wed, 12 Oct 2022 14:09:01 +0200 Subject: [PATCH 5/6] protoXEP OpenPGP for XMPP Pubsub: version 0.0.5 - add forgotten "timestamp" in example - add implementation node on double encryption - add clarification that sender should be a node owner --- inbox/pubsub-encryption.xml | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/inbox/pubsub-encryption.xml b/inbox/pubsub-encryption.xml index 42e6a02d..00235b07 100644 --- a/inbox/pubsub-encryption.xml +++ b/inbox/pubsub-encryption.xml @@ -31,9 +31,21 @@ goffi@jabber.fr - 0.0.4 + 0.0.5 2022-10-12 jp + +
        +
      • add forgotten "timestamp" in example
        • +
      • add implementation node on double encryption
        • +
      • add clarification that sender should be a node owner
        • +
      +       +       + + 0.0.4 + 2022-10-11 + jp
      • add a security note to indicate that <shared-secret/> and <revoke/> sender must be checked.
        • @@ -140,6 +152,7 @@ jid='pubsub.capulet.lit' node='123abc' id='1234-abcd-5678-efgh' + timestamp='2022-10-10T13:24:31Z' type='http://www.w3.org/2005/Atom' > ZSRD5lK9mz-5VHNyu2N1XLiJZ8I87jkv85ceZkVrOGA @@ -181,6 +194,10 @@

        Note that encrypted items MAY be mixed with plain text items: for instance if a blog is public, but some of its items are private. However the proper handling of this use case is out of scope of this specification.

        + +

        This specification uses &xep0373; independently of &xep0374;, implementations SHOULD avoid double encryption (e.g. by excluding <openpgp/> element qualified by 'urn:xmpp:openpgp:0' namespace from encryption by XEP-0374 implementation), and MUST ensure that element is correctly decrypted. Double encryption should be checked, and the <openpgp/> element MUST be decrypted even if OXIM (XEP-0374) is not being used.

        +         +

        If a client supports the protocol specified in this XEP, it MUST advertise it by including the "urn:xmpp:openpgp:pubsub:0" discovery feature in response to a &xep0030; information request:

        @@ -206,7 +223,7 @@
          -
        • When receiving a <shared-secret/> or a <revoke/> element, the receiving client MUST ensure that the signing sender is the same as the one for all known shared secrets of this pubsub node. This prevents a malicious actor for misleading the client into using a non-legitimate secret.
          • +
        • When receiving a <shared-secret/> or a <revoke/> element, the receiving client MUST ensure that the signing sender is the same as the one for all known shared secrets of this pubsub node (usually a node owner). This prevents a malicious actor for misleading the client into using a non-legitimate secret.
        • To limit the surface of attack, the access model of an encrypted node should be set to "whitelist" and only people having the shared key should be allowed to retrieve encrypted items.
        • If the shared key is compromised, or a user access is revoked, the key MUST be rotated. However, only new items are encrypted with the new key, any previous item should be considered as compromised too.
        • Sometimes client may use metadata to construct item ID, this is notably the case for some &xep0277; implementation, as the resulting item ID is used to generate user friendly URLs. To avoid metadata leakage, clients SHOULD NOT derivate the item ID from any data of the item when pubsub encryption is used.
          • From 8c41ff5c612b5dc22c9cb6d5e39583e9754bb4ae Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Poisson?= Date: Wed, 12 Oct 2022 14:35:50 +0200 Subject: [PATCH 6/6] protoXEP OpenPGP for XMPP Pubsub: version 0.0.6 - add forgotten "jid" and "node" attribute to - clarify that wrapper is used --- inbox/pubsub-encryption.xml | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/inbox/pubsub-encryption.xml b/inbox/pubsub-encryption.xml index 00235b07..d57ca7f5 100644 --- a/inbox/pubsub-encryption.xml +++ b/inbox/pubsub-encryption.xml @@ -30,6 +30,17 @@ goffi@goffi.org goffi@jabber.fr + + 0.0.6 + 2022-10-12 + jp + +
            +
          • add forgotten "jid" and "node" attribute to <revoke/>
            • +
          • clarify that <openpgp/> wrapper is used
            • +
          +           +           0.0.5 2022-10-12 @@ -130,7 +141,7 @@ -

          Now that Juliet has started to publish encrypted items on a blog, she wants to share the secret key with her confidante and her lover. To do so she uses a e2ee &MESSAGE; stanza by using a <signcrypt/> as specified in XEP-0373 "Exchanging OpenPGP Encrypted and Signed Data". The encrypted payload of the <signcrypt/> MUST contain a <shared-secret/> element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace. This element MUST have the following attributes:

          +

          Now that Juliet has started to publish encrypted items on a blog, she wants to share the secret key with her confidante and her lover. To do so she uses a e2ee &MESSAGE; stanza by using an <openpgp/> element wrapping a <signcrypt/> as specified in XEP-0373 "Exchanging OpenPGP Encrypted and Signed Data". The encrypted payload of the <signcrypt/> MUST contain a <shared-secret/> element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace. This element MUST have the following attributes:

          • a 'timestamp' attribute whose value is the datetime of the shared key generation. Datetime format is specified in &xep0082;.
          • a 'jid' attribute with bare JID of the pubsub/PEP service;
            • @@ -169,18 +180,19 @@

            If there is any doubt about the compromise of a shared secret or if access to the encrypted node is revoked for an entity, the shared secret SHOULD BE rotated.

            -

            To rotate a key, a &MESSAGE; must be sent to all people which got the shared secret. The &MESSAGE; MUST contain a XEP-0373 <signcrypt/> element whose payload is an encrypted <revoke/> element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace, which MUST have an 'id' attribute whose value is the shared secret ID. Optionally, the <revoke/> element MAY have one or more <reason/> child element(s) which contain a human readable message explaining the reason of the revocation. The <reason/> element MAY contain an 'xml:lang' attribute with the language code of the text, and there MAY be several <reason/> elements if and only if they have distinct xml:lang. A revoked key MUST NOT be used to encrypt new items.

            +

            To rotate a key, a &MESSAGE; must be sent to all people which got the shared secret. The &MESSAGE; MUST contain a XEP-0373 <openpgp/> element with a <signcrypt/> element whose payload is an encrypted <revoke/> element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace, which MUST have a 'jid' attribute whose value is the JID of the pubsub/PEP service where the node is, a 'node' attribute whose value is the name of the node, and an 'id' attribute whose value is the shared secret ID.

            +

            Optionally, the <revoke/> element MAY have one or more <reason/> child element(s) which contain a human readable message explaining the reason of the revocation. The <reason/> element MAY contain an 'xml:lang' attribute with the language code of the text, and there MAY be several <reason/> elements if and only if they have distinct xml:lang. A revoked key MUST NOT be used to encrypt new items.

            Then a new shared secret MUST be generated and transmitted to all participants (excluding those who have seen their access revoked) as explained in Transmit Shared Secret.

            Note that if an entity's access is revoked, it SHOULD also be removed from the node's whitelist (if "whitelist" has been used as access model as recommended).

            Following example only show the <revoke/> element, as it is normally put as an encrypted payload of &xep0373; <signcrypt/> payload.

            + Revoked access from an entity ]]> -

            Items published before the key rotation SHOULD NOT be re-encrypted as it would be resource intensive, and revoked entities may have made a copy.

            +

            Items published before the key rotation SHOULD NOT be re-encrypted as it would be resource intensive, and revoked entities may have made a copy anyway.

            When access to the shared secret is granted to a new entity, all previously used keys SHOULD be transmitted (with their 'revoked' attribute set to "true" as explained in Transmit Shared Secret.) along with the currently used shared secret. This allows the new entity to decrypt the items encrypted with the old keys. The <shared-secret/> elements can either be sent in the same encrypted payload of a single &MESSAGE;, or split into multiple encrypted &MESSAGE;, it's up to the implementation to decide which is better (keep in mind that too many shared secrets in a single message may reach the maximum stanza size limit at some point, even if this limit is not likely to be reached for most usual cases).