Re: [Standards] Addressing Security Concerns in XEP-0115 Entity Capabilities

[Joe Hildebrand]

On 9/14/11 4:31 PM, "Waqas Hussain"  wrote:

> An entity which understood double verify would have the option to
> either be vulnerable to poisoning, or participate in IQ floods. It's
> this that I'm against.

Presumably, the new XEP would recommend that you negatively cache in the
case that it rejected an unverified caps result.

> So poisoning succeeds. And what happens with these logs? How do you
> find the poison needle in the haystack of legitimate messages? I hope
> you don't want admins to do this...

You have the choice.  All of your clients can just reject caps that don't
have the second hash, and negatively cache them.

Some of my clients will want to do backward-compatibility for the next year
or two, but that's a risk I'm willing to take on behalf of my customers.

-- 
Joe Hildebrand

Re: [Standards] Addressing Security Concerns in XEP-0115 Entity Capabilities

[Matthew A. Miller]

On Sep 14, 2011, at 16:31, Waqas Hussain wrote:

> On Thu, Sep 15, 2011 at 1:37 AM, Matthew A. Miller
>  wrote:
>> 
>> On Sep 14, 2011, at 13:40, Waqas Hussain wrote:
>> 
>>> 
>>> So.. which caps is included in presence? The current exploitable one?
>>> Then this doesn't help with preventing poisoning, does it?
>>> 
>> 
>> the caps hash would be as it is today.  So, yes, a client that doesn't 
>> understand this double-verify would still be vulnerable.
>> 
> 
> An entity which understood double verify would have the option to
> either be vulnerable to poisoning, or participate in IQ floods. It's
> this that I'm against.
> 

Frankly, at this point, I'm starting to think the IQ "flood" would actually be 
a good thing.

It would be a pain point for users and admins, prompting them to get these 
"untrusted" clients off the network.

I also put "flood" in quotes.  Let's face it, it would be the early adopters 
sending all of the requests, and there are policies these clients can implement 
to help mitigate that.

>>> What does considering the result suspect mean? I'm hoping you don't
>>> mean it isn't cached. Because that would be much worse than just using
>>> a new XEP, which would be a perfectly smooth transition.
>>> 
>> 
>> Being suspect means it's up to the implementation and deployment.
>> *  Some might accept (and cache) them but with a log message somewhere.
> 
> Err
> 
> So poisoning succeeds. And what happens with these logs? How do you
> find the poison needle in the haystack of legitimate messages? I hope
> you don't want admins to do this...
> 

Admins that care about the services they provide actually do monitor their 
logs.  Some of them even have found or wrote tools to help this do this stuff 
already.

Client writers that care about their users actually do make sure they can get 
information such as logs from said users.

>> *  Some might reject (and not cache) them unconditionally.
> 
> And therefore early adopters are punished with IQ floods...
> 

Actually, it would be the late adopters punished with IQ floods.  The early 
adopters would be contributing to it.

>> *  Some might put in a timebomb into their implementations that will switch 
>> from "accepted" to "rejected".
> 
> I just don't like this particular idea...
> 

Just because you don't like it doesn't make it go away.

Another possibility is that such implementations perform further heuristics if 
the results are suspect:
* any category or type that contains '/' might be rejected
* any result that does not include 'http://jabber.org/protocol/caps' and 
'http://jabber.org/protocol/disco#info' as features (not poisoning identities 
or extensions) is rejected (we should all be doing this anyway; violation of 
XEPs -0030 and -0115)
* any category or type that is empty is rejected (we should all be doing this 
anyway; violation of XEP-0030)
* any feature that looks like a typical identity (e.g. 'client/pc//client 
name') might get rejected
* etc etc

>> 
>>> I have assumed the whole point of all this effort to keep the old XEP
>>> is to get rid of the transition period, so if you are not going to
>>> cache exploitable caps at all, might as well define a clean new XEP.
>> 
>> The point of trying to keep the old XEP is not to eliminate a transition, 
>> but to make it less painful.  I do think having a complete replacement to 
>> caps is more painful than applying an addendum or two.  As Dave said, the 
>> building is not burning (yet).
>> 
> 
> I see. Frankly I was (and still am) confused at what the point was.
> 
> Make it less painful? For whom?
> 
> Less painful for developers? I disagree that adding tons of extra
> checks and magic disco features and forms is going to make developers
> happy.

1) There haven't been tons.  A handful perhaps.
2) this particular idea (discohash form) is something I've talked about with 
others for different but somewhat related purposes.  It might get put into a 
proposal regardless of where this discussion leads.
3) It does build upon the existing software people have.  Someone starting from 
scratch will have more to do, but frankly they'll have more (IMO, double) to do 
until any TBD spec has deployed saturation.

