Peter Saint-Andre wrote: > 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.
Yes > 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. That's why I splitted the secure channel from the e2e streams in the draft. > 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. Does it change Jingle? Or does it only change Jingle RTP? > 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. As I see it, <security> is an add-on to Jingle. > 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. IMHO that would not justify an IETF draft. > 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 People told me that an external dependency is not a problem. I strongly feel that XTLS and e2e streams belong into the draft. As you said, people who know MUCH more about security may look at it now. IMHO that is the important part. I see no problem with file-transfer refering to the draft. > (I don't think it's appropriate to suddenly move all of the Jingle > specifications to an XMPP WG!), No, we should not do that. If we start with that, what about XEP-0030? We don't want to give up XEPs from drafts without reason. > 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. IMHO the draft specifies the core of e2e security and one simple use case (e2e streams). The examples show as much Jingle as needed to understand it. > 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. It would be nice to have only one doc, but that would mean to merge Jingle into the doc. I loud NO from me. Dirk -- The 50-50-90 rule: Any time you have a 50-50 chance of getting something right, there's a 90% probability you'll get it wrong.
