[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XMPP Compatibility
"Peterson, Jon" <jon.peterson@neustar.biz> writes:
> > "Peterson, Jon" <jon.peterson@neustar.biz> writes:
> [snip]
> > > The same IM features are available in that case. I'm not sure
> > > what sorts of 'features' other than the content of an IM you're
> concerned
> > > about, though.
> > Whatever happens to be in the headers. For instance, XMPP stanzas
> > have a thread-id in the meta-data.
> >
> [snip]
> > I think we're talking past each other. I expect there to be substantial
> > amounts of meta-information in the IM messages, as in the thread ID above.
>
> SIMPLE has something somewhat similar to the thread-id (SIP's Call-ID) in
> its own metadata, sure. My point was just that I don't think a lot of
> critical features are going to be implemented in the metadata (from my own
> reading of the XMPP drafts, MSGFMT already accommodates most of what the
> metadata contains - minimal information needed for message routing and
> transaction correlation).
The history of RFC822 belies this claim. More and more information
is getting shoved in the e-mail headers every day.
> I don't think the analogy quite holds. Native SIP is both, I think (like
> HTTP).
This was a bad choice, in my mind. The failure to separate routing
information from content has been the source of a lot of problems
with SIP. cf. sec-agree.
> As I said before, MSGFMT does not seem to confer any properties when it is
> used without security. A gateway still needs to perform protocol translation
> on some of the SIMPLE/XMPP metadata in order to be able to route messages.
> The metadata it needs to be able to translate is roughly the same as what
> MSGFMT will contain. Carrying this metadata around in MSGFMT without
> applying security properties to it will always be redundant, I think. What
> purpose do you envision it will serve?
Not having two code paths really should be enough. The world would
be better if we *pretended* that the set of data that would
be e2e encrypted was inviolate even when it technically isn't.
There are two sets of metadata: one intended for end-entity consumption
and one intended for routing. They happen to be mixed in both XMPP and
SIMPLE, but that's a bad thing. Using MSGFMT via option (1) below
forces us to draw that line when encryption is used. I want to draw
it all the time. I think encapsulation is a good thing.
> > Let's be concrete for a moment here. At the moment, XMPP messages
> > are sent in stanzas like this:
> >
> > <message to='warlord@jis.mit.edu/Gabber@JIS.MIT.EDU' type='chat'>
> > <body>
> > Just sending a test message.
> > </body>
> > </message>
> >
> > If we use MSGFMT to send this, there are two choices:
> > ---------
> > To: warlord@jis.mit.edu/Gabber@JIS.MIT.EDU
> >
> > Content-Type: text/xml
> >
> > <body>
> > Just sending a test message.
> > </body>
> > ----------
> >
> > Or:
> > ---------
> > To: warlord@jis.mit.edu/Gabber@JIS.MIT.EDU
> >
> > Content-Type: text/jabber-xml
> >
> > <message to='warlord@jis.mit.edu/Gabber@JIS.MIT.EDU' type='chat'>
> > <body>
> > Just sending a test message.
> > </body>
> > </message>
> > ----------
> >
> > I think you're endorsing something like the second approach. The
> > problem with this second approach is that it doesn't really work. The
> > receiver actually needs to be able to read Jabber's format in order to
> > display the message. This defeats the purpose of using MSGFMT.
> >
>
> Actually, no, the CPIM approach is more like your first option above.
Well, I certainly modelled that example after CPIM, so that's not surprising.
However, it's not what you get when you endorse the metadata-in-body
approach.
> add a lot of 'features' to the metadata that would require e2e security,
> this isn't a very attractive development path, I agree. But I'm not sure I
> think either XMPP or SIMPLE is likely to do so. Can you substantiate why you
> think many pieces of e2e 'feature' metadata will be added to XMPP in the
> future?
As I said, it's the history of every extensible protocol I know of.
It's certainly been true of HTTP and RFC822. And the fact that XMPP
uses XML so liberally means that it's incredibly easy to add metadata.
> The point is, we need to know what metadata actually requires security
> properties, and what the risks are of not having security properties for
> some metadata. It isn't immediately clear to me, for example, that an
> attacker would gain a whole lot by changing the thread-id. Much of the
> metadata in SIP is explicitly not securable e2e (it needs to be changed by
> intermediaries), and would never need to pass through a CPIM gateway. Would
> any intermediary be required to read the thread-id, or is it an e2e
> property?
It's an e2e property as far as I can tell.
But I think saying "The point is, we need to know what metadata
actually requires security properties, and what the risks are of not
having security properties for some metadata." completely misses
the point. Trying to make these decisions for each individual
header is impossible in a complex system. That's *precisely*
what I'm trying to avoid.
The purpose of making architectural choices like this is to
give you a bright line that guides the rest of your decisions.
-Ekr
--
[Eric Rescorla ekr@rtfm.com]
http://www.rtfm.com/