Re: [Standards] rfc3920bis -06
Joe Hildebrand wrote: On Jul 29, 2008, at 8:23 AM, Peter Saint-Andre wrote: Dirk Meyer wrote: Only client but IIRC adding a friend to the roster resulted in getting an iq result without sending a get or set. Very confusing. So you sent presence type='subscribe'/ and you received an IQ result from your server? That sounds like a server bug. If he meant IQ set, then it's just the roster push, not a server bug. That could be the case. Again, I'm not sure what it was and I do not believe it was a server bug. It can be confusing, but once your client knows how to handle roster pushes to the point of not changing your internal data structures until you get the push, things get a lot easier. But they are very confusing in the first place. Dirk -- This is the Time Travelling Agency's answering machine. We're closed right now but leave a message before the beep and we might have called you back.
[Standards] [Fwd: I-D Action:draft-dusseault-impl-reports-00.txt]
This may be of interest here. We've talked before about producing implementation reports regarding the XMPP RFCs (for advancement to Draft Standard) and also for XEPs (for advancement from Draft to Final). We could use a lightweight format like this for such reports. /psa Original Message From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: I-D Action:draft-dusseault-impl-reports-00.txt Date: Thu, 31 Jul 2008 09:45:01 -0700 (PDT) A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Guidance on Interoperation and Implementation Reports Author(s) : L. Dusseault, R. Sparks Filename: draft-dusseault-impl-reports-00.txt Pages : 13 Date: 2008-07-31 Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol. Historic reports have varied widely in form and level of content and there is little guidance available to new report preparers. This document updates the existing processes and provides more detail on what is appropriate in an interoperability and implementation report. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dusseault-impl-reports-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Questions about xhtml-im
Pavel Simerda wrote: On Sat, 02 Aug 2008 21:40:49 +0200 Maciek Niedzielski [EMAIL PROTECTED] wrote: Jehan wrote: But still for most end users, the best is wysiwyg And this is why xhtml-im needs to be about formatting, not semantics: most end users want to get (and send) what they see. And they want you to see what they see. I see no point in forbidding the semantics! I personally turn off xhtml-im as I have no way to just turn off styling (it's annoying to let others configure my fonts and colors, especially if it doesn't really work). If you don't forbid semantics, I could turn off the styling and keep the seemantic part (styled to my own preferences). And... keeping the semantic markup doesn't do any harm to users that don't know about it. They'll just configure the fonts and colors, that I don't care about (and I won't see). Right. I agree with both of you. :P So I say that we update XEP-0071 to no longer disallow semantic markup (in fact there's no real way to do that in XHTML Modularization anyway!) and encourage experimentation to see which elements people really want to use (I think it will be mostly em and strong, myself). /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed changes for ESessions
Jonathan Schleifer wrote: Hi! I'm a Gajim developer and we have implemented ESessions. However, as we're currently the only XMPP client to my knowledge implementing it and the XEP is currently deferred, we plan to make a few changes and like to get them back in the XEP. We talk some about end-to-end encryption at the XMPP Summit recently (nothing formal -- just a dinner discussion among people who are interested in the topic). The rough consensus was that we'll work to implement and deploy end-to-end streams and upgrade using TLS. It's a bit of a hack, but has some good features. I'll post about that in a separate thread. 1.) While the Sessions XEP explicitly states that session should NOT be regarded as ended, we think that this is fine for normal sessions, but not for ESessions. The reason is quite simple: If a contact changed his status to unavailable, the reason might be that the connection was lost due to lost TCP packages. That also means that maybe messages we sent got lost. As ESessions don't work when a message was lost and thus decrypting of further messages is not possible, we would like to regard an ESession as terminated when a contact signs off and re-establish a new ESession as soon as that user becomes available again. We also thought about keeping the thread ID and sending unencrypted. However, I'm against that as it could be that the other client reconnected and still think it's in an ESession and gets problems with this. That's why I prefer to use a new thread ID then. That is good input to the definition of a session (or chat session), which is still a bit unclear. 2.) I'm not completely satisfied with the security of ESessions. They give an attacker pretty much possibilities for known plain-text and timing attacks. Thus, I propose the following changes: * Add a random tag to every stanza before encryption to make sure an attacker never knows the full plain-text. With the current version of the XEP, an attacker would know the full plain-text for example on typing notifications, which can be spotted very easily on their size (another issue I'll talk about later). True. * Typing notifications make it easy for an attacker to do a timing attack. There are attacks that lets an attacker guess the content of a message by looking at how long was typed and the timing distance to the last message. The solution I'd propose is to send a bogus stanza from time to time, only including a random tag, but with a value a bit longer than proposed in the first point of 2.). Additionally, a XEP-0184 receipt request should be added to SOME of those bogus packets - whether or not that receipt is added is random. If the client does not support XEP-0184, a receipt is never requested, of course, therefore the bogus packets won't request it as well then. * XEP-0184 receipt requests are always answered instantly. So an attacker knows by just the timing that a packet is an answer to a XEP-0184 receipt request. That's why I propose to ALWAYS answer XEP-0184 receipt requests unencrypted, as the attacker would only get data for a known full-plain-text attack from this. Additionally, bogus XEP-0184 receipt requests should be sent from time to time - this would already be covered by the point before this one (bogus stanzas that randomly include a XEP-0184 receipt request) I don't we have that problem with an end-to-end stream, do we? * Add padding with a random length, so it's impossible to analyze the message on it's length. Without this, it's easy to guess from the length of a packet if it's for example a typing notification, allowing the before mentioned timing attack. Plus the size of an encrypted message already gives a clue about the possible content. 3.) This suggestion is optional and I personally would NOT implement it, as IMHO, this is against the idea of instant messaging: Add a random delay to packets, not a big one, only a small time. This would make timing attacks even harder. I would add that as an optional thing to the XEP, maybe something the clients can enable on demand when messaging doesn't need to be so instant. What exactly is the timing attack? I'd be glad to hear some opinions to these proposals before we implement them. Maybe someone got even better ideas on how to solve the current deficiencies? I've been doing some research on Short Authentication Strings (SAS), and I think the usage of SAS in ESessions may be close to worthless. But I'll post about that separately. However, we are very likely going to do something against these deficiencies and of course it would be nice if the XEP could be
Re: [Standards] comments on section 8.3, draft-saintandre-rfc3920bis-06.html
Pedro Melo wrote: On Jul 22, 2008, at 2:12 AM, Ovidiu Craciun wrote: Excerpt from: http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-06.html Section: 8.3. Generation of Resource Identifiers A resource identifier can be security-critical. For example, if a malicious entity can guess a client's resource identifier then it may be able to determine if the client (and therefore the controlling principal) is online or offline, thus resulting in a presence leak as described under Section 15.13 (Presence Leaks). Traditionally, XMPP resource identifiers have been generated by clients in ways that are not secure (e.g., hardcoding the resource identifier to the name of the client or to a common location such as home or work). However, for the sake of proper security, a resource identifier SHOULD be random (see [RANDOM] (Eastlake, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security,” June 2005.)). It is RECOMMENDED that the resource identifier incorporate a Universally Unique Identifier (UUID), for which the format specified in [UUID] (Leach, P., Mealling, M., and R. Salz, “A Universally Unique IDentifier (UUID) URN Namespace,” July 2005.) is RECOMMENDED. From the IMPP RFC I get that: X can read Y's presence info only (A) if Y's presence info is public domain, or (B) if Y previously allowed X to read it's presence. In this case, when a malicious entity, that can guess X's resource identifier, is be able to read X's presence only if (A) or (B) is true, in which case it is not a security threat, it is by default. What I am saying is that the presence leaks are not related with the easiness of guessing X's resource IDs but if the server is handling correctly the presence information for a given JID. I believe the above paragraph is not referring to presence leaks as a full presence stanza but just as a way for me to know if you are online or not. It might not be your full presence but it is still a leak. Yes, this is not a leak of presence/ stanzas, but it is effectively a leak of information about whether a particular resource is online. If I can guess your resource, I might trick your client into replying to an IQ or direct presence stanza. Any of those replies would mean that you are online at the moment, and therefore constitute a presence leak. Correct. Also, the requirement to have a resource identifier be random for the sake of proper security it is also a forced and unnecessary requirement. The server should guarantee the security by implementing correctly a secure protocol not by following recommendations. If you bind your sessions without a resource, the server will give you a random resource. For the server to enforce a proper security perimeter, it would have to filter (drop) IQ's directed to your JID from JIDs outside your roster. This would most likely prevent some normal (as in currently available and useful) workflows. Well, this is pretty much how Google Talk works, and it mostly functions just fine. Sometimes I chat with people that are not on my roster, including file transfer. That would be impossible with a server-side firewall. Of course, you can today implement such firewall with privacy lists, if your server supports them. Right. Or XEP-0191. Effectively Google Talk (and other similar services) deploy a rule of forbid communications with people not on my roster on the user's behalf -- no need for fancy privacy rules managed by the user. Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] presence priority -1 issues
Pedro Melo wrote: On Jul 31, 2008, at 5:21 PM, Dave Cridland wrote: On Thu Jul 31 17:17:40 2008, Pedro Melo wrote: Moving forward, this would allow clever clients to observe that it wasn't a IM client capable of handling calendaring requests, but a dumb calendaring bot working on behalf of the user. Not following. Clients could have an integrated calendaring app, allowing both chat and calendaring traffic to happen to the same full jid. Alternately, it may only do one or the other. Yes, but then you would only need to publish the proper feature. What makes a automated system try a certain protocol is the feature, not the identity. The identity automation/calender (per Peter example) is only needed to mark a resource as a non-IM resource. So a clever Calendar application that also allows chat would probably still announce itself with a client/pc but would also set feature to support cal-dav-over-xmpp, or whatever. Then do we need a feature for IM (as in, sorry, this calendaring resource doesn't do that instant messaging stuff)? /psa smime.p7s Description: S/MIME Cryptographic Signature
[Standards] forwarding (was: Re: xep-0077: account removal... and after?)
Olivier Goffart wrote: I'm about off topic here, but since you mention this spec i'd like to add my two cent. It would be cool to add a way to specify a new jid, so the server could reply with a gone/ error with the new Jid or even forward message to the new one. What prevents a malicious user from setting up an account, subscribing it to every bot on the network, and then forwarding that traffic to some third user? Sounds like a fun attack. :) /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [Fwd: SASL to draft questionnaire]
Hi Gato, Thanks for the feedback. It seems that I will need to poke other developers directly. :) /psa Gaston Dombiak wrote: Hey Peter, Openfire uses the SASL support provided by Java. That means that SASL PLAIN, DIGEST-MD5, GSSAPI, etc. are provided by Java. The only SASL mechanisms that we manually implemented on the server are SASL ANONYMOUS and SASL EXTERNAL. On the Smack side I recall implementing SASL PLAIN but we might now be using the one provied by Java. Regards, -- Gato On 7/30/08 12:34 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote: This may be of interest here -- the SASL folks are working to advance RFC 4422 to Draft and are looking for implementation reports. Has anyone on this list developed their own SASL implementation, or are all the XMPP clients, servers, and libraries incorporating specialized SASL code? Thanks! /psa Original Message Date: Tue, 29 Jul 2008 17:14:32 +0100 From: Chris Newman [EMAIL PROTECTED] Subject: SASL to draft questionnaire To: [EMAIL PROTECTED] Here's a proposed questionnaire for an implementation report. I am not volunteering to compile responses to the questions, but I am willing to answer these questions for my implementations. - Chris --- RFC 4422 Implementation Questionnaire === 0. Contact and Description Organization Name: Implementation (Software or Service) Name: 1. Have you implemented SASL and/or SASL mechanism? 2. Which SASL mechanisms have you implemented? 3. For how long has it been deployed? 4. What features have NOT been implemented from SASL? 5. What features of SASL or SASL mechanisms are problematic for your implementation? 6. Please add any other comments you wish to share: smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0231 (Data Element) - local caching
Ahoj Pavle, That all sounds good. Now we just need to update the spec (which the Council is currently voting on!). I'll try to do that soon. Peter Pavel Simerda wrote: On Thu, 31 Jul 2008 08:07:04 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Wed, 30 Jul 2008 07:04:16 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Pavel Simerda wrote: On Tue, 29 Jul 2008 19:49:01 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Ahoj Pavle! Pavel Simerda wrote: Hello, I have some suggestions for XEP-0231 (Data Element). Thanks for looking at this spec so thoroughly. I actually have some questions. First, lolek from the jabbim.cz project is going to propose a XEP for text emoticons. Similar to XEP-0038? We can bring that back if someone wants to maintain it. Similar but more powerful and not file-based but most probably based on Data Elements. There may be a lot of other extensive changes. If these changes can be made, I believe Martin would maintain it if he gets the chance. OK, great. I'm happy to help. Thanks, I'll invite him to jdev conference sometime next week. I like his ideas but I suggested him to use Data Element instead of a custom solution. +1 He still has doubts but I promised him to try to sort it out and to help him with language corrections of his document too. Great, thanks. I didn't find in the specs what should be used for domain ID in the CID. The examples apparently use the domain part of JID that is not unique for the clients. I looked at the RFC and still don't know a proper mapping to XMPP. His original idea was to use a cryptographic hash function and not a CID. I think your idea of a UUID followed by the domain part of the JID would work well. He also pointed out he misses a feature that would allow a client to advertise which mimetypes it supports. Yes we can add a disco feature for that. This is another questions... if it's just emoticons, should we just support png and mng types or add some accept-advertisement facility? I don't think it hurts to define a way to advertise what MIME types you support. We'll use the data element for things other than emoticons, but IMHO the simplest approach would be to advertise in general which MIME types you support, not I support these mime types for emoticons and I support these other mime types for file transfer thumbnails etc. Does anyone think that level of complexity is needed? I'm not sure. Let's wait for other comments. Well I'm not a fan of adding complexity if we don't need it. Agreed. Is there a written policy for image formats in XMPP extensions? Not yet. PNG for static raster images, MNG for animated raster images, SVG for vector images? That's something I would expect from every client. Sure. But some people think JPG and GIF are good too (e.g., I think JPG is the default in vCards or LDAP or somesuch). Yep, JPG is good for photos, I have forgotten because I was still thinking about the emoticons. GIF is good for nothing when we have static PNG and animated MNG that not only supersede it in all areas but also make a distinction between static and animated, which is good. (Just my opinion, others may or may not agree.) Let's move this out of discussion about XEP-0231... and discuss the image (and other) formats policy separately if needed. Right now, as the example shows: message from='[EMAIL PROTECTED]/castle' to='[EMAIL PROTECTED]' type='groupchat' bodyYet here's a spot./body html xmlns='http://jabber.org/protocol/xhtml-im' body xmlns='http://www.w3.org/1999/xhtml' p Yet here's a spot. img alt='A spot' src='cid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@shakespeare.lit'/ /p /body /html data xmlns='urn:xmpp:tmp:data-element' alt='A spot' cid='[EMAIL PROTECTED]' type='image/png' iVBORw0KGgoNSUhEUgoKCAYAAACNMs+9BGdBTUEAALGP C/xhBQlwSFlzAAALEwAACxMBAJqcGAd0SU1FB9YGARc5KB0XV+IA AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0 vr4MkhoXe0rZigBJRU5ErkJggg== /data /message Note: in this particular example the data is very short, this may not be the case in real world where people tend to ignore the size of data they send. Yes, that's just about the smallest image I could find. The spec says that the image should not be more than 8k (which is twice the suggested size of an IBB chunk) but we don't know if people will typically send images that are smaller or larger than 8k -- I think smaller but I don't know that yet. Might it be advertised by the client/server? And rejected if the other party tries to send a bigger one (just to force them to fix it)? I think that's handled at a different layer (e.g., rate limiting). But we do need to define better handling for stanzas that are too large