> A nice clean separate algorithm is much more likely to do that.
> 

When it comes to canonicalization, nothing is clean.  Nothing.

> Less painful for users/server-admins? Your particular proposal gives
> them IQ floods (most of the proposals from stpeter do not have this
> issue).

The IQ floods are *from* the early adopters, depending on their policies.  They 
also might be as vulnerable as existing clients today, depending on their 
policies.

> 
> Less painful for spec writers? I don't think so.
> 

This is a non-sequitur.

> This is how I see it:
> stpeter's proposals: 1. dont succeed in fixing the issue, 2. don't
> have the flood issue, 3. don't add anything to presence, 4. complicate
> the spec.
> your proposal: 1. either doesn't fix the issue, 2. or causes floods,
> 3. doesn

Re: [Standards] Addressing Security Concerns in XEP-0115 Entity Capabilities

[Waqas Hussain]

On Thu, Sep 15, 2011 at 1:37 AM, Matthew A. Miller
 wrote:
>
> On Sep 14, 2011, at 13:40, Waqas Hussain wrote:
>
>>
>> So.. which caps is included in presence? The current exploitable one?
>> Then this doesn't help with preventing poisoning, does it?
>>
>
> the caps hash would be as it is today.  So, yes, a client that doesn't 
> understand this double-verify would still be vulnerable.
>

An entity which understood double verify would have the option to
either be vulnerable to poisoning, or participate in IQ floods. It's
this that I'm against.

>> What does considering the result suspect mean? I'm hoping you don't
>> mean it isn't cached. Because that would be much worse than just using
>> a new XEP, which would be a perfectly smooth transition.
>>
>
> Being suspect means it's up to the implementation and deployment.
> *  Some might accept (and cache) them but with a log message somewhere.

Err

So poisoning succeeds. And what happens with these logs? How do you
find the poison needle in the haystack of legitimate messages? I hope
you don't want admins to do this...

> *  Some might reject (and not cache) them unconditionally.

And therefore early adopters are punished with IQ floods...

> *  Some might put in a timebomb into their implementations that will switch 
> from "accepted" to "rejected".

I just don't like this particular idea...

>
>> I have assumed the whole point of all this effort to keep the old XEP
>> is to get rid of the transition period, so if you are not going to
>> cache exploitable caps at all, might as well define a clean new XEP.
>
> The point of trying to keep the old XEP is not to eliminate a transition, but 
> to make it less painful.  I do think having a complete replacement to caps is 
> more painful than applying an addendum or two.  As Dave said, the building is 
> not burning (yet).
>

I see. Frankly I was (and still am) confused at what the point was.

Make it less painful? For whom?

Less painful for developers? I disagree that adding tons of extra
checks and magic disco features and forms is going to make developers
happy. A nice clean separate algorithm is much more likely to do that.

Less painful for users/server-admins? Your particular proposal gives
them IQ floods (most of the proposals from stpeter do not have this
issue).

Less painful for spec writers? I don't think so.

This is how I see it:
stpeter's proposals: 1. dont succeed in fixing the issue, 2. don't
have the flood issue, 3. don't add anything to presence, 4. complicate
the spec.
your proposal: 1. either doesn't fix the issue, 2. or causes floods,
3. doesn't add anything to presence, 4. complicates the spec, as both
the current and new algorithms are now part of it.
new XEP: 1. fixes the issue, 2. doesn't cause floods, 3. does add
something to presence during the transition, 4. simplifies the spec.

