[Standards] XEP-0115, 1.3pre2

[Joe Hildebrand]

On Apr 5, 2007, at 11:38 AM, Olivier Goffart wrote:

> Le jeudi 5 avril 2007, Joe Hildebrand a écrit :
>> On Apr 3, 2007, at 2:47 AM, Richard Dobson wrote:
>>> Im not sure if hashes are really required, surely the server can
>>> just compare the results from several different sources and use the
>>> most common one as the real one.
>>
>> Agree, except that if you detect one that doesn't match, there should
>> be a warning dialog popped up, since it's either:
>> a) an attack or
>> b) a client bug (probably a version number wasn't updated that should
>> have been).
>
> The problem is that clients will probably not check on several  
> contacts. (It's
> much more difficult)
> The hash is a lot simpler to check.

It's not "much more difficult".  It's a config option to say how may  
to check (say N), keeping a counter associated with each node#ver and  
node#ext to compare with N, sending up to N requests, and checking  
them each against the first one to respond.  You can decide to keep a  
hash locally if you like.  You would have to have the logic to  
compute the hash in the client anyway, so there's a) no win b) an  
increase in message size and c) backwards incompatibility.

> Also is the server optimization that I suggested interesting ?  
> (cache the
> results of discovery <iq/> and reply to discovery instead of  
> forwarding the
> <iq/> to the contact)

I don't have a problem with the server doing caching, if the  
implementor wants; it's against the spirit of 3920 (I think the  
receiving server MUST deliver, according to the spec), but in this  
case it's not a big deal.  In particular, servers doing XEP-163 will  
need to cache this information anyway.

However, there is not much benefit to this, since a) users tend to  
cluster into small numbers of clients within a community, and b)  
clients only send this to new versions of other clients that they  
haven't seen before.  It's a very small amount of traffic in the  
grand scheme.

> If this is done, the client will not be able to popup a dialog (the  
> server
> could just send a message to the administrator)

A client that is concerned about security will still have to check,  
unless you forsee a way for the client to determine that the server  
is doing this for them.

> And it will be more and more easy to do an attack. Just connect  
> with a lot of
> accounts to the server with an evil client (or fake server)

This only works if people are dumb enough to subscribe to your presence.

> Note that such attack is still relatively not critical.
>
>
> Evil Scenario
> Google want that everyone use GTalk, so he use his server to remove  
> all
> <features/> from discovery <iq /> routed by the server that doesn't  
> come from
> google talk client.  So all others client will start looking crapy.

It would be very apparent very quickly, and we'd all make a stink.   
However, you are always trusting your server not to modify your  
stanzas; 115 doesn't add anything new here.

-- 
Joe Hildebrand