Re: [Standards] OX questions/remarks
Hey! Am 27.08.22 um 17:25 schrieb Tim Henkes: Hi, I'm implementing OX and have a bunch of questions/remarks that I would like to hear the authors' (or really anybodies') perspectives on. In no particular order: 1. Section 8.1 tells me to be prepared to find multiple public keys in "[...] the Personal Eventing Protocol node.". The XEP specifies multiple PEP nodes that could be meant here, but I can't make sense of that warning for any of them. If the Public-Key Data Node (4.1) is meant, then multiple keys in that node would be weird, since the node URI is built with the fingerprint of the contained key. If the Public Key Metadata Node (4.2) is meant, then well yeah, it contains a list... Am I missing the point of 8.1, or is it maybe a leftover? I *think* this is about public key certificates comprised of multiple (sub-)keys (e.g. an ECDSA primary key + ECDSA/ECDH subkeys). Those are the norm for EC keys, so maybe to reduce the potential for confusion we should remove this statement entirely? 5. It should be emphasized that the public keys list has to updated not only when a new public key is added, but also when an existing public key is updated. It is mentioned in 4.2 but doesn't receive enough emphasis IMO. This is required since public keys can be updated without their fingerprints changing, and there needs to be a way to detect that. This rationale should be given in the specification too. I agree. 9. 5.4 point 3. As far as I understand from RFC 4880, a "Symmetric-Key Encrypted Session Key" packet encrypts a symmetric key with a passphrase. The XEP only talks about a symmetric key. So, do you want me to: - use the backup code as the symmetric key and generate a passphrase/let the user enter a passphrase? - use the backup code as the passphrase and have GPG think of a symmetric key/derive one from the passphrase? The implementation is supposed to use the backup code as the passphrase to derive a symmetric key from via an S2K mechanism. See https://www.rfc-editor.org/rfc/rfc4880#section-3.7.2.2 For gpg you would use the backup code as input for `gpg -c`. Paul ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] OX questions/remarks
Hi, I'm implementing OX and have a bunch of questions/remarks that I would like to hear the authors' (or really anybodies') perspectives on. In no particular order: 1. Section 8.1 tells me to be prepared to find multiple public keys in "[...] the Personal Eventing Protocol node.". The XEP specifies multiple PEP nodes that could be meant here, but I can't make sense of that warning for any of them. If the Public-Key Data Node (4.1) is meant, then multiple keys in that node would be weird, since the node URI is built with the fingerprint of the contained key. If the Public Key Metadata Node (4.2) is meant, then well yeah, it contains a list... Am I missing the point of 8.1, or is it maybe a leftover? 2. What's the "set pubsub#send_last_published_item to 'on_sub' or 'never'" about? Why do you take my only chance of staying up-to-date with the published data? If I don't want updates, I'll do it the PEP way and just don't advertise "+notify" for the node. 3. 4.5 mandates to set deliver_payloads to false for all PEP nodes, probably to optimize PEP update traffic for clients coming online. Leaving aside the maybe subjective question of whether that's overkill, there are two problems with this: - The XEP should mandate that updates to the metadata node use a different item id, otherwise I don't know of a way to find out whether the item's content has changed without payload - There are no PEP updates when following the spec, see 2., which makes deliver_payloads irrelevant 4. 4.1: "In absence of a use-case specific access model, it is RECOMMENDED to use the 'open' access model for the public key data node [...]." (similar sentence in 4.2) You can't really leave the access model up to use-cases, since use-cases are plural while the node is singular. How would you handle it if externally specified use-cases require clashing access models? I think the spec should just make the open access model a MUST. 5. It should be emphasized that the public keys list has to updated not only when a new public key is added, but also when an existing public key is updated. It is mentioned in 4.2 but doesn't receive enough emphasis IMO. This is required since public keys can be updated without their fingerprints changing, and there needs to be a way to detect that. This rationale should be given in the specification too. 6. 4.1 says about the data node that "[t]he publishing entity SHOULD set the PubSub item ID to the time the item is published [...]". This seems like a weird somewhat-duplication of the timestamp information in the metadata node. Is there a good reason for this? 7. Section 5 specifies a PEP node to "[...] synchronize the user's secret OpenPGP key.". First of all, as far as I understand the spec, it is not "the" secret key, but "one of the potentially many" secret keys. Second, there is a complete lack of protocol flow specification around that node. I don't see clients implementing "secret key synchronization" in an interoperable way based on the node definition alone. 8. Section 9 says that "[i]mplementation[s] MUST provide a way for the user to establish and assign trust to a public key.". Normative language for UX-related stuff in protocol specifications is always a spicy topic by itself and is only deemed appropriate in rare and specific cases. This is a case that feels extremely misplaced to me, especially given that the beginning of the same paragraph reads "[...] [the XEP] does not define how the trust relation to [keys] should be established.". One could argue that this is an attempt at enforcing some user-friendliness, but the specification doesn't give a single use case that even involves the user. If anything, this should be part of OXIM, where I'd still oppose it. 9. 5.4 point 3. As far as I understand from RFC 4880, a "Symmetric-Key Encrypted Session Key" packet encrypts a symmetric key with a passphrase. The XEP only talks about a symmetric key. So, do you want me to: - use the backup code as the symmetric key and generate a passphrase/let the user enter a passphrase? - use the backup code as the passphrase and have GPG think of a symmetric key/derive one from the passphrase? Thanks, Tim ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)
+1 for MUST Am Samstag, 27. August 2022, 11:41:38 CEST schrieb Dave Cridland: > On Wed, 24 Aug 2022 at 07:56, Daniel Gultsch wrote: > > And yes we are currently implementing it. That's why I’m providing > > feedback on the XEP. And yes we are using it with compression and yes > > we do terminate TLS early and can’t use HT-* and yes we use PLAIN for > > regular logins too and therefor we don’t have an issue with the > > "downgrade" in security. > > Just on the TLS early termination, could you still support > tls-server-end-point, which (IIRC) doesn't need anything but a static > configuration of the server's certificate? > > It's also a SHOULD, I saw, in XEP-0440 - I'd be inclined to raise that to a > MUST, even though I prefer tls-exporter if possible, because it's very easy > to support. Assuming, of course, that any form of channel binding is > possible. > > Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Lemmy Community Check In
Hi all, It's been 4 months since I launched an XMPP focused Lemmy instance (TL;DR — like Reddit, but federated) and aside from an initial spam wave, so far it's going well, though it's also a little quiet. This post is just a check in to see how folks are feeling about it. I wanted to see how many XSF members have tried it, and whether they think it's a good idea to maintain going forwards? Have you had any good or bad experiences with it? Other thoughts about how things are going? We have the hosting for free for 1 year, so plenty of time left to try it and make a decision before then! If you haven't tried it, head over to https://community.xmpp.net/ and sign up for an account! —Sam -- Sam Whited ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)
On Wed, 24 Aug 2022 at 07:56, Daniel Gultsch wrote: > And yes we are currently implementing it. That's why I’m providing > feedback on the XEP. And yes we are using it with compression and yes > we do terminate TLS early and can’t use HT-* and yes we use PLAIN for > regular logins too and therefor we don’t have an issue with the > "downgrade" in security. > > Just on the TLS early termination, could you still support tls-server-end-point, which (IIRC) doesn't need anything but a static configuration of the server's certificate? It's also a SHOULD, I saw, in XEP-0440 - I'd be inclined to raise that to a MUST, even though I prefer tls-exporter if possible, because it's very easy to support. Assuming, of course, that any form of channel binding is possible. Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