Oh, and I agree there is no burning building. I don't think anyone
thinks there is at the moment.

>
> - m&m
> 
>
>

--
Waqas Hussain

Re: [Standards] MSN does XMPP

[Mark Rejhon]

Agreed...

I would like Microsoft to pass through XEP-0301 (In-Band Real-Time Text).
I know that someone from Microsoft's team contacted me inquiring about
this; an steps from Microsoft should be encouraged.

Standardized tests such as Acid made Microsoft Internet Explorer 9
much more compliant, so I think an "Acid" style test for XMPP might be
an interesting idea.  We need to raise XMPP compliance to a much
higher level.   Facebook's XMPP is also having some interop issues on
XMPP, it is rejecting certain protocols, too.

Someone would just slap together a standard XMPP "testing client" that
runs on two ends, and tests various XMPP protocols, ranging from
simple message deliveries, status changes, etc, to see if the system
goes through.   The two clients could bounce back results through the
clear XMPP messaging channel as a log (simple approach), or would also
talk to each other separately (directly or via a trusted Jabber
server) to "compare notes" (more complex approach).

Even a simplistic test client (1,000 lines of source code running on a
pre-existing Jabber library), could be slapped together by one of us.
It would only test just a few tests, and only brief undocumented
extension passing (can just be a small amount of random XML data in a
 payload to begin with) -- could be our "Acid Version 1" to
begin with.

Mark Rejhon

On Wed, Sep 14, 2011 at 1:43 PM, Nicolas Vérité
 wrote:
> Hi,
>
> Thanks for those of you who twitted it:
> http://www.liveside.net/2011/09/14/messenger-connect-is-now-live-connect-new-apis-for-skydrive-and-hotmail-calendar/
> XMPP Interface : You can integrate Messenger into your Web-based,
> desktop, or mobile instant messaging products by connecting to our
> XMPP service.
>
> It's Microsoft! Quite a sign... but...
>
> Now, what we may see is cheating on the protocol, interop risks.
>
> What do we have to prevent this? Nothing.
>
> Certification is far too complex and costly (for all).
>
> Simple tests (like ACID) may be a good way: with public testing and
> results, it lets the communities booh the cheaters.
>
> I think it's the most important task we have now.
>
> What is your opinion?
> --
> Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com
> Jabber ID : xmpp:n...@jabber.fr
>

Re: [Standards] MSN does XMPP

[Peter Saint-Andre]

On 9/14/11 3:52 PM, Peter Saint-Andre wrote:
> On 9/14/11 3:14 PM, David Ammouial wrote:
>> 14/09/2011, Justin:
>>> - login requires using a special SASL mechanism 
>>> "X-MESSENGER-OAUTH2". - JIDs are {identifier}@messenger.live.com,
>>> where {identifier} comes from the OAuth access token.
>>
>> Could it be linked to this old, deferred specification? 
>> http://xmpp.org/extensions/xep-0235.html
> 
> No, that wasn't for authentication with the server.
> 
>> Whatever it is, I hope they'll document it at some point. I'm
>> confident that they will – if they want to allow connection via 
>> traditional clients, it would be counter-productive to force 
>> developpers to reverse-engineer the authentication protocol.
> 
> Agreed.

See also:

http://adium.im/pipermail/devel_adium.im/2011-September/008736.html

/psa

Re: [Standards] MSN does XMPP

[Peter Saint-Andre]

On 9/14/11 3:53 PM, Peter Saint-Andre wrote:
> On 9/14/11 1:49 PM, Peter Saint-Andre wrote:
>> On 9/14/11 1:12 PM, Nicolas Vérité wrote:
>>> On Wed, Sep 14, 2011 at 20:52, Peter Saint-Andre  wrote:
 On 9/14/11 12:49 PM, Dave Cridland wrote:
> Running some
> interop tests

 Perhaps it's time for another online interop test?
