Re: [Standards] digest algorithm in XTLS
Hi, On 27.12.2013 13:11, Fedor Brunner wrote: Hi, I'm comparing the documents http://xmpp.org/extensions/inbox/jingle-xtls.html https://tools.ietf.org/id/draft-meyer-xmpp-e2e-encryption-02.html in the http://xmpp.org/extensions/inbox/jingle-xtls.html the digest algorithm for X.509 certificate fingerprint is missing. The file from the inbox is older than the Internet Draft. Maybe there was an error I fixed when converting it (I do not remember) Regards, Dirk -- $100 placed at 7 percent interest compounded quarterly for 200 years will increase to more than $100,000,000 - by which time it will be worth nothing. [Robert A. Heinlein 1907-1988]
Re: [Standards] Feedback on XEP-0257: Client Certificate Management for SASL EXTERNAL
Hi, On 05/31/2012 07:49 PM, Peter Saint-Andre wrote: Given that Dirk it not really actively involved in XMPP any longer (AFAIK) Sadly, no, my current job does not involve XMPP at all and my free hacking time is used for Freevo. I still plan to make it possible to control Freevo using XMPP but that is not something that will happen soon. But if someone includes me in a Cc, I will answer. :) I think it would be good for Thijs and perhaps Kim to take over maintenance of this spec. Sounds like a good idea. I also agree about decoupling this spec from XEP-0189, which as you say went in a different direction because of some work that Matt Miller and I were doing on end-to-end encryption at the IETF. Is it correct that 0.14 is the latest version of 0189? - It uses XEP 0189 to format the public keys. However, afaict it was written for version 0.8 of that specification, which differs a lot from the current version. I don't think the latest version suffices (it appears to me it can only send the public key and some other meta-data such as begin and end time, not the full certificate). Theoretically, this is not a problem as everyone can look up the old version of the XEP, but in practice it might be very confusing and cause problems for developers who need to implement different versions of 0189. Yes, I just added the full certificate. The current version of 0189 is different and in its current version it is useless for SASL EXTERNAL. - I'd like some clarification of the meaning of the name elements: It has been a long time, I hope I can remember :) The append element should contain a name and the keyinfo contains a different name, which according to 0189v0.8, should be th SHA1 hash of the certificate. Is the former name required to be unique? The examples suggest revocation and removal is done based on the latter name, but this is not explicitly noted. The first name was a human readable name. Otherwise, the user does not know which certificate to remove. It is never stated that it should be unique, but it would be helpfull for the user to know which certificate belongs to which client (the idea was to have a different certificate for each client to revoke a stolen device without touching everything else). Since it is never stated to be unique and the SHA1 hash is, the hash is used for the revoke. - Related to the previous point, 0189v0.8 says that the x509cert element is optional, and only the fingerprint is required. While technically this is not a problem for 0257 (hash the client's certificate when it connects, and only compare that), I think this would have a lot of usability and security problems. Yes, for 0189 alone the hash was enough, for 0257 it should be required. Taking the last 3 points together, I propose removing the link with 0189, as that XEP seems to serve a different purpose now. All that is really necessary is to transmit the PEM encoded certificate, so the x509cert element could directly be inside the append element. The name in the keyinfo (which is actually a fingerprint) should either be removed completely (it adds no info) and therefore basing removing and revoking on the real name, or it should be renamed to something like fingerprint/hash/id and the XEP should be changed to explicitly note that removal/revocation is based on this value. Agreed. Remove the reference to 0189, keep the human readable name and make it unique. By that the user can identify the client if every client has a different certificate. Remove/revoke can be done using that unique name. Additionally, I think it would be a nice enhancement to be able to check which online resources are using which client side certificate at a given moment, for example as part of the items / query result. Though maybe this is a bit too far outside the scope of this XEP. Sounds like a good idea. It would be very nice to have SASL EXTERNAL support for clients in Prosody. This would be an important step forward for me if I will ever implement XMPP support in Freevo. Regards, Dirk
Re: [Standards] upcoming XEP deferrals
Hi, Peter Saint-Andre wrote: A number of XEPs are due to be deferred in the next 4-5 weeks. Here is my take... *sigh* I have not enough time right now to work on specifications :( But here some comments on stuff I'm involved in somehow. 4. XEP-0247: Jingle XML Streams http://xmpp.org/extensions/xep-0247.html IMHO we don't need this one any longer, so it can lapse without issue. Yes, the important stuff is part of the XTLS ID 5. XEP-0257: Client Certificate Management for SASL EXTERNAL http://xmpp.org/extensions/xep-0257.html I'll ping Dirk Meyer about this one. Good question. There is an expired ID in this area I want to update if I find some free time for it. So should I continue to update the ID even though the XMPP WG does not have this topic on its agenda or should I drop the ID and merge the changes back to the XEP? Right now the ID is more up--to-date than the XEP. Again, I hope to get some time to work on specs the next days. On my list is an XTLS ID update, SASL EXTERNAL, improve XEP-0265, and some comments and adjustments to Peter's latest XEP-0189 changes. Dirk -- I have yet to meet a C compiler that is more friendly and easier to use than eating soup with a knife.
Re: [Standards] XMPP server certificate
Hi, Jonathan Schleifer wrote: Peter Saint-Andre stpe...@stpeter.im wrote: Who said that including CAs is evil? My argument is that policies differ. Just because a lot of people use a particular CA doesn't make it good. Deciding on policies is something the user should do, not the client. I for example trust something open and transparent like CACert much more than some company like VeriSign etc. And my sister has no idea what you are talking about, what these CA things are, why there is a warning, and how she can check these strange numbers called fingerprint. IMHO clients should include a basic sets of CAs. Dirk -- In some cultures what I do would be considered normal.
Re: [Standards] S5B and proxy connect errors
Marcus Lundblad wrote: A has access to a proxy. [...] At this point A will try to connect to the proxy in order to activate the bytestream, but this will fail since A's firewall blocks port . OK, the problem is a A THINKS it has access to a proxy but that is not the case. A never tried if the proxy works. I think adding an additional transport-info/ tag with a value such as proxy-error would be appropriate in this situation. This would be the opposite of the activated action. This could also be used, if for some reason activating the bytestream failed (such as the wrong hash being used). What do you think? I guess you are right. What do other people think? IMHO a proxy error similar to activated seems to be a good idea. If everything goes like planed, I will finish my thesis next week and will have more XMPP time by than and can update XEP0260 (as well as other specs still on my todo list). 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.
Re: [Standards] Is XEP-0049 superseded by XEP-0223?
Peter Saint-Andre wrote: On 9/29/09 10:05 AM, Peter Ferne wrote: On 29 Sep 2009, at 17:03, Peter Saint-Andre wrote: I won't be convinced that XEP-0223 truly supersedes XEP-0049 until I see people actively using it for the same use cases... Are you aware of any specific reasons why it hasn't gained traction, other than inertia? No, I'm not. But I think we need some experimentation with the pubsub approach before we definitively kill off private XML storage. Stupid question: is there any pubsub server out there that supports XEP-0223? XEP-0223 requires a pubsub server to have a virtual pubsub service with pubsub#persist_items = true and pubsub#max_items 1. AFAIK pubsub servers only support PEP on the virtual server which makes no sense without the ability to store more than one item. And there is the issue when to sync the private storage. See http://www.mail-archive.com/pub...@xmpp.org/msg0.html [1] Dirk -- panic (No CPUs found. System halted.\n); 2.4.3 linux/arch/parisc/kernel/setup.c
Re: [Standards] Is XEP-0049 superseded by XEP-0223?
Peter Saint-Andre wrote: On 10/15/09 9:53 AM, Dirk Meyer wrote: And there is the issue when to sync the private storage. See http://www.mail-archive.com/pub...@xmpp.org/msg0.html [1] As far as I can see, the discussion on the pub...@xmpp.org list did not lead to consensus about the options you proposed. Please reply to my last message about that on the pubsub list if you disagree. :) No, the discussion lead to no consensus. Still, the problem exists unsolved. Is there an easy way to check if my pubsub storage is modified since I last checked? I guess I have to answer to one of the posts and maybe restart the discussion. Dirk -- I've already told you more than I know.
Re: [Standards] [Jingle] Fwd: Application referrals - GROBJ
Dave Cridland wrote: FYI, I thought this might be interesting from the point of view of XMPP/Jingle, whether filesharing or VOIP or whatever. It's also got an impressive sounding name. I have no time to read the draft right now, but isn't that the reason we have HIP (Host Identification Protocol)? Dirk -- It's the same old story; boy meets beer, boy drinks beer... boy gets another beer. -- Cheers
Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
Hi, I wonder if someone has a comment on it. Joe and Dave suggested a framing parameter to use BEEP instead of what I created. Since BEEP sounds ok to me, there is no reason for a framing parameter and just use BEEP. Dirk Meyer wrote: After reading BEEP again... Dirk Meyer wrote: Dave Cridland wrote: On Fri Apr 24 16:31:20 2009, Joe Hildebrand wrote: Sorry I'm so far behind. Any chance XEP-265 could have a framing parameter in the Jingle portion? Some folks might like to just use BEEP instead of the framing mechanism specified in the XEP. Or at least a BEEP-lite - we (Isode) may actually produce a spec for the MPP protocol that is, more or less, that - we use it for internal fast comms in our products already. What do you mean by BEEP-lite? I looked at BEEP again to check if we could use it instead of the self-made framing and found two parts I don't like: 1. Every MSG needs an RPY or NUL as answer? If you transfer a video in frames (that is one reason why I wrote it), what is the answer? Or does your BEEP-lite ignore the it? That is still an issue. We could just ignore that and just use MSG in all cases. We don't speak BEEP in channel 0 anyway, so it is not BEEP. Suggestion: we only send MSG frames. Om the other hand we could use NUL as answer to some frames as ack to get reliability. 2. I also do not like the seqno. It has a maximum value of 4GB which is not enough when watching HD content. I see, it wraps back to 0. That works for larger content but I would prefer larger values in seqnum ... and the question remains if seqnum is needed after all. Would it be bad to increase the range of the value? Even if it wraps at 4GB, I would prefer to make it larger. But that could break with BEEP. Besides that, it would be ok for me to use the BEEP style frameming. This would move the content-type stuff away from the XML stream into the frameming but that is ok for me. Reading BEEP again, I don't see where BEEP says how I can check if I have mime headers or not. The BEEP header is only the one line and the payload does not specify MIME in the ABNF style. I would be nice if someone with more knowledge on BEEP could comment on that. We do not need the mime-stuff, only the framing. Dirk -- program, n.: A magic spell cast over a computer allowing it to turn one's input into error messages. tr.v. To engage in a pastime similar to banging one's head against a wall, but with fewer opportunities for reward.
Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
Hi, sorry for the late answer -- stupid PhD thesis Dave Cridland wrote: On Fri Apr 24 16:31:20 2009, Joe Hildebrand wrote: Sorry I'm so far behind. Any chance XEP-265 could have a framing parameter in the Jingle portion? Some folks might like to just use BEEP instead of the framing mechanism specified in the XEP. Or at least a BEEP-lite - we (Isode) may actually produce a spec for the MPP protocol that is, more or less, that - we use it for internal fast comms in our products already. What do you mean by BEEP-lite? I looked at BEEP again to check if we could use it instead of the self-made framing and found two parts I don't like: 1. Every MSG needs an RPY or NUL as answer? If you transfer a video in frames (that is one reason why I wrote it), what is the answer? Or does your BEEP-lite ignore the it? 2. I also do not like the seqno. It has a maximum value of 4GB which is not enough when watching HD content. Besides that, it would be ok for me to use the BEEP style frameming. This would move the content-type stuff away from the XML stream into the frameming but that is ok for me. But in any case, yes, a framing mechanism sounds great. I'm thinking about it. It would be nice to know what parts of BEEP you need and how your so-called BEEP-lite looks like. BEEP over XMPP who would have thought that 5 years ago? Dirk -- To study and not think is a waste. To think and not study is dangerous. [Confucius 551 BC - 479 BC]
Re: [Standards] LAST CALL: XEP-0198 (Stream Management)
XMPP Extensions Editor wrote: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? Yes 5. Is the specification accurate and clearly written? I did not follow the whole discussion, but IMHO the 'h' attribute is not clear. | The 'h' attribute identifies the last handled stanza (i.e., the last | stanza that the receiver will acknowledge as having received). I wonder if I start at 1 again after each ack. The examples in 8.1 increase the number while example 22 in 8.2 resets the counter. Next question: what is a stanza? Only mssage, iq and presence? What about the ping from XEP-0199? What about the ack itself? Dirk -- Microsoft is not the answer. Microsoft is the question. 'No' is the answer!
Re: [Standards] XEP-0199 -- implementation notes?
Peter Saint-Andre wrote: In the XMPP Council meeting yesterday, we discussed the desirability of adding some implementation notes to XEP-0199 (XMPP Ping) before advancing it from Draft to Final. Stupid question: why use XEP-0199 and not r/ a h='0'/ from XEP-0189 for this task? Some XMPP clients do not respond to IQ stanzas containing unsupported payloads. Although this is in violation of XMPP Core, this behavior can result in disconnection of clients that are in fact actively connected to the server. Maybe this is a good thing to force developers to update the client. Dirk -- I don't suffer from insanity. I enjoy every minute of it.
Re: [Standards] SIFT
Peter Saint-Andre wrote: http://xmpp.org/extensions/inbox/sift.html I only took a quick look at the spec and maybe I missed it, but what happens to an IQ that got filtered? If a client sends an IQ it expects an answer and that answer maybe 'client not available'. What is the answer if the recipient filters the IQ? Dirk -- How can something be 'new and improved'? If it's new what was it improving on?
Re: [Standards] SIFT
Jiří Zárevúcky wrote: 2009/5/16 Dirk Meyer dme...@tzi.de: Peter Saint-Andre wrote: http://xmpp.org/extensions/inbox/sift.html I only took a quick look at the spec and maybe I missed it, but what happens to an IQ that got filtered? If a client sends an IQ it expects an answer and that answer maybe 'client not available'. What is the answer if the recipient filters the IQ? I believe server should reply with service-unavailable on behalf of the client. That way it is consistent with XMPP-CORE and doesn't introduce any security problems. Sounds good. This should be part of section 3.3 Dirk -- Time passed, which, basically, is its job. -- Terry Pratchett (in: Equal Rites)
Re: [Standards] XEPs 246 + 247 (end-to-end streams)
Peter Saint-Andre wrote: On 5/6/09 9:32 AM, Justin Karneges wrote: On Wednesday 06 May 2009 07:47:10 Peter Saint-Andre wrote: Dirk Meyer and I think that we no longer need XEP-0246 (End-to-End XML Streams) and XEP-0247 (Jingle XML Streams). Are there any objections to simply retracting these? Wasn't there a plan to have Link-Local Messaging depend on XEP-246? I think that was just us getting spec-happy. I would be a nice idea if we would have gone with XEP-0247 so it can share spec with link-local. But link-local is now the only one using this kind of stream and also in draft state. Dirk -- I have yet to meet a C compiler that is more friendly and easier to use than eating soup with a knife.
Re: [Standards] ACTIVE: XEP-0263 (ECO-XMPP)
Jacek Konieczny wrote: On Wed, Apr 01, 2009 at 07:04:12AM -0500, XMPP Extensions Editor wrote: Version 1.0 of XEP-0263 (ECO-XMPP) has been released. Abstract: This specification defines best practices and protocol modifications that will reduce the energy consumption of XMPP systems and thereby help to save the planet. Great document! I am sure European Union will be happy to refund implementations here in Europe. I am sure someone would really be able to get some funds for this. :) The sad thing is: I really believe some people would be able to get funding for this from the EU. Dirk -- I don't read books, but I have friends who do. -Presidential Candidate George W. Bush
Re: [Standards] XEP boilerplate
Remko Tronçon wrote: FYI, last night I adjusted the XEP boilerplate so that it shows a bit more information at the top. Load any XEP to see. +1. I missed the authors on top. Yes +1. It is also nice to have the date/revision on top. Dirk -- Everything should be made as simple as possible, but not simpler. (A.Einstein)
Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
Andreas Monitzer wrote: On Mar 16, 2009, at 13:09, Dirk Meyer wrote: Yes, maybe restrict the usage to a stanza and not allow it inside a stanza by default. So a client MAY send any return from any XEP out of band, but only the whole result. If out of band is allowed somewehere deep inside a stanza it SHOULD be added to the XEP defining that namespace. That's not a good idea, since then you couldn't use it for binary data at all (since you never have base64-encoded data at the top level). Having it only in specific stanzas would mean that you couldn't implement a solution for everything, but only on a case-by-case basis (or you'd have to carry around a list of situations where it's allowed – ugh). Yes, but on the other hand it would be a pain for the developer to expect out of band data everywhere. And it is not needed in most cases. Maybe use the service discovery to handle the list: featureurn:xmpp:jingle:apps:out-of-band:0/feature featureurn:xmpp:tmp:media:server+outband/feature This means that the client expects out of band data as first child element in any stanza and inside every element in the media server namespace. I know it kind of sucks to carry the list around. Another way would be that the urn:xmpp:tmp:media:server namespace defines where out of band data may happen. So if you support out of band data, just must expect for every complete stanza and everytwhere in the media server namespace where it is defined. No idea what the best solution is. Dirk -- Drugs cause amnesia and other things I can't remember...
Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
Andreas Monitzer wrote: On Mar 16, 2009, at 12:42, Pedro Melo wrote: I like the framing part, as expected :). But why such a specific protocol? Why not just open a peer-to-peer XMPP stream and route everything between the two endpoints through it? You could even reuse end-to-end encryption XEPs. Because then you'd have to base64 encode all binary data, making most of the advantages of this extension mood. That is one reason, the other one is that a large stanza will block the e2e stream. Having one stream for large stanzas and binary data with framing helps. And you can use xtls over that stream, too. Dirk -- Evolution doesn't take prisoners
Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
Andreas Monitzer wrote: Why use a non-existing protocol as an example, when you could use the well-known discovery protocol for it? Simple, I did not thought about that :) I had my future media server XEP in mind, but XEP-0030 can also serve as an example. All the item listings can be very long. Section 3, Example 5: That's not EBNF, could you change it to the correct syntax, so there is no room for interpretation? It is not? OK, I will fix it. It should have been EBNF :) On a higher level, I think that's a great idea :) Could be hell for some client implementations, though, due to the asynchronicity (you have to buffer the parts of the stanza you already know, and collect the rest before passing it to the upper layers). Yes, maybe restrict the usage to a stanza and not allow it inside a stanza by default. So a client MAY send any return from any XEP out of band, but only the whole result. If out of band is allowed somewehere deep inside a stanza it SHOULD be added to the XEP defining that namespace. You should also add the regular section about discovering support for this protocol. Yes, it is only a first draft. If people think that it is a good idea, I will add all this. Thanks for the feedback. Dirk -- I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. -- Bjarne Stroustrup
Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
Dave Cridland wrote: On Mon Mar 16 14:43:38 2009, Andreas Monitzer wrote: On Mar 16, 2009, at 13:09, Dirk Meyer wrote: Yes, maybe restrict the usage to a stanza and not allow it inside a stanza by default. So a client MAY send any return from any XEP out of band, but only the whole result. If out of band is allowed somewehere deep inside a stanza it SHOULD be added to the XEP defining that namespace. That's not a good idea, since then you couldn't use it for binary data at all (since you never have base64-encoded data at the top level). Having it only in specific stanzas would mean that you couldn't implement a solution for everything, but only on a case-by-case basis (or you'd have to carry around a list of situations where it's allowed – ugh). Bob... XEP-0231 Bob already defines a mechanism for referencing blobs. This provides an alternative transport for them. Yes, reading bob gave me the idea :) I want to add a section to describe how this can interact with bob. What this won't allow is for huge XML blobs to be referenced within stanzas, but I can't think of a single use case for that - perhaps I'm being naïve, but I think Bob and this between them are an interesting concept. I thought about using bob's cid for the content, but the use case is different. For bob I request the stuff later, in my idea it comes by itself. No need for a constant id like bob. Dirk -- An aquarium is just interactive television for cats.
Re: [Standards] XEP-0065 and encryption
Robbie Hanson wrote: XEP-0065 (Socks5 Bytestreams) states in the security considerations section that negotiation of [SSL/TLS] is outside the scope of this document. I believe this is no longer valid. For example, consider XEP-0189 (Public Key Publishing), and how the XMPP protocol could be used to help enable TLS encryption using self-signed certificates. XEP-0189 is only part of a larger security concept. http://www.ietf.org/internet-drafts/draft-meyer-xmpp-e2e-encryption-01.txt defines a TLS based security layer for Jingle and together with XEP-0260 you get a secure SOCKS5 stream for all Jingle applications (e.g. TLS for file transfer XEP-0234) iq type='result' from='tar...@example.org/bar' to='initia...@example.com/foo' id='initiate' query xmlns='http://jabber.org/protocol/bytestreams' streamhost-used jid='streamhostproxy.example.net'/ publicKey5AF9...[publicKeyInHex]...2C4/publicKey /query /iq This is all done in draft-meyer-xmpp-e2e-encryption-01. Dirk -- There is no law requiring me to make sense.
Re: [Standards] Multiple binds in XMPP-CORE
Dave Cridland wrote: On Sat Feb 28 19:49:51 2009, Justin Karneges wrote: Given that you can bind multiple resources in a single XMPP-Core session, it probably makes more sense to keep the session management before binding. If you resume a session, then all resources are resumed. This also means that the session management id has a 1-to-many relationship with full JIDs. This sounds like another reason why multiple binds are just overcomplicating the protocol. Additions like this to core cause unforseen issues like this. Who wants this, anyway, and why is it going into core? /me raises his hand I'm thinking of maybe having a proxy in the home network. All local devices connect to the proxy and the proxy relays everything to the server. In that case the proxy registers all resources from its clients to the server. Maybe it is a stupid idea, maybe not. Dirk -- This signature is temporarily under construction
Re: [Standards] Multiple binds in XMPP-CORE
Dave Cridland wrote: On Sun Mar 1 09:45:12 2009, Dirk Meyer wrote: I'm thinking of maybe having a proxy in the home network. All local devices connect to the proxy and the proxy relays everything to the server. In that case the proxy registers all resources from its clients to the server. Maybe it is a stupid idea, maybe not. Okay, so I look forward to your document explaining the security implications of deliberately introducing a man in the middle. ;-) Seriously, what does such an architecture gain you? It was just an idea. But reading all the answers here, I guess I do not need it. So ignore my last mail. :) Dirk -- Warning: Dates in Calendar are closer than they appear.
Re: [Standards] UPDATED: XEP-0257 (Client Certificate Management for SASL EXTERNAL)
Johansson Olle E wrote: I think we should change the text about self-signed vs CA-signed that is currently a bit ambigous. I know that Dirk's use case is not CA- related, but I still think that the XEP should be more neutral and I see a lot of use cases where a CA will be required. I added the text on request based on a discussion on the summit (with you?). The only use case I could think of was a company internal use of XMPP. Maybe other use cases requiring a CA should be added to the beginning of the doc. Can you write down / outline some use cases? A recommendation for server developers would be to implement a model where the admin can set a policy for the use of certificates for SASL external: - Only trusted certificates for bare JID certificates and any cert for full JID (bot) certificates - Only trusted certificates for both bare JID and full JID certificates - Any kind of certificate From your other mail: A free public XMPP server MUST allow self-signed certificates and certificatessigned by a CA unknown to the server. (line 184) I don't think this XEP is a good place to define policys and definitions of a free public XMPP server. That's outside of the scope. Adding a MUST here requires us to define free public XMPP server. Yes, I also don't like how I wrote it down. I wrote it because I guess most people will not have a certificate for all their devices. Therefore I wanted to make sure that I can use self-signed certificates on public servers such as xmpp.org. Dirk -- May brute force be with you.
Re: [Standards] UPDATED: XEP-0257 (Client Certificate Management for SASL EXTERNAL)
Peter Saint-Andre wrote: So you'll have two kinds of certs: one that is limited to a particular full JID (let's call it a full-JID cert) and one that isn't (let's call it a bare-JID cert). If a bare-JID cert is currently logged in with a full JID that matches a given full-JID cert (e.g., our TV resource), then Dirk is suggesting that the client presenting the full-JID would have priority and the server would bump the client that presented a bare-JID cert. So that rule would provide guidance to the server regarding the alternatives described in Section 8.5.2.2 of rfc3920bis: http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-08.html#bind-clientsubmit-error-conflict Right. Section 8.5.2.2 gives many options and suggests to provide a different resource to the client. That is not possible with a full JID in the cert. I added it to my todo list for the next revision. Dirk -- ++?++ Out of Cheese Error. Redo From Start. -- (Terry Pratchett, Interesting Times)
Re: [Standards] MUC E2E encryption
Hi, Okano, Stephen wrote: I have been following the forums on end-to-end encryption for a while as I am involved in a project developing group end-to-end encryption. It looks like the XEPs currently are focused on e2e encryption between two entities. Is there any framework for implementing encryption in a Multi-User Chat framework? Not yet. I thought about it some time ago, but didn't came up with a good solution. One question: do you trust the MUC server? If you do (and only misstrust the link between your client and the MUC server), you can open an e2e link to the MUC server. But I guess you don't trust the MUC server and want to encrypt all communication in the channel. That requires some sort of key distribution. We have extended pidgin's implementation of XMPP to enable group e2e encryption using our own XMPP tags, but I can imagine there might already be a standardized way for specifying group e2e in XMPP. Maybe you can send us your idea and we can find a way to make it working based on our current e2e discussions. Dirk -- Stress is when You wake up screaming and then realize You haven't slept at all
Re: [Standards] LAST CALL: XEP-0205 (Best Practices to Discourage Denial of Service Attacks)
Peter Saint-Andre wrote: 1. authentication attempts per account 2. authentication attempts per IP address 3. connection attempts per account 4. connection attempts per IP address 5. simultaneous connections per account 6. simultaneous connections per account Currently XEP-0205 says a server could do #1 but the consequences might be a DoS against the legitimate user, so instead it recommends #4 or #6 because the spec assumes that the attacker will come from a different IP address than the one used by the legitimate user. But #4 and #6 don't solve the problem that Waqas mentions (a DoS attack launched by someone from your same IP address, e.g. from behind the same NAT). Must people have a NAT at home. If someone inside my home network is running a DoS on my account, I have bigger problems than my XMPP account. Dirk -- A Life? Cool! Where can I download one of those from?
Re: [Standards] XEP readability
Peter Saint-Andre wrote: Some members of the XMPP Council commented recently that the front matter (author info, legal notices, etc.) in existing XEPs is quite lengthy. Therefore I have modified the XSLT to move almost all of that information to appendices. All of the XEPs have been regenerated to use this new format: http://xmpp.org/extensions/ Let me know what you think. Better, but I would not move all metadata to the end. Comparing it to an RFC, I would move Appendix A (dependencies and version), B (who wrote that stuff), D (not important, but it should be at the top IMHO), and F (it is necessary to read the XEP) back to the top. Dirk -- Early to rise, early to bed, makes a man healthy, wealthy and dead. -- Terry Pratchett, The Light Fantastic
Re: [Standards] XEP readability
Dirk Meyer wrote: Peter Saint-Andre wrote: Some members of the XMPP Council commented recently that the front matter (author info, legal notices, etc.) in existing XEPs is quite lengthy. Therefore I have modified the XSLT to move almost all of that information to appendices. All of the XEPs have been regenerated to use this new format: http://xmpp.org/extensions/ Let me know what you think. Better, but I would not move all metadata to the end. Comparing it to an RFC, I would move Appendix A (dependencies and version), B (who wrote that stuff), D (not important, but it should be at the top IMHO), and F (it is necessary to read the XEP) back to the top. And something else: the top says Copyright (c) 1999 - 2009 XMPP Standards Foundation. See Legal Notices. That is not correct. E.g. my XEPs have no copyright before 2008, they did not exist at that time. Maybe parse the first version info as copyright start date. Dirk -- Original Pentium of Borg: Division is futile - your decimals will be approximated.
Re: [Standards] XTLS revisited
Dave Cridland wrote: Okay, so humour me for a second. Sure :) In practical terms, then, we move XEP-0250 negotiation inside Jingle as a transport, and strip down IBB to remove the initial open business (we can essentially compound that into the session-initiate). Furthermore, we can assume that SASL EXTERNAL is simply not required here - because it's not, really, for many cases. Now, the exchange becomes: -- session-initiate -- result - TLS negotiate over IBB-a-like -- session-accept -- result - XMPP stuff overTLS-protected IBB-a-like. I had a similar idea when writing my last mail. Let's think this further. I can add everything I want in a Jingle stanza. It would also be a good idea to have TLS for Jingle. Even if we do XTLS without Jingle, a TCP secure file transfer is also a good idea. Let's take XEP-0234: Jingle File Transfer as example: We send our TLS wish and the XEP-0250 offer in the initiate: | iq from='kingclaud...@shakespeare.lit/castle' | id='jingle1' | to='laer...@shakespeare.lit/castle' | type='set' | jingle xmlns='urn:xmpp:jingle:0' | action='session-initiate' | initiator='kingclaud...@shakespeare.lit/castle' | sid='851ba2' | content creator='initiator' name='a-file-offer' | description xmlns='urn:xmpp:jingle:apps:file-transfer:0' | ... | /description | transport xmlns='urn:xmpp:jingle:transports:bytestreams:0'/ | tls | offer from XEP-0250/ | /tls | /content | /jingle | /iq Now the two clients set up the stream using the defined transport and the responder accepts the session. If the responder supports Jingle TLS it has to include its offer. We now if it supports Jingle TLS using disco#query. | iq from='laer...@shakespeare.lit/castle' | id='accept1' | to='kingclaud...@shakespeare.lit/castle' | type='set' | jingle xmlns='urn:xmpp:jingle:0' | action='session-accept' | initiator='kingclaud...@shakespeare.lit/castle' | sid='851ba2' | content creator='initiator' name='a-file-offer' | description xmlns='urn:xmpp:jingle:apps:file-transfer:0' | ... | /description | transport xmlns='urn:xmpp:jingle:transports:bytestreams:0'/ | /content | tls | offer from XEP-0250/ | /tls | /jingle | /iq Problem: if you check prior to opening the stream if we have a common ground for TLS. If we don't, we went to all this incl. opening a stream for nothing. Now we need step three of XEP-0250. We can use Jingle info for that | iq from='kingclaud...@shakespeare.lit/castle' | id='info1' | to='laer...@shakespeare.lit/castle' | type='set' | jingle xmlns='urn:xmpp:jingle:0' | action='session-info' | initiator='kingclaud...@shakespeare.lit/castle' | sid='a73sjjvkla37jfea' | tls method='x509'/ | /jingle | /iq After that kingclaudius starts the TLS handshake. I see this as being one RTT longer than classic XTLS - the session-accept - but in practise I'm not clear that we really need to wait for that before sending media in this case, since both ends know if it's working at a fundamental level. We need to wait for the XEP-0250 counter-offer. On the other hand we can use the iq stanzas from XEP-0250 parallel while we set up the transport. The only thing I see as potentially being problematic then for implementors is that whilst a Jingle session is active, the session can potentially be renegotiated - is this something that's a candidate for being made optional? (Maybe it's really needed for VOIP applications, but it doesn't seem a requirement for this, or file transfer.) That is not only a problem for TLS, it is a problem for all TCP-like sessions. The normal file transfer has the same problem. Dirk -- Buy one for the price of two and get another one free!
Re: [Standards] XTLS revisited
Remko Tronçon wrote: Hi Marcus, Would it make sense to use an in-band bytestream (XEP-0047) for the tunneling part? Well, to be fair, I don't expect using IBB as a transport will win you anything, and will rather complicate things needlessly. The only part that looks similar to IBB is that they both use stanzas with base64-encoded data, but base64-encoding data is just one line of code ;-) It is a bit more complicated. My TLS lib wants a socket, so I have to connect the Base64 code with a Unix domain socket. I already had that code for IBB and required some copy-paste for XTLS. Using IBB would be easier (at least in my lib). But IBB adds an additional roundtrip (IBB open). I prefer the way XTLS is now without IBB; even if it means some duplicate code. I now have XTLS implemeted, but without XEP-0250 offers. Right now I accept every certificate. If someone needs a peer to test with let me know. Dirk -- Hard work never killed anyone, but why give it a chance?
Re: [Standards] XTLS revisited
Dave Cridland wrote: Okay, so the gain here is that we lose the Jingle negotiation, effectively, and mandate something roughly equivalent to IBB. Yes The downside is that we lose the ability to go direct from client to client should we need to, and one reason for doing so would be for efficiency. (There are others, independent of encryption). Yes. The question is: what do we want? Jingle-based allows direct connections with the cost of many additional roundtrips: while XTLS only needs 3 roundtrips, Jingle XML streams need at least 7, maybe more depending on the transport. And it is the question of work for the developer: if you have Jingle and link-local support, Jingle XML streams is as simple as it can get. But if you don't have these, XTLS is much easier. Jingle XML Streams: More flexible. You can use direct connections and it would also be possible to use other features besides STARTTLS XTLS: Much faster, easier to implement I'm not sure what's better. As I see it, there are two ways of approaching cryptography in XMPP: 1) We concentrate on getting an efficient, but basic, end-to-end encryption protocol, which is easy to write and deploy. I'm firmly convinced that the XEP-0247 approach is right here - it's allowing us to get the transport right, the authentication right, and all using existing crypto libraries as much as possible. I just don't see any real likelyhood of clients not being able to use Jingle, given XEP-0234 etc. In this scenario, the server isn't involved at all, and the scope for cryptography is narrow. 2) We concentrate on getting a full-featured cryptography suite in place, akin to S/MIME and ESS in email. In this scenario, the server may well be involved, discarding bad packets, verifying signatures, and we'd be aiming to support things like MUC and PubSub. This is not going to be possible with TLS, we need to go to things like XML-dsig, and involve triple-wrapping and other fun things. I don't see which this proposal is addressing. 1) It is the same as XEP-0247: we use TLS. XTLS and XEP-0247 only differ in the transport we use. Dirk -- This signature is temporarily under construction
Re: [Standards] XTLS revisited
Justin Karneges wrote: On Monday 15 December 2008 07:46:16 Peter Saint-Andre wrote: Therefore I suggest that we simplify e2e by using something very close to the original XTLS proposal to set up, use, and tear down and XTLS tunnel. I've outlined the protocol below. First, we should use IBB. Sure, it adds complexity with the block sizes and message vs iq, but you want this stuff. There is one problem hidden deep inside the current version of XTLS. XEP-0250 requires a three-way handshake: A sends its offer B sends its offer based on A's A sends final method to be used The last step is needed to ask for a password when using SRP before you start up your TLS lib. Right now, it is included in the first data message. When we use IBB we can not do that. We need an extra message: A: xtls incl. offer B: xtls incl. offer A: xtls incl. method A: ibb open B: ibb open result It is a small change and you can send the IBB open without waiting for the method iq result. The only downside is the extra round trip on startup. If it's that big of a deal, we can make a special extension that lets you IBB + XTLS in one shot. 1. Initiator sends start request to responder iq from='ro...@montague.net/orchard' id='xtls_1' to='jul...@capulet.com/balcony' type='set' start xmlns='urn:xmpp:tmp:xtls'/ /iq iq from='ro...@montague.net/orchard' id='xtls_1' to='jul...@capulet.com/balcony' type='set' open sid='mySID' block-size='4096' xmlns='http://jabber.org/protocol/ibb' start xmlns='urn:xmpp:tmp:xtls'/ /open /iq 2. Responder tells initiator to proceed iq from='jul...@capulet.com/balcony' id='xtls_1' to='ro...@montague.net/orchard' type='result' proceed xmlns='urn:xmpp:tmp:xtls'/ /iq iq from='jul...@capulet.com/balcony' id='xtls_1' to='ro...@montague.net/orchard' type='result'/ That's not much worse, is it? If XTLS is implemented and we start needing tweaks to the transport, we'll be happy we did it this way. That would work. The error handling will be a bit complicated because if xtls fails, you have to shut down the already open IBB link. But that's ok for me. We need to add a note that the 3rd xtls message with the method MUST be send BEFORE the first IBB data stanza. Dirk -- I just found out that the brain is like a computer. If that's true, then there really aren't any stupid people. Just people running Windows.
Re: [Standards] XTLS revisited
Peter Saint-Andre wrote: Justin Karneges wrote: On Monday 15 December 2008 07:46:16 Peter Saint-Andre wrote: Therefore I suggest that we simplify e2e by using something very close to the original XTLS proposal to set up, use, and tear down and XTLS tunnel. I've outlined the protocol below. First, we should use IBB. Sure, it adds complexity with the block sizes and message vs iq, but you want this stuff. The only downside is the extra round trip on startup. And the concern that lots of server admins will block IBB because people use it for file transfer, whereas (some) server admins might be less likely to block a technology that enables user security. Since you can use IBB over XTLS, an admin may ban XTLS, too. Dirk -- If you're not part of the solution, be part of the problem!
Re: [Standards] XTLS revisited
Jonathan Schleifer wrote: Maybe we should make it a requirement that one stanza can only include one message. That'd make things a lot easier. No, you need to have control over your TLS lib to do so. With the current way you just feed your stanzas into your TLS lib and everytime it outputs something, you send it away. As simple as possible. Dirk -- Life is a sexually transmitted disease.
Re: [Standards] XTLS revisited
Dave Cridland wrote: On Mon Dec 15 17:16:19 2008, Dirk Meyer wrote: Yes. The question is: what do we want? Jingle-based allows direct connections with the cost of many additional roundtrips: while XTLS only needs 3 roundtrips, Jingle XML streams need at least 7, maybe more depending on the transport. Interesting - yes, you've got one RTT for XTLS negotiation, whereas it's 3 or so for Jingle (I thought - given that you're saying 3 vs 7 I might well have missed one). Jingle XML Streams do not only use Jingle, they also use a normal stream setup similar to client/server communication: one roundtrip Jingle, at least one for the transport (IBB) to open the stream. These are two. After that we have stream setup, STARTTLS feature negotiation, TLS itself (2 rt), and a stream restart. Sums up to 7. XTLS needs one rt for itself + 2 for TLS. And I agree that's an issue we should be addressing, since it'll affect not only encryption, but file transfer, too. No, if we would use TLS directly on Jingle it would be less. Am I the only one who has alarm bells ringing when we're told that our flagship protocol for negotiating end-to-end streams isn't suitable for negotiating end-to-end streams? Not suitable for e2e XML streams. For other use cases incl. TLS over Jingle without the stream stuff it is simpler. BTW, adding TLS for any Jingle stream would be also nice to have. I'm sure what *ought* to be better. :) Dirk -- Someday I'll find that peer and reset his connection!
Re: [Standards] XMPP VPN?
Jonathan Schleifer wrote: Well, I recently saw that Wippien has VPN support and uses XMPP for the messaging part. I thought that it maybe might be a good idea to have a XEP for VPN via XMPP. I think this could be achieved quite well with Jingle. We would just need a XEP which specifies how the packets should be transfered over the tunnel established by Jingle. What do you think? I always like the something-over-XMPP idea. This includes HTTP, VNC, and VPN seems crazy but why not. But for everything like this we need more bandwidth. If can not use IBB for that. VPN over XMPP can use the existing ICE-UDP, but this against shows that we need good TCP support for XMPP. Dirk -- Unix is the worst operating system; except for all others. -- Berry Kercheval
Re: [Standards] XMPP VPN?
Jonathan Schleifer wrote: Am 13.12.2008 um 09:57 schrieb Dirk Meyer: I always like the something-over-XMPP idea. This includes HTTP, VNC, and VPN seems crazy but why not. But for everything like this we need more bandwidth. If can not use IBB for that. VPN over XMPP can use the existing ICE-UDP, but this against shows that we need good TCP support for XMPP. Well, I would even call that idea less crazy than HTTP-over-XMPP or VNC-over-XMPP HTTP over XMPP may be just wrong to do, but VNC over HTTP is very usefull. Think about all the PC users you know who ask your for help from time to time. It is easier if you can just use VNC to show them remotly. But they are always behind a NAT, so VNC does not work. There are solutions to that problem, but providing VNC access by using XMPP and tunnel the VNC data over a Jingle stream is a very ellegant trick. There will be a button Get help from Jonathan and the XMPP client will connect to you, negotiate a Jingle connection and you will see the remote desktop. But that would require a) end-to-end security and b) a TCP-like connection. On the other hand, I would all have less time to do stuff I want if my sister could get help with a single button :) Dirk -- Computer analyst to programmer: You start coding. I'll go find out what they want.
Re: [Standards] XMPP VPN?
Jonathan Schleifer wrote: Sure VNC via XMPP is useless, and once again this is where XMPP could replace something proprietary: TeamViewer for example. usefull? And BTW, I guess it would cost me about one day of work to make a prototype and does this. But it will be very slow since my stack only supports IBB as transport. What I want to say here: XMPP can replace many proprietary solutions with a working Jingle stack. Most solutions only exist to help you through the NAT -- we can do that, too Dirk -- Remaining time multiplied by distress is constant.
[Standards] Seeking in file transfers
Hi, as written on the devel list, I'm thinking about adding seek support to file transfers. I'm working on media networks in my PhD thesis and a seekable stream is exactly what I need. First a small scenario why I think it is useful: I have a media server with a video file. This could either be a storage server for my media files or a record server with the latest recordings I made. Now I want to watch that video. The current approach is to use the file transfer and start watching while the bytes are coming in. This is similar to watching a video file over HTTP. But there are two problems: 1. If it is a recording, I may want to skip the first minutes (recording started to early) or skip the commercials. I don't not like to wait until the file transfer has catched up. 2. Some video container have an (optional) index at the end of the file. To play such a file the player should read the first bytes and the last bytes before starting playback. We also don't want to set up a new stream using SOCKS5 or a future ICE-TCP every time the user seeks (IBB is a stupid idea here, so we ignore it). So we have one stream for the data and should use XMPP stanzas for controlling it. I see two ways of doing it right now, maybe someone has a better idea 1. Add the number of bytes you want to receive on the stream. | Player: send me bytes 0-1023 | File-Server sends the first kb over the data stream | Player: send me bytes 1024-2047 | File-Server sends the second kb over the data stream Well, 1kb may not be a good choice, maybe request 1MB chunks. It is up to the application and use case. Pros: good control over the stream Cons: requires many XMPP messages. 2. Assume that the initiator wants to read the stream like a normal file transfer and add some marks to the stream similar to HTTP chunks: | File-Server sends 0 1024\n over the data stream | File-Server sends first kb over the data stream | File-Server sends 1024 1024\n over the data stream | File-Server sends second kb over the data stream | Player sends seek to byte 528743 command, but it takes some time |until that request makes it to the file server | File-Server sends 2048 1024\n over the data stream | File-Server sends third kb over the data stream | File-Server got the seek request | File-Server sends 528743 1024\n over the data stream | File-Server sends 1 kb starting from byte 528743 over the data stream HTTP chunks use ASCII for the metadata like stream position, we could replace 1024 1024\n with a binary struct containing position and length of a chunk. What do you think about that? Should it be part of the Jingle file transfer XEP? If 2. is used, the initiator of the session requesting the stream should be able to turn it off for normal file transfer without the metadata (maybe by setting chunk size to 0). Dirk -- Did you know that dolphins are so intelligent that within only a few weeks of captivity, they can train Americans to stand at the very edge of the pool and throw them fish.
Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
Kurt Zeilenga wrote: On Dec 4, 2008, at 10:18 AM, Dirk Meyer wrote: Kurt Zeilenga wrote: On Dec 4, 2008, at 2:04 AM, Dirk Meyer wrote: It is part of urn:xmpp:tmp:saslcert (or will be once I write the schema). The problem is that there are two reason to revoke a certificate: 1. A certificate is about to expire. The client uploads a new one and revokes the old. The client should stay connected. More interestingly, is what about other sesssions using the old certificate. There is only one. Each client has its own certificate, I don't see why a user would not use a single certificate in multiple clients, especially for certificates issued by a non-user-operated CA. The idea behind this proposal ist to make it possible to remove one client from the system later. If all clients share the same certificate, there isn't much difference to the password based login or the current SASL EXTERNAL XEP. The whole idea is that each client has its own certificate so every client uses something different to log in which can be revoked on a per-client-bases. Deactivation, to me, means that it has been removed from a list of acceptable user certificates. A deactivated certificate can certainly be used in the future. For instance, by adding back to the list of acceptable user certificates. Deactivation does not imply revocation. I have to think about what I want here. I guess deactivation is easier because it does not require a list of certificates that can not be added again later. The revoke/deactivate has nothing to do with the mechanism defined by X.509. There is no URL were you can check if a certificate is valid or not. They may be self-signed and the list handled by my proposal ist the list of certificates that are allowed to be used for login. A user can request its CA revoke the certificate, but a user can deactivate the certificate (remove it from the list of acceptable certificates). With self-signed certificates this is not possible. Dirk -- Freedom of speech is wonderful - right up there with the freedom not to listen.
Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
Kurt Zeilenga wrote: If there are some hidden assumptions/use cases, I think they should be more clearly called out and discussed in the proposal. I will do that in the next version Some XMPP server implementations already support multiple passwords per user. Of course, the server has no clue how such passwords are shared amongst a user's clients, likewise for user certificates. They do? What XEP handles that? I think what your proposal needs to focus on activation/deactivation of user certificates, leaving revocation handling to other documents (but noting that leave revocation handling to other documents). Thanks for the input. I see now that I need to write much more doc about the use case behind this. And I will not use revoke. Dirk -- Right now I'm having amnesia and deja vu at the same time. I think I've forgotten this before.
Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
Philipp Hancke wrote: why does the client generate the certificate? Sending a CSR to the server and signing it there (which may take a long time) seems easier from the certificate managment point of view. IMHO it is more complicated. Why doing a complex CSR (which as you wrote may take a long time) when a client can upload a certificate. The client is trusted when doing so and the certificate only has to work between these two. And it results in a certificate signed by an entity that the server trusts. Well, the server can trust the client with its own certificate. But you raise an interessting point: what do others think? CSR or the other way. Alexey already wrote that he prevers not to deal with CSR. Dirk -- A mathematician is a machine for converting coffee into theorems.
Re: [Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
Kurt Zeilenga wrote: On Dec 4, 2008, at 2:04 AM, Dirk Meyer wrote: It is part of urn:xmpp:tmp:saslcert (or will be once I write the schema). The problem is that there are two reason to revoke a certificate: 1. A certificate is about to expire. The client uploads a new one and revokes the old. The client should stay connected. More interestingly, is what about other sesssions using the old certificate. There is only one. Each client has its own certificate, otherwise it is not possible to remove one bad client from the network without affecting others. The same certificate can also be used for XEP-0250. 2. A device should be removed (e.g. stolen). In that case the certificate is compromised and if the device is logged in right now, it should be disconnected by the server. First, it's not clear to me what you mean be 'revoke' a certificate. In particular, whether you mean to 'revoke' in the X.509 sense of the word, or whether you simply mean to no longer consider a certificate as suitable for gaining access (that is, removing it from a list of acceptable user certificates, or deactivated). Second, I'm not sure it matters all that much. Yes, I mean revoke it exactly that way. It will not be possible to log in with that certificate anymore. Anyways, there are many reasons why a certificate could be 'revoked' or 'deactivated'. Agreed. Maybe revoke and deactivate mean something different: revoke means it is a compromised certificate, deactivate means it can not be used in the future. While some might argue that existing sessions should not be impacted by either a 'revocation' or 'deactiviation', some might also argue that all sessions (including those used to 'revocate' or 'deactivate') should be immediately disconnected or at least quarantined in some manner (for instance, all subsequent messages generate 'please reconnect' errors). And there is some who are somewhere in the middle. Now back to your cases... If a user 'revokes' or 'deactivates' a clearance, he might be doing so as he thinks it is compromised, regardless of the proximity to the expiration time of the old certificate. Right. My mobile phone gets stolen or I simply loose it, I revoke the certificate and my maybe currently connected phone should disconnect at once. If an implementation is going to disconnect (or fail requests) existing session on revocation and/or deactivation, I would argue this should occur either on all sessions, or to all but the session which issued the revocation/deactivation order. And for this session, it should discontinued (or fail requests) very soon after the order. That problem should not exist if each client has its own certificate. In that case there is only one session. I will write some more doc about this. Looking forward to this... And I will add some text about each client having its own certificate :) Dirk -- We live in a society where pizza gets to your house before the police.
Re: [Standards] Message Mine'ing
Dave Cridland wrote: But, as well as that, it also does this: presence to='[EMAIL PROTECTED]' !-- Usual current presence, as broadcast, but also private stuff: -- messages xmlns='urn:xmpp:tmp:messages' message from='[EMAIL PROTECTED]/thing' count='1'/ /messages /presence If I'm in your roster, don't I get the presence update, too? And I would think: Ah, he is chatting with Peter again. Not good for privacy. Maybe I always wanted to know the JID of the Peter guy you so often chat with, now I know it. Dirk -- Five exclamation marks, the sure sign of an insane mind. -- (Terry Pratchett, Reaper Man)
Re: [Standards] Message Mine'ing
Peter Saint-Andre wrote: ejabberd already does this if there is more than one resource with the highest prio. If you have for example two resources with prio 50 and one with prio 30, both with prio 50 will receive messages to the bare JID. Most servers do that. What I'm suggesting is more of the Google Talk behavior -- a message sent to the bare JID gets sent to *all* resources regardless of priority. That is, priority is ignored and maybe even deprecated. First of all, we need some sort of negative priority for bots. IMHO it maes no sense to send a message to a device that can not answer. That said, I have a scenario were you may want priorities: I have my mobile phone is my pocket and when I get a message, it makes a small noise. When working at my laptop, I do not want the phone to react on new messages at all. The phone has prio 30 and my laptop 50. If I go away and auto away kicks in, the laptop will be 20 and the phone gets the messages. On the other hand, if a message arives at my laptop and I just left the room (auto away has not kicked in yet), I want to know about that message. I like the idea from Dave: The Hey, I have pending messages here! one. (ie, a bare_jid-wide version of the flashing taskbar item thingy.) My laptop receives the message and tries to notify me. After a user defined timeout the laptop sends the Hey, I have pending messages here! message to my mobile phone and the phones makes noise. When I look at the phone, the phones says Give me the pending message to my laptop. Does this scenario make sense? Dirk -- Pascal: A programming language named after a man who would turn over in his grave if he knew about it. -- Datamation, January 15, 1984
Re: [Standards] Message Mine'ing
Hi, Jack Erwin wrote: Message mine'ing provides more of a do what I mean experience for the end user. When he leaves his desk, he will still be alerted via his mobile client when a new conversation has been initiated, and will do it without any sort of preparatory action. If the end user participates in the conversation, his desktop client will not be cluttered with the initial fragment of that conversation. As an added benefit, if he chooses to ignore the conversation, it will be ready and waiting on his desktop client when he returns. I like the idea, but what happens if I switch clients during a conversation? In your example, we chat with the desktop client. I think we are done, but do not close the chat window (I sometimes do that). Now I go away with my mobile client. If you send a message now, I guess the message will be send to the full JID of my desktop client and I will not get the message. Maybe a thread can expire somehow and after a time, we should send to the bare JID again doing the whole 'mine' thing again. Or am I missing something here? I'm do not know the way how chatting works with full and bare JIDs. Dirk -- [Our enemies] never stop thinking about new ways to harm our country and our people, and neither do we. (George W. Bush, August 5th 2004)
[Standards] Small Typo in XEP-0077
Hi, there is a small typo in example 16 for XEP-0077. The title is Password Change and it should be something like Cancel Account. Since it is a final XEP, I did not dare to fix it in svn. :) Dirk -- When someone says, 'do you want my opinion?' - have you noticed that it's always a negative one.
Re: [Standards] C2C TLS
Dave Cridland wrote: On Tue Nov 25 13:03:15 2008, Jonathan Schleifer wrote: I also like the fact that you don't try to use a direct connection, which has the known problems, which many just ignored in the previous discussion. Actually, it's not that the problems are ignored, they're simply punted. XEP-0247 simply says Hey, we'll negotiate something that works, and avoids the entire issue, by design. This is a good thing. Yes. My c2c plugin just tells Jingle to open a stream and doesn't care what it is. We're hoping that technologies like ICE-TCP and other transport layer solutions will be developed. This seems pretty reasonable - I'm not convinced by ICE-TCP itself Same here. ICE-TCP is very complex and we do not need it. IMHO we have some basic candidates: 1. One client has a public IP address and is not behind a firewall. 2. One client is behind a NAT, but NAT-PMP or UPnP IGD is available 3. One client knows a TURN server IMHO that's it. Do we need more? Should it be more complex? In fact, 1 and 2 are similar for the peer's point of view: it can connect. You can replace 2 with everything you want, e.g. TEREDO or whatever comes to your mind. Just send candidates with increasing complexity on your side until it works. If it does not, try TURN. If that also does not work, let it fail and we can try SOCKS5 and IBB on Jingle-level. but we're not tied to TCP, just a reliably ordered stream, which makes life rather simpler. (FWIW, I suspect we could use ICE to setup two-way UDP communications and layer a reliability layer on that - in fact, I think it's been done). That is also an option and should be in another XEP. So Jingle can try direct TCP like above, reliable UDP if that does not work, SOCKS5 as next solution, and maybe IBB as fallback. What any sane person would realise is that XMPP expertise won't help there at all, and that a good design would allow these additional technologies to be designed by others, and simply slotted in post-facto. Yes. But IMHO the core of ICE-TCP is just that: try what we have. Dirk -- Never say 'OOPS!' Always say 'Ah, Interesting!'
Re: [Standards] C2C TLS
Jonathan Schleifer wrote: IMO, that brings far too much complexity for a such a simple and mandatory thing like end-to-end encryption. A dependency on Jingle really is too much IMO. IMHO Jingle should be part of any client. File transfer over Jingle is much better than the normal one. You can change the transport if it does not work. And Jingle itself is very simple and not that hard to code. If you want to support RTP over Jingle for a VoIP client, it is much more complicated. Jingle itself is just negotiate a session, fire up IBB or SOCKS5 (which you have for file transfer anyway) and that's it. It should be so simple to implement, be it whether a library like suggest for ESessions or via a very simple protocol that everybody can very easily implement, that even the most simple client could implement it. Thus have no dependencies on any complex XEP etc. I guess the problem for Jingle is, that the XEP uses VoIP as example. Take a look at XEP 0234 (Jingle Filetransfer). It is much easier to understand and more similar to the Jingle security stuff. Dirk -- The best things in life aren't things.
Re: [Standards] C2C TLS
Jonathan Schleifer wrote: I'd be interested to have a look at that client lib. In which language is it written? It is written in Python. I did not use existings libs because the focus of that lib is not normal XMPP chatting, I wanted a lib designed for application control. E.g. I want to control my dvb card at home from my laptop at work. XMPP is the transport layer, but chatting is not used. I will have some time at the end of the week to clean up some mess in the lib and put it into the freevo svn so everyone can take a look at it. I also like the fact that you don't try to use a direct connection, which has the known problems, which many just ignored in the previous discussion. Well, it is more an accident. The c2c layer just tells my jingle plugin to open a stream. Since the only stream plugin I have right now is IBB, I have to use it. Later I want to add direct support, but it will be possible to define what you want. E.g. media transport is not allowed to use IBB and you may also configure the system to always use IBB for c2c if you like. The lib itself doesn't care. If your lib works, I'd be happy to see clients using it :). Like I said, the lib is primary for bot-to-bot communication. It can not even open a thread. But if someone wants, it shouldn't be hard to implement it. But unfortunately, a new lib doesn't solve the problem for the current clients, or did you patch any existing, widespread lib like xmpppy? No, unfortunately my lib does not provide any TLS based security for any existing clients. But if someone else adds support in a client, we can use it to do some interop-testing. Dirk -- Drinking coffee for instant relaxation? That's like drinking alcohol for instant motor skills. -- Marc Price
Re: [Standards] C2C TLS
Jonathan Schleifer wrote: Am 24.11.2008 um 18:50 schrieb Dave Cridland: C2C TLS has numerous carefully audited crypto implementations, and one (or two?) test client implementations. Now, arguably, it might well have more - I'm not sure how many of the existing XEP-0174 clients will simply use TLS if offered, which would count in at least some respects. Please name at least two implementation so I can test those :). I have one lib that implements XEP-0247 for server based communication and XEP-0174 for link-local communication. In both bases starttls is used. I also added XEP-0250 support to provide X.509 certificate or SRP support -- no OpenGPG authentication right now. This works for both XEP-0247 and XEP-0174. The lib is not yet released, but I can send it to you if you want to test a client against it. I also wanted to implement XEP-0189 for public key handling to use in XEP-0250, but I have some problems with ejabberd not providing the list of all published keys using PEP. So ATM you have to put all known certificates in a file for the client, that is no good solution. I plan to release my code for some time now, but writing down my PhD thesis consumes a lot of my time. And without a proper key handling it is not so much fun. Well, what about SAS? I still can't see it. There is no SAS for TLS right now. TLS-SRP cames close to it (you have to know a password before opening the connection) and that is working for me. And do they use jingle inband or direct connections? Right now only InBand, my client has no support for SOCKS5. If they use direct connections, is NAT traversal implemented, using a STUN server etc.? No, we have no XEP for that yet. I'm trying to figure out what we need when implementing ICE-TCP. This is off-topic right now, but I wonder if we need the complexity of ICE-TCP or if we can go an easier way. Dirk -- You might have mail.
Re: [Standards] C2C TLS
See my other mail for additional information, I just want to answer your questions very quickly: Jonathan Schleifer wrote: 1.) What is the current state of the XEP? Is it even a XEP now? Open a stream with either XEP-0174 or XEP-0247 and use starttls. To help you with that we have XEP-0250 and XEP-0189. 2.) How many clients implement it? If any, which? I guess only my lib right now. 3.) If there are clients, do they use direct connections or use Jingle's inband mode? Right now only IBB, ICE-TCL will be implemented when it is ready 4.) How was the SAS problem solved, if it was solved at all? If not, how will it be solved? We only use what TLS provides. There is no SAS in TLS ATM, so no SAS support. TLS-SRP is your choice to authenticate someone. 5.) How much work was it to implement it? Was it really just 5 minutes of work as some said in the discussion before? We you only count XEP-0247 with an implementation that already had link-local support, than I needed about 1 hour to code it. XEP-0250 cost me some time to find a TLS lib that provides more than just X.509 certificates on Python level (openssl and gnutls support everything we need, but the Python bindings lack support for OpenGPG and SRP support). Implementing the XEP took about 3 hours of work. 6.) I predicted that it will still take a long time until C2C TLS will reach the state ESessions now has. To me, it seems my prediction was right. Anything I overlooked? I point to Dave's answer in this matter. The state of the XEP is working (I tested it) and client support is still missing. Compared to only one client using ESessions, it isn't that bad. If only one client implements ESessions after it is around for a longer time, it doesn't look good for it. If the TLS based solution has no client support after one year it was first published, I agree, it is also a failure. Dirk -- Computer Science: solving today's problems tomorrow.
Re: [Standards] Jingle HTTP
Peter Saint-Andre wrote: Dirk Meyer wrote: Hi, I had a strange discussion with a co-worker yesterday about the abuse of HTTP. Well, to make a long story short: http://www.tzi.de/~dmeyer/jingle-http.html This is a very early draft and only shows the very basic idea. What do you think? IMHO it could be useful. Interesting. I'd like to see how this could use Google Talk's pseudo-tcp as the transport. I may need to ping some Googlers off-list about how they do things, because I don't see any documentation online at http://code.google.com/apis/talk/talk_developers_home.html. http://code.google.com/p/gtalkbot/source/browse/trunk/talk/p2p/base/pseudotcp.cc It looks like they really speak some sort of TCP over the link. I don't know if that is such a good idea. If we use Jingle (with ICE-TCP) we have a stream that already is TCP most of the time. The only benefit we have with pseudo-tcp is that we can use port numbers with it. But aren't the Jingle applications similar to port numbers. Maybe add a generic application with an id to Jingle: | jingle xmlns='urn:xmpp:jingle:0' | action='session-initiate' | initiator='[EMAIL PROTECTED]/castle' | sid='851ba2' | content creator='initiator' name='a-stream-offer' | description xmlns='urn:xmpp:jingle:apps:stream:0' | application name=http/ | /description | transport xmlns='urn:xmpp:jingle:transports:ice-tcp:0'/ | /content | /jingle The application name is similar to TCP ports, there will be NO registrar involved. You can use whatever you want (similar to use a port in TCP). This simply opens a stream to do something depending on the application. So an application address is not host:port, it is fullJID:app. I'm not sure how to transform that into a valid URI. About URIs: Reading RFC 2396 section 3: | absoluteURI = scheme : ( hier_part | opaque_part ) | hier_part = ( net_path | abs_path ) [ ? query ] | net_path = // authority [ abs_path ] | authority = server | reg_name So reg_name MUST be point to the jull JID of the peer and define the Jinfle application. A closer look at reg_name: | reg_name = 1*( unreserved | escaped | $ | , | |; | : | @ | | = | + ) Maybe I miss something, but something like this should work for my HTTP proposal (named xhttp(s) because it uses reg_name and not server) | http://[EMAIL PROTECTED]:castle/index.html Is an XMPP resource allowed to include a /? If yes, than we need to adjust this. Maybe this is useful, maybe this is a stupid idea. I'm not sure yet. But if it would possible to address something through Jingle it would be very cool. Dirk -- A computer scientist is someone who, when told to 'Go to Hell', sees the 'go to', rather than the destination, as harmful.
Re: [Standards] Jingle HTTP
Remko Tronçon wrote: ... which was originally implemented in Psi as a proof-of-concept, but never got beyond this stage for privacy reasons. You should keep in mind that an IM client runs on a desktop machine, which most probably contains a lot of sensitive information. Enabling an IM client to expose the file system (even only partially) opens a whole can of worms on the security front. The whole fs is a very bad idea, but I do not see a reason against exposing /home/dmeyer/shared to the rest of the world. Think of a MUC. I have a file with some stuff and just post an URI to my internal web server into the room and everyone can download it. Dirk -- The Second Law of Thermodynamics: If you think things are in a mess now, just wait! -- Jim Warner
Re: [Standards] Jingle HTTP
Dave Cridland wrote: On Tue Oct 28 12:04:06 2008, Dirk Meyer wrote: The whole fs is a very bad idea, but I do not see a reason against exposing /home/dmeyer/shared to the rest of the world. Think of a MUC. I have a file with some stuff and just post an URI to my internal web server into the room and everyone can download it. True, but then you'd have all the requisite security considerations of running a webserver. As Remko points out, webservers have a long and fruitful history of excting bugs like malformed UTF-8, path processing, and countless other joyous things. I agree, there are some things you must take care of. Stuff like getting /foo/../../../ should not be possible. And if you add cgi-like stuff you may get into a lot of trouble. Maybe you can just forward everything to a real web server on your machine. I'm not sure you'd want this availale in every client, nor available to all-comers. Maybe not, but I would like to see it in a bot. :) Dirk -- I don't suffer from insanity. I enjoy every minute of it.
[Standards] Jingle HTTP
Hi, I had a strange discussion with a co-worker yesterday about the abuse of HTTP. Well, to make a long story short: http://www.tzi.de/~dmeyer/jingle-http.html This is a very early draft and only shows the very basic idea. What do you think? IMHO it could be useful. Dirk -- When nothing can possibly go wrong, it will.
Re: [Standards] Jingle HTTP
Dave Cridland wrote: On Thu Oct 23 11:48:09 2008, Dirk Meyer wrote: Hi, I had a strange discussion with a co-worker yesterday about the abuse of HTTP. Well, to make a long story short: http://www.tzi.de/~dmeyer/jingle-http.html This is a very early draft and only shows the very basic idea. What do you think? IMHO it could be useful. I think this would be useful to work on for a number of reasons, not least because it gives me an excuse to suggest using it to run XMPP over BOSH over HTTP over Jingle over XMPP over BOSH over HTTP over Jingle over ... Come on, you were all thinking it. Sure. And I can find a use case for HTTP over XMPP over BOSH. But if you want to use BOSH over XMPP over BOSH ... well, I guess I will be forced to report you to the protocol police because you abused at least two protocols. :) Seriously, I can see lots of interesting, if slightly weird, use cases for this. One interessting would be a reverse file transfer. Jingle filetransfer is a push mechanism: I want to send you a file and you can accept. With HTTP over XMPP it is the reverse. I may have a list of files you can pull from my client, maybe even a special bot only for file access. There are slightly more if you introduce the concept of proxying, and even more if one can figure out a way of encoding the Jid within the URI, such that a browser might switch between HTTP/Jingle and HTTP/TCP. That would be cool and I'm thinking about it. A method is needed to encode the full JID and the HTTP resource into one URI. But that is not that easy. Anyway, the current proposal is just a simple brain dump. More feedback (and use cases) welcome. ;) Dirk -- Students nowadays, complaining they only get 5MBs of disk space! In my day we were lucky if we had one file, and that was /dev/null.
Re: [Standards] XEP-0174: Serverless Messaging interactions with XEP-0115 Entity Capabilities
Peter Saint-Andre wrote: Alban Crequy wrote: I implemented an automatic caps lookup via disco in telepathy-salut (the XEP-0174 implementation in the Telepathy framework). It opens a stream only if a ver TXT record is advertised *and* if the ver record is not already known. Right, I see the need for that. But it's unfortunate. Still thinking... Maybe it is a bad idea, maybe not. We could provide a query TCP feature. So if you do not know the client, you open a connection and get the follwoing features: starttls (for real communication) and query to get the disco#query results and close the stream after that. Or we use a second port just for the query. Connect to that port and you get a stream with just the query results and the socket is closed again. I now, it is not a good solution, but I have the same problem as Alban. I need to know what the remote entity can do. Dirk -- I'm going to live forever, or die trying! -- Spider Robinson
Re: [Standards] XEP-0174: Serverless Messaging interactions with XEP-0115 Entity Capabilities
Peter Saint-Andre wrote: Alban Crequy wrote: However, if the 2 clients both implement XEP-030 Service Discovery and XEP-0115 Entity Capabilities, they will both initiate a stream in order to send a discovery request as soon as they appear online via DNS-SD, without user intervention. Really? I thought we were advertising caps in DNS TXT. See the ver record here: http://xmpp.org/extensions/xep-0174.html#registrar-linklocal-reg So I think that opening a stream to everyone who appears online via DNS-SD is a bad idea. Thus I would say that if you know the ver, you'll know what the other entity is. But if you don't know the ver, don't automatically open a stream to the other entity just to do all the caps lookup magic via disco. Thinking of my bot-to-bot communication scenario it may happen. I client may want to know if another media server got online to present it in the user interface. If the ver is not known, it has to open a stream to discovery what the ver means. Do we want this to happen? No. Sjoerd suggested on IRC to add random slack time before initiating a stream to avoid it. That is one possibility. We have a solution for that in xtls, maybe we should copy it to XEP-0246 End-to-End XML Streams: | It is possible that both parties may attempt to start the use of XTLS | at the same time [13], in which case one party may receive an XTLS | start stanza from the other party after it has sent such an XTLS start | stanza but before receiving a response. In this case, one of the | initiation requests shall be considered to have higher priority than | the other, and the party that receives the lower priority initiation | request shall return a conflict/ stanza error in response to the | lower priority request. The higher priority request MUST be considered | the request that is generated by the party whose JID is sorted before | the other party when the JIDs of both parties are sorted using | i;octet collation as specified in Section 9.3 of RFC 4790 [14]. Dirk -- Buy one for the price of two and get another one free!
Re: [Standards] [E2E] Why we need a body element
Jonathan Schleifer wrote: Am 02.10.2008 um 14:13 schrieb Remko Tronçon: I'm affraid you're wrong. Jingle File Transfer would be pretty useless if that were true. And we can use these transports for E2E as well or will that give problems? E2E over Jingle File Transfer makes no sense. But it raises a different question: can we secure the file transport? Ok, we could use an E2E stream and use IBB on that stream for file transport. That looks kind of ugly to me. It would be cool if we could add some starttls support on file transport, too. Dirk -- Students? barked the Archchancellor. Yes, Master. You know? They're the thinner ones with the pale faces? Because we're a *university*? They come with the whole thing, like rats -- -- (Terry Pratchett, Moving Pictures)
Re: [Standards] [E2E] Why we need a body element
Jonathan Schleifer wrote: Am 02.10.2008 um 13:36 schrieb Pedro Melo: small clients that are willing to implement Jingle + E2E but can't afford to implement any of the ping/ack XEPs out there? The problem is that they *DON'T* (and I already said that before) implement Jingle + E2E, thus can't warn the receiver of a message that was unable to decrypt, because it's not supported! Even if the new client supports it, it will fail because a secure session is between clients, not users. But still, I do not get why you want to notify the receiver. You wrote you saw the following message: [This is part of an encrypted session. If you see this message, something went wrong.]. Now what? What can you do? Nothing except sending a message to the sender that something is wrong and you can not read the message. Well, the sender already knows that. Dirk -- System going down at 1:45 this afternoon for disk crashing.
Re: [Standards] [E2E] Why we need a body element
Jonathan Schleifer wrote: We had proposals for end-to-end encryption using TLS here. It was suggested to use a stream in a stream using Jingle inbound. These stream will be encapsulated in the stream using messages or iqs then. And I think we should go for messages, but also include a body that states that this is part of an encrypted session. There is no statement in the XEP that the stream in inband. The clients can use SOCKS5 or a direct connection for the private stream. I do not see were you want to put the body in that case. It was argued that the message may never get to the wrong resource when I mentioned that problem, but the example posted before states the opposite, that it indeed DOES happen in the real world. If you use IQ stanzas for e2e streams they should never reach the wrong resource. If they do, it is a bug in the server. And even if they do, the receiver should rehect that IBB stanza (unknown sid) and the sender knows that the e2e stream is broken. Dirk -- /* Nobody will ever see this message :-) */ panic(Cannot initialize video hardware\n); 2.0.38 /usr/src/linux/arch/m68k/atari/atafb.c
Re: [Standards] [E2E] Why we need a body element
Jonathan Schleifer wrote: Dirk Meyer [EMAIL PROTECTED] wrote: There is no statement in the XEP that the stream in inband. The clients can use SOCKS5 or a direct connection for the private stream. I do not see were you want to put the body in that case. I'm talking about IF we use IBB, which seems what most intended to do and is the most sane - you don't always want a direct connection when you talk to someone, especially as this might be a privacy problem. OK. So you want to add a body if we use IBB. And because you can not add a body with an error message to an iq you want to add a note in the XEP to use message for IBB. Is that correct? If you use IQ stanzas for e2e streams they should never reach the wrong resource. If they do, it is a bug in the server. And even if they do, the receiver should rehect that IBB stanza (unknown sid) and the sender knows that the e2e stream is broken. I was talking about if we use message. You propose to use message because we can add a body to it and we can not do that with iq. But why do you propose message in the first place when the routing problem does not happen with iq? Sorry, I do not understand what you mean. Dirk -- If a train station is a place where a train stops, what's a workstation?
Re: [Standards] [E2E] Why we need a body element
Jonathan Schleifer wrote: Wrong. It can. You have client A and client B installed. Both have the same resource configured. Client A can handle it, client B can't. Client B connectes and kicks client A. Tada, you got the problem. [...] The client did that before, but it changed while sending. We got a race condition here. Ok, we have a race condition here for some seconds and the sender already send the message before receiving the new capabilities. In that case the receiver gets an IBB with an unknwon sid and sends an error. It does not know that it is part of an e2e so it can not inform the user. Only the sender can detect this problem. It helps the sender to know that something went wrong, but not the receiver. The the race condition I mentioned above. Why do you want to inform the receiver? He can not do anything about the problem. It is the sender who has to fix it by either re-open the e2e stream with the new client and resend the message or if that is not possible (the new client has no e2e support) it should inform the sender about the problem suggesting an insecure resend. If the user does not want to use insecure communication, the client may drop the message. Anyway, IF you want to inform the receiver, the sender could generate a new message 'e2e stream broken, message not delivered' and send it to the receiver. Dirk -- There is no reason for any individual to have a computer in their home. (Ken Olsen, Präsident von DEC, 1977)
Re: [Standards] Namespaces, specifications, and protocol life cycles
Peter Saint-Andre wrote: Dirk Meyer wrote: it would be nice to have a list of implementations that support a specific XEP. A second step would maybe some inter-op testing. There are two at the summit, but I guess that is not enough. For major XMPP technologies we've started documenting that: http://xmpp.org/tech/ Much more work is required, however. Very much work (Pubsub rocks is true but not very helpful). Since the is a Wiki page for all XEPs, maybe we could use it. Each client or server can add itself as I support this starting from version foo. I see it is done with BOSH: http://wiki.jabber.org/web/Bidirectional-streams_Over_Synchronous_HTTP_(BOSH)_(XEP-0124) Dirk -- Hard work never killed anyone, but why give it a chance?
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.
Re: [Standards] rfc3920bis -06
Peter Saint-Andre wrote: Dirk Meyer wrote: Sorry for the late answer, I've been very busy the last weeks. Peter Saint-Andre wrote: Dirk Meyer wrote: The same is true for presence (in RFC 39210. I found the presence handling much too complicate to implement. It took me longer than adding PubSub and XTLS support. Yes, presence is complex. Sorry about that. Did you implement it in a server or a client? 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. I'm not sure what it was, but something like that. I will have time to clean up my implementation next week and I will do some more testing with my server (I now use ejabberd 2 which I did not use before). If the JID contained in the 'to' attribute is of the form [EMAIL PROTECTED]/resource and there is a connected resource that exactly matches the full JID, the server SHOULD deliver the stanza to that connected resource. I would prefer MUST It needs to be a conditional MUST, because the server MUST NOT deliver a message stanza to you if: 1. According to XEP-0016 you are blocking messages from the sender. 2. According to RFC 3920 your resource has negative presence priority. So maybe not MUST send to this resource but MUST NOT send the message to a different resource. This keeps XEP-0016 in place. So you are suggesting that a message addressed to a full JID would never be delivered to another resource (or stored offline?) if that resource does not exist. Correct? I hadn't considered that option. [...] A message that is addressed to a resource with a negative priority is delivered to that resource. The only thing that negative priority does is prohibit delivery to that resource if the message was addressed to the bare JID, not the full JID. Interessting question. What should happen if you send a message to the full JID of a resource that does not exist anymore. And to combine it with a negative priority: what happens if that resource had a negative priority before indicating non-chat. 1. Discard? Always a bad idea without letting the sender know. 2. Store? Possible, but may not make any sense. Depends on the context. 3. Send to someone else? Makes no sense in some contexts? If I have a message based IBB a different receiver can not handle it. Regards, Dirk -- Either toss the Windows out of your computer, or toss your computer out the window! -- Richard Stallman
Re: [Standards] rfc3920bis -06
Sorry for the late answer, I've been very busy the last weeks. Peter Saint-Andre wrote: Dirk Meyer wrote: The same is true for presence (in RFC 39210. I found the presence handling much too complicate to implement. It took me longer than adding PubSub and XTLS support. Yes, presence is complex. Sorry about that. Did you implement it in a server or a client? Only client but IIRC adding a friend to the roster resulted in getting an iq result without sending a get or set. Very confusing. 11.2.3.3. Full JID --- If the JID contained in the 'to' attribute is of the form [EMAIL PROTECTED]/resource and there is no connected resource that exactly matches the full JID, the stanza shall be processed as if the JID were of the form [EMAIL PROTECTED]. Is this also true for IQ stanzas? That would be very confusing if I query one entity for services and send something to it, it is gone and some other entity gets it. What happens if I send a get-IQ and my application crashes. Does the result go to a different entity? No, it doesn't, because IQs to the bare JID are handled by the server itself on behalf of the bare JID, not delivered to another resource. Right, my fault. If my application uses the full JID it has a reason to do so. I also would prefer the same for messages (which I can get with XEP-0079). What is the same here? I mean when I send a message to the full JID it MUST send be routed to that JID, just like for IQ stanzas. When chatting I use the bare JID and talk to the client with the best priority. When something chooses a full JID it has a reason to do so and a server should hinor that. If the JID contained in the 'to' attribute is of the form [EMAIL PROTECTED]/resource and there is a connected resource that exactly matches the full JID, the server SHOULD deliver the stanza to that connected resource. I would prefer MUST It needs to be a conditional MUST, because the server MUST NOT deliver a message stanza to you if: 1. According to XEP-0016 you are blocking messages from the sender. 2. According to RFC 3920 your resource has negative presence priority. So maybe not MUST send to this resource but MUST NOT send the message to a different resource. This keeps XEP-0016 in place. And about negative priorities, I think if someone uses a full JID it has a reason for this, no matter what the priority is. My basic problem is how to handle two non-chat applications? They must have a negative priority to prevent receiving user chat messages but they may want to chat between each other. Dirk -- ++?++ Out of Cheese Error. Redo From Start. -- (Terry Pratchett, Interesting Times)
Re: [Standards] rfc3920bis -06
Peter Saint-Andre wrote: I've just submitted version -06 of draft-saintandre-rfc3920bis to the IETF. This version incorporates feedback from Joe Hildebrand, as well as my own near-final review and consistency check. Read it here: http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-06.html I'm starting to get serious about pushing this forward at the IETF, so I'd really appreciate reviews from folks on this list. Is there a list of new features compared to RFC 3920? Here some feedbacks whithout re-reading everything: Basic Question -- I always wondered why starttls and sasl are stanzas and bind uses the iq stanza. Is there a reason why starttls is no iq stanza? | C - iq type='set' | starttls/ | /iq | S - iq type='result'/ The same is true for presence (in RFC 39210. I found the presence handling much too complicate to implement. It took me longer than adding PubSub and XTLS support. 5.3.3. id -- I had no time to read everything, where is that id needed later? 5.7.3. Handling of Idle Streams I did not following the discussion, but should this in an RFC? XEP-0199 looks like a much cleaner way and even if many client use the whitespace ping, it is more like a bad hack, there isn't even a ping responce. 8.6.2. Binding an Additional Resource -- I see that multiple resource bindings are now included. But IMHO it could be done simpler. If I understand it correctly when I want to bind three resources I have to send three bind-iq and wait for the answer. Why not use: | C: iq id='bind_2' type='set' | bind xmlns='urn:ietf:params:xml:ns:xmpp-bind' |resourcebalcony/resource |resourcehome/resource | /bind |/iq 11.2.3.3. Full JID --- If the JID contained in the 'to' attribute is of the form [EMAIL PROTECTED]/resource and there is no connected resource that exactly matches the full JID, the stanza shall be processed as if the JID were of the form [EMAIL PROTECTED]. Is this also true for IQ stanzas? That would be very confusing if I query one entity for services and send something to it, it is gone and some other entity gets it. What happens if I send a get-IQ and my application crashes. Does the result go to a different entity? If my application uses the full JID it has a reason to do so. I also would prefer the same for messages (which I can get with XEP-0079). If the JID contained in the 'to' attribute is of the form [EMAIL PROTECTED]/resource and there is a connected resource that exactly matches the full JID, the server SHOULD deliver the stanza to that connected resource. I would prefer MUST Dirk -- Wake up and smell the coffee. -- Ann Landers
Re: [Standards] Service discovery for clients
JabberForum wrote: I have just made a test on last version of ejabberd 2.0.1 with an account subscribed to pubsub nodes. The server sent me pubsub messages (seen in xml console) but never sent me any service discovery IQ query!!! So the server sent me a message without even knowing if I was able to understand it (and indeed my client was not, so discarded the message silently): I'm not sure but a client does not announce PubSub support on the service discovery. My understanding is that the server announces this feature because it understands the pubsub IQ stanzes. If my implementation finds a _client_ that has pubsub in its features my implementation would try to _subscribe_ to something. Dirk -- If a train station is a place where a train stops, what's a workstation?
[Standards] Jingle File Transfer Question
Hi, I have a small Jingle File Transfer question regarding multiple candidates. In example 9 the initiator sends two offers, one with SOCKS5 and one with IBB. After that the responder removes one and opens the transport (in this case IBB). But why remove one _before_ trying to open (ok, we know IBB will work). IMHO it should be something like this: | Initiator send SOCKS5 and IBB session-initiate | Responder sends IQ result | Responder tries SOCKS5 before accept! | a. it fails |Responder tries IBB |Responder uses content-remove on SOCKS5 | b. it works |Responder uses content-remove on IBB | Responder sends session-accept So why do we need content-replace here? And why sending a content-remove? If the responder sends only the IBB content in session-accept, isn't this an indirect content-remove already? Dirk, thinking Jingle is a bit confusing -- If you can't beat your computer at chess, try kickboxing.
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
Peter Saint-Andre wrote: P.S.: Too bad I implemented the current XTLS today for testing Ouch. You are too fast. :( Doesn't matter. I also had my previous coded so it is similar to the new specs. Except that I have no jingle implementation yet. If we can get this spec'd out soon, perhaps we'll even be able to hold a bit of an interop event + hackfest at the XMPP Summit July 21 and 22: I will have to talk to my boss if the university will pay for it. :) Dirk -- The trouble with work is... it's so daily.
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
Peter Saint-Andre wrote: 1. We modify XEP-0174 so it just defines _presence._tcp as a discovery mechanism, as a result of which you have an IP address and port that you can use for a direct TCP connection that functions as a transport for an e2e XML stream. 2. We split the e2e XML streams stuff out from XEP-0174 into a new e2e-streams spec, which defines how you use whatever reliable transport is close to hand (direct TCP connection, IBB, SOCKS5, ice-tcp, etc.) as the transport for an e2e XML stream (this can be unencrypted as all XEP-0174 implementations do now, or upgraded to encrypted using STARTTLS, which is what we'd recommend -- but this way it is backwards-compatible and enables code reuse). It should get a note about clientCert requests. 3. The current XTLS spec morphs into a new Jingle-xmpp spec that defines a Jingle application type for an XMPP session (as defined in XEP-streams), where that application type can use IBB, SOCKS5, ice-tcp, or any other reliable transport. Sounds ok to me. Funny thing is that XTLS gets closer again to my first idea (except that I did not used jingle). If you need some help writing 2. or 3. give me a call. I will be away for the weekend but could help you out on sunday evening (which will be the whole sunday in your timezone). Dirk P.S.: Too bad I implemented the current XTLS today for testing -- [X] -- nail here for new monitor
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
Dave Cridland wrote: On Sat Jun 7 00:07:36 2008, XMPP Extensions Editor wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: XMPP Transport Layer Security Some comments: 1) I like using streams, too, that seems to make perfect sense, especially given XEP-0174. [...] However, I got talking to Rob McQueen - there's a certain amount of sense in, instead of describing this in terms of IBB, describing it in terms of Jingle. It's possible - and reasonable - to consider an XMPP stream as content, in which case the TLS becomes a transport (or possibly attribute of the transport). An one hand it is reasonable to use Jingle, I had something like this is my first draft. On the other hand I would like to reduce the number of roundtrips needed to set up an XTLS connection. I would even consider making XTLS different to remove one roundtrip by adding IBB open to the xtls iq: | iq from='[EMAIL PROTECTED]/orchard' | id='xtls_1' | to='[EMAIL PROTECTED]/balcony' | type='set' | xtls xmlns='urn:xmpp:tmp:xtls' | open xmlns='http://jabber.org/protocol/ibb' | block-size='4096' | sid='MySid'/ | /xtls | /iq I'm not sure if it violates any rules, but IMHO this would be the fastest way to set up a client-to-client TLS stream. In my scenario I have many bots talking to each other so I want to reduce the server load to avoid sending too much stanzas when a new bot comes up. So we have two choices here: 1. Use jingle and re-use XEP-0174 code. + looks reasonable + makes it possible to use something else except IBB - more roundtrips, even more if you try SOCKS5 and it does not work 2. XTLS the way it is now, maybe the shortcut from above + faster to set up - special handling since it is different from XEP-0174 I prefer the second one, but I guess that is something for the XMPP Cousil to vote for. Dirk -- - Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! -
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
Justin Karneges wrote: I think the original intent with XTLS was to use a new parser instance for the content of each TLS packet, but this violates the TLS abstraction. My original intent was to open a new stream incl. feature handling. I implemented that and therefor never had the missing root element problem. Treated as a stream, we cannot enforce that a particular TLS packet contains an entire XML document. A single TLS packet might contain many messages, and one message might be split across many TLS packets. Better that we change the stream to work like this: [ immediate TLS handshake ] some_root_element message/ message/ message/ /some_root_element If you want that only to re-use your parser, it is an implementation problem. To re-use a parser just feed some_root_element to your parser manually. If you are doing it because it matches the XMPP style with one large XML document we should go for stream. I'm happy with both because, but we should NOT wait for the stream from the peer because it would add an extra roundtrip. Dirk -- UNIX _is_ user friendly - it's just selective about who its friends are!
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
JabberForum wrote: ProtoXEP: 1. Discover Support 2. Send XTLS negotiation request, i.e. xtls/ 3. Receive XTLS negotation response 4. Open IBB 5. Send stanza With stream:features step: 1. Discover Support 2. Open IBB 3. Send TLS negotiation request, i.e. starttls/ 3. Receive TLS negotiation response, i.e. proceed/ 4. Send stanza Both take the same amount of roundtrips between the two entities. No, with stream:features you have two additional roundtrips. At the beginning you send stream and wait for an answer and an extra stanza with the features. After starttls you restart the stream and also have a stream roundtrip. And well, using the stream idea would not make it XTLS, because you could open a stream without using starttls (ok, that makes no sense, but you could do it). On the other hand (and that is why I used exactly that idea in my first draft) you could re-use code from link-local messaging. An IBB stream can be handled like a TCP connection link-local. Dirk -- Boat: A hole in the water surrounded by wood.
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
Justin Karneges wrote: The default namespace is nice, since we needed to qualify the message/ stanzas anyway. The 'to' and 'from' are a tad superfluous, but maybe we should consider them for consistency with XEP-174 (Link Local) ? Same for putting to/from on the message stanzas. [...] stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' from='[EMAIL PROTECTED]' to='[EMAIL PROTECTED]' message from='[EMAIL PROTECTED]' to='[EMAIL PROTECTED]' bodyM'lady, I would be pleased to make your acquaintance./body /message Since for both XTLS and link-local we do not need the to and the from in message and iq stanzas. IIRC XEP-0174 says I MUST add them, but we already have them in the stream. So why not use the FULL jid the the stream and strip all routing information later? I also think it would be worth having a note about proper stream closure. It may be comforting to know if the peer has intentionally ended an XTLS session, to distinguish from a network problem or attack. Sounds ok to me. Dirk -- Sorry - yesterday was the deadline for all complaints.
Re: [Standards] New XMPP Use Case: Private Media Networks
Peter Saint-Andre wrote: On 06/05/2008 9:17 AM, Justin Karneges wrote: I'm not sure about overloading the sid. A more-traditional namespaced-element approach should work just as well: iq type='set' from='[EMAIL PROTECTED]/orchard' to='[EMAIL PROTECTED]/balcony' id='inband_1' open sid='mySID' block-size='4096' xmlns='http://jabber.org/protocol/ibb' xtls xmlns='xtls-ns'/ /open /iq It seems that Justin and I are in agreement. :) Ok, not hardcoding the sid. My XML schema knowledge is very limited but as far as I understand XEP-0047 you can not add an element inside the open. Dirk, since you are working on this, perhaps you could send me an updated XML file and I could check it / clean it up a bit for XSF conformance / style issues? I will do that tomorrow. I will replace the hardcoded sid from the last version I sent you with Justins idea, but I will leave out the schema because I have no idea how to define xtls inside the open of IBB. I will also update the text a bit and after that you can clean it up. Then we can ping the XMPP Council about approving this as a real XEP so that we can have it in source control etc. That would be great. Dirk -- I don't read books, but I have friends who do. -Presidential Candidate George W. Bush
Re: [Standards] New XMPP Use Case: Private Media Networks
Hi, Peter Saint-Andre wrote: You might want to make it clear that by server you don't mean XMPP server and by client you don't mean XMPP client. I guess I should use my own words service provider and controller all the time to avoid confusion. In your architecture, is a node (1) [EMAIL PROTECTED] or (2) [EMAIL PROTECTED]/resource? If (2), does each application have its own certificate? (2) and each application has its own certificate. About authorization, you might want to check out XEP-0235. I already was thinking about this. I have to do some more thinking. Since I'm about to split the doc into three XEP proposals, the authorization doc will be send to you later. About security, what about using something like XTLS? http://www.xmpp.org/extensions/inbox/xtls.html I was thinking about DTLS, I did not know that there already is something in the inbox. But not many tls implementations support it, my python bindings use tlslite which lacks dlls support. I know it is not a good reason, but since all XMPP clients already support starttls for streams this looks like a simpler idea. And the overhead IBB + starttls is similar to XTLS, with stream compression in the inside even less. And when not using IBB, it can reduce the server traffic. I will do some more thinking about this. Before finishing it and sending it to the XMPP council I want to ask on this list for some opinions about it. It clearly uses XMPP in a way XMPP was not indented to be used, but it could be the base for new use cases (examples of such use cases are in the document). Well, HTTP is being used for things that Tim Berners-Lee never intended, so who are we to complain about creative uses of XMPP? :) :) Dirk -- Dancing is a vertical expression of a horizontal desire.
[Standards] What is a node?
Hi, while re-writing my XEP proposal I came to a simple question: what is a node? The RFC uses node as part of the bare JID: [EMAIL PROTECTED] So a node is something not unique at all, the same node could be used for a different domain for a different user. PubSub uses node completly different. Some XEPs like jingle use 'entity' for a client with a full JID. So my understanding is that when I write about specific client I should NOT use the word 'node' and 'entity' instead, right? A 'user' has different XMPP 'entities'. Dirk -- Always remember you're unique, just like everyone else.
Re: [Standards] UPDATED: XEP-0234 (Jingle File Transfer)
XMPP Extensions Editor wrote: Version 0.3 of XEP-0234 (Jingle File Transfer) has been released. URL: http://www.xmpp.org/extensions/xep-0234.html The caption of example 12 is wrong, the initiator acknowledges session-accept. Dirk -- Only Irish coffee provides in a single glass all four essential food groups -- alcohol, caffeine, sugar, and fat. -- Alex Levine
Re: [Standards] New XMPP Use Case: Private Media Networks
Dave Cridland wrote: One thing that does immediately ring alarm bells for me, personally, is that the design conflates several orthogonal aspects of inter-device communication. There's a number of reasons I don't like this, in particular because if other protocols and/or profiles want to use these, they'd have to reference your XEP piecewise, which makes these new XEPs harder to follow. After some thinking, I guess I will split my proposal into three XEPs: 1. Service Provider including section 4. I will also add variable monitoring to it. 2. Client-to-Client Communication including section 6. After reading some more XEPs, I guess jingle is the way to go to open the stream between clients. I will change that. 3. Authorization Service will include sections 7 and 8. Sections 3 and 5 will be moved to one of these three, I'm not sure now. I would like to start with the first one, sending it to the XMPP council next week. One question: the doc says I should send it to http://www.xmpp.org/extensions/inbox/. But looking at that dir, I see only html files. Doesn't it make more sense to upload the xml file? What is the correct way to do this? Dirk -- Earn cash in your spare time - blackmail friends.
Re: [Standards] New XMPP Use Case: Private Media Networks
Hi, Dave Cridland wrote: This looks interesting. Particularly so because of the case allowing information flow between public services and private media services. I'm thinking particularly of data stores such as the BBC's Programmes thing, but this would be equally applicable to a number of cases I'd imagine, including being able to watch something my neighbour had recorded if I had their permission. Or even better: if you want to record two shows but only have one DVB-T receiver and your neighbour does not need his at that time, you could use it (with his permission). This notion of bring these traditionally isolated networks into (secure) contact with the internet as a whole seems like a good enough reason to go this route on its own - I really like the symmetry between accessing your local media store and someone else's one remotely via essentially the same mechanism. Thanks. Unlike a HTTP based approach like UPnP, XMPP provides a much better core for what I call a Personal Media Network. I think that's basically a good plan, but one of the key features of UPnP is that it's Plug 'n' Play - specifically, dropping a device onto a network essentially makes the device attach and become available to the network. Your proposal misses this out, and I think that's a critical shortcoming. You can not have plug and play AND security. In fact, there is a UPnP security document but I know no device implementing it. So it has to be plug, insert a pin, play. This can be addressed easily by bootstrapping via Link Local XMPP (XEP-0174), and using some simple authentication mechanism - akin to a Bluetooth pairing - to allow a push of configuration data to make the jump to client/server XMPP, although that might be somewhat overkill - but it allows for physically isolated networks to operate perfectly well, too. Section 8.2 describes how to find an authorization node link local and the peering in 8.3 is similar (from the users point of view) to bluetooth peering. For link-local devices it is more or less plug and play (which the additional pin). I don't entirely agree it's using XMPP in an unintended way, really - the use of C2C pubsub is unusual, though I like the concept. Again, thanks. One thing that does immediately ring alarm bells for me, personally, is that the design conflates several orthogonal aspects of inter-device communication. There's a number of reasons I don't like this, in particular because if other protocols and/or profiles want to use these, they'd have to reference your XEP piecewise, which makes these new XEPs harder to follow. I'd encourage you to split out each concept into a distinct document: a) One that describes C2C PubSub - maybe, although it's potentially a small enough adaptation that it'll need nothing new. LOL, if you could see my private svn you would see that I moved the whole section 4 (Service Provider and Controller) in an extra document, moved it back and the same again. They kept referencing each other. :) But only moving the C2C PubSub away sounds like a good idea. b) One that describes C2C security, although admittedly you may wish to punt on this, and simply note that it's an issue that needs solving. I don't understand what you mean. c) One that describes a media device framework using XMPP. I'd fold in the pairing bootstrap from Link-Local here, but again, this might need its own document if it turns out to be too big. and d) I guess there could be the need for one higher level bytestream XEP. This XEP could use direct connections, a TURN or SOCKS5 server and IBB as fallback. Having a bi-directional datastream XEP could be very usefull and for transmitting video files, IBB is not an option. Direct connections may be possible if one node is not behind a NAT/firewall (e.g. a mobile phone) and also with IPv6. While my home network is behind an IPv4 NAT, I have a /64 IPv6 network with public IP addresses for all my devices at home. However, I'd reiterate that the subject matter and general concept seems solid to me, and well worth persuing. I like to hear that. :) Thanks for the feedback, Dirk -- Microsoft Windows didn't get as bad as it is overnight -- it took over ten years of careful development
[Standards] New XMPP Use Case: Private Media Networks
Hi, I wrote a first draft of a possible XMPP extension which opens new use cases for XMPP. But before I go into details, let me introduce myself: my name is Dirk Meyer and I work at the TZI which is part of the University of Bremen. My doctor thesis is about media networks and possible new use cases if all devices of a user can interact with each other. Unlike a HTTP based approach like UPnP, XMPP provides a much better core for what I call a Personal Media Network. My first (not finished) draft can be found at http://www.tzi.de/~dmeyer/media-network.html Before finishing it and sending it to the XMPP council I want to ask on this list for some opinions about it. It clearly uses XMPP in a way XMPP was not indented to be used, but it could be the base for new use cases (examples of such use cases are in the document). Besides working at the TZI I'm also maintainer of the Freevo project and want to use the XMPP based private network as communication between different media applications inside Freevo. I already have a small Python based XMPP implementation specially designed for this use cases (not in public svn yet). So, if you have some free minutes, please take a look at my draft and tell me what you think about this idea. Regards, Dirk -- The world is full of willing people -- some willing to work and some willing to let them. - Robert Frost.
