From rabbi at abditum.com Fri Feb 1 15:56:29 2008 From: rabbi at abditum.com (Len Sassaman) Date: Fri, 1 Feb 2008 12:56:29 -0800 (PST) Subject: [OTR-dev] Version negotiation problems in Adium/Pidgin? Message-ID: I ran into a problem earlier, where an XP/Pidgin 2.3.1/OTR 3.1.0 was prompted with a box asking her to enter a secret only I would know, etc. I assume this is an implementation of the socialist millionaire's problem-inspired authentication protocol Ian was working on? In any case, my version of Adium (1.2.1), does not support this. All I see are fingerprint and secure id. Shouldn't there be a protocol negotiation here? --Len. From ian at cypherpunks.ca Fri Feb 1 16:34:06 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 1 Feb 2008 16:34:06 -0500 Subject: [OTR-dev] Version negotiation problems in Adium/Pidgin? In-Reply-To: References: Message-ID: <20080201213406.GP5797@yoink.cs.uwaterloo.ca> On Fri, Feb 01, 2008 at 12:56:29PM -0800, Len Sassaman wrote: > I ran into a problem earlier, where an XP/Pidgin 2.3.1/OTR 3.1.0 was > prompted with a box asking her to enter a secret only I would know, etc. > > I assume this is an implementation of the socialist millionaire's > problem-inspired authentication protocol Ian was working on? In any case, > my version of Adium (1.2.1), does not support this. All I see are > fingerprint and secure id. > > Shouldn't there be a protocol negotiation here? Yup, probably. We're actually doing an overhaul of the buddy authentication UI right now, as a result of having done a user study. We'll keep this issue in mind as well. - Ian From jwn2 at ucsd.edu Fri Feb 1 16:44:33 2008 From: jwn2 at ucsd.edu (John W Noerenberg II) Date: Fri, 1 Feb 2008 13:44:33 -0800 Subject: [OTR-dev] OS X 10.5.1, OTR Proxy & AIM direct connections Message-ID: When two AIM users start a direct connection (to exchange files via a chat session, for example), OTR Proxy doesn't pick up the new connection. Adium is smart enough to notice that OTR Proxy has dropped the ball and complains vociferously, but OTR Proxy gives no indication there's anything amiss. It would seem it's blissfully unaware the conversation has switched to a different port. Is there a Bugzilla database for reporting things like this? This would not be the only issue with OTR Proxy on a Mac. :-) -- john noerenberg ---------------------------------------------------------------------- Statt des t?richten Ignorabimus hei?e im Gegenteil unsere L?sung: Wir m?ssen wissen, Wir werden wissen. -- David Hilbert, "Logic and the Understanding of Nature, Sep 1930 ---------------------------------------------------------------------- From ian at cypherpunks.ca Fri Feb 1 16:49:49 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 1 Feb 2008 16:49:49 -0500 Subject: [OTR-dev] OTR with Jabber/XMPP In-Reply-To: <200801281753.m0SHrh4n023935@paip.net> References: <20071209010325.GU32346@yoink.cs.uwaterloo.ca> <200801281753.m0SHrh4n023935@paip.net> Message-ID: <20080201214949.GS5797@yoink.cs.uwaterloo.ca> On Mon, Jan 28, 2008 at 06:53:39PM +0100, Timo Engel wrote: > > Hello, > > there are some problems when using the gaim/pidgin plugin with Jabber/XMPP. > Pidgin uses HTML messages which are described in XEP-0071. A XMPP messages > which is encrypted with the Gaim/Pidgin OTR Plugin looks like this: > > > > [EncryptedBody] > > > > [EncryptedHTML] > > > > > The contents of [EncryptedBody] and [EncryptedHTML] are the same. After > decrypting the message, there is HTML code in the body-element. This is not a > valid XMPP message and is problematic if the client doesn't use HTML. > > The encrypted HTML code is not XML compliant. After decrypting the message it > could not be parsed from an XML parser. This is really annoying, because the > client can't display the message. This has been discussed before. The ciphertext is valid XML, since the ciphertext itself contains no markup. When the user-agent decrypts the OTR ciphertext to get plaintext, it may have markup, because the OTR specification says it can. If the user-agent doesn't understand markup, the OTR plugin for that user-agent is responsible for removing it. - Ian From ian at cypherpunks.ca Fri Feb 1 16:56:04 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 1 Feb 2008 16:56:04 -0500 Subject: [OTR-dev] OS X 10.5.1, OTR Proxy & AIM direct connections In-Reply-To: References: Message-ID: <20080201215604.GT5797@yoink.cs.uwaterloo.ca> On Fri, Feb 01, 2008 at 01:44:33PM -0800, John W Noerenberg II wrote: > When two AIM users start a direct connection (to exchange files via a > chat session, for example), OTR Proxy doesn't pick up the new > connection. Adium is smart enough to notice that OTR Proxy has > dropped the ball and complains vociferously, but OTR Proxy gives no > indication there's anything amiss. It would seem it's blissfully > unaware the conversation has switched to a different port. I'm not sure how OTR Proxy could know that an IM client had made a direct connection to someone, ignoring the proxy settings. > Is there a Bugzilla database for reporting things like this? This > would not be the only issue with OTR Proxy on a Mac. :-) There is a bug database on sourceforge, but I'm afraid otrproxy isn't really getting much attention right now, since none of the developers use OS X. :-( - Ian From timo-e at freenet.de Sat Feb 2 09:47:43 2008 From: timo-e at freenet.de (Timo Engel) Date: Sat, 02 Feb 2008 15:47:43 +0100 (CET) Subject: [OTR-dev] OTR with Jabber/XMPP In-Reply-To: <20080201214949.GS5797@yoink.cs.uwaterloo.ca> Message-ID: <200802021447.m12Elk8E013787@paip.net> On 01-Feb-2008 Ian Goldberg wrote: > On Mon, Jan 28, 2008 at 06:53:39PM +0100, Timo Engel wrote: >> [...] >> The contents of [EncryptedBody] and [EncryptedHTML] are the same. After >> decrypting the message, there is HTML code in the body-element. This is not >> a >> valid XMPP message and is problematic if the client doesn't use HTML. >> >> The encrypted HTML code is not XML compliant. After decrypting the message >> it >> could not be parsed from an XML parser. This is really annoying, because the >> client can't display the message. > > This has been discussed before. The ciphertext is valid XML, since the > ciphertext itself contains no markup. When the user-agent decrypts the > OTR ciphertext to get plaintext, it may have markup, because the OTR > specification says it can. If the user-agent doesn't understand markup, > the OTR plugin for that user-agent is responsible for removing it. It should not be task of the receiving plugin to remove HTML tags. For that reason a XMPP messages has a body-element where html content is not allowed and the optional html-element with XHTML markup. The markup should be valid XHTML. This is not the case if gaim is used with the otr-plugin. Without the plugin, the messages from gaim are valid. Perhaps this is a problem of the plugin-interface of gaim. From enigma at turingstudio.com Wed Feb 6 14:35:25 2008 From: enigma at turingstudio.com (alex black) Date: Wed, 6 Feb 2008 11:35:25 -0800 Subject: [OTR-dev] daemon-only? Message-ID: hey all, is there a daemon-only version of otrproxy? I think it would be pretty easy to do this from the commandline, and then I wouldn't have to keep a window running all the time (which would reduce memory consumption..) any opinions? best, _alex -- alex black, founder the turing studio, inc. 510.666.0074 root at turingstudio.com http://www.turingstudio.com 800 jones street berkeley, ca 94710 From enigma at turingstudio.com Wed Feb 6 18:29:00 2008 From: enigma at turingstudio.com (alex black) Date: Wed, 6 Feb 2008 15:29:00 -0800 Subject: [OTR-dev] daemon-only? In-Reply-To: References: Message-ID: <2CB265FD-11E2-44DF-B697-2309C7F5D6A2@turingstudio.com> Donny made the point that I could use adium - that's true, however adium constantly dumps debug in my logs and it's unstable. iChat, even with retarded lack of OTR support, is still my favorite client. I'd love to use OTRProxy with it, but I can't figure out a way to background it so it doesn't appear in the dock or create a window - thus the request for a daemon and a simple config tool. anyway - if there is a method someone knows of, great, if not, just a suggestion ;) _a > hey all, > > is there a daemon-only version of otrproxy? I think it would be > pretty easy to do this from the commandline, and then I wouldn't > have to keep a window running all the time (which would reduce > memory consumption..) > > any opinions? > > best, > > _alex > > > -- > alex black, founder > the turing studio, inc. > > 510.666.0074 > root at turingstudio.com > http://www.turingstudio.com > > 800 jones street > berkeley, ca 94710 > > > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev From evan.s at dreskin.net Wed Feb 6 19:16:38 2008 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 6 Feb 2008 19:16:38 -0500 Subject: [OTR-dev] daemon-only? In-Reply-To: <2CB265FD-11E2-44DF-B697-2309C7F5D6A2@turingstudio.com> References: <2CB265FD-11E2-44DF-B697-2309C7F5D6A2@turingstudio.com> Message-ID: <824F631C-604B-4337-ADAD-5E4B1E405ECF@dreskin.net> On Feb 6, 2008, at 6:29 PM, alex black wrote: > Donny made the point that I could use adium - that's true, however > adium constantly dumps debug in my logs and it's unstable. Could you please email me the debug output that adium "dumps in your logs" and a representative crash log? Adium runs 24/7 for me without crashing, and I'm not aware of any noisy debug output in release builds. -Evan > iChat, even with retarded lack of OTR support, is still my favorite > client. I'd love to use OTRProxy with it, but I can't figure out a > way to background it so it doesn't appear in the dock or create a > window - thus the request for a daemon and a simple config tool. > > anyway - if there is a method someone knows of, great, if not, just > a suggestion ;) > > _a > > >> hey all, >> >> is there a daemon-only version of otrproxy? I think it would be >> pretty easy to do this from the commandline, and then I wouldn't >> have to keep a window running all the time (which would reduce >> memory consumption..) >> >> any opinions? >> >> best, >> >> _alex >> >> >> -- >> alex black, founder >> the turing studio, inc. >> >> 510.666.0074 >> root at turingstudio.com >> http://www.turingstudio.com >> >> 800 jones street >> berkeley, ca 94710 >> >> >> >> _______________________________________________ >> OTR-dev mailing list >> OTR-dev at lists.cypherpunks.ca >> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From jwn2 at ucsd.edu Wed Feb 6 21:48:03 2008 From: jwn2 at ucsd.edu (John W Noerenberg II) Date: Wed, 6 Feb 2008 18:48:03 -0800 Subject: [OTR-dev] daemon-only? In-Reply-To: References: Message-ID: At 11:35 AM -0800 2/6/08, alex black wrote: >is there a daemon-only version of otrproxy? I think it would be >pretty easy to do this from the commandline, and then I wouldn't >have to keep a window running all the time (which would reduce >memory consumption..) > >any opinions? You need some kind of UI in order to validate trust in newly acquired keys, or to selectively enable OTR for users for whom you have keys. However, I agree the current UI (on a Mac) leaves much to be desired. :-) As for memory consumption, a version of of OTR Proxy built with wxWidgets 2.8.7 is using (at the moment) 8.96MB of real memory and 940.57 MB or virtual. The amount of virtual memory surprised me, but I haven't studied why. -- john noerenberg ---------------------------------------------------------------------- Statt des t?richten Ignorabimus hei?e im Gegenteil unsere L?sung: Wir m?ssen wissen, Wir werden wissen. -- David Hilbert, "Logic and the Understanding of Nature, Sep 1930 ---------------------------------------------------------------------- From enigma at turingstudio.com Thu Feb 7 00:55:56 2008 From: enigma at turingstudio.com (Alex Black) Date: Wed, 6 Feb 2008 21:55:56 -0800 Subject: [OTR-dev] daemon-only? In-Reply-To: References: Message-ID: > You need some kind of UI in order to validate trust in newly > acquired keys, or to selectively enable OTR for users for whom you > have keys. However, I agree the current UI (on a Mac) leaves much to > be desired. :-) In my mind, the only UI necessary is what you mention. Generating keys should be automatic, so the only real UI that should ever be presented is: --------------------------------------------- [][][] --------------------------------------------- [ Do you want to accept an incoming key [ from user (blah?) [ [ [ Deny ] [ Accept ] --------------------------------------------- The rest of the UI (active sessions, etc) is superfluous. If the implementation were that: a background process that has one single piece of UI - I think it would be ideal. I'm _amazed_ pathetic apple didn't include OTR in iChat, but I digress ;) best, _alex From jwn2 at ucsd.edu Thu Feb 7 01:21:18 2008 From: jwn2 at ucsd.edu (John W Noerenberg II) Date: Wed, 6 Feb 2008 22:21:18 -0800 Subject: [OTR-dev] daemon-only? In-Reply-To: References:

Message-ID: At 9:55 PM -0800 2/6/08, Alex Black wrote: >--------------------------------------------- >[][][] >--------------------------------------------- >[ Do you want to accept an incoming key >[ from user (blah?) >[ >[ [ Deny ] [ Accept ] >--------------------------------------------- It can't be quite this simple, because there has to be a means to defend against the possible MITM attack. Also, there are circumstances when one can legitimately generate more than one key. As a UI designer, you have to consider how to minimize confusion for the users in those situations. There also have to be mechanisms to indicate when a session is private and when it is exposed. >The rest of the UI (active sessions, etc) is superfluous. Much of what I see in the UI is an attempt to deal with these issues I've outlined above. That doesn't necessarily mean I think think it's a well-executed design. ;-) From enigma at turingstudio.com Thu Feb 7 03:21:54 2008 From: enigma at turingstudio.com (Alex Black) Date: Thu, 7 Feb 2008 00:21:54 -0800 Subject: [OTR-dev] daemon-only? In-Reply-To: References:

Message-ID: > It can't be quite this simple, because there has to be a means to > defend against the possible MITM attack. Also, there are > circumstances when one can legitimately generate more than one key. > As a UI designer, you have to consider how to minimize confusion for > the users in those situations. generate more than one key = single command. do you mean more than one key for an individual username? never had cause to do it. would those keys be used for specific recipients? > There also have to be mechanisms to indicate when a session is > private and when it is exposed. Is it insane to have OTR announced in the chat session (proxy masquerading as the other user)? would certainly be in context.. >> Much of what I see in the UI is an attempt to deal with these >> issues I've outlined above. That doesn't necessarily mean I think >> think it's a well-executed design. ;-) ok: keygen can be handled either with a simple commandline app or with a slightly fancier standalone ui, though I don't see the point given the audience for an OTR proxy ;) I think most can, at minimum, get to a terminal and execute a command. which leaves announcing the session is encrypted or in the clear and soliciting user approval for the acceptance of keys. the former can be a matter of preference: "I don't care / don't tell me" "announce the status whenever it changes" or "announce only when encryption is being used". the latter can I think be effectively handled by a simple dialog. even something fancy that fades up ;) best, _alex -- alex black founder, turing 510 666 0074 enigma at turingstudio.com From Jan at onGlobe.de Thu Feb 7 10:30:52 2008 From: Jan at onGlobe.de (Jan Scheele) Date: Thu, 07 Feb 2008 16:30:52 +0100 Subject: [OTR-dev] Re: OTR-dev digest, Vol 1 #228 - 7 msgs In-Reply-To: <20080207114634.14705.80340.Mailman@brandeis.paip.net> References: <20080207114634.14705.80340.Mailman@brandeis.paip.net> Message-ID: <47AB242C.7070003@onGlobe.de> otr-dev-request at lists.cypherpunks.ca schrieb: > Send OTR-dev mailing list submissions to > otr-dev at lists.cypherpunks.ca > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > or, via email, send a message with subject or body 'help' to > otr-dev-request at lists.cypherpunks.ca > > You can reach the person managing the list at > otr-dev-admin at lists.cypherpunks.ca > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OTR-dev digest..." > > > Today's Topics: > > 1. daemon-only? (alex black) > 2. Re: daemon-only? (alex black) > 3. Re: daemon-only? (Evan Schoenberg) > 4. Re: daemon-only? (John W Noerenberg II) > 5. Re: daemon-only? (Alex Black) > 6. Re: daemon-only? (John W Noerenberg II) > 7. Re: daemon-only? (Alex Black) > > --__--__-- > > Message: 1 > From: alex black > To: otr-dev at lists.cypherpunks.ca > Date: Wed, 6 Feb 2008 11:35:25 -0800 > Subject: [OTR-dev] daemon-only? > > hey all, > > is there a daemon-only version of otrproxy? I think it would be pretty > easy to do this from the commandline, and then I wouldn't have to keep > a window running all the time (which would reduce memory consumption..) > > any opinions? > > best, > > _alex > > > Hi! about the deamon subject... In Windows it is possible to use a third party program to send any other program to the taskbar notification area (tna). If you're under mac os or what else, maybe that's also possible?! Jan From ian at cypherpunks.ca Tue Feb 12 07:39:07 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 12 Feb 2008 07:39:07 -0500 Subject: [OTR-dev] OTR with Jabber/XMPP In-Reply-To: <200802021447.m12Elk8E013787@paip.net> References: <20080201214949.GS5797@yoink.cs.uwaterloo.ca> <200802021447.m12Elk8E013787@paip.net> Message-ID: <20080212123907.GV5797@yoink.cs.uwaterloo.ca> On Sat, Feb 02, 2008 at 03:47:43PM +0100, Timo Engel wrote: > It should not be task of the receiving plugin to remove HTML tags. For > that reason a XMPP messages has a body-element where html content is > not allowed and the optional html-element with XHTML markup. No, it really should be. Suppose the OTR specification said that the plaintext should first be rot-13 encoded before being encrypted. The receiving OTR plugin would then be responsible for rot-13 decoding before passing the plaintext up to the application. Similarly, since the OTR specification says that the plaintext can have HTML-markup, it's up to the receiving OTR plugin to handle that before passing it up to the receiving application. For some receiving applications, this is easy, since nothing has to be done. For others, the markup needs to be stripped. The XMPP specification says that there must be no html content in the body-element, which is in fact what happens; the body-element is base64-encoded ciphertext with no markup (on the ciphertext). You seem to be saying that if one takes a valid XMPP message that contains ciphertext, and decrypts the encrypted part, while making no other changes to the XMPP message, the result should also be a valid XMPP message. However, that's just not true. - Ian From l-otr.0705+23jv-l at ruediger-kuhlmann.de Mon Feb 25 19:29:25 2008 From: l-otr.0705+23jv-l at ruediger-kuhlmann.de (=?iso-8859-1?Q?R=FCdiger?= Kuhlmann) Date: Tue, 26 Feb 2008 01:29:25 +0100 Subject: Poll (was: [otr-dev] OTR with Jabber/XMPP) In-Reply-To: <20080212123907.GV5797@yoink.cs.uwaterloo.ca> References: <20080201214949.GS5797@yoink.cs.uwaterloo.ca> <200802021447.m12Elk8E013787@paip.net> <20080212123907.GV5797@yoink.cs.uwaterloo.ca> Message-ID: <20080226002925.GD5638@msgids.ruediger-kuhlmann.de> Hi, >--[Ian Goldberg]-- > On Sat, Feb 02, 2008 at 03:47:43PM +0100, Timo Engel wrote: > > It should not be task of the receiving plugin to remove HTML tags. For > > that reason a XMPP messages has a body-element where html content is > > not allowed and the optional html-element with XHTML markup. > No, it really should be. Suppose the OTR specification said that the > plaintext should first be rot-13 encoded before being encrypted. The > receiving OTR plugin would then be responsible for rot-13 decoding > before passing the plaintext up to the application. Similarly, since > the OTR specification says that the plaintext can have HTML-markup, it's > up to the receiving OTR plugin to handle that before passing it up to > the receiving application. For some receiving applications, this is > easy, since nothing has to be done. For others, the markup needs to be > stripped. > The XMPP specification says that there must be no html content in the > body-element, which is in fact what happens; the body-element is > base64-encoded ciphertext with no markup (on the ciphertext). I re-read the specification. The XMPP specification says that the body element may not contain HTML markup (for this, specific nodes are created), and contains the plain text message. The documentation of libOTR (in particular, the README) specifies that the usage of libOTR for sending a message consists of letting libOTR munge the message to be sent; there is no mentioning of stripping HTML tags for either sending or receiving. From this it follows that the text put into the XMPP body tag may not contain encrypted data from plaintext that contains markup. So there is plainly a bug in Pidgin if it does so. What it produces maybe technically a correct XMPP message, and the encrypted data is technically a correct OTR stream, but the combination is still incorrect. Note that the only place in the specification that says anything about markup in the message (chapter "Data Message") is of no relevance here, for the obvious reason that of course a plaintext message may in general contain markup. There just may be circumstances where this is not the case. Here's the question to all plugin developers: Do you put encrypted HTML tags into the body node of XMPP messages? (please mention the XMPP client you're involvced with) -- "See, free nations are peaceful nations. Free nations don't attack each other. Free nations don't develop weapons of mass destruction." - George W. Bush, Milwaukee, Wis., Oct. 3, 2003 From timo-e at freenet.de Wed Feb 27 13:57:31 2008 From: timo-e at freenet.de (Timo Engel) Date: Wed, 27 Feb 2008 19:57:31 +0100 Subject: [OTR-dev] Re: Poll In-Reply-To: <20080226002925.GD5638@msgids.ruediger-kuhlmann.de> References: <20080201214949.GS5797@yoink.cs.uwaterloo.ca> <200802021447.m12Elk8E013787@paip.net> <20080212123907.GV5797@yoink.cs.uwaterloo.ca> <20080226002925.GD5638@msgids.ruediger-kuhlmann.de> Message-ID: <47C5B29B.4040804@freenet.de> R?diger Kuhlmann schrieb: > Hi, > >> --[Ian Goldberg]-- >> On Sat, Feb 02, 2008 at 03:47:43PM +0100, Timo Engel wrote: >>> It should not be task of the receiving plugin to remove HTML tags. For >>> that reason a XMPP messages has a body-element where html content is >>> not allowed and the optional html-element with XHTML markup. >> No, it really should be. Suppose the OTR specification said that the >> plaintext should first be rot-13 encoded before being encrypted. The >> receiving OTR plugin would then be responsible for rot-13 decoding >> before passing the plaintext up to the application. Similarly, since >> the OTR specification says that the plaintext can have HTML-markup, it's >> up to the receiving OTR plugin to handle that before passing it up to >> the receiving application. For some receiving applications, this is >> easy, since nothing has to be done. For others, the markup needs to be >> stripped. >> The XMPP specification says that there must be no html content in the >> body-element, which is in fact what happens; the body-element is >> base64-encoded ciphertext with no markup (on the ciphertext). > > I re-read the specification. The XMPP specification says that the body > element may not contain HTML markup (for this, specific nodes are created), > and contains the plain text message. The documentation of libOTR (in > particular, the README) specifies that the usage of libOTR for sending a > message consists of letting libOTR munge the message to be sent; there is no > mentioning of stripping HTML tags for either sending or receiving. From this > it follows that the text put into the XMPP body tag may not contain > encrypted data from plaintext that contains markup. So there is plainly a > bug in Pidgin if it does so. What it produces maybe technically a correct > XMPP message, and the encrypted data is technically a correct OTR stream, > but the combination is still incorrect. Thats exactly the problem i tried to explain. Additional, the HTML-Markup of Pidgin-Otr messages are not XML complient. Probably most developer will do it currently the way like Pidgin-Otr does it. But Pidgin is not the best Jabber client and the plugin does not use the benefits of XMPP.