>>>
>>> Perhaps it's time to go further than these interop tests?
>>
>> I'm not disagreeing with that, but I think another round of interop
>> tests would be good preparation for more formal testing at the next XMPP
>> Summit (probably at FOSDEM 2012) and also automated testing at xmpp.org,
>> perhaps leading to certification. The XSF Board of Directors plans to
>> discuss this and related matters at its meeting on September 21, and as
>> always those meetings are open to the public in the chatroom at
>> xmpp:x...@muc.xmpp.org (the meeting will be either at 16:00 UTC or one
>> hour later, I will post again when that's been decided).
> 
> The meeting will be held on 2011-09-21 at 16:00 UTC.

Oh, and for your convenience:

http://xmpp.org/calendar/xsf-board.ics

Or even:

http://xmpp.org/calendar/xsf-all.ics

/psa

Re: [Standards] MSN does XMPP

[Peter Saint-Andre]

On 9/14/11 1:49 PM, Peter Saint-Andre wrote:
> On 9/14/11 1:12 PM, Nicolas Vérité wrote:
>> On Wed, Sep 14, 2011 at 20:52, Peter Saint-Andre  wrote:
>>> On 9/14/11 12:49 PM, Dave Cridland wrote:
 Running some
 interop tests
>>>
>>> Perhaps it's time for another online interop test?
>>
>> Perhaps it's time to go further than these interop tests?
> 
> I'm not disagreeing with that, but I think another round of interop
> tests would be good preparation for more formal testing at the next XMPP
> Summit (probably at FOSDEM 2012) and also automated testing at xmpp.org,
> perhaps leading to certification. The XSF Board of Directors plans to
> discuss this and related matters at its meeting on September 21, and as
> always those meetings are open to the public in the chatroom at
> xmpp:x...@muc.xmpp.org (the meeting will be either at 16:00 UTC or one
> hour later, I will post again when that's been decided).

The meeting will be held on 2011-09-21 at 16:00 UTC.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Re: [Standards] MSN does XMPP

[Peter Saint-Andre]

On 9/14/11 3:14 PM, David Ammouial wrote:
> 14/09/2011, Justin:
>> - login requires using a special SASL mechanism 
>> "X-MESSENGER-OAUTH2". - JIDs are {identifier}@messenger.live.com,
>> where {identifier} comes from the OAuth access token.
> 
> Could it be linked to this old, deferred specification? 
> http://xmpp.org/extensions/xep-0235.html

No, that wasn't for authentication with the server.

> Whatever it is, I hope they'll document it at some point. I'm
> confident that they will – if they want to allow connection via 
> traditional clients, it would be counter-productive to force 
> developpers to reverse-engineer the authentication protocol.

Agreed.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Re: [Standards] MSN does XMPP

[David Ammouial]

14/09/2011, Justin:
>   - login requires using a special SASL mechanism
> "X-MESSENGER-OAUTH2".
>   - JIDs are {identifier}@messenger.live.com, where {identifier}
> comes from the OAuth access token.

Could it be linked to this old, deferred specification?
http://xmpp.org/extensions/xep-0235.html

Whatever it is, I hope they'll document it at some point.
I'm confident that they will – if they want to allow connection via
traditional clients, it would be counter-productive to force
developpers to reverse-engineer the authentication protocol.

-- 
David


signature.asc
Description: PGP signature

Re: [Standards] MSN does XMPP

[Justin Karneges]

On Wednesday, September 14, 2011 01:02:13 PM Tobias Markmann wrote:
> On Wed, Sep 14, 2011 at 22:00, Justin Karneges
> 
>  wrote:
> >  - login requires using a special SASL mechanism "X-MESSENGER-OAUTH2".
> 
> Is that by any chance
> http://tools.ietf.org/html/draft-mills-kitten-sasl-oauth-03 ?

I am not an OAuth person but I don't think it's quite the same thing.  At 
least, the docs say to just pass an access token as the SASL payload, while 
the above draft has a special HTTP-formatted SASL payload.

Justin

Re: [Standards] Addressing Security Concerns in XEP-0115 Entity Capabilities

[Matthew A. Miller]

On Sep 14, 2011, at 13:40, Waqas Hussain wrote:

> On Wed, Sep 14, 2011 at 12:04 AM, Matthew A. Miller
>  wrote:
>> 
>> On Sep 13, 2011, at 12:18, Matthew A. Miller wrote:
>> 
>> 
>>> I've been thinking of something that might be a less-awful compromise.  
>>> I'll post to this list about it soon for us all to mock and ridicule (-:
>>> 
>> 
>> So, the less-awful compromise I was talking about is this:
>> 
>> We develop a XEP-0128 extension that defines how to canonicalize and hash 
>> disco#info results, which fixes all of the known issues with caps' current 
>> canonicalization and can be applied to any disco#info result. e.g.:
>> 
>> 
>>  
>>  ...
>>  
>>  
>>  ...
>>  
>>
>>  urn:xmpp:discohash:0
>>
>>
>>  SHA-1
>>
>>
>>  EHdJI0CahGt8XjSWUz59ODb4OrY=
>>
>>  
>> 
>> 
>> In terms of XEP-0115, a "concerned" implementation would first look and 
>> validate this hash (according to the new TBD spec).  If this extension is 
>> missing it might consider the disco results suspect (and still validate the 
>> XEP-0115 hash) or outright invalid (maybe sometime in the distant future).  
>> If present and valid, it could either A) assume the caps hash is valid (if 
>> just mildly concerned), or B) validate the caps hash but confident it will 
>> not find any of the known attacks to XEP-0115 (if correctly paranoid).
>> 
>> It does mean a fully-conforming implementation is canonicalizing and hashing 
>> twice (once for the TBD spec, once for XEP-0115), but it does mean existing 
>> implementations would still work in both directions. Plus, we could then use 
>> this for any disco#info result, potentially applying a cryptographic 
>> signature.
>> 
>> 
>> Thoughts?
>> 
>> - m&m
>> 
> 
> So.. which caps is included in presence? The current exploitable one?
> Then this doesn't help with preventing poisoning, does it?
> 

