[standards-jig] Security problems with JEP-115

Matthew A. Miller linuxwolf at outer-planes.net
Fri Sep 19 23:08:23 UTC 2003


This is probably beating a dead-horse now, but here we go.  Replies 
inline...


-  LW

Jacek Konieczny wrote:

>On Thu, Sep 18, 2003 at 08:43:19AM -0600, Matthew A. Miller wrote:
>  
>
>>First, I would like you to *fully* explain how this allows one client 
>>(client-A) to disable features of another client (client-B) (and not 
>>simply allow client-B to "mask" capabilities to, or work differently 
>>with, client-A).
>>    
>>
>
>Such "masking" is bad enough. Imagine that the client B is configured to
>use encryption with any other client that supports it. When this
>capability is masked client-B would send unencrypted messages.
>  
>
If Client-A says it does not support encryption (and doesn't), Client-B 
could never speak encryptedly *to it* anyway.  I still don't see the 
problem here.

>>Second, this JEP does provide a bitmask (of sorts), via the "ext" 
>>attribute.  The JEP also outlines a number of rules on how it's applied 
>>and used. Again, if this isn't adequate, detailed insight is greatly 
>>appreciated.
>>    
>>
>
>The problem is that meaning of bundle names is not defined and probably
>not trusted source has to be asked for the meaning.
>  
>
The bundle names are not defined because they are 
implementation-dependent.  It is meant to work with disco (JEP-0030) to 
do the actual discovery, and provides a "key" by which to cache the 
query results.

>>As was previously stated, if you provide a another solution, we'll 
>>consider it; if you provide a better solution, we'll use it!  
>>    
>>
>
>See the other post for my MD5-based improvement proposition.
>
>  
>
>>But in this case, the call of "do nothing" just isn't enough.
>>    
>>
>
>We have many JEPs which were proofed bad at some moment. IMHO it is
>better to show that some way looks wrong at its begining.
>  
>
And you have yet to prove what harm this JEP causes.  If you, as a user, 
don't want this information going out, then use a client that [A] does 
not send this, and/or [B] lets you choose to disable the feature.  If 
you, as a client developer, don't want this information going out, then 
don't implement this JEP.

There are users and clients out there that want this feature.  For those 
users and clients, this provides a better solution than the current 
"let's query everyone everytime their presence changes!" madness.

>Greets,
>        Jacek
>_______________________________________________
>Standards-JIG mailing list
>Standards-JIG at jabber.org
>http://mailman.jabber.org/listinfo/standards-jig
>  
>




More information about the Standards mailing list