On Friday 16 January 2009 15:39:31 Peter Saint-Andre wrote: > For #1, I think we would define a new application type, such as > "urn:xmpp:jingle:apps:xtls":
Yes. > [I don't see a need to negotiate DTLS directly via Jingle, but I suppose > that if we need it we would define a different Jingle application type, > such as "urn:xmpp:jingle:apps:dtls".] To be clear, you're not negotiating TLS directly via Jingle here either. You're proposing an application type called XTLS, and XTLS would describe usage of TLS as part of the protocol flow. I make this distinction because there's an open idea on the table right now about offering TLS at the Jingle level. More at the end of this mail. > So we'd need a way to exchange information about the association via > Jingle. In DTLS-SRTP you need a separate DTLS-SRTP session for each > host/port quartet, but you can share the same *DTLS* session for > multiple DTLS-SRTP sessions. Yes, although it's unclear to me how you're suggesting DTLS be used here. As I understand it, DTLS-SRTP requires an existing DTLS session to operate. One approach, for example, would be to have a DTLS session established over the transport (once for each port, so RTP and RTCP would each have their own DTLS session). > 3. Exchange of keying material for a secure media transport within the > Jingle content-description. This is secure only if the Jingle exchange > happens over a secure channel, such as an XTLS tunnel as described under > #1. This is what we currently have in XEP-0167 for SRTP, although we > might want to refactor the XML a bit for consistency: Yes. > We still need to define something here for ZRTP, but I think that's > fairly straightforward because AFAICS all that we need to include is the > zrtp-hash: Yes. > And if desired the initiator could offer all three rtpsec methods > (DTLS-SRTP, SRTP, and ZRTP): Yes. Now, what do we do about encrypted file transfer? One way would be to (reusing my words from above) propose an application type called File Transfer, and File Transfer would describe usage of TLS as part of the protocol flow. This makes sense, right? However, an alternative approach, what Dirk and I have been talking about lately, is the idea of making TLS a built-in (but optional) feature of Jingle. So, if the negotiated Jingle transport is stream-based, and TLS was flagged for use in the iq exchange, then a TLS session would be established over the transport, and the application would ride on top. This would make it so File Transfer and XTLS wouldn't need to each redundantly describe usage of TLS. -Justin