the caps hash would be as it is today.  So, yes, a client that doesn't 
understand this double-verify would still be vulnerable.

> What does considering the result suspect mean? I'm hoping you don't
> mean it isn't cached. Because that would be much worse than just using
> a new XEP, which would be a perfectly smooth transition.
> 

Being suspect means it's up to the implementation and deployment.
*  Some might accept (and cache) them but with a log message somewhere.
*  Some might reject (and not cache) them unconditionally.
*  Some might put in a timebomb into their implementations that will switch 
from "accepted" to "rejected".

> I have assumed the whole point of all this effort to keep the old XEP
> is to get rid of the transition period, so if you are not going to
> cache exploitable caps at all, might as well define a clean new XEP.

The point of trying to keep the old XEP is not to eliminate a transition, but 
to make it less painful.  I do think having a complete replacement to caps is 
more painful than applying an addendum or two.  As Dave said, the building is 
not burning (yet).


- m&m




smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] MSN does XMPP

[Tobias Markmann]

On Wed, Sep 14, 2011 at 22:00, Justin Karneges
 wrote:
>  - login requires using a special SASL mechanism "X-MESSENGER-OAUTH2".
>

Is that by any chance
http://tools.ietf.org/html/draft-mills-kitten-sasl-oauth-03 ?

Re: [Standards] MSN does XMPP

[Justin Karneges]

On Wednesday, September 14, 2011 12:25:52 PM Justin Karneges wrote:
> On Wednesday, September 14, 2011 10:43:38 AM Nicolas Vérité wrote:
> > Thanks for those of you who twitted it:
> > http://www.liveside.net/2011/09/14/messenger-connect-is-now-live-connect-
> > ne w-apis-for-skydrive-and-hotmail-calendar/ XMPP Interface : You can
> > integrate Messenger into your Web-based,
> > desktop, or mobile instant messaging products by connecting to our
> > XMPP service.
> 
> Has anyone had any luck viewing the SDK documentation?  There's a .chm file
> and an .msi file, but the former appears to have no content and the latter
> installs but with no indication that anything has been installed.  I'm on
> Windows 7.

Replying to myself.  I just learned that .chm files are considered potentially 
harmful and by default the operating system blocks loading of their content.  
You have to click "Unblock" in the properties of any such file you care about.  
Shows you how much I use Windows..

