[Standards] LAST CALL: XEP-0320 (Use of DTLS-SRTP in Jingle Sessions)
fippo at goodadvice.pages.de
Wed Sep 16 18:34:20 UTC 2015
Am 26.08.2015 um 08:59 schrieb XMPP Extensions Editor:
> This message constitutes notice of a Last Call for comments on XEP-0320 (Use of DTLS-SRTP in Jingle Sessions).
> Abstract: This specification defines how to use DTLS-SRTP (RFC 5763) in the Jingle application type for the Real-time Transport Protocol (RTP) as a way to negotiate media path key agreement for secure RTP in one-to-one media sessions.
> URL: http://xmpp.org/extensions/xep-0320.html
> This Last Call begins today and shall end at the close of business on 2015-09-07.
> Please consider the following questions during this Last Call and send your feedback to the standards at xmpp.org discussion list:
with my authors hat on (and since I want to try out the idea that
authors should provide a writeup for LC):
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
Currently, Jingle supports two other methods for encrypting RTP:
SDES and ZRTP
SDES is an encryption method where the signaling server knows the key.
It allows retroactive decryption. The author of SDES asked for it to be
not used anymore (in the WebRTC context) at the 2013 IETF in Berlin.
Sadly, it is still widely used, e.g. by whatsapp  or Facebook
Messenger . You can see me being disappointed by this in either 
or  :-)
ZRTP is good (and provides protection against MITM attacks). However, it
is not natively implemented by WebRTC. See  for some background
DTLS is currently the way all WebRTC calls get established (minus Google
Hangouts which still uses SDES but technically that makes them "not
webrtc"). So this specification is one of the key pieces in allowing
Jingle to be used for establishing WebRTC calls.
> 2. Does the specification solve the problem stated in the introduction and requirements?
It provides a mapping to SDP for WebRTC purposes and can also be used
natively with ORTCs RTCDtlsTransport.
> 3. Do you plan to implement this specification in your code? If not, why not?
I've done that, probably twice. And I have seen it interop here 
> 4. Do you have any security concerns related to this specification?
I wonder if it should be repeated that this does not automagically
protect against MITM attacks.
> 5. Is the specification accurate and clearly written?
> Your feedback is appreciated!
More information about the Standards