Justin Karneges wrote: > On Wednesday 14 January 2009 13:16:10 Peter Saint-Andre wrote: >> Justin Karneges wrote: >>> On Tuesday 13 January 2009 15:16:23 Peter Saint-Andre wrote: >>>> According to my reading of RFC 4568, SDP Security Descriptions MUST NOT >>>> be used unless the signalling channel (that's XMPP for us) can "provide >>>> strong message authentication and packet-payload encryption, as well as >>>> effective replay protection". Because we don't provide those services in >>>> XMPP out of the box, I don't think we can securely use a=crypto (or our >>>> XMLish flavor of a=crypto as currently described in XEP-0167). But we >>>> might be able to use it if we negotiate XTLS (or some other e2e method) >>>> first. >>> I'm of the opinion that requiring e2e encryption to bootstrap secure oob >>> sessions is perfectly acceptable. Relatedly, I'm of the opinion that >>> having oob sessions inherit the security properties of XMPP helps avoid >>> confusion. >>> >>> With the way XEP-167 is currently written, RTP is just as secure as your >>> text chat. It's as simple as that. If both participants use the same >>> server, and use TLS to that server, then RTP is protected within that >>> domain, just as text chats are. If both participants use e2e encryption >>> to protect the Jingle iq stanzas, then RTP is fully protected end-to-end. >> It's just as secure, but I think the layering is wrong. IMHO we want to >> pull the security negotiation out of the transport negotiation. At a >> high level, this: >> >> <iq> >> <jingle> >> <content> >> <description/> >> <transport/> >> <security/> >> </content> >> </jingle> >> </iq> > > Well, yes and no. Yes, I agree generic transport security should be offered > at the Jingle level.
I don't know that there is such a thing as generic transport security, but I need to ponder that further. > However, SRTP (the topic of this thread, or at least > where I branched it) should not be offered at the Jingle level because it is > application-specific. That seems sensible. > So, to be clear, I think Jingle should offer exactly two generic security > options: TLS (for use with stream-based transports/apps) and DTLS (for use > with datagram-based transports/apps). I'm not sure about that yet. > If SRTP (or ZRTP, etc) are used, these would be details of Jingle RTP, and > their associated data exchanges would occur within <description/>. That part seems agreeable -- it is what we have today in XEP-0167, except that we haven't yet defined how to include the zrtp-hash. Peter
