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] 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.