Details from the docs:
  - messenger.live.com is the XMPP domain (there are xmpp-client SRV records 
but no xmpp-server).
  - login requires using a special SASL mechanism "X-MESSENGER-OAUTH2".
  - JIDs are {identifier}@messenger.live.com, where {identifier} comes from the 
OAuth access token.
  - No mention of S2S as far as I can tell, even though the announcement seems 
to hint at it: "Messenger will now be accessible via XMPP for any application 
or *IM network* that wants to interoperate with it." (emphasis mine)
  - The docs reference RFCs and XEPs.  Very nice. :)

Justin

Re: [Standards] MSN does XMPP

[Peter Saint-Andre]

On 9/14/11 1:12 PM, Nicolas Vérité wrote:
> On Wed, Sep 14, 2011 at 20:52, Peter Saint-Andre  wrote:
>> On 9/14/11 12:49 PM, Dave Cridland wrote:
>>> Running some
>>> interop tests
>>
>> Perhaps it's time for another online interop test?
> 
> Perhaps it's time to go further than these interop tests?

I'm not disagreeing with that, but I think another round of interop
tests would be good preparation for more formal testing at the next XMPP
Summit (probably at FOSDEM 2012) and also automated testing at xmpp.org,
perhaps leading to certification. The XSF Board of Directors plans to
discuss this and related matters at its meeting on September 21, and as
always those meetings are open to the public in the chatroom at
xmpp:x...@muc.xmpp.org (the meeting will be either at 16:00 UTC or one
hour later, I will post again when that's been decided).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Re: [Standards] Addressing Security Concerns in XEP-0115 Entity Capabilities

[Waqas Hussain]

On Wed, Sep 14, 2011 at 12:04 AM, Matthew A. Miller
 wrote:
>
> On Sep 13, 2011, at 12:18, Matthew A. Miller wrote:
>
>
>> I've been thinking of something that might be a less-awful compromise.  I'll 
>> post to this list about it soon for us all to mock and ridicule (-:
>>
>
> So, the less-awful compromise I was talking about is this:
>
> We develop a XEP-0128 extension that defines how to canonicalize and hash 
> disco#info results, which fixes all of the known issues with caps' current 
> canonicalization and can be applied to any disco#info result. e.g.:
>
> 
>  
>  ...
>  
>  
>  ...
>  
>    
>      urn:xmpp:discohash:0
>    
>    
>      SHA-1
>    
>    
>      EHdJI0CahGt8XjSWUz59ODb4OrY=
>    
>  
> 
>
> In terms of XEP-0115, a "concerned" implementation would first look and 
> validate this hash (according to the new TBD spec).  If this extension is 
> missing it might consider the disco results suspect (and still validate the 
> XEP-0115 hash) or outright invalid (maybe sometime in the distant future).  
> If present and valid, it could either A) assume the caps hash is valid (if 
> just mildly concerned), or B) validate the caps hash but confident it will 
> not find any of the known attacks to XEP-0115 (if correctly paranoid).
>
> It does mean a fully-conforming implementation is canonicalizing and hashing 
> twice (once for the TBD spec, once for XEP-0115), but it does mean existing 
> implementations would still work in both directions. Plus, we could then use 
> this for any disco#info result, potentially applying a cryptographic 
> signature.
>
>
> Thoughts?
>
> - m&m
> 

So.. which caps is included in presence? The current exploitable one?
Then this doesn't help with preventing poisoning, does it?

What does considering the result suspect mean? I'm hoping you don't
mean it isn't cached. Because that would be much worse than just using
a new XEP, which would be a perfectly smooth transition.

I have assumed the whole point of all this effort to keep the old XEP
is to get rid of the transition period, so if you are not going to
cache exploitable caps at all, might as well define a clean new XEP.

--
Waqas Hussain

Re: [Standards] Addressing Security Concerns in XEP-0115 Entity Capabilities

[Waqas Hussain]

