[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: XMPP Compatibility
More below.
- J
> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@rtfm.com]
> Sent: Monday, March 31, 2003 4:37 PM
> To: Peterson, Jon
> Cc: iab@ietf.org; iesg@ietf.org
> Subject: Re: XMPP Compatibility
>
>
> "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).
[snip]
> I want to distinguish between messaging protocols and message
> transport protocols. The analogy is to RFC822/MIME versus SMTP.
I don't think the analogy quite holds. Native SIP is both, I think (like
HTTP). In any event, in CPIM gatewaying, protocol translation would be done
on the SIMPLE-XMPP level, and the MIME bodies present within SIMPLE or XMPP
would be relayed without modification. Since SIMPLE and XMPP both have
headers and whatnot, that protocol translation of their metadata is
non-trivial.
There was one proposal (PRIM) a few years ago that was essentially
MSGFMT-over-TCP. They, of course, needed to use MSGFMT all the time.
The motivation for message format was to allow for e2e security properties
that could survive the traversal of a CPIM gateway.
> > The encryption format is just a wrapper for the same content that would
> > appear in the cleartext version of the message (along with some metadata
for
> > integrity purposes, and to prevent replay attacks). You need to have a
> > 'cleartext' format anyway because that's what gets secured within the
> > ciphertext wrapper.
> Yes. I want that to be the same whether encryption is used or not.
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?
> 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. In my
previous note, I didn't mean to endorse any particular strategy for using
MSGFMT with XMPP. Agreed that the second option is self-defeating.
> On the other hand, if we use something like the first approach, what
> happens when we want to add another kind of meta-data, like
> thread id. There's no defined place to put this in MSGFMT,
> so we either have to use the extensions mechanism or fall
> back to the second approach, which ruins compatibility.
> So, the extensions mechanism it is. But now we have two
> parallel lines of message format development, one for MSGFMT
> with extensions and one for XMPP proper. Yuck.
>
Using MSGFMT entails that any metadata that requires security properties has
a corresponding MSGFMT extension, or what have you, yes. If you intend to
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?
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?
> Or have I misunderstood you?
> -Ekr
>