Re: [Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
Peter Saint-Andre wrote: Ian Paterson wrote: In real life servers will always be compromised (especially in cases where the attacker is the service provider). So SASL PLAIN still contains a serious vulnerability that is easily fixed in those cases where DIGEST-MD5 is a practical option. Except that DIGEST-MD5 is effectively being deprecated by the IETF. Thus the interest in SCRAM, YAP, and their ilk. With all due respect to the experts at the IETF, I feel (as a non-expert) that they are trying to depricate DIGEST-MD5 before it has a suitable replacement (i.e. another one that protects users' passwords from a compromised server). I strongly agree we should recommend/require SCRAM and/or YAP as soon as they are baked. But is that likely to happen before 3920bis is puiblished? I agree that if we start recommending SASL PLAIN in addition to DIGEST-MD5 now, *and if we continue to do so in the future*, then we can ensure that current implementations will still be compatible with future implementations that have removed support for DIGEST-MD5. However I don't understand why we are considering recommending weakening the security of XMPP servers in the short and medium term by not requiring any of DIGEST-MD5 or SCRAM or YAP. Are XMPP implementors experiencing interoperability issues with DIGEST-MD5? If so can't we fix them with a Best Practices XEP - as we did with SASL ANONYMOUS and SASL EXTERNAL? Which of the 7 problems with DIGEST-MD5 mentioned in [1] make DIGEST-MD5 less secure for XMPP authentication than SASL PLAIN? - Ian [1] http://www.ietf.org/internet-drafts/draft-melnikov-digest-to-historic-00.txt
Re: [Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]
Dave Cridland wrote: On Tue Sep 11 11:55:35 2007, Jonathan Chayce Dickinson wrote: Interesting because most clients used Digest-MD5, so what do we use now? Cram-MD5? Or is there some other newfangled method out there? DIGEST-MD5 is still more secure than CRAM-MD5, and this won't change because of that draft. :-) I strongly agree. Despite its imperfections, RFC 3920bis should continue recommending and requiring DIGEST-MD5 until something better has been adopted by the IETF. Furthermore I disagree with the following problem with the DIGEST-MD5 mechanism included in the Internet-Draft: Implementations may chose to store inner hashes instead of clear text passwords. While this has some useful properties, such as compromise of an authentication database on one server does not automatically compromise an authentication database with the same username and password on other servers, in practice this was rarely done. Firstly, the inner hash is not compatible with commonly deployed Unix password databases. Secondly, change of a username invalidates the corresponding inner hash. In practice inner hashes may be stored relatively rarely, however that does not necessarily make the optional feature into a problem. It is, IMHO, a critical security feature that should be employed whenever practical. Perhaps RFC 3920bis could encourage this practice - while mentioning the potential impracticalities. Note, a change in the SASL mechanisms supported by future versions of an XMPP server is probably a more likely cause of invalidating the inner hash than changing XMPP usernames (which are generally fixed). - Ian
Re: [Standards] e2e encryption and jingle
Niklas Höglund wrote: I'd like all my communication to be encrypted end-to-end, so I like the development going on in the jabber community on that side. Voice calls are also very useful, but from a quick look at the jabber XEPs I can't see how these two features should interoperate. How should this work? The clients should negotiate an Encrypted Session first. Then the client should negotiate the Jingle Session. That protects the potentially sensitive information (e.g. IP addresses) that is exchanged during the Jingle negotiation. A note about this might usefully be added to the 5.1 Resource Determination and/or Security Considerations sections of XEP-0166. Note that this separation of layers enables the protocols to be used independently, however, the fact that the two negotiations are carried out simultaneously creates latency in the establishment of a call (something that AFAICT is an issue in the Real World). Perhaps a couple of round trips could be saved by *optionally* including the first jingle/ negotiation elements in the message/ stanzas used for the Encrypted Session negotiation (instead of in subsequent iq/ stanzas)? - Ian
Re: [Standards] Group Name with Gateway Registration
Tomasz Sterna wrote: Dnia 15-08-2007, śro o godzinie 18:31 +0100, Ian Paterson napisał(a): Currently the name of the group that contacts will be added to tends to be hardcoded on the gateway. You are talking about gateway XEP-0144 usage? Yes, or the direct roster editing that some server-hosted-plugin gateways seem to perform. - Ian
Re: [Standards] Group Name with Gateway Registration
Ian Paterson wrote: Currently the name of the group that contacts will be added to tends to be hardcoded on the gateway. This causes problems if there are language issues or, more typically, if the user has two accounts on a legacy service (accessed via two instances of a gateway server) - in which case the contacts will end up being mixed within the same group. To solve this I'd suggest adding a new example (see [1] below) to Section 7 Contact Lists that indicates how the client/user might specify during registration a group name (see the group field/ below) that the gateway will use whenever it adds contacts to the user's roster. Someone mentioned offlist that some legacy services now support groups, and that some gateways now use these group names (instead of a single hardcoded group). So it may be useful for the client to be able to indicate a prefix/suffix for all group names, instead of a single prefered group name. (A zero length prefix/suffix would be equivalent to no change to the group names at all.) I'd suggest a second additional field like the one in the examples below. - Ian SERVER SENDS: . . . field type='list-single' label='Group Name Modification' var='groupmodify' option label='Prefix' valueprefix/value /option option label='Suffix' valuesuffix/value /option option label='Fixed' valuefixed/value /option /field field type='text-single' label='Group Name' var='group' value/ /field . . . CLIENT SENDS: . . . field var='groupmodify' valuesuffix/value /field field var='group' value (Yahoo Work)/value /field . . .
Re: [Standards] whiteboarding and shared editing
Greg Hudson wrote: A generic XML editor isn't going to know much about the semantics of the document it is editing. It's not necessarily going to be a good framework for a whiteboarding application, any more than emacs is a good foundation for Photoshop. They both edit files, but... Nobody is suggesting deploying a single editor for two different applications. We are suggesting that although the two editors would be designed for incompatible applications, they could talk the same protocol at the lowest level, and that they could therefore share a code library (just as many very different applications might use the same database engine). I would have thought that, a *very low level* synchronised XML editing protocol suitable for SVG documents could be very similar to, for example, one for XHTML documents. 1. What significant differences do people see between two such *lowest* level protocols? 2. Could those differences be optional parts of a single low-level protocol? 3. What specific real-world disadvantages do people see if we use a single low level building-block protocol? All XML editing applications share the same major challenge, i.e. the various issues surrounding synchronization. IMHO, the application-specific protocol issues tend to be relatively trivial to work out. So if we standardise on a good extensible synchronization protocol then we will facilitate many applications and avoid protocol designers reinventing the wheel. - Ian
[Standards] Group Name with Gateway Registration
Peter Saint-Andre wrote: Ian Paterson wrote: Peter Saint-Andre wrote: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0100.xml?%40diffMode=u%40diffWrap=sr1=1092r2=1134u=3ignore=k= TinyURL: http://tinyurl.com/2dxv5j That looks good, thanks :-) Super, I've added that to the agenda for the next Council meeting: Since we're already making a couple changes to this XEP, can we consider including a recommended fix for the issue below: Currently the name of the group that contacts will be added to tends to be hardcoded on the gateway. This causes problems if there are language issues or, more typically, if the user has two accounts on a legacy service (accessed via two instances of a gateway server) - in which case the contacts will end up being mixed within the same group. To solve this I'd suggest adding a new example (see [1] below) to Section 7 Contact Lists that indicates how the client/user might specify during registration a group name (see the group field/ below) that the gateway will use whenever it adds contacts to the user's roster. - Ian [1] CLIENT SENDS: iq type='set' from='[EMAIL PROTECTED]/orchard' to='aim.shakespeare.lit' id='reg2' query xmlns='jabber:iq:register' x xmlns='jabber:x:data' type='submit' field var='FORM_TYPE' valuejabber:iq:register/value /field field var='username' valueRomeoMyRomeo/value /field field var='password' valueILoveJuliet/value /field field var='group' valueAIM (Work)/value /field /x /query /iq
Re: [Standards] Username Escaping with Gateway Registration
Peter Saint-Andre wrote: Peter Saint-Andre wrote: Ian Paterson wrote: XEP-0100 Gateway Interaction doesn't, AFAICT, explain whether the username supplied at registration should be the Legacy Service username or the Jabber username. [The difference between these usernames (typically escaping) is explained in section 6.2 (User Addressing).] Can anyone please enlighten me on which username should be used? The username used for registration is the LegacyUserAddress. I'll clarify this in the spec. See here: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0100.xml?%40diffMode=u%40diffWrap=sr1=1092r2=1134u=3ignore=k= TinyURL: http://tinyurl.com/2dxv5j That looks good, thanks :-) - Ian
[Standards] Username Escaping with Gateway Registration
XEP-0100 Gateway Interaction doesn't, AFAICT, explain whether the username supplied at registration should be the Legacy Service username or the Jabber username. [The difference between these usernames (typically escaping) is explained in section 6.2 (User Addressing).] Can anyone please enlighten me on which username should be used? I think it would be very useful to specify this in the XEP. - Ian
Re: [Standards] IMML
Alex Jones wrote: By the way, how the sending client knows in is an emoticon? Many users I know just type them, not select from list. That's an application issue that can be tackled. In any event, rather the sender decide than the receiver. Yes. The sending user will see how her client interpreted what she typed, and can therefore control what the receiving user will see before clicking SEND. Alex Jones wrote: On Wed, 2007-08-08 at 13:21 +0100, Ian Paterson wrote: Mridul Muralidharan wrote: If we just add another tag to explicitly mark emoticons - and remove the implicit rendering completely - then Alex's baseline requirements should be done with IM-XHTML itself ? Yes. This would be backward compatible too since, IIRC, XHTML parsers should ignore tags they don't understand (and the tag would be qualified by a namespace other than 'http://www.w3.org/1999/xhtml' anyway). I feel it shouldn't be a part of XHTML-IM though. I think there is a need to use icons that is independent of the need to use even the most minimal, valid support of XHTML-IM. Well, RFC 3921 states that the body/ element MUST NOT contain mixed content. And I agree with Michal that we should avoid including three copies of the message in each stanza. So it seems that the only place for the new emoticon tags is inside the XHTML-IM (under a different namespace). Furthermore, it would be complicated to write the code to display both XHTML and emoticon elements if they are kept separate. Whereas it is trivial to write the code to ignore the one or the other if they are merged. - Ian
Re: [Standards] XEP-0045: direct invitations
Peter Saint-Andre wrote: Michal 'vorner' Vaner wrote: So just one last question - how does a client know, when to send direct or usual presence? Sends both? Perhaps. Inviting people to rooms happens infrequently enough that it's not a bandwidth issue. But it may be confusing for the receiving client to get two invitations. Then do we need some logic for checking duplicate invitations? Ick. This is definitely Ick. But the other options (Aunt Tillie decides or hardcode @gmail.com) are even worse. I understand why Google Talk has this policy, so I'm not going to argue them out of it. But it does introduce complications. *Maybe* we need to consider addressing the valid reasons that Google Talk feels it needs this policy, rather than handling the symptoms of the policy? Can we solve the real problem? i.e. can we create enough anti-spim protocols and/or infrastructure to make Google (and everyone else) confident enough to relax this policy? - Ian
Re: [Standards] inactive XEPs
Peter Saint-Andre wrote: The following XEPs have been inactive for 6+ months and therefore are subject to automatic deferral. If you have an interest in these specs, please speak up. XEP-0154: User Profile http://www.xmpp.org/extensions/xep-0154.html Now that PEP/PDP are being finalized, I hope we can move this to Draft and start to depricate vcard-temp. - Ian
Re: [Standards] XEP-0115 1.4pre2
Dave Cridland wrote: For maximum pedantry, you might note that the base64 encoding used MUST NOT contain whitespace (which RFC 4648 says is the default anyway) and MUST set padding bits to 0 (which RFC 4648 says applications MAY require). These requirements mean that the resultant base64 from any given input has precisely one form, and so can be used for direct comparison. Yes, this is important to specify. - Ian
Re: [Standards] XEP-0115 1.4pre1
Peter Saint-Andre wrote: I've made a first pass at updating XEP-0115 (Entity Capabilities) in line with recent list discussion: This looks like a good first pass. - In section 1.2 How it Works: 1. If Benvolio is publishing caps with a different 'node' but the same 'ver' then I don't need to perform another disco#info. So can you make that clear from the outset by giving Benvolio a different node attribute to Romeo in the example? - When generating the ver attribute (section 5): 1. It would be more secure to include a delimiter character between the various parts of the string E. The delimiter should be a '' character since it may not appear in an XML attribute value. 2. The big-endian array of bytes output by the hash function should be converted directly to a base64 string, since converting it to a hexadecimal string first only serves to double the length of the ver attribute. - Discovering Capabilities (Section 6.2) Why should the client pick a random JID from that list? Why is the disco#info query sent to a node of node#ver (see section 1.2 too). Why should the capabilities supported by the base installation of the application without plugins or other add-ons be returned, and not the capabilities that the client currently offers (i.e. those that correspond to the hash value)? Insert a point saying that clients SHOULD (MUST?) calculate the hash of the returned identity and features to confirm that they correspond to value of the 'ver' attribute (to prevent caps cache poisoning). - Ian
Re: [Standards] XEP-0115 1.4pre1
Peter Saint-Andre wrote:
Ian Paterson wrote:
- In section 1.2 How it Works:
1. If Benvolio is publishing caps with a different 'node' but the same
'ver' then I don't need to perform another disco#info. So can you make
that clear from the very outset by giving Benvolio a different node
attribute to Romeo in the example?
Any objections to changing 'http://exodus.jabberstudio.org/caps' to
'http://psi-im.org/caps' in the second presence stanza in section 1.2
(i.e. the one from '[EMAIL PROTECTED]/230193')?
Why is the disco#info query sent to a node of node#ver (see section
1.2 too). Why should the capabilities supported by the base
installation of the application without plugins or other add-ons be
returned, and not the capabilities that the client currently offers
(i.e. those that correspond to the hash value)?
More leftover text. Removed.
OK, thanks. In that case, in Section 1.2 the text: '(note that the
disco#info query is sent to a node of node#ver)' and #{ver} in the two
disco#info examples also need to be removed.
Finally, a small typo, there's a double '' character in the line below
from section 5:
5. E =
'client/pchttp://jabber.org/protocol/disco#infohttp://jabber.org/protocol/disco#itemshttp://jabber.org/protocol/muc'
- Ian
Re: [Standards] private storage revisited
Peter Saint-Andre wrote:
We already have one such solution/hack in PEP: the +notify
namespaces used in entity capabilities to signal that a subscriber wants
to receive notifications related to a given namespace. Your suggestion
of +whitelist (etc.) is in the same spirit, but +notify does not force
semantic structure on NodeIds, which +{access_model} does (and the
objections may arise because NodeIds are supposed to lack semantic
structure).
Yes, there is a significant difference between +notify (where the var attribute of the
feature/ element continues to specify only the functionality that the client supports), and
+{access_model} (where the 'node' attribute of the feature/ element no longer simply
identifies a node, i.e. it is overloaded to also specify the configuration of the server).
That said, we still might want to consider defining a new notify='true' attribute for
disco#info feature/ elements. Disco is Final, but this change would be 100%
backwards compatible, and is therefore permitted. What do people think?
- Ian
Re: [Standards] private storage revisited
Ian Paterson wrote: Wow! consensus on Personal Publishing! I'm off to celebrate :-) :-) Well, so far only a consensus of 3 people who disagreed in the past. - Ian
Re: [Standards] private storage revisited
Peter Saint-Andre wrote: So we'd have something like this: iq from='juliet at capulet.com/balcony' type='set' id='foo' pubsub xmlns='http://jabber.org/protocol/pubsub' publish node='http://jabber.org/protocol/activity' item activity xmlns='http://jabber.org/protocol/activity' relaxing partying/ /relaxing text xml:lang='en'My nurseapos;s birthday!/text /activity /item /publish preconditions x xmlns='jabber:x:data' type='submit' field var='FORM_TYPE' type='hidden' valuehttp://jabber.org/protocol/pubsub#node_config/value /field field var='pubsub#access_model' optionvaluewhitelist/value/option /field /x /preconditions /pubsub /iq If the node exists and the precondition is not met (in this case, if the access model is something other than whitelist), then the publish fails with a suitable error condition (probably conflict/ along with some pubsub-specific condition). If the node exists and the precondition is met, then the publish succeeds. If the node does not exist, then the service auto-creates the node with default configuration in all respects except those specified in the preconditions (in this case, the node would be created with an access model of whitelist) and the publish succeeds. Correct? Correct. +1 Thank you Ralph, Peter. Wow! consensus on Personal Publishing! I'm off to celebrate :-) :-) - Ian
Re: [Standards] private storage revisited
Peter Saint-Andre wrote: Whenever a client publishes the first item to a node that ends in +[accessmodel], the pubsub service MUST create the node with a default access model equal to the specified model (that is open or presence or roster or authorize or whitelist). [1] For such a node, the access model MUST remain fixed and a pubsub service MUST return an error if the node owner tries to change it. [1] In fact roster doesn't make sense here since you need to specify the roster group. And BTW the list for whitelist must start out empty, i.e., only the node owner can publish or subscribe. I think I agree with everything above except the proposed syntax. *If* we agree on the functionality, then IMHO it *should* be trivial to come up with a more appropriate syntax. I strongly disagree with overloading the node attribute with the access model. IMHO, mixing an identifier and a configuration parameter into the same attribute would be a horrible (and unnecessary) hack. Instead of: publish node='http://jabber.org/protocol/activity+whitelist' I could live with this syntax: publish node='http://jabber.org/protocol/activity' access_model='whitelist' However, IMHO, the following example stanza would fit better with the rest of the protocol. That would make it easier for developers, since they could simply reuse their existing configure/ element processing code: iq from='[EMAIL PROTECTED]/balcony' type='set' id='create-presence' pubsub xmlns='http://jabber.org/protocol/pubsub' publish node='http://jabber.org/protocol/activity' item activity xmlns='http://jabber.org/protocol/activity' relaxing partying/ /relaxing text xml:lang='en'My nurseapos;s birthday!/text /activity /item /publish configure x xmlns='jabber:x:data' type='submit' field var='FORM_TYPE' type='hidden' valuehttp://jabber.org/protocol/pubsub#node_config/value /field field var='pubsub#access_model' optionvaluewhitelist/value/option /field /x /configure /pubsub /iq I stress that the functionality associated with the above example would be absolutely identical to that which Peter described above. - Ian P.S. I put Ralph on copy because, although he has been very busy recently, we're not going to move forward on this without his input and eventual acceptance (he's both a principle author of the PubSub protocol and a council member).
Re: [Standards] Re: [jdev] XEP-0115: Entity Capabilities
Mridul Muralidharan wrote: Joe Hildebrand wrote: Changing the meaning of node breaks backwards compatibility, whereas nothing else in the current proposal does. If there's no good reason to break backward compatibility, I suggest that we avoid it. I am not sure what was decided as the final design for the spec regarding hashing, but moving from existing scheme of ver ext also breaks backward compatibility. I don't think it does. 1. The 'ver' attribute used to be opaque, so existing implementations should cope perfectly if they receive one containing a base64-encoded hash value instead of something like 2.3. 2. The 'ext' attribute used to optional, so legacy applications won't mind if it is never specified by implementations of the latest protocol versions. 3. The new 'hash' attribute (containing the name of the hash) will be ignored by existing implementations. New implementations will need to be aware that if no 'hash' value is specified they should ignore the caps element (they should not attempt to be compatible with legacy caps since that would make them vulnerable to cache poisoning). - Ian
Re: [Standards] Re: [jdev] XEP-0115: Entity Capabilities
Peter Saint-Andre wrote: I also agree with Dave that we want to future-proof this. What if 3 years from now we want to use SHA-256 and 7 years from now we want to use an algorithm that emerges from the current NIST work? It might be good to include a 'hash' attribute whose value is one of the hash function text names from the IANA registry (but the value defaults to MD5 or whatever we settle on now so that you don't have to include it until we decide to allow alternate algorithms). +1 If we want to prevent malicious cache poisoning going forward, then clients need to be able to upgrade the hash they are using. MD5 is not secure enough even for this purpose. (I've read about attacks that require less than an hour of computing time!) IMHO, SHA256 is the most reasonable default. 2) do we need ext in the hash world? Rachel makes a good point that without ext, more data has to be cached, since there will be redundant features associated with different ver's. I think it's a toss-up; no ext's is considerably simpler for all involved; no partitioning of features on the sender side and no unions on the receiving side. I don't think we need 'ext' in the hash world. +1 the protocol is far simpler to implement without extensions. More storage will be required. But I'm not sure that we'll hit the sweet spot for storage-challenged clients. i.e. It may well be that those clients that have insufficient storage to cache the hash for each combination of plugins also have insufficient storage to cache hashes for each separate extension (i.e. they can't use caps at all). Joe Hildebrand wrote: On Jul 3, 2007, at 6:48 AM, Ian Paterson wrote: Rachel Blackman wrote: Let's say we have node='http://ceruleanstudios.com/astra/caps' and ver='h$someverylongstring' and ext='h$otherverylongstring' Or how about simply: node='$' ver='base64encodedHashOfFeatures' No. The other reason for caps is so that receivers can show a different icon for each different client that they have received presence from. There has to be a URI to define the sending client. Yes, that cuts down on the old iq:version flood. Or so we hope. :) Hmm, going forward, are the clients that most people use going to continue showing these icons? Is this a feature we need to care about? Even though I'm one of the small group of people involved in the XMPP community, I really don't care what client my contacts are using. Will there ever be mass demand for this feature? On the rare occasions where people are interested, they'll probably be perfectly happy to explicitly ask their client to find out the other user's client version on a case-by-case basis. IMHO the 'node' attribute could be repurposed to be the name of the hash function (for backwards compatibility). We could also add some language to the XEP stating that clients SHOULD NOT perform an iq:version flood. (IMHO, assuming the features hash is available via caps, there is little justification for such behavior.) Dave Cridland wrote: Assuming you didn't really mean base64, since hashes are typically represented as strings simply as hex digits. Base64 would be smaller, but unusual, and potentially include character-space clashes with Disco. I did mean base64, but if people think that is too hard to implement, then hex is fine (even though it is 50% longer). I don't understand how base64 could create clashes with Disco. - Ian
Re: [Standards] Re: [jdev] XEP-0115: Entity Capabilities
Justin Karneges wrote: Apologies for not understanding this thread at all and just commenting out of nowhere, but what security is gained by using a hash in the caps protocol? If there is no security gained by using a hash (e.g. everyone has access to the raw data such that they can all calculate the same hash) then what difference does it make which algorithm is used? What if the raw data is supplied by the attacker? Imagine Eve wants to poison the caches of clients that haven't yet received presence from a brand new release of Psi. If it is easy to discover collisions for the hash used by Psi, then Eve can send Psi's hash to a client and respond to its resulting disco request with a false set of features that she generated earlier. The false set would probably include a single unrecognizable feature whose 'var' value could be manipulated to ensure the set has the correct hash value, for example: feature var='[EMAIL PROTECTED]'/. - Ian
Re: [Standards] compliance: RFCs or bis drafts?
Peter Saint-Andre wrote: CON The RFCs are more stable. The bis drafts are officially works in progress and therefore are subject to change. Developers hate coding to a spec that is a moving target (on the other hand, they hate coding to a spec that will soon be obsolete, too). Yes, although the bis drafts are subject to change, they are almost certainly normatively closer than the RFCs to the final bis documents. IMHO that fact, plus all the clarifications, corrections and improvements, makes them better for developers. - Ian