On Tue, Sep 13, 2011 at 2:22 AM, Peter Saint-Andre  wrote:
> On 9/7/11 8:51 PM, Peter Saint-Andre wrote:
>> On 9/7/11 2:33 PM, Joe Hildebrand wrote:
>>> On 9/5/11 6:39 AM, "Dave Cridland"  wrote:
>>>
 Of course, it may be simplest just to bite the bullet and switch hash
 algorithm - or even change the 'hash' attribute name - because then
 it'll get treated as a pre-1.4 caps by the vast majority of entities
 and everything will happen right (or at least, no worse than it often
 does today anyway).
>>>
>>> A bunch of our software already assumes that if you're doing old caps, you
>>> don't have any caps we care about.
>>>
 I'm gradually leaning toward this, because although it's *quite*
 violent, the downside is not impossible.

 BTW, anyone any idea what happens if you include more than one 
 in a presence, in practical terms?
>>>
>>> I imagine you'd break enough stuff that my vote would be to use a different
>>> namespace.  And then all of the people who complain to me about the *VAST*
>>> number of octets that caps takes will redouble their bitching and moaning.
>>
>> That's one reason I'd prefer to patch up XEP-0115. Including both caps
>> and son-of-caps in presence broadcast strikes me as a bad idea.
>
> Joe Hildebrand, Matt Miller, and I talked about caps off-list last week
> over a high-bandwidth connection (i.e., in person). We came up with one
> possible approach for discussion on the list.
>
> One of the major problems with the current approach is that there's no
> hard border between identities and features, and between features and
> extensions. As a result, malicious software can define certain clever
> identities and features and extensions that bleed over into adjacent
> parts of the input string.
>
> One way to solve this problem is to define a new algorithm, either in a
> revision to XEP-0115 or in a new spec with a new namespace. To conserve
> space in presence, we'd prefer to avoid a new namespace. So that it is
> possible to continue using the vast majority of existing caps hashes,
> we'd prefer to keep the algorithm the same, if that can be accomplished
> in a secure way.
>
> We thought of another approach, which has two parts...
>
> First, we need a way to mark the border between identities and features.
> We can do so by defining a new feature that is *always* sorted first
> according to i;octet collation (RFC 4790). Now, the 'var' attribute in
> disco#info is defined as xs:string [1] so any Char [2] from the XML spec
> is allowed. The first-sorted Char would be U+0009 but that's not
> printable. The first printable Char would be U+0020 but that might be
> difficult to debug (var=" ") and certainly would be difficult to list in
> the relevant XMPP registry [3]. Thus I would propose U+0021:
>
> 
>
> (Nit: yes, you'd have to check for the existence of features that start
> with U+0009, U+000A, U+000D, and U+0020 and treat such features as an
> attack; if people don't like that special-casing we can just go with
> U+0009 instead of U+0021.)
>
> Any software supporting this approach would need to advertise support
> for the first-sorted disco feature. If an application processes a caps
> input string that *not* contain the first-sorted feature, based on local
> service policy it could either reject it as an attack or accept it as
> using the old-style caps algorithm. (Eventually everyone would regard it
> as an attack, but that might not happen for a few years.)
>
> Second, we need a way to mark the border between features and
> extensions, or more generally to make sure that extensions can't leak
> into the feature space. Because there is no last-sorted disco feature
> (since the Unicode Consortium might always add new code points), we
> thought of defining a new FORM_TYPE "urn:xmpp:clarkform" or somesuch. In
> forms of this type, the field names MUST use Clark notation [4], like so:
>
>    
>      
>        urn:xmpp:formtype
>      
>      
>        baz
>        qux
>      
>    
>
> We then legislate that XEP-0128 extensions MUST use this FORM_TYPE (this
> is not a major imposition since there is very little use of XEP-0128 in
> the wild). Here again, if an application processes an input string that
> contains a FORM_TYPE other than "urn:xmpp:clarkform", based on local
> service policy it could either reject it as an attack or accept it as
> using the old-style caps algorithm.
>
> Joe and Matt, do correct me if I've misrepresented our discussion.
>
> Peter
>
> [1] http://www.w3.org/TR/xmlschema-2/#string
> [2] http://www.w3.org/TR/2008/REC-xml-20081126/#NT-Char
> [3] http://xmpp.org/registrar/disco-features.html
> [4] http://www.jclark.com/xml/xmlns.htm
>

