From ian@cypherpunks.ca Wed Aug 3 19:44:45 2005 From: ian@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@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@entermail.net Wed Aug 3 20:08:23 2005 From: arodland@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> --nextPart2195853.U4kOyMcoOx Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=20 client (or go away for a day), implicitly resetting my session, while my=20 buddy stays online, and later sends me an encrypted message I can't read. H= ow=20 about: 1. Alice sends "End Session" request and tears down her session. No further= =20 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=20 confirm his awareness of this [1]. 3. Any messages that Bob sends to Alice before confirming the end-of-sessio= n=20 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,= =20 i.e. "Alice12345 has ended the secure session. Please type OTR2i94hd to=20 confirm.", or by hijacking the OTR privacy widget on clients that have it; = a=20 status message is produced and the widget changes from "OTR: Private" to=20 "OTR: Locked"; clicking the widget changes it to "OTR: Not Private". =2D- Andrew Rodland --nextPart2195853.U4kOyMcoOx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBC8RYs6xdpaulLLFURAkBvAKCTLgyTXNMmW7amA5T5YiMelEKPOQCfXrLj 9HN0J1IFWyi4/cDAsJLCe9Q= =g5/x -----END PGP SIGNATURE----- --nextPart2195853.U4kOyMcoOx-- From ian@cypherpunks.ca Wed Aug 3 20:23:08 2005 From: ian@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@entermail.net Wed Aug 3 20:38:32 2005 From: arodland@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> --nextPart2450515.996NpSVO8l Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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= =20 like to see it improved in certain UI-related ways, but now that I know wha= t=20 I'm talking about, it's no longer a protocol-change issue :) Andrew --nextPart2450515.996NpSVO8l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBC8R0+6xdpaulLLFURAlUmAJ4ogPq65YJiM71RSHh4z4ADun7pDwCfaBwR n3NMZzNwwj4UCeFN0TaYOys= =8usr -----END PGP SIGNATURE----- --nextPart2450515.996NpSVO8l-- From ian@cypherpunks.ca Wed Aug 3 20:44:08 2005 From: ian@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@gmail.com Thu Aug 4 01:36:46 2005 From: alex323@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> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2A0F72FB4432AB59263FF27C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >>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@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 --------------enig2A0F72FB4432AB59263FF27C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQIVAwUBQvFjIoNsvbPFJtOPAQNfPg//RwTTZHWooH9ARhpr3gUfJZZPClCq+UlI 1uM/oubv3f0QTYbahaKrjXXO+H12Btuy1pWwHXwg+dDV2V0mXKaUBupdHUiYOfsV 091mLcTn5dSLR+80OtQGrAaH7NHcZLQ7imc4wOkdrC6VhYJYBW+kSsAqqECAfFGJ btRcSXOJzlOIzqvfeClxS7rckoxSvcFqfrLZhFqkTJYWma7uDxycsd972k/XtX+T NjbLXg2mIjdnZAQT//PLByYG2J+xkb4LvCTF70wolSrDNcaH4cOf0kwz2SN6eMAm WomCpy9cEaXYheJ4NdmhBeWBZXGiFBJD2Yl0EFWC37HCbqu2tm5QFJHxdo5WgZI9 /G8NXxwnrkOmdqY1hEJsGYyOpJdpm/Hzcm9DpGGojsOc0aztN2bNoQnQ7qKQEXLm dVONnCY/JGI46iVTDCAlJyOcdYuEWEF1x1epUYBZumDbIOj4+x15JnhvF7Fu4hcd 90uC8akCGRZE/Mm4sooMUgkhGwsaceXmGA5HJKodEkS14YGxCRHwUQShcNyrbg/d po9X8vA2Oj9wvux7sw/I3IuyUhUeei3OI+7e94xRkf+4GoBy3OiV1jBpOr2alXbD e0GOqVmdNcR/dzFNlRctxkCGjCNBfrJUfzgcLycKnPCCtYULZ3iI0gNJPFoXlKTx xgdorkm5Epw= =l+WD -----END PGP SIGNATURE----- --------------enig2A0F72FB4432AB59263FF27C-- From gdt@ir.bbn.com Thu Aug 4 13:07:10 2005 From: gdt@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@ir.bbn.com Thu Aug 4 13:19:02 2005 From: gdt@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@cypherpunks.ca Thu Aug 4 13:25:06 2005 From: ian@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@cypherpunks.ca Thu Aug 4 14:09:05 2005 From: ian@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@ir.bbn.com Thu Aug 4 14:18:35 2005 From: gdt@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@cypherpunks.ca Thu Aug 4 14:41:34 2005 From: ian@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@paip.net Thu Aug 4 14:54:27 2005 From: kat@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@ir.bbn.com Thu Aug 4 15:29:45 2005 From: gdt@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@ir.bbn.com Thu Aug 4 15:39:27 2005 From: gdt@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@cypherpunks.ca Thu Aug 4 18:00:59 2005 From: ian@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@ir.bbn.com Thu Aug 4 18:34:56 2005 From: gdt@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@dreskin.net Thu Aug 4 18:36:01 2005 From: evan.s@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> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-22-988357401 Content-Type: multipart/alternative; boundary=Apple-Mail-21-988357127 --Apple-Mail-21-988357127 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed 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 --Apple-Mail-21-988357127 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
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.=A0 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.=A0 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.=A0 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.=A0 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.=A0 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?

