Hi Goffi, Thanks a lot for working on this, it's indeed a very interesting endeavor and has potential to make gateways more practical. The attempt to generalize, trying to describe payload and encryption algorithm (formatter and encrypter) independently seems like it is effectively overcomplicating things. Realistically, there aren't going to be a lot of situations where formatter and encrypter are not effective paired together. Further, because the gateway server is the one to decide which formatter to use (as the client is unable to know that on its own), it can likely do shenanigans there. Basically the more formatters a client implements, the more likely it is that these formatters have partial overlap, allowing the server to modify what content is displayed in the client. Ruling out illegal formatter+encrypter combinations on the protocol level reduces this risk drastically. Some modern encryption systems, like MLS, solve this issue by specifying the content type inside the encrypted+signed part of the message. In those cases, the formatter should never be specified by the gateway as it is implied from the encryption system. I see you already made an attempt with putting PGP/MIME into this framework. You are referencing OX to base your PGP part on it, however OX requires the recipient to verify that the PGP key has a user id in the form "xmpp:<bare-jid>" (this is a MUST in XEP-0373 § 3.2). As the gateway can't add new user ids to the PGP key and the other end is not aware of XMPP being involved, this is almost impossible to work out in practice. For PGP there are two popular payloads (outside OX) that are popular: - Plain. This is already supported via XEP-0027. - PGP/MIME. This is what you basically do this for. As you can see with this example, the generalization into formatter and encrypter is already not that helpful with the PGP usecase although it's one of the few that has two popular payload formats in real world. You tried to draft a specification for a MIME GRE Formatter. However, MIME is not a payload format. The payload inside PGP/MIME is an Internet Message (RFC 822 / 2822 / 5322). IMO, the following two things would make more sense to specify as XEPs: - A XEP that describes how to process rfc822 messages as a client and how to interpret them into XMPP. This could technically be used with a message/rfc822 type XEP-0481 <content> element - yes I hate me for even suggesting that - but also other things, including: - A second XEP that describes how to do PGP/MIME over XMPP (that is transporting PGP-encrypted RFC822 messages and discovering the keys to use for this), with the obvious intent of it to be used in the context of gateways, but technically 100% valid to be used in other contexts. A note on the procedure on specifying this: I think it would have been better to first merge all of the three ProtoXEPs you proposed now in a single Experimental XEP and see from there how it develops. The XEP can still be split up in the same way as you did right now before moving to Stable, but to me it feels more natural to have them all in one, as changes to one are likely to affect the others and maybe during the development we discover that a different way to split them makes more sense. Marvin On Mon, 2025-01-13 at 21:30 +0100, Goffi wrote:

Le lundi 13 janvier 2025, 12:50:48 heure normale d’Europe centrale Daniel Gultsch a écrit :

...

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Gateway Relayed Encryption Abstract: This specification describes a mechanism for end-to-end encryption with gateways that is compatible with third-party networks.

URL: https://xmpp.org/extensions/inbox/gateway-relayed-encryption.html

The Council will decide in the next two weeks whether to accept this proposal as an official XEP. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org

Hello,

some information on this one :

- I have a working implementation with the email gateway I'm currently working on. - I've done minimal specification for OpenPGP and MIME, as I wanted to work on it during experimental phase if it get accepted. Notably I plan to specify more the mapping of XMPP data to MIME header, and to specify the signature with OpenPGP. - authentication is not handled, that's another issue with gateways which must be tackled separately. However, I think that it's easier to handle: with a similar mechanism we can ask the client to do whatever challenge is required. - if there is interest in this, I hope that we can discuss it at incoming summit.

Best, Goffi

Hi Daniel, Le mardi 14 janvier 2025, 09:18:21 heure normale d’Europe centrale Daniel Gultsch a écrit :

Hi Goffi,

I’m a bit conflicted on that. I’m a big proponent of using Experimental as a base for people to do experiments in (and I’m working hard to move everything that turned out to be both useful and working to stable). Furthermore I believe that "hybrid bridges" are something that we need to experiment with if we want to maintain our concept of bridges/gateways.

However as someone who has actually implemented XMPP<->PGP Encrypted emails before I’m also seeing a lot of challenges in this particular one and in hybrid bridges in general.

I know that this is a challenge, and I think that experimental is for that: having a written specification help people to understand the feature and have test implementation. I believe that gateway e2ee is doable and necessary, and I have a working implementation in my email gateway (however, not yet perfect, as signing is not done at the moment, still better than plain text).

I’m with Marvin on this one. How about instead of handing out 3 XEP numbers we give you one to do your experiments in and we take it from there. I would like to see at least one other (experimental) gateway to proof out that this can actually be generalized.

Sure, as I've said in the other reply, I'm absolutely fine with that. Lets see if other people are interested in working on that. Of course there are not so many gateway developers, so it's more difficult to find than client developers. Best, Goffi

Hence OX could simply state that recipients must verify the signature. And that only if the PGP message is supposed to originate from within XMPP it the user ID should contain the sender's XMPP address.