Okay.. let's see... while that was a nice try, it still doesn't work..

First, are you mandating that every client include that disco form in
their caps, even if they don't use any dataforms? If yes, ugly. If no,
they are still open to attack.

Second, I'm assuming you want to keep backwards co

Re: [Standards] MSN does XMPP

[Justin Karneges]

On Wednesday, September 14, 2011 10:43:38 AM Nicolas Vérité wrote:
> Thanks for those of you who twitted it:
> http://www.liveside.net/2011/09/14/messenger-connect-is-now-live-connect-ne
> w-apis-for-skydrive-and-hotmail-calendar/ XMPP Interface : You can
> integrate Messenger into your Web-based,
> desktop, or mobile instant messaging products by connecting to our
> XMPP service.

Has anyone had any luck viewing the SDK documentation?  There's a .chm file and 
an .msi file, but the former appears to have no content and the latter installs 
but with no indication that anything has been installed.  I'm on Windows 7.

Justin

Re: [Standards] MSN does XMPP

[Nicolas Vérité]

On Wed, Sep 14, 2011 at 20:52, Peter Saint-Andre  wrote:
> On 9/14/11 12:49 PM, Dave Cridland wrote:
>> Running some
>> interop tests
>
> Perhaps it's time for another online interop test?

Perhaps it's time to go further than these interop tests?
-- 
Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com
Jabber ID : xmpp:n...@jabber.fr

Re: [Standards] MSN does XMPP

[Peter Saint-Andre]

On 9/14/11 12:49 PM, Dave Cridland wrote:
> On Wed Sep 14 18:43:38 2011, Nicolas Vérité wrote:
>> It's Microsoft! Quite a sign... but...
>>
>> Now, what we may see is cheating on the protocol, interop risks.
> 
> I'd rather assume that any bugs in the implementation are just that -
> unintentional errors - until we hear otherwise.

Hanlon's Razor and all that:

http://en.wikipedia.org/wiki/Hanlon%27s_razor

> I hope they do have bugs, mind. If they don't have any bugs in the
> protocol implementation at all, that'll just make all of the rest of us
> look really bad...
> 
> Does anyone have any contacts with the development team? 

I have contacts.

> Running some
> interop tests to help them catch anything would be great. Unusual
> implementations often highlight bugs in specification and existing
> implementations, too.

Perhaps it's time for another online interop test? I'll commit to
helping more this time (last December I was swamped with work on the
updated RFCs).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Re: [Standards] MSN does XMPP

[Dave Cridland]

On Wed Sep 14 18:43:38 2011, Nicolas Vérité wrote:

It's Microsoft! Quite a sign... but...

Now, what we may see is cheating on the protocol, interop risks.


I'd rather assume that any bugs in the implementation are just that -  
unintentional errors - until we hear otherwise.


I hope they do have bugs, mind. If they don't have any bugs in the  
protocol implementation at all, that'll just make all of the rest of  
us look really bad...


Does anyone have any contacts with the development team? Running some  
interop tests to help them catch anything would be great. Unusual  
implementations often highlight bugs in specification and existing  
implementations, too.


Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

[Standards] MSN does XMPP

[Nicolas Vérité]

Hi,

Thanks for those of you who twitted it:
http://www.liveside.net/2011/09/14/messenger-connect-is-now-live-connect-new-apis-for-skydrive-and-hotmail-calendar/
XMPP Interface : You can integrate Messenger into your Web-based,
desktop, or mobile instant messaging products by connecting to our
XMPP service.

It's Microsoft! Quite a sign... but...

Now, what we may see is cheating on the protocol, interop risks.

What do we have to prevent this? Nothing.

Certification is far too complex and costly (for all).

Simple tests (like ACID) may be a good way: with public testing and
results, it lets the communities booh the cheaters.

I think it's the most important task we have now.

What is your opinion?
-- 
Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com
Jabber ID : xmpp:n...@jabber.fr