From ian at cypherpunks.ca Wed Aug 3 14:44:45 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 3 Aug 2005 14:44:45 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: References: Message-ID: <20050803184445.GF1007@smtp.paip.net> On Tue, Jul 26, 2005 at 08:39:01AM -0400, Greg Troxel wrote: > I'd like an OTR implementation to be able to send a computer-readable, > authenticated "delete SA" message to the other side, for example when > exiting a client. It was a design decision very early on that there be no way for a client do drop from "private" to "not private" except if the user explicitly requests it. Imagine you were typing some long private message to your buddy, and just before you push "Enter", your client receives this "delete SA" message. We do *not* want your private message to be sent unencrypted! > I would like to be able to sign OTR public keys (not session keys, but > the signing keys) in openpgp format, and to be able to send openpgp > keys to peers, kind of like x509 certs in IKE, so that I can leverage > the PGP WoT to authenticate OTR signing keys. Checking one signing > key for someone is far more reasonable than checking 6 OTR keys for my > friend's 6 computers, and thus far more likely to happen. You of course *can* sign OTR public keys in openpgp format: -----BEGIN PGP SIGNED MESSAGE----- The OTR fingerprint for otr4ian on AIM is C5D70FB3 135CB595 F2F31E01 88884CEF BDD73BD9 The OTR fingerprint for otr4ian at jabber.org on Jabber is 30216646 4D6CDA2A 9DBBB761 8E91679C 0345858C -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQCVAwUBQvEPGEZRiTErSPb1AQFPgAQAgVP4jp6r9isxNNH8DX8ieCdzISMBdIDz g3C6dymF6j8BWVdd1AIgrB3SojEOVIi5ZBGSNteHFfCMqJN+IFRm9QL8T55J9jJf 6PTeeWOkh1xpZUKuWl+ybeo9lcS1dIAW+0jPpLRqqej3TT5PjXMyfBuOgTqPCeGb Of+it/Z2j/4= =PiUt -----END PGP SIGNATURE----- Your buddy should put something like that on his web page. That being said, some future version is likely to support various "in-band" verification mechanisms, including preshared secrets. - Ian From arodland at entermail.net Wed Aug 3 15:08:23 2005 From: arodland at entermail.net (Andrew Rodland) Date: Wed, 3 Aug 2005 15:08:23 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: <20050803184445.GF1007@smtp.paip.net> References: <20050803184445.GF1007@smtp.paip.net> Message-ID: <200508031508.28981.arodland@entermail.net> On Wednesday 03 August 2005 02:44 pm, Ian Goldberg wrote: > On Tue, Jul 26, 2005 at 08:39:01AM -0400, Greg Troxel wrote: > > I'd like an OTR implementation to be able to send a computer-readable, > > authenticated "delete SA" message to the other side, for example when > > exiting a client. > > It was a design decision very early on that there be no way for a client > do drop from "private" to "not private" except if the user explicitly > requests it. Imagine you were typing some long private message to your > buddy, and just before you push "Enter", your client receives this > "delete SA" message. We do *not* want your private message to be sent > unencrypted! > I still think that it would be useful, to prevent the case where I restart my client (or go away for a day), implicitly resetting my session, while my buddy stays online, and later sends me an encrypted message I can't read. How about: 1. Alice sends "End Session" request and tears down her session. No further confirmation is needed on her end because she initiated the privacy drop. 2. Bob receives notification that Alice has ended the session, and is asked to confirm his awareness of this [1]. 3. Any messages that Bob sends to Alice before confirming the end-of-session are discarded by OTR, and OTR sends a further reminder status message. [1]: This could be done with a status message and challenge/response thing, i.e. "Alice12345 has ended the secure session. Please type OTR2i94hd to confirm.", or by hijacking the OTR privacy widget on clients that have it; a status message is produced and the widget changes from "OTR: Private" to "OTR: Locked"; clicking the widget changes it to "OTR: Not Private". -- Andrew Rodland -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ian at cypherpunks.ca Wed Aug 3 15:23:08 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 3 Aug 2005 15:23:08 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: <200508031508.28981.arodland@entermail.net> References: <20050803184445.GF1007@smtp.paip.net> <200508031508.28981.arodland@entermail.net> Message-ID: <20050803192308.GH1007@smtp.paip.net> On Wed, Aug 03, 2005 at 03:08:23PM -0400, Andrew Rodland wrote: > I still think that it would be useful, to prevent the case where I restart my > client (or go away for a day), implicitly resetting my session, while my > buddy stays online, and later sends me an encrypted message I can't read. How > about: > > > 1. Alice sends "End Session" request and tears down her session. No further > confirmation is needed on her end because she initiated the privacy drop. > 2. Bob receives notification that Alice has ended the session, and is asked to > confirm his awareness of this [1]. > 3. Any messages that Bob sends to Alice before confirming the end-of-session > are discarded by OTR, and OTR sends a further reminder status message. This is hardly different at all from what happens today: Bob is informed that Alice has terminated her session, and that he should do the same. Anything else Bob types before he either (1) terminates his OTR session, or (2) starts a new one, results in an error message from gaim. This is fine; what we *don't* want is for Bob's client to *automatically* terminate his session. - Ian From arodland at entermail.net Wed Aug 3 15:38:32 2005 From: arodland at entermail.net (Andrew Rodland) Date: Wed, 3 Aug 2005 15:38:32 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: <20050803192308.GH1007@smtp.paip.net> References: <200508031508.28981.arodland@entermail.net> <20050803192308.GH1007@smtp.paip.net> Message-ID: <200508031538.38194.arodland@entermail.net> On Wednesday 03 August 2005 03:23 pm, Ian Goldberg wrote: > On Wed, Aug 03, 2005 at 03:08:23PM -0400, Andrew Rodland wrote: > > I still think that it would be useful, to prevent the case where I > > restart my client (or go away for a day), implicitly resetting my > > session, while my buddy stays online, and later sends me an encrypted > > message I can't read. How about: > > > > > > 1. Alice sends "End Session" request and tears down her session. No > > further confirmation is needed on her end because she initiated the > > privacy drop. 2. Bob receives notification that Alice has ended the > > session, and is asked to confirm his awareness of this [1]. > > 3. Any messages that Bob sends to Alice before confirming the > > end-of-session are discarded by OTR, and OTR sends a further reminder > > status message. > > This is hardly different at all from what happens today: Bob is > informed that Alice has terminated her session, and that he should do > the same. Anything else Bob types before he either (1) terminates his > OTR session, or (2) starts a new one, results in an error message from > gaim. > > This is fine; what we *don't* want is for Bob's client to > *automatically* terminate his session. Okay, you're right -- it's just that the option is pretty well hidden. I'd like to see it improved in certain UI-related ways, but now that I know what I'm talking about, it's no longer a protocol-change issue :) Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ian at cypherpunks.ca Wed Aug 3 15:44:08 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 3 Aug 2005 15:44:08 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: <200508031538.38194.arodland@entermail.net> References: <200508031508.28981.arodland@entermail.net> <20050803192308.GH1007@smtp.paip.net> <200508031538.38194.arodland@entermail.net> Message-ID: <20050803194408.GI1007@smtp.paip.net> On Wed, Aug 03, 2005 at 03:38:32PM -0400, Andrew Rodland wrote: > Okay, you're right -- it's just that the option is pretty well hidden. I'd > like to see it improved in certain UI-related ways, but now that I know what > I'm talking about, it's no longer a protocol-change issue :) In the CVS version, the OTR button has a right-click context menu. "End private conversation" is one of the entries on that. - Ian From alex323 at gmail.com Wed Aug 3 20:36:46 2005 From: alex323 at gmail.com (Alex) Date: Wed, 03 Aug 2005 20:36:46 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: <20050803184445.GF1007@smtp.paip.net> References: <20050803184445.GF1007@smtp.paip.net> Message-ID: <42F1631E.6020100@gmail.com> >>I would like to be able to sign OTR public keys (not session keys, but >>the signing keys) in openpgp format, and to be able to send openpgp >>keys to peers, kind of like x509 certs in IKE, so that I can leverage >>the PGP WoT to authenticate OTR signing keys. Checking one signing >>key for someone is far more reasonable than checking 6 OTR keys for my >>friend's 6 computers, and thus far more likely to happen. > > >You of course *can* sign OTR public keys in openpgp format: > Ian Goldberg wrote: > The OTR fingerprint for otr4ian on AIM is > C5D70FB3 135CB595 F2F31E01 88884CEF BDD73BD9 > > The OTR fingerprint for otr4ian at jabber.org on Jabber is > 30216646 4D6CDA2A 9DBBB761 8E91679C 0345858C > You just gave me a great idea for my C# implementation of OTR :) I will try to feature something like that. - Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: OpenPGP digital signature URL: From gdt at ir.bbn.com Thu Aug 4 08:07:10 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: 04 Aug 2005 08:07:10 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: <20050803184445.GF1007@smtp.paip.net> References: <20050803184445.GF1007@smtp.paip.net> Message-ID: It was a design decision very early on that there be no way for a client do drop from "private" to "not private" except if the user explicitly requests it. Imagine you were typing some long private message to your buddy, and just before you push "Enter", your client receives this "delete SA" message. We do *not* want your private message to be sent unencrypted! This conflates two things: protecting the user from sending cleartext unexpectedly rational SA management Before there was policy (always use OTR, etc.), the approach made certainly made sense because there was no way to specify policy a la IPsec SPD. Now the two issues can be separated. I'd argue that for a peer that should be using OTR, treatment of the first message and of a SA-deleted message should be somewhat similar, but not entirely the same. The problem I run into is: OTR session with Alice I exit my client Alice says something Alice exits her client I reappear on the net I get an encrypted message I can't read. What I'd like is for my client to send a "destroy SA" message, that changes Alice's client from "Private" to "Private/Broken" where her client will still refuse to send cleartext, but will know that the key is invalid, and try to do an OTR setup exchange before sending a message. This should be the same behavior as if OTR is required for this user. I see no security problem with Private/Broken - but in this case Alice's client can say "OTR exchange failed to complete - message not sent" and Alice will know that I didn't get the message. You of course *can* sign OTR public keys in openpgp format: I know I can do that. I'd like to have automatic key management so that I don't have to do manual comparisons, just like how the PGP WoT works. I see the simplicity argument, but it's too bad that OTR public keys aren't in openpgp format. -- Greg Troxel From gdt at ir.bbn.com Thu Aug 4 08:19:02 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: 04 Aug 2005 08:19:02 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: References: <20050803184445.GF1007@smtp.paip.net> Message-ID: Also, I should say thanks for all your work on OTR - I use it daily. I just changed the per-user policy for one correspondent and on typing a message got the policy violation popup. Then I got an 'established' popup (I had previously accepted public key fingerprint). I'd prefer to see these inline, as I don't consider them error cases. At least I'd like the first popup to be changed to show the exchange complete, rather than leaving two. This is exactly the behavior (modulo popup/inline issues) I'd like to see for Private/Broken. Essentially Private/Broken would force "require OTR" policy. (One could even wonder about starting key exchange when typing begins, but that's a separate issue.) -- Greg Troxel From ian at cypherpunks.ca Thu Aug 4 08:25:06 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 4 Aug 2005 08:25:06 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: References: <20050803184445.GF1007@smtp.paip.net> Message-ID: <20050804122506.GJ1007@smtp.paip.net> On Thu, Aug 04, 2005 at 08:07:10AM -0400, Greg Troxel wrote: > OTR session with Alice > > I exit my client > > Alice says something > > Alice exits her client > > I reappear on the net > > I get an encrypted message I can't read. > > What I'd like is for my client to send a "destroy SA" message, that > changes Alice's client from "Private" to "Private/Broken" where her > client will still refuse to send cleartext, but will know that the key > is invalid, and try to do an OTR setup exchange before sending a > message. This should be the same behavior as if OTR is required for > this user. If you were to select "End private conversation" from the OTR menu before quitting your client, wouldn't something just like this happen? > You of course *can* sign OTR public keys in openpgp format: > > I know I can do that. I'd like to have automatic key management so > that I don't have to do manual comparisons, just like how the PGP WoT > works. I see the simplicity argument, but it's too bad that OTR > public keys aren't in openpgp format. I don't think the *format* is the issue: if you're proposing to use your *actual gpg key* as the signing key, then you're opening lots of cans of worms. How do you import the signatures into OTR? How does someone who's never heard of gpg verify them? Even if they have heard of gpg, where is their public key ring? Where's your secret key ring? Is it even on this particular computer? Are we assuming you're using any one particular implementation of the openpgp format? Since when does the PGP WoT not require manual comparisons, anyway? Could you be more explicit about a user scenario? - Ian From ian at cypherpunks.ca Thu Aug 4 09:09:05 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 4 Aug 2005 09:09:05 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: References: <20050803184445.GF1007@smtp.paip.net> Message-ID: <20050804130905.GK1007@smtp.paip.net> On Thu, Aug 04, 2005 at 08:19:02AM -0400, Greg Troxel wrote: > Also, I should say thanks for all your work on OTR - I use it daily. > > I just changed the per-user policy for one correspondent and on typing > a message got the policy violation popup. Then I got an 'established' > popup (I had previously accepted public key fingerprint). I'd prefer > to see these inline, as I don't consider them error cases. At least > I'd like the first popup to be changed to show the exchange complete, > rather than leaving two. Most popups are now inline in the CVS version. > This is exactly the behavior (modulo popup/inline issues) I'd like to > see for Private/Broken. Essentially Private/Broken would force > "require OTR" policy. What is different about what you want vs. the current "end private conversation" functionality? - Ian From gdt at ir.bbn.com Thu Aug 4 09:18:35 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: 04 Aug 2005 09:18:35 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: <20050804122506.GJ1007@smtp.paip.net> References: <20050803184445.GF1007@smtp.paip.net> <20050804122506.GJ1007@smtp.paip.net> Message-ID: If you were to select "End private conversation" from the OTR menu before quitting your client, wouldn't something just like this happen? Does that send a message to the other side to discard the SA? I want my client to have an exit hook that sends destroy messages, just as when one does "/etc/rc.d/racoon stop" on NetBSD the racoon sends DELETE messages to the other side. I see the same issue for the other side with this as what I was proposing. I don't think the *format* is the issue: if you're proposing to use your *actual gpg key* as the signing key, then you're opening lots of cans of worms. No, I mean to have a gpg key that I use for signing email, and a separate per-machine otr signing key, much like we do now. How do you import the signatures into OTR? How does someone who's never heard of gpg verify them? Even if they have heard of gpg, where is their public key ring? Where's your secret key ring? Is it even on this particular computer? I didn't mean to make this gpg-only, so that raw OTR won't work. Are we assuming you're using any one particular implementation of the openpgp format? Well, there's really only one Free implementation... Of course I'm using gnupg. Since when does the PGP WoT not require manual comparisons, anyway? It does. But my point is that once I've exchanged fingerprints of long-term signing keys with someone and cross-certified, then I don't need to confirm their yearly encryption keys, or their friend's keys, because I can let pgp's PKI do that for me. Could you be more explicit about a user scenario? Sure. I have gpg set up, and public/private ring, for normal email use. I have cross-signatures with my friends and colleagues, who are, not super coincidentally, the same people I want to do OTR with. I run OTR on the same computer, and generate an OTR public/private keypair. Somehow, I: export my OTR public key to gnupg sign my OTR public key with my regular gpg key import that signature back to OTR For machines where I don't have my pgp private keys, perhaps this is a bit harder, but still not that bad. My correspondents do likewise I begin an OTR key exchange My client sends not only my public key, but also the signatures. My client receives the other person's public OTR key and signatures. My client asks gnupg (somehow) to verify the signature, and the trust path from a PGP WoT viewpoint. If acceptable to PGP (i.e., would be used to send mail w/o warning), I don't get a popup, or I get different status. For this I need the public part of my keyring, but not the private keyring. The result is that I can use the long-term signing keys to verify OTR signing keys. This has two advantages: * it leverages the work I've already done for PGP key exchange (which is hard, and we know most people aren't as rigorous about this as they perhaps should be) * because of the leverage, it makes it far more likely that OTR signing keys will be actually verified somehow -- Greg Troxel From ian at cypherpunks.ca Thu Aug 4 09:41:34 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 4 Aug 2005 09:41:34 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: References: <20050803184445.GF1007@smtp.paip.net> <20050804122506.GJ1007@smtp.paip.net> Message-ID: <20050804134134.GL1007@smtp.paip.net> On Thu, Aug 04, 2005 at 09:18:35AM -0400, Greg Troxel wrote: > If you were to select "End private conversation" from the OTR menu > before quitting your client, wouldn't something just like this happen? > > Does that send a message to the other side to discard the SA? I want > my client to have an exit hook that sends destroy messages, just as > when one does "/etc/rc.d/racoon stop" on NetBSD the racoon sends > DELETE messages to the other side. I see the same issue for the > other side with this as what I was proposing. It sends a message to the other side (if it thinks he's logged in) that you have discarded your SA. > I don't think the *format* is the issue: if you're proposing to use your > *actual gpg key* as the signing key, then you're opening lots of cans of > worms. > > No, I mean to have a gpg key that I use for signing email, and a > separate per-machine otr signing key, much like we do now. Right; that's what I thought you were getting at. > How do you import the signatures into OTR? How does someone > who's never heard of gpg verify them? Even if they have heard of gpg, > where is their public key ring? Where's your secret key ring? Is it > even on this particular computer? > > I didn't mean to make this gpg-only, so that raw OTR won't work. I figured that, too. > Are we assuming you're using any one particular implementation of > the openpgp format? > > Well, there's really only one Free implementation... Of course I'm > using gnupg. Today, that's true. Are more people using gpg on, say, Windows, than pgp? How would we know? Do we care? > Since when does the PGP WoT not require manual comparisons, anyway? > > It does. But my point is that once I've exchanged fingerprints of > long-term signing keys with someone and cross-certified, then I don't > need to confirm their yearly encryption keys, or their friend's keys, > because I can let pgp's PKI do that for me. > > Could you be more explicit about a user scenario? > > Sure. > > I have gpg set up, and public/private ring, for normal email use. I > have cross-signatures with my friends and colleagues, who are, not > super coincidentally, the same people I want to do OTR with. Well, first note that approximately everyone who uses OTR is not in this situation (having already done the work of manually verifying the fingerprints of friends' keys), but go on. > I run OTR on the same computer, and generate an OTR public/private > keypair. > > Somehow, I: > export my OTR public key to gnupg > sign my OTR public key with my regular gpg key > import that signature back to OTR > > For machines where I don't have my pgp private keys, perhaps this is a > bit harder, but still not that bad. There's a highly non-trivial beast hiding in "somehow". > My correspondents do likewise > > I begin an OTR key exchange > > My client sends not only my public key, but also the signatures. My > client receives the other person's public OTR key and signatures. My > client asks gnupg (somehow) to verify the signature, and the trust > path from a PGP WoT viewpoint. If acceptable to PGP (i.e., would be > used to send mail w/o warning), I don't get a popup, or I get > different status. Surely you don't want the gpg signature to be transmitted on *every* key exchange? You only need to send it once. The CVS version has an explicit step for "verify fingerprint"; *technically*, a plausible thing to do would be to allow the user to choose between 1) manual fingerprint comparison with an out-of-band source [the only method currently supported] 2) preshared secret 3) gpg 4) fleem-based protocols, etc. But someone will have to come up with a UI for this which is highly non-sucky. > For this I need the public part of my keyring, but not the private > keyring. So the gaim-otr app should go looking on your disk for your public keyring, parse it, and do the verification? Or just spawn gpg itself in some invocation? > The result is that I can use the long-term signing keys to verify OTR > signing keys. This has two advantages: > > * it leverages the work I've already done for PGP key exchange (which > is hard, and we know most people aren't as rigorous about this as > they perhaps should be) > > * because of the leverage, it makes it far more likely that OTR > signing keys will be actually verified somehow But only in the event that you *have* done the work with pgp/gpg already. Which almost everyone has not. There's certainly a place in the "verify fingerprint" part of the protocol for gpg signatures. But both integration and UI are likely to be nightmarish. [Check out the CVS version to see the new "verify fingerprint" mechanism.] - Ian From kat at paip.net Thu Aug 4 09:54:27 2005 From: kat at paip.net (Kat Hanna) Date: Thu, 4 Aug 2005 09:54:27 -0400 (EDT) Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: <20050804134134.GL1007@smtp.paip.net> References: <20050803184445.GF1007@smtp.paip.net> <20050804122506.GJ1007@smtp.paip.net> <20050804134134.GL1007@smtp.paip.net> Message-ID: On Thu, 4 Aug 2005, Ian Goldberg wrote: > Surely you don't want the gpg signature to be transmitted on *every* > key exchange? You only need to send it once. The CVS version has an > explicit step for "verify fingerprint"; *technically*, a plausible thing > to do would be to allow the user to choose between > > 1) manual fingerprint comparison with an out-of-band source > [the only method currently supported] > 2) preshared secret > 3) gpg > 4) fleem-based protocols, etc. > > But someone will have to come up with a UI for this which is highly > non-sucky. This UI point is hugely important. Right now, people who've never used an encryption app before report painless setup and unconfused use. As we add in features, we have to keep these people in mind. Let's not let this turn into yet another difficult-to-use (for most people) security system. -Kat From gdt at ir.bbn.com Thu Aug 4 10:29:45 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: 04 Aug 2005 10:29:45 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: <20050804130905.GK1007@smtp.paip.net> References: <20050803184445.GF1007@smtp.paip.net> <20050804130905.GK1007@smtp.paip.net> Message-ID: Ian Goldberg writes: > Most popups are now inline in the CVS version. I'm glad to hear that. Another reason to release before the protocol change :-) > What is different about what you want vs. the current "end private > conversation" functionality? After reading the source I realized that end private is in the OTR preferences menu and found it. I was trying to right-click on 'otr: private' and looking in the buddy list context menu. After playing with this, and reading the code, I find that it's pretty close to what I want. I'd like to see: ability to end private sessions from chat window (right-click on otr: and get menu of options such as refresh, end, show hash, otr options dialog?) opening up global prefs, choosing otr, etc. is too hard. Ability to automatically end private sessions (for only online buddies, or perhaps all?) on client exit. Easy UI operation to end all private conversations. I think this is just invoking the existing functionality on the exiting side. Indication that state is private/broken on receiving side. It seems to be in this state, as sending gets me a popup that I have to end or refresh. Perhaps 'OTR: Private/x' would do. Make trying to send in private/broken try a refresh by default, just like 'otr required, no session'. Remove 'you should do the same' exhortation from has closed notice. This is policy, and I don't like it :-) I close sessions to avoid unreadable messages - my intent is to start a new one when needed, and with 'use' rather than 'require' policy this results in a cleartext message. To me, ending a session to talk in non-OTR is rare, and indicates that my buddy has a non-OTR client now, and that should definitely we very manual. In 'private connection closed/message not sent' dialog, include local account in parens after 'you'. This is confusing when talking to yourself to test without bothering others. I'd also like a way to expire private sessions after a long period of unuse if the buddy is offline, to proactively avoid the sending on old session problem when a new peer client starts. But the auto-resend behavior works well enough that I think this is unwarranted. -- Greg Troxel From gdt at ir.bbn.com Thu Aug 4 10:39:27 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: 04 Aug 2005 10:39:27 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: <20050804134134.GL1007@smtp.paip.net> References: <20050803184445.GF1007@smtp.paip.net> <20050804122506.GJ1007@smtp.paip.net> <20050804134134.GL1007@smtp.paip.net> Message-ID: Ian Goldberg writes: > > Well, there's really only one Free implementation... Of course I'm > > using gnupg. > > Today, that's true. Are more people using gpg on, say, Windows, than > pgp? How would we know? Do we care? This raises the issue that programs should be able to invoke openpgp operations in a portable way. Gnome would have a corba service, and while complicated it's semantically sensible. > > I have gpg set up, and public/private ring, for normal email use. I > > have cross-signatures with my friends and colleagues, who are, not > > super coincidentally, the same people I want to do OTR with. > > Well, first note that approximately everyone who uses OTR is not in this > situation (having already done the work of manually verifying the > fingerprints of friends' keys), but go on. You are saying that most OTR users do not use PGP? I can believe that. > > I run OTR on the same computer, and generate an OTR public/private > > keypair. > > > > Somehow, I: > > export my OTR public key to gnupg > > sign my OTR public key with my regular gpg key > > import that signature back to OTR > > > > For machines where I don't have my pgp private keys, perhaps this is a > > bit harder, but still not that bad. > > There's a highly non-trivial beast hiding in "somehow". Yes, but it's not amazingly hard. click on "export OTR signing key to file", gpg --import, gpg --edit-key, sign, gpg --export, "import OTR signing keys from file". > > My client sends not only my public key, but also the signatures. My > > client receives the other person's public OTR key and signatures. My > > client asks gnupg (somehow) to verify the signature, and the trust > > path from a PGP WoT viewpoint. If acceptable to PGP (i.e., would be > > used to send mail w/o warning), I don't get a popup, or I get > > different status. > > Surely you don't want the gpg signature to be transmitted on *every* > key exchange? You only need to send it once. The CVS version has an > explicit step for "verify fingerprint"; *technically*, a plausible thing > to do would be to allow the user to choose between i meant on initial conversation, but we could have a 'sigs available' TLV with a 'send sigs' request. > 1) manual fingerprint comparison with an out-of-band source > [the only method currently supported] > 2) preshared secret > 3) gpg > 4) fleem-based protocols, etc. > > But someone will have to come up with a UI for this which is highly > non-sucky. sure, but I'm trying to suggest putting the hooks in the protocol so that can happen without a protocol change. > > For this I need the public part of my keyring, but not the private > > keyring. > > So the gaim-otr app should go looking on your disk for your public > keyring, parse it, and do the verification? Or just spawn gpg itself in > some invocation? The right way probably involves some on-machine RPC to a PGP service, which could involve spawning gpg, especially at first. > > The result is that I can use the long-term signing keys to verify OTR > > signing keys. This has two advantages: > > > > * it leverages the work I've already done for PGP key exchange (which > > is hard, and we know most people aren't as rigorous about this as > > they perhaps should be) > > > > * because of the leverage, it makes it far more likely that OTR > > signing keys will be actually verified somehow > > But only in the event that you *have* done the work with pgp/gpg > already. Which almost everyone has not. But if they haven't, they probably aren't checking OTR signing key hashes either. > There's certainly a place in the "verify fingerprint" part of the > protocol for gpg signatures. But both integration and UI are likely to > be nightmarish. If you think that if the UI part is addressed the protocol can handle gpg sigs w/o an incompatible wire change, then that's what matters for now. > [Check out the CVS version to see the new "verify fingerprint" mechanism.] will put on copious spare time list :-) -- Greg Troxel From ian at cypherpunks.ca Thu Aug 4 13:00:59 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 4 Aug 2005 13:00:59 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: References: <20050803184445.GF1007@smtp.paip.net> <20050804130905.GK1007@smtp.paip.net> Message-ID: <20050804170059.GN1007@smtp.paip.net> On Thu, Aug 04, 2005 at 10:29:45AM -0400, Greg Troxel wrote: > After playing with this, and reading the code, I find that it's pretty > close to what I want. I'd like to see: > > ability to end private sessions from chat window (right-click on > otr: and get menu of options such as refresh, end, show hash, otr > options dialog?) opening up global prefs, choosing otr, etc. is too > hard. As I mentioned, that's already in CVS. > Ability to automatically end private sessions (for only online > buddies, or perhaps all?) on client exit. Easy UI operation to end > all private conversations. I think this is just invoking the > existing functionality on the exiting side. I just checked, and gaim does indeed notify plugins just before it's going to quit. So this seems at least plausible. Note that the plugins have to react immediately, since in a moment gaim will be exiting. So if, for example, your AIM connection is currently throttled, queueing the disconnect message for later delivery won't work. > Indication that state is private/broken on receiving side. It seems > to be in this state, as sending gets me a popup that I have to end > or refresh. Perhaps 'OTR: Private/x' would do. Possible, though this has changed a bit in CVS, so we'll need to think about this a little more. - Ian From gdt at ir.bbn.com Thu Aug 4 13:34:56 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: 04 Aug 2005 13:34:56 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: <20050804170059.GN1007@smtp.paip.net> References: <20050803184445.GF1007@smtp.paip.net> <20050804130905.GK1007@smtp.paip.net> <20050804170059.GN1007@smtp.paip.net> Message-ID: Ian Goldberg writes: > > Ability to automatically end private sessions (for only online > > buddies, or perhaps all?) on client exit. Easy UI operation to end > > all private conversations. I think this is just invoking the > > existing functionality on the exiting side. > > I just checked, and gaim does indeed notify plugins just before it's > going to quit. So this seems at least plausible. Note that the > plugins have to react immediately, since in a moment gaim will be > exiting. So if, for example, your AIM connection is currently > throttled, queueing the disconnect message for later delivery won't > work. It sounds like gaim needs a way for a plugin to put a short hold on exiting while cleanup proceeds. I don't know how receptive gaim folks are to missing features in the plugin architecture.... -- Greg Troxel From evan.s at dreskin.net Thu Aug 4 13:36:01 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Thu, 4 Aug 2005 13:36:01 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: <20050804130905.GK1007@smtp.paip.net> References: <20050803184445.GF1007@smtp.paip.net> <20050804130905.GK1007@smtp.paip.net> Message-ID: <8D207816-37CA-4F7C-B429-9A322BC1D6EB@dreskin.net> On Aug 4, 2005, at 9:09 AM, Ian Goldberg wrote: >> This is exactly the behavior (modulo popup/inline issues) I'd like to >> see for Private/Broken. Essentially Private/Broken would force >> "require OTR" policy. >> > > What is different about what you want vs. the current "end private > conversation" functionality? If the other side went into a "Private/Broken" type state in response to receiving the packet sent after selecting "end private conversation" there would be no difference I can think of. That's not the case at present: Currently: OTR session with Alice I exit my client (without selecting End Private Conversation, which is what happens with most users) I reconnect Alice says something. Her client is currently in the Private state, with the previous secure session. I get an encrypted message I can't read (sent using the encryption from the old secure session). Here's what I'd (and I believe Greg) would want to see: OTR session with Alice I exit my client (without selecting End Private Conversation, which is what happens with most users) Alice's client is told that I ended the private conversation -- mostly likely because the gaim-otr or other client plugin ends all private conversations before disconnecting or quitting. I reconnect. Alice says something. Her client is currently in the "Private/ Broken" state -- it will not send in plaintext, but it knows the secure session is almost certainly invalid. Alice's client automatically attempts to negotiate a new secure session. If succesful, it "resends" the message (really sending it across the network for the first time), now encrypted with the new secure session. I get an OTR Established message followed immediately by the encrypted message (sent using the encryption for the new secure session). Does that make sense? -Evan www.adiumx.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From ian at cypherpunks.ca Thu Aug 4 14:35:35 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 4 Aug 2005 14:35:35 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: <8D207816-37CA-4F7C-B429-9A322BC1D6EB@dreskin.net> References: <20050803184445.GF1007@smtp.paip.net> <20050804130905.GK1007@smtp.paip.net> <8D207816-37CA-4F7C-B429-9A322BC1D6EB@dreskin.net> Message-ID: <20050804183535.GO1007@smtp.paip.net> On Thu, Aug 04, 2005 at 01:36:01PM -0400, Evan Schoenberg wrote: > Currently: > OTR session with Alice > I exit my client (without selecting End Private Conversation, which > is what happens with most users) > I reconnect > Alice says something. Her client is currently in the Private state, > with the previous secure session. > I get an encrypted message I can't read (sent using the encryption > from the old secure session). Note that this causes OTR to automatically restart if you're in Opportunistic mode. - Ian From ian at cypherpunks.ca Thu Aug 4 14:41:13 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 4 Aug 2005 14:41:13 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: <20050804183535.GO1007@smtp.paip.net> References: <20050803184445.GF1007@smtp.paip.net> <20050804130905.GK1007@smtp.paip.net> <8D207816-37CA-4F7C-B429-9A322BC1D6EB@dreskin.net> <20050804183535.GO1007@smtp.paip.net> Message-ID: <20050804184113.GP1007@smtp.paip.net> On Thu, Aug 04, 2005 at 02:35:35PM -0400, Ian Goldberg wrote: > On Thu, Aug 04, 2005 at 01:36:01PM -0400, Evan Schoenberg wrote: > > Currently: > > OTR session with Alice > > I exit my client (without selecting End Private Conversation, which > > is what happens with most users) > > I reconnect > > Alice says something. Her client is currently in the Private state, > > with the previous secure session. > > I get an encrypted message I can't read (sent using the encryption > > from the old secure session). > > Note that this causes OTR to automatically restart if you're in > Opportunistic mode. And I forgot to say: which will also cause Alice's message to get resent. That being said, it's arguably more correct for gaim to disconnect its contexts before exiting, and the patch is totally trivial, so I committed it to CVS. ;-) - Ian From evan.s at dreskin.net Thu Aug 4 14:48:38 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Thu, 4 Aug 2005 14:48:38 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: <20050804183535.GO1007@smtp.paip.net> References: <20050803184445.GF1007@smtp.paip.net> <20050804130905.GK1007@smtp.paip.net> <8D207816-37CA-4F7C-B429-9A322BC1D6EB@dreskin.net> <20050804183535.GO1007@smtp.paip.net> Message-ID: <40D74353-CB59-4DE4-9FCE-B95664D255BC@dreskin.net> On Aug 4, 2005, at 2:35 PM, Ian Goldberg wrote: > > Note that this causes OTR to automatically restart if you're in > Opportunistic mode. > Yes. Which is off by default in Adium because of repeated complaints about the whitespace trailing initial messages. People notice these things and get upset if you're forcing them into it -- I think Opportunistic is a perfect default for an external plugin (obviously anyone who downloads and installs OTRProxy or gaim-otr is wanting to use OTR with some regularity), but it's not good for the world's only client with built-in OTR (*grin*). Basically what I'd like, to put it differently, is a sort of Smart Opportunistic mode -- an Opportunistic that applies when in Manual Only mode after the secure session has been ended by one side but not the other. -Evan -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From evan.s at dreskin.net Thu Aug 4 14:56:13 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Thu, 4 Aug 2005 14:56:13 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: <20050804184113.GP1007@smtp.paip.net> References: <20050803184445.GF1007@smtp.paip.net> <20050804130905.GK1007@smtp.paip.net> <8D207816-37CA-4F7C-B429-9A322BC1D6EB@dreskin.net> <20050804183535.GO1007@smtp.paip.net> <20050804184113.GP1007@smtp.paip.net> Message-ID: <8C2F9DAA-37DF-46D2-A1DF-C587D169B030@dreskin.net> This just happened, thought it was clearly illustrate both the problem under discussion and a related issue: 2:45:31 PM OtherUser: brb OtherUser disconnected (2:45:32 PM) OtherUser connected (2:49:00 PM) 2:49:45 PM OtherUser: The following message received from OtherUser was not encrypted: [and we're back 2:49:52 PM tekjew: and this. 2:49:52 PM OtherUser: ?OTR Error: You sent encrypted data to OtherUser, who wasn't expecting it. 2:49:53 PM tekjew: is 2:49:53 PM OtherUser: ?OTR Error: You sent encrypted data to OtherUser, who wasn't expecting it. 2:49:54 PM tekjew: what 2:49:54 PM OtherUser: ?OTR Error: You sent encrypted data to OtherUser, who wasn't expecting it. 2:50:00 PM tekjew: I mean, Ian. 2:50:00 PM OtherUser: ?OTR Error: You sent encrypted data to OtherUser, who wasn't expecting it. Ended encrypted OTR chat. (2:50:02 PM) 2:50:03 PM OtherUser: ?OTR Error: You sent encrypted data to OtherUser, who wasn't expecting it. 2:50:07 PM tekjew: hehe 2:50:08 PM tekjew: perfect! 2:50:12 PM tekjew: thanks for letting me demo that :) So OtherUser quit and then reloaded. He sent me an unencrypted message... fine so far, that's to be expected. But when I sent "and this." I would have wanted the Magic Opportunistic (Private/Broken) mode to take effect and renegotiate a session. Note the other interesting oddity, though I can see why it would happen -- When I did click "End encrypted session" locally, the encrypted 'closed' packet was sent to OtherUser, and then I was told that I sent encrypted data. Most users would be very confused by this particular bit of information, since as far as they know they didn't send any data to the other user. -Evan On Aug 4, 2005, at 2:41 PM, Ian Goldberg wrote: > On Thu, Aug 04, 2005 at 02:35:35PM -0400, Ian Goldberg wrote: > >> On Thu, Aug 04, 2005 at 01:36:01PM -0400, Evan Schoenberg wrote: >> >>> Currently: >>> OTR session with Alice >>> I exit my client (without selecting End Private Conversation, which >>> is what happens with most users) >>> I reconnect >>> Alice says something. Her client is currently in the Private state, >>> with the previous secure session. >>> I get an encrypted message I can't read (sent using the encryption >>> from the old secure session). >>> >> >> Note that this causes OTR to automatically restart if you're in >> Opportunistic mode. >> > > And I forgot to say: which will also cause Alice's message to get > resent. > > That being said, it's arguably more correct for gaim to disconnect its > contexts before exiting, and the patch is totally trivial, so I > committed it to CVS. ;-) > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From gdt at ir.bbn.com Mon Aug 8 09:05:13 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: 08 Aug 2005 09:05:13 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: <40D74353-CB59-4DE4-9FCE-B95664D255BC@dreskin.net> References: <20050803184445.GF1007@smtp.paip.net> <20050804130905.GK1007@smtp.paip.net> <8D207816-37CA-4F7C-B429-9A322BC1D6EB@dreskin.net> <20050804183535.GO1007@smtp.paip.net> <40D74353-CB59-4DE4-9FCE-B95664D255BC@dreskin.net> Message-ID: I presume that in Adium one can enable/disable OTR (much like the plugin in gaim) and that when enabled it does opportunistic exchanges. It would be nice to be able to set per-user OTR policy to require or opportunistic or none, so that the one can enable OTR in general and then turn off opportunistic for those correspondents that don't like it. I agree that the current send-with-old-key, get nack, KEX, resend behavior does much the same as what I'm asking for, but a) it shows the user 'unreadable message received' b) it results in sent but unreadable messages for machines that should have been private/broken but are offline. Ian: thanks for putting that fix into cvs. -- Greg Troxel From evan.s at dreskin.net Mon Aug 8 12:01:06 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Mon, 8 Aug 2005 12:01:06 -0400 Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: References: <20050803184445.GF1007@smtp.paip.net> <20050804130905.GK1007@smtp.paip.net> <8D207816-37CA-4F7C-B429-9A322BC1D6EB@dreskin.net> <20050804183535.GO1007@smtp.paip.net> <40D74353-CB59-4DE4-9FCE-B95664D255BC@dreskin.net> Message-ID: <03D31E0B-5F23-426C-AEA3-AC2DE1335EC7@dreskin.net> On Aug 8, 2005, at 9:05 AM, Greg Troxel wrote: > I presume that in Adium one can enable/disable OTR (much like the > plugin in gaim) > You could set the policy to Never and not click the OTR button. You can't disable it. > and that when enabled it does opportunistic > exchanges. > The default is equivalent to the Manual policy. You can set it to be opportunistic... > It would be nice to be able to set per-user OTR policy to > require or opportunistic or none, so that the one can enable OTR in > general and then turn off opportunistic for those correspondents that > don't like it. > You can. > I agree that the current send-with-old-key, get nack, KEX, resend > behavior does much the same as what I'm asking for, but > > a) it shows the user 'unreadable message received' > > b) it results in sent but unreadable messages for machines that should > have been private/broken but are offline. > > Right -- decidedly confusing for most users, and avoidable as we discussed previously, I think. -Evan > Ian: thanks for putting that fix into cvs. > > > > -- > Greg Troxel > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From alex323 at gmail.com Mon Aug 8 14:41:26 2005 From: alex323 at gmail.com (Alex) Date: Mon, 08 Aug 2005 14:41:26 -0400 Subject: [OTR-dev] Seg fault in otr_parse Message-ID: <42F7A756.7080608@gmail.com> Try entering this into otr_parse and see what happens ;) ?OTR:AAEDAAAAAQAAAAEAAADAQlmXvP+eeXWzF7z4UVVG5ReFFEerkfZDTEvEAEeFoghpJxQoVSp5ykTSBoO/bkB1IbRVy2d+PpU/0NBq5b99WDOgaeRfM2jAwo9TfCa0gCxcz8fWNe3aDuRkb0/291C1OoyVMC1wfAn8QafkLaGCqjpogCRs74IwCAJq0h9OvaPzIuuwhWTfGdjkGrIJiTimMhLh+3hXxEcpJgoL/PZoEr54TmF/iUyH7+M7u46shTc0mKdLOMKRWnfHycNu7HrNAAAAAAAAAAEAAAAQ/+v5ll994dU1J5KfL4Kl9kqXwAAepOvU2Lv8f+LKEKFbc7sNAAAAAQA=. It makes an 'infinate' loop when it tries to output all of the mac's stored. [snip] Key 6666: 0000000000000000000000000000000000000000 Key 6667: 0000000000000000000000000000000000000000 Key 6668: 0000000000000000000000000000000000000000 Key 6669: 0000000000000000000000000000000000000000 Key 6670: 0000000000000000000000000000000000000000 Key 6671: 0000000000000000000000000000000000000000 Key 6672: 0000000000000000000000000000000000000000 Segmentation fault alex at ninjutsu ~ $ - Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: OpenPGP digital signature URL: From ian at cypherpunks.ca Mon Aug 8 16:55:44 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 8 Aug 2005 16:55:44 -0400 Subject: [OTR-dev] Seg fault in otr_parse In-Reply-To: <42F7A756.7080608@gmail.com> References: <42F7A756.7080608@gmail.com> Message-ID: <20050808205544.GY1007@smtp.paip.net> On Mon, Aug 08, 2005 at 02:41:26PM -0400, Alex wrote: > Try entering this into otr_parse and see what happens ;) > > ?OTR:AAEDAAAAAQAAAAEAAADAQlmXvP+eeXWzF7z4UVVG5ReFFEerkfZDTEvEAEeFoghpJxQoVSp5ykTSBoO/bkB1IbRVy2d+PpU/0NBq5b99WDOgaeRfM2jAwo9TfCa0gCxcz8fWNe3aDuRkb0/291C1OoyVMC1wfAn8QafkLaGCqjpogCRs74IwCAJq0h9OvaPzIuuwhWTfGdjkGrIJiTimMhLh+3hXxEcpJgoL/PZoEr54TmF/iUyH7+M7u46shTc0mKdLOMKRWnfHycNu7HrNAAAAAAAAAAEAAAAQ/+v5ll994dU1J5KfL4Kl9kqXwAAepOvU2Lv8f+LKEKFbc7sNAAAAAQA=. > > It makes an 'infinate' loop when it tries to output all of the mac's stored. Well caught. It was only the printing routine that was in error; it went into an infinite loop when it encountered a malformed Data Message with a revealed MAC key length which wasn't a multiple of 20 bytes. Fixed in CVS. - Ian From rabbi at abditum.com Fri Aug 12 19:38:59 2005 From: rabbi at abditum.com (Len Sassaman) Date: Fri, 12 Aug 2005 16:38:59 -0700 (PDT) Subject: [OTR-dev] Flaw in OTR Protocol (with workaround!) In-Reply-To: <8C2F9DAA-37DF-46D2-A1DF-C587D169B030@dreskin.net> References: <20050803184445.GF1007@smtp.paip.net> <20050804130905.GK1007@smtp.paip.net> <8D207816-37CA-4F7C-B429-9A322BC1D6EB@dreskin.net> <20050804183535.GO1007@smtp.paip.net> <20050804184113.GP1007@smtp.paip.net> <8C2F9DAA-37DF-46D2-A1DF-C587D169B030@dreskin.net> Message-ID: (Sorry for top-posting...) This brings up a similar UI annoyance that I keep encountering. There is a frequent error message that occurs, saying "User has sent a malformed message." This error message is displayed to both parties after every transmission, and the only way I've found to eliminate it is to have both parties restart otrproxy. Perhaps we need to look at improving the quality of the error messages (things like "you've sent a malformed message" don't really make sense to most users, and certainly don't give any hint as to what to do about it -- what's the threat? what's the solution? Even I can't figure that out) as well as improving the delivery of the error messages. There has to be some other method of presenting warnings to the user without making the IM program effectively unusable, unless that's the goal, in which case, the IM client shouldn't be allowed to send messages out in the first place. Perhaps otrproxy pop-up windows are a better place to put these sorts of messages. --Len. On Thu, 4 Aug 2005, Evan Schoenberg wrote: > This just happened, thought it was clearly illustrate both the > problem under discussion and a related issue: > > > 2:45:31 PM OtherUser: brb > OtherUser disconnected (2:45:32 PM) > OtherUser connected (2:49:00 PM) > 2:49:45 PM OtherUser: The following message received from OtherUser > was not encrypted: [and we're back > 2:49:52 PM tekjew: and this. > 2:49:52 PM OtherUser: ?OTR Error: You sent encrypted data to > OtherUser, who wasn't expecting it. > 2:49:53 PM tekjew: is > 2:49:53 PM OtherUser: ?OTR Error: You sent encrypted data to > OtherUser, who wasn't expecting it. > 2:49:54 PM tekjew: what > 2:49:54 PM OtherUser: ?OTR Error: You sent encrypted data to > OtherUser, who wasn't expecting it. > 2:50:00 PM tekjew: I mean, Ian. > 2:50:00 PM OtherUser: ?OTR Error: You sent encrypted data to > OtherUser, who wasn't expecting it. > Ended encrypted OTR chat. (2:50:02 PM) > 2:50:03 PM OtherUser: ?OTR Error: You sent encrypted data to > OtherUser, who wasn't expecting it. > 2:50:07 PM tekjew: hehe > 2:50:08 PM tekjew: perfect! > 2:50:12 PM tekjew: thanks for letting me demo that :) > > So OtherUser quit and then reloaded. He sent me an unencrypted > message... fine so far, that's to be expected. But when I sent "and > this." I would have wanted the Magic Opportunistic (Private/Broken) > mode to take effect and renegotiate a session. > > Note the other interesting oddity, though I can see why it would > happen -- When I did click "End encrypted session" locally, the > encrypted 'closed' packet was sent to OtherUser, and then I was told > that I sent encrypted data. Most users would be very confused by > this particular bit of information, since as far as they know they > didn't send any data to the other user. > > -Evan > > > On Aug 4, 2005, at 2:41 PM, Ian Goldberg wrote: > > > On Thu, Aug 04, 2005 at 02:35:35PM -0400, Ian Goldberg wrote: > > > >> On Thu, Aug 04, 2005 at 01:36:01PM -0400, Evan Schoenberg wrote: > >> > >>> Currently: > >>> OTR session with Alice > >>> I exit my client (without selecting End Private Conversation, which > >>> is what happens with most users) > >>> I reconnect > >>> Alice says something. Her client is currently in the Private state, > >>> with the previous secure session. > >>> I get an encrypted message I can't read (sent using the encryption > >>> from the old secure session). > >>> > >> > >> Note that this causes OTR to automatically restart if you're in > >> Opportunistic mode. > >> > > > > And I forgot to say: which will also cause Alice's message to get > > resent. > > > > That being said, it's arguably more correct for gaim to disconnect its > > contexts before exiting, and the patch is totally trivial, so I > > committed it to CVS. ;-) > > > > - Ian > > _______________________________________________ > > OTR-dev mailing list > > OTR-dev at lists.cypherpunks.ca > > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > > > > --Len. From alex323 at gmail.com Mon Aug 22 11:29:45 2005 From: alex323 at gmail.com (Alex) Date: Mon, 22 Aug 2005 11:29:45 -0400 Subject: [OTR-dev] Problem with task bar icon and new private conversations Message-ID: <4309EF69.2080703@gmail.com> In gaim (1.4.0 at the time of this writing) I have the option of making the icon in the taskbar flash when I receive a new message. In the case of an OTR key exchange, the message dialog just pops up out of no where with this message: (11:25:38) *Private conversation with dosirc started.* I was wondering if there was some way of making the icon flash when a new private conversation is started. I am currently using the CVS version of gaim-otr and libotr. - Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: OpenPGP digital signature URL: From kenta at MIT.EDU Thu Aug 25 20:01:23 2005 From: kenta at MIT.EDU (Ken T Takusagawa) Date: Thu, 25 Aug 2005 20:01:23 -0400 (EDT) Subject: [OTR-dev] configure CFLAGS LIBOTR_CFLAGS Message-ID: There is something wrong going on in the configure script approximately line 19203 CFLAGS="$libotr_save_CFLAGS" clobbers the -I$libotr_inc_prefix value so that next compile fails.