Another entry in the internet security hall of shame....

Peter Saint-Andre stpeter at jabber.org
Fri Aug 26 15:43:06 EDT 2005


Enzo Michelangeli wrote:

>>Remember that Jabber and similar protocols also trust servers to some
>>extent. Servers store and distribute valuable information like
>>presence data -- it is architecturally hard to do otherwise.
> 
> 
> Well, not really: the buddies on the list can be located through a
> Distributed Hash Table such as Kademlia, and, once their IP addresses are
> known, their presence can be checked by ping/pong exchange of UDP packets
> every few seconds. The biggest problem is represented by NATs, but there
> are techniques that can alleviate it (hole punching or, in stubborn cases,
> relaying through non-NATted nodes).

We don't expose IP addresses in XMPP, instead we use logical addresses 
managed by servers. That's a different approach from what you've 
described, but of course you're free to build an alternative presence 
and messaging protocol and network if you'd like. :-)

>>I agree that you *also* want end to end, such as pgp over Jabber
>>provides. I really wish Gaim supported the pgp over Jabber stuff the
>>way PSI does...
> 
> 
> Why not get OTR then? http://www.cypherpunks.ca/otr/

OTR encrypts only the message text, but XMPP can be used to send all 
sorts of interesting XML traffic (such as SOAP, XML-RPC, etc.) in 
addition to simple IM. So we want to encrypt more than what in XMPP is 
the XML character data of the <body/> child of the top-level message 
stanza. RFC 3923 enables XMPP implementations to encrypt the entire XML 
stanza, but no one has implemented that yet and it doesn't support 
perfect forward security etc. Another possible approach being discussed 
is here:

http://www.jabber.org/jeps/jep-0116.html

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3511 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20050826/1ee3be75/attachment.bin>


More information about the cryptography mailing list