[Standards] JingleFT XEP encryption conflicts
lancestout at gmail.com
Tue Jan 3 23:19:56 UTC 2017
> Lance might have other opinions, but I read XEP-0234 as saying "this isn't the place to look for transport-layer encryption, if it's defined anywhere it would be in XEPs 260 and 261", whereas the latter specs are saying "um, our authors haven't defined that yet but maybe we need to be updated with some proper security methods, eh?”
E2E security in Jingle can be negotiated in three different places:
1) As part of the application
2) As part of the transport
3) As an additional layer between the transport and the application
In order for a Jingle content to be considered ‘secure’, at least one of those three options needs to be ticked.
An example of (1) is the RTP application, which handles its own E2E encryption (using the SRTP profile). That is why the <description/> for an RTP application can include an <encryption /> element to specify parameters for SDES or ZRTP (and technically could be updated to allow indicating the use of DTLS-SRTP). This is also why RTP never needed to use the Jingle <security /> element.
We don’t quite have a XEP that fully shows (2), but WebRTC datachannels would fall into this category because they are SCTP on top of DTLS. That is, you *have* to negotiate DTLS in order to even have a WebRTC datachannel transport; the transport never operates as ‘plaintext’.
The original design of Jingle was that option (3) would be the common approach. The Jingle <security /> element would allow negotiating TLS or DTLS on top of any transport. Thus things like SOCKS5 and IBB didn’t need to include how to do TLS, etc, because that was going to be defined by https://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption-02. Unfortunately, that spec was never finished for some reason. (Probably because it wasn’t a requirement for RTP?)
The integration of OMEMO with Jingle would be to define this style of generic security layer.
More information about the Standards