On 8/26/15 9:59 AM, XMPP Extensions Editor wrote:
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@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to
clarify an existing protocol?
Yes.
2. Does the specification solve the problem stated in the introduction and
requirements?
Yes. It's a bit hacky in places but I think it's OK to sacrifice
elegance to practicality. :-)
3. Do you plan to implement this specification in your code? If not, why not?
At &yet we're using this in jingle.js:
https://github.com/otalk/jingle.js
4. Do you have any security concerns related to this specification?
Not really, and this improves the security situation because DTLS-SRTP
is highly desirable (and required for WebRTC).
In an ideal world we would all have a clearer understanding of Jingle
security preconditions, which is unhelpfully spread across XEP-0166 and
an expired Internet-Draft:
http://xmpp.org/extensions/xep-0166.html#preconditions
https://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption-02
I talked with the author of XEP-0320 last week about that (hi Fippo!)
and I got mostly comfortable with the approach he's taken in XEP-0320,
i.e., advertising the keying material for the transport layer by making
the <fingerprint/> element a child of the <transport/> element. Another
approach would be to make the <fingerprint/> element a child of the
<security/> element as we did in draft-meyer-xmpp-e2e-encryption.
However, Fippo mostly convinced me that this <fingerprint/> element is
used for DTLS-SRTP encryption and thus is associated with the transport
layer. What exactly we use the <security/> element for is another
question that we need to sort out separately.
Thus I'm OK with this approach to setting up DTLS-SRTP.
5. Is the specification accurate and clearly written?
I think the spec needs to make it clear which values of the 'setup'
attribute must be supported from RFC 4145. In particular, I think the
value "holdconn" (which means "The endpoint does not want the connection
to be established for the time being") doesn't make sense in the Jingle
context because we're not really using the 'setup' attribute here as
part of an offer/answer exchange (see RFC 3264).
Peter
