[Standards] Proposed XMPP Extension: Jingle Encrypted Transports

Dave Cridland dave at cridland.net
Thu Aug 31 07:59:40 UTC 2017

On 30 August 2017 at 21:32, Daniel Gultsch <daniel at gultsch.de> wrote:
> 2017-08-30 22:10 GMT+02:00 Paul Schaub <vanitasvitae at riseup.net>:
>> First things first: My intention for submitting JET to the XSF inbox was
>> to get some comments and first feedback in order to discover caveats and
>> pitfalls in the protocol.
>> By no means I'd consider JET ready to be implemented or accepted :D
> OK. Fair enough. I think what people usually do at this stage is
> render the XEP themselves, put it up somewhere and show it around to
> get some feedback. That way you don't trigger council action and it is
> way easier to make changes because you don't have to go through the
> editor.

This is getting a bit meta, but the reason I really dislike that is
that you're asking people to work on protocol stuff outside the IPR
policy of the XSF. This exposes people implementing, or discussing, to
all sorts of legal shenanigans that are somewhat mitigated by the
copyright assignment in submission.

If there's something preventing this, we really need to fix it.

>> Am 30.08.2017 um 17:47 schrieb Daniel Gultsch:
>>> I feel like this XEP is underspecified. On one hand it tries to be
>>> agnostic of the actual encryption being used on the other hand it is
>>> not necessarily clear to me - given a an encryption method X - how
>>> exactly the transport secret is encrypted in method X. The OpenPGP
>>> examples look like the TS is put into the body??? And in OMEMO as
>>> well?
>> Correct, the transport secret is interpreted as the body for the
>> encryption function. I specified it that way
> No. I don't think it is specified yet. That's my problem with the XEP.
> But if that's how you want to be you should write it down (=specify it)
>> encrypts <body/> elements and I thought that probably every encryption
>> method will offer some kind of body encryption.
> That's a pretty bold statement when trying to be encryption agnostic.
> If you want to be agnostic the spec has to work for future XEPs as
> well.
> And things like OX can technically have multiple bodies (=multiple languages)
>> I know that this is not
>> ideal, so I'd love to find a better way :)
> My gut feeling also things we should find a better way. But I can also
> get onboard the 'hacky' way of putting it in the body as long as it is
> specified correctly.
>> The fact, that for example OX offers multiple encryption modes (<crypt/>
>> and <signcrypt/>) gives me the feeling, that it might be desirable to
>> have JET only specify, how the transport is secured using the symmetric
>> key and have multiple sub-XEPs (is that a thing?) for OX, OMEMO etc.
>> Those might also have their own namespaces then.
> This and my concerns raised above lead me to believe that things might
> get easier if we have a JET XEP that contains the reusable parts (how
> long to keep the key cached and whatever) and then a JET-OMEMO and
> JET-X that only explain how the TS is transported.

As an aside here, splitting the XEP up might be the right choice, but
it can be done later, and shouldn't have any technical effect

>>> important things like discovery are missing.
> Having multiple XEPs would also solve the discovery thing.
> cheers
> Daniel
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________

More information about the Standards mailing list