www.adiumx.com


= --Apple-Mail-21-988357127-- --Apple-Mail-22-988357401 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC8lICI5gp6xQhrvcRApTMAJ9H/JJuhckZsuiIbjaXg7PjaObK4gCfaoGq l4giwBBScc/ahpLAqMQjLNY= =9DZH -----END PGP SIGNATURE----- --Apple-Mail-22-988357401-- From ian@cypherpunks.ca Thu Aug 4 19:35:35 2005 From: ian@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@cypherpunks.ca Thu Aug 4 19:41:13 2005 From: ian@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@dreskin.net Thu Aug 4 19:48:38 2005 From: evan.s@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> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-28-992714496 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed 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 --Apple-Mail-28-992714496 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC8mMHI5gp6xQhrvcRAlKnAJ9IOg+v47NTy2rOYl02UtYl6SySYgCgnvZW Or/N9jix3huXmDgNdFDn3yE= =7C7S -----END PGP SIGNATURE----- --Apple-Mail-28-992714496-- From evan.s@dreskin.net Thu Aug 4 19:56:13 2005 From: evan.s@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 is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-30-993169538 Content-Type: multipart/alternative; boundary=Apple-Mail-29-993169161 --Apple-Mail-29-993169161 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed 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@lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > --Apple-Mail-29-993169161 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
This just = happened, thought it was clearly illustrate both the problem under = discussion and a related issue:

<I'm in an = OTR session with OtherUser, both of us are on Manual>
2:45:31 PM=A0OtherUser: brb
OtherUser disconnected (2:45:32 PM)
OtherUser=A0connected (2:49:00 PM)
2:49:45 PM=A0OtherUser: The following = message received from=A0OtherUser was not = encrypted: [and we're back
2:49:52 PM tekjew: and = this.
2:49:52 PM=A0OtherUser: ?OTR Error: You = sent encrypted data to OtherUser, who wasn't expecting it.
2:49:53 PM tekjew: is
2:49:53 = PM=A0OtherUser: = ?OTR Error: You sent encrypted data to OtherUser, who wasn't = expecting it.
2:49:54 PM tekjew: what
2:49:54 = PM=A0OtherUser: = ?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=A0OtherUser: ?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=A0OtherUser: ?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=A0OtherUs= er quit and then reloaded.=A0 He sent me an unencrypted message... fine = so far, that's to be expected.=A0 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.=A0 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 =A0
is what = happens with most users)
I = reconnect
Alice says something.=A0 Her client is currently in = the Private state, =A0
with the = previous secure session.
I get an = encrypted message I can't read (sent using the encryption =A0
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.=A0 ;-)

=A0=A0 - Ian
OTR-dev mailing list