Honestly, why does OX care at all about user ID? It already knows what exact key is allowed, so what user id it does or doesn't have doesn't really affect security by much. OMEMO doesn't have user ids at all for example.

Hi, thank you for all your feedbacks, and sorry for the late answer, I'm overwhelmed. Le lundi 13 janvier 2025, 22:53:12 heure normale d’Europe centrale Marvin W a écrit :

[SNIP]

The attempt to generalize, trying to describe payload and encryption algorithm (formatter and encrypter) independently seems like it is effectively overcomplicating things. Realistically, there aren't going to be a lot of situations where formatter and encrypter are not effective paired together.

Actually the main use case is for OpenPGP, as it makes sense to re-use the key handling specified in XEP-0373, but the formatting is totally dependent of the legacy network. For other use cases, indeed it would be better to have everything paired. Actually my long term goal is to use webassembly for that with a system of verification/validation.

Further, because the gateway server is the one to decide which formatter to use (as the client is unable to know that on its own), it can likely do shenanigans there. Basically the more formatters a client implements, the more likely it is that these formatters have partial overlap, allowing the server to modify what content is displayed in the client. Ruling out illegal formatter+encrypter combinations on the protocol level reduces this risk drastically.

Yeah that's right.

Some modern encryption systems, like MLS, solve this issue by specifying the content type inside the encrypted+signed part of the message. In those cases, the formatter should never be specified by the gateway as it is implied from the encryption system.

In the case of MLS, I think that my specification is actually not needed at all.

I see you already made an attempt with putting PGP/MIME into this framework.

You are referencing OX to base your PGP part on it, however OX requires the recipient to verify that the PGP key has a user id in the form "xmpp:<bare-jid>" (this is a MUST in XEP-0373 § 3.2). As the gateway can't add new user ids to the PGP key and the other end is not aware of XMPP being involved, this is almost impossible to work out in practice.

Good catch. I've seen that this topic has been discussed by Flow in a reply to this message.

For PGP there are two popular payloads (outside OX) that are popular: - Plain. This is already supported via XEP-0027. - PGP/MIME. This is what you basically do this for.

As you can see with this example, the generalization into formatter and encrypter is already not that helpful with the PGP usecase although it's one of the few that has two popular payload formats in real world.

I'm clearly targeting email gateways here, and MIME fits. Plain should probably be handled too indeed, for decryption.

You tried to draft a specification for a MIME GRE Formatter. However, MIME is not a payload format. The payload inside PGP/MIME is an Internet Message (RFC 822 / 2822 / 5322).

The specification is mostly a link to relevant RFCs and how to map data (and any missing one can be added easily). I went with the idea that all major programming languages have a MIME implementation available already, and the main problem for devs is how to map XMPP data.

IMO, the following two things would make more sense to specify as XEPs: - A XEP that describes how to process rfc822 messages as a client and how to interpret them into XMPP. This could technically be used with a message/rfc822 type XEP-0481 <content> element - yes I hate me for even suggesting that - but also other things, including: - A second XEP that describes how to do PGP/MIME over XMPP (that is transporting PGP-encrypted RFC822 messages and discovering the keys to use for this), with the obvious intent of it to be used in the context of gateways, but technically 100% valid to be used in other contexts.

A note on the procedure on specifying this: I think it would have been better to first merge all of the three ProtoXEPs you proposed now in a single Experimental XEP and see from there how it develops. The XEP can still be split up in the same way as you did right now before moving to Stable, but to me it feels more natural to have them all in one, as changes to one are likely to affect the others and maybe during the development we discover that a different way to split them makes more sense.

Sure. The most important XEP is main mechanism, other 2 can be merged easily, at least for now. I went with 3 because XEP numbers are cheap (yeah I know there is a debate on that), but I'm fine with a single one at least for now. Best, Goffi

Hi Singpolyma, Le lundi 13 janvier 2025, 21:49:17 heure normale d’Europe centrale Stephen Paul Weber a écrit :

...

URL: https://xmpp.org/extensions/inbox/gateway-relayed-encryption.html

...

To specify the formatter to use, a Service Discovery (XEP-0030) [1] disco feature of 'urn:xmpp:gre:formatter:[FORMATTER_NAME]:[VERSION]' MUST be announced

Specifying the format of a feature like this doesn't seem useful to me. The specific ones will still need to be registered and maybe they'll use this pattern (it's often useful if they do) but I see no reason to require it.

Yes sure, I just thought that it would make formatter/encrypter discovery easier, but that's a detail and clearly not necessary.

In general it seems like this XEP basically says "other XEPs may exist that define formatters and encrypters, if you implement them then do what they say to do" ? So it's essentially a prologue to each of these other XEPs? And those other XEPs are effectively expected to specify an entire external messaging protocol as a XEP?

It'z explaining the general mechanism, and the wrapper to look for, how to detect the feature and exchange data. And no, the messaging protocol is handled by the gateways, it's only about encrypting payload, and teaching client how to do so. My long term goal is to have a generic, sandboxed, webassembly based mechanism that clients have to implement once for all. The case of OpenPGP is special because we can re-use large part of OX for that. Best, Goffi