I've started reviewing all the Jingle specifications for one final read-through, and it struck me that the security-related bits are now in draft-meyer-xmpp-e2e-encryption:
http://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption The primary driver for this work is indeed end-to-end encryption of XMPP traffic as explained in that I-D, but the <security/> element could also be used to provide a "security context" (not sure if that is the proper phrase) for a streaming or datagram transport that is used with any application type. So there really are three different moving parts here: 1. The application type. The urn:xmpp:jingle:apps:xmlstream:0 namespace from the I-D defines a new application type for end-to-end XML streams, which we strongly recommend that you do over a secured transport (else what is the point other than escaping the tyranny of rate limits?). However, you could also do file transfer (XEP-0234) or VoIP (XEP-0167) or any other Jingle application type over a secured transport. 2. The transport. As explained in XEP-0166, the transport can be streaming (in-band bytestreams, SOCKS5 bytestreams, ice-tcp, etc.) or datagram (raw UDP, ice-udp, etc.) Adding "XTLS" into the mix changes the dynamics of session negotiation, which is pretty core to Jingle as a negotiation framework. 3. The security context (a.k.a. "XTLS"). Until now, no Jingle transport methods had a security context (or, to be precise, they had a null context). But the urn:xmpp:jingle:security:xtls:0 namespace defined in the I-D adds a <security/> element to any Jingle negotiation, which can be used to establish a security context via "XTLS", i.e., TLS for a streaming transport and DTLS for a datagram transport. My question is, where does the definition of XLTS really belong? It feels odd *not* to define it in XEP-0166, since that is the core Jingle spec and the addition of security contexts changes how sessions are negotiated. If we did that, draft-meyer-xmpp-e2e-encryption would be rather brief because it would define only the combination of the end-to-end XML streams application type, a streaming transport (most simply in-band bytestreams), and a security context. On the other hand, if we define security contexts in an Internet-Draft then it is more likely to receive proper security review within the IETF. However, at that point it seems that we might be bringing in a whole raft of dependencies. Perhaps that is manageable (I don't think it's appropriate to suddenly move all of the Jingle specifications to an XMPP WG!), but I want to make sure that we can manage this work in such a way that we receive the proper security reviews for XTLS without burdening the IETF with masses of new work. Finally, somewhat of an aesthetic point is that I'd really like to have only one document that defines end-to-end encryption of XMPP traffic, rather than forcing a developer to read a spec on end-to-end XML streams, a spec on Jingle security contexts, and so on. Perhaps that is not so important in the end, but I'd appreciate feedback about it from client developers. Thoughts? Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
