> 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?”

Right :)


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.




/Lance


_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________

Reply via email to