[Standards] XTLS revisited

Dirk Meyer dmeyer at tzi.de
Mon Dec 15 17:16:19 UTC 2008


Dave Cridland wrote:
> Okay, so the gain here is that we lose the Jingle negotiation,
> effectively, and mandate something roughly equivalent to IBB.

Yes

> The downside is that we lose the ability to go direct from client to
> client should we need to, and one reason for doing so would be for
> efficiency. (There are others, independent of encryption).

Yes. The question is: what do we want? Jingle-based allows direct
connections with the cost of many additional roundtrips: while XTLS only
needs 3 roundtrips, Jingle XML streams need at least 7, maybe more
depending on the transport. And it is the question of work for the
developer: if you have Jingle and link-local support, Jingle XML streams
is as simple as it can get. But if you don't have these, XTLS is much
easier.

Jingle XML Streams: More flexible. You can use direct connections and
    it would also be possible to use other features besides STARTTLS

XTLS: Much faster, easier to implement

I'm not sure what's better.

> As I see it, there are two ways of approaching cryptography in XMPP:
>
> 1) We concentrate on getting an efficient, but basic, end-to-end
> encryption protocol, which is easy to write and deploy. I'm firmly
> convinced that the XEP-0247 approach is right here - it's allowing us
> to get the transport right, the authentication right, and all using
> existing crypto libraries as much as possible. I just don't see any
> real likelyhood of clients not being able to use Jingle, given
> XEP-0234 etc. In this scenario, the server isn't involved at all, and
> the scope for cryptography is narrow.
>
> 2) We concentrate on getting a full-featured cryptography suite in
> place, akin to S/MIME and ESS in email. In this scenario, the server
> may well be involved, discarding bad packets, verifying signatures,
> and we'd be aiming to support things like MUC and PubSub. This is not
> going to be possible with TLS, we need to go to things like XML-dsig,
> and involve triple-wrapping and other fun things.
>
> I don't see which this proposal is addressing.

1) It is the same as XEP-0247: we use TLS. XTLS and XEP-0247 only differ
in the transport we use.


Dirk

-- 
This signature is temporarily under construction



More information about the Standards mailing list