= --Apple-Mail-29-993169161-- --Apple-Mail-30-993169538 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC8mTOI5gp6xQhrvcRAmVlAKChVTNdnq1CRWXamJA8my+xCu4MngCfXd6W etOBuouV45YNpAD8fCivEUY= =8R50 -----END PGP SIGNATURE----- --Apple-Mail-30-993169538-- From gdt@ir.bbn.com Mon Aug 8 14:05:13 2005 From: gdt@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@dreskin.net Mon Aug 8 17:01:06 2005 From: evan.s@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> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2--819220617 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed 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 > > > --Apple-Mail-2--819220617 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC94HDI5gp6xQhrvcRAj+xAJ0Yc9M2FEP2hwzkok0cPTRQGaW75QCeOxVD q6AjEFWmXIRKmzcZU//n/5Y= =nnsY -----END PGP SIGNATURE----- --Apple-Mail-2--819220617-- From alex323@gmail.com Mon Aug 8 19:41:26 2005 From: alex323@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> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0B5F73D40E77990689C7E62D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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@ninjutsu ~ $ - Alex --------------enig0B5F73D40E77990689C7E62D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQIVAwUBQvenWoNsvbPFJtOPAQOu1g/8CUo6/nIbahVbirnkKs7lAMTAYP+5/RB+ rc3DKh0flVozf7bEC38IEcZzA6hQhdmMSx8RtZSJT94Z9idJE4JX63U5Coq5YyIe gxDFUo4VH/ZzuUFBmSPZenzP8xN16KgF84ZuxqNiOG+0FUfQj6yq6qni6ng+Lt+2 W22lqyV8EehYnCrNDNYKnZN/OoJ6Tm7yL1Zem4dmrERjbvKLl/9l4bywD1p6I1ej EGUyncugqn8rsZM60iKxGVWYdriiNF0oDbXhzxNZmhdbvhgpD8FXhw9pTMvjXnSz EMp0xg7XGgekfD1vOJAHE+1Ke7zxCfmliZYz5EbwGKhKoPUooJ+NUDglIQGj7P7F ezX+zYmCCmCC2itplzH1oI8ca35mACT29fAEdFRpbBPPVyx2WYYKr21+Hxxm2usp MI9keOHsyfYeBS0oSDFp5OF0HK5f+PcTT5EAvyNqQF4htffOElWYhz8H7moKu0C8 UV8vEtXqoTMfgjwLwyduMS8EajG2Lpj4cCmonXRZVjAzTO3gjXPdpX5e97L2nula iztOe1cAkM66272S6/jBCQrEF/l7X2P1+PW1chc4zKTM0jbs62wz+/rAZeNIK7lc nSKzAK0ywOJG01Y4h0JcVEG8H2oukSffhm7qVcPu0C7xObRjLSUZCalKTIY163Ga u9QHNXoQ30Q= =XUel -----END PGP SIGNATURE----- --------------enig0B5F73D40E77990689C7E62D-- From ian@cypherpunks.ca Mon Aug 8 21:55:44 2005 From: ian@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@abditum.com Sat Aug 13 00:38:59 2005 From: rabbi@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@lists.cypherpunks.ca > > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > > > > --Len. From alex323@gmail.com Mon Aug 22 16:29:45 2005 From: alex323@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> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig125B71017D377414A3426D7D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 --------------enig125B71017D377414A3426D7D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iQIVAwUBQwnvboNsvbPFJtOPAQPQIg//cQIPLCK1qKLoUqf4H5maeJvbfBLRkvlY 33aCDdimTNb2iPwKoq1a6DHBWf3J4ITm+CPFp5r7FKwh9uiCgyOKLW6L4ul9+5yG W3dfWxchbir/cA+dzVQ3xgwhYiucoFh0jTX3M0VoPuTL8wjU6AjAsDiPULMTXIAh fWZ//7y1L0w0EkOx9wjeA36FlP4joe4+6dDVTB01htnOma8ddwEfy2Cvnf1iW/eN ggY2ZQsiIYmrv8inH0FrJlHmG0+6JYrWDpDK8luT02pEHEfHA1/HDLDCy1Nt02pZ wi95xUA9ebGOu/gegA6F1AapeG+CHC02NwEsElOWzEaAucoLTwwPG1I0ouWkMvfa YD0jdxExSo45qYX8fhoABmh8pTBTR1LoT1+Q0E1nLLQs9des3uQaMLAPyQ6w+bal PvvEFJXczt0tXpHfIVX2nEVrpKw++GYArTW/VECf6Hldhswgsekbcn19JnPQxqvO 8533Mg6496jgIe+1vdUmz4SNA6IuXL8BTX/cavb7FzJWCA9FwIOWAZyrKCK3Zsl8 mOT81OpcfrP8QKfJr7GSkbFVE852TGvpbJwdrwAbk2AYIP8ssiK+9GCPL1UNgzYf 4WXh6n0jsY13FqB+2fOHd1c4GtdT3Gc/TrvOlfcav3iKrZE4ykrJcdQzUGxvpu7u 3V6YTdaCUpw= =dUOj -----END PGP SIGNATURE----- --------------enig125B71017D377414A3426D7D-- From kenta@MIT.EDU Fri Aug 26 01:01:23 2005 From: kenta@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.