[standards-jig] Version 0.3 of JEP-0046 / DTCP

Ben Schumacher ben at blahr.com
Mon Sep 23 08:58:50 UTC 2002


Please see comments inline.

On Fri, 20 Sep 2002, Justin Karneges wrote:
> DTCP does verification completely out-of-bound for the sake of simplicity, as
> there might be more than one host/port to try to connect to.  The purpose of
> DTCP's key/verify is really only to make sure you are talking to the right
> person in the easiest way possible (the verify is to prevent a local LAN user
> spoofing the address of a user on a remote LAN).

This is exactly the problem I am suggesting you address. DTCP's
verification does not guarantee that you are talking to the right person.
To fully verify this, you would need to combine inbound communication in
the out-of-bound verification process. Basically, the assumption is that
we (as Jabber users/developers) trust the server and trust any connections
to the server. You are removing this trust.

When you make a connection using DTCP, you have no way of verifying that
the connection is being made with the party you have been communicating
with. As I mentioned in my previous email, it would be a simple task to
grab the key/verify tokens from the XMPP traffic and use them to hijack a

You state in this email that the <verify> tag is used "to prevent a
local LAN user spoofing the address of a user on a remote LAN" and in the
document as "this is how you can prove you are really connected to Joe."
Unfortunately, however, your current mechanism succeeds at neither of
these claims. The way to do this correctly would be to do some sort of
combined inbound and OOB verification after the TCP socket has been

> For any real security, I would think this would have to be combined with SSL
> and/or XML encryption, which is more of an issue with Jabber as-a-whole.
> Perhaps we could come up with a real xml encryption standard, rather than
> complicating our other protocols with their own weaker method?  Or is this
> just too far away from happening anytime soon?

You speak of DTCP as a solution that should be simple to implement.
Relying on SSL seems to be contrary to this claim. If you really want true
security using this mechanism, you would need to implement certificate
verification. This would significantly complicate any implementation, even
if the surrounding syntax stays simple.

Regardless, I'm not concerned about full connection security right
now, I'm just saying it would be nice if we used an already trusted, and
authenticated XMPP connection was used to help verify that these OOB
socket connections are made with the appropriate party. Even if you use
SSL on the connection, you are not offering this level of trust, unless
you do some sort of SSL certificate verification between the two clients.

As for XML encryption, since the specification for this hasn't even been
finalized yet (at least, not last time I looked into it), I don't think it
would be beneficial to wait on it for this protocol. And again, if you do
want to use XML encryption over this TCP socket connection, that is
outside the scope of "Jabber as-a-whole" and imposes more semantics on
this protocol.

> Since we are all aware now of the security holes in DTCP, for comparison what
> are the security holes in JOBS?  Do these security holes change if SSL is
> added to the mix?

SSL would do nothing to secure a JOBS connection, nor is the protocol
intended to offer this level security. JOBS does, however, offer you
assurance that you are communicating OOB with the party that you want to
communicate with. Should the involved parties wish to improve on the
security of this connection, they are then able to employ a number of
security mechanisms over this virtual connection. The data shared between
these parties could be encrypted by a number of different mechanisms, but
still use simple sockets at the network level.

> It is quite possible I don't understand all of the implications here.  I am
> not a security expert..

I don't claim to be either, but I can still see a potential weakness in
your protocol in the current proposal.



More information about the Standards mailing list