From alex323 at gmail.com  Sun Apr  4 19:23:34 2010
From: alex323 at gmail.com (Alex)
Date: Sun, 4 Apr 2010 19:23:34 -0400
Subject: [OTR-users] OTR transport protocol?
Message-ID: <20100404192334.0bd765eb@gmail.com>

Hi. Would there be any use for an implementation of OTR in a way
similar to that of TLS?

-- 
Alex


From ian at cypherpunks.ca  Sun Apr  4 19:48:27 2010
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Sun, 4 Apr 2010 19:48:27 -0400
Subject: [OTR-users] OTR transport protocol?
In-Reply-To: <20100404192334.0bd765eb@gmail.com>
References: <20100404192334.0bd765eb@gmail.com>
Message-ID: <20100404234827.GU16932@yoink.cs.uwaterloo.ca>

On Sun, Apr 04, 2010 at 07:23:34PM -0400, Alex wrote:
> Hi. Would there be any use for an implementation of OTR in a way
> similar to that of TLS?

Good question.

TLS already has the ability to do perfect forward secrecy by using one
of the ephemeral Diffie-Helman ciphersuites.  It does mutual
authentication using certificates, but I've seen proposals to include
PAKE, and even SMP, into TLS.  One would have to figure out exactly what
deniability/repudiation properties one was looking for to see if TLS
could be coaxed into doing that.

That said, if you squint in the right way, you could pretend that
today's OTR was indeed a transport-level protocol, since you can send
arbitrary packetized TCP streams over it.  (You'd have to remove the
specification of how to interpret the decrypted message, though.)
Its utility would be quite different from TLS, though, since it's mainly
useful for connecting people who know (and can authenticate) each other,
whereas TLS can connect strangers, proving they trust the
PKI-in-the-sky. (See, for example, http://government.zdnet.com/?p=8257 )

   - Ian


From alex323 at gmail.com  Sun Apr  4 21:24:48 2010
From: alex323 at gmail.com (Alex)
Date: Sun, 4 Apr 2010 21:24:48 -0400
Subject: [OTR-users] OTR transport protocol?
In-Reply-To: <20100404234827.GU16932@yoink.cs.uwaterloo.ca>
References: <20100404192334.0bd765eb@gmail.com>
	<20100404234827.GU16932@yoink.cs.uwaterloo.ca>
Message-ID: <20100404212448.261e0aec@gmail.com>

On Sun, 4 Apr 2010 19:48:27 -0400
Ian Goldberg <ian at cypherpunks.ca> wrote:

> On Sun, Apr 04, 2010 at 07:23:34PM -0400, Alex wrote:
> > Hi. Would there be any use for an implementation of OTR in a way
> > similar to that of TLS?
> 
> Good question.
> 
> TLS already has the ability to do perfect forward secrecy by using one
> of the ephemeral Diffie-Helman ciphersuites.  It does mutual
> authentication using certificates, but I've seen proposals to include
> PAKE, and even SMP, into TLS.  One would have to figure out exactly
> what deniability/repudiation properties one was looking for to see if
> TLS could be coaxed into doing that.
> 
> That said, if you squint in the right way, you could pretend that
> today's OTR was indeed a transport-level protocol, since you can send
> arbitrary packetized TCP streams over it.  (You'd have to remove the
> specification of how to interpret the decrypted message, though.)
> Its utility would be quite different from TLS, though, since it's
> mainly useful for connecting people who know (and can authenticate)
> each other, whereas TLS can connect strangers, proving they trust the
> PKI-in-the-sky. (See, for example,
> http://government.zdnet.com/?p=8257 )
> 

What do you think of a bank whose branch-employees hand out business
cards containing a fingerprint for use with OTR? The user can go home
and visit the bank's website (using an OTR transport mechanism), at
which point a dialog would ask them if they want to trust the given
fingerprint or not. They can compare it to what is on the business card,
and the server can be authenticated.

The bank's servers (seeing that you are unverified) can ask you a
question only you would know via the shared-secret OTR feature. After
this point, your fingerprint would become trusted on the bank's end and
you won't have to go through that again unless you lose access to the
key (by using a different computer, etc).

Assuming that the code for this was written and incorporated in to
most browsers/OSs, this would be very practical solution to the root
CA problem described in the zdnet article above.

One potential issue is that people are terribly passive and complacent,
and they think that if they aren't doing anything wrong that they have
nothing to hide. I guess we can't code away those problems.

-- 
Alex


From ian at cypherpunks.ca  Mon Apr  5 15:53:38 2010
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Mon, 5 Apr 2010 15:53:38 -0400
Subject: [OTR-users] OTR transport protocol?
In-Reply-To: <20100404212448.261e0aec@gmail.com>
References: <20100404192334.0bd765eb@gmail.com>
	<20100404234827.GU16932@yoink.cs.uwaterloo.ca>
	<20100404212448.261e0aec@gmail.com>
Message-ID: <20100405195338.GB16381@thunk.cs.uwaterloo.ca>

On Sun, Apr 04, 2010 at 09:24:48PM -0400, Alex wrote:
> On Sun, 4 Apr 2010 19:48:27 -0400
> Ian Goldberg <ian at cypherpunks.ca> wrote:
> 
> > On Sun, Apr 04, 2010 at 07:23:34PM -0400, Alex wrote:
> > > Hi. Would there be any use for an implementation of OTR in a way
> > > similar to that of TLS?
> > 
> > Good question.
> > 
> > TLS already has the ability to do perfect forward secrecy by using one
> > of the ephemeral Diffie-Helman ciphersuites.  It does mutual
> > authentication using certificates, but I've seen proposals to include
> > PAKE, and even SMP, into TLS.  One would have to figure out exactly
> > what deniability/repudiation properties one was looking for to see if
> > TLS could be coaxed into doing that.
> > 
> > That said, if you squint in the right way, you could pretend that
> > today's OTR was indeed a transport-level protocol, since you can send
> > arbitrary packetized TCP streams over it.  (You'd have to remove the
> > specification of how to interpret the decrypted message, though.)
> > Its utility would be quite different from TLS, though, since it's
> > mainly useful for connecting people who know (and can authenticate)
> > each other, whereas TLS can connect strangers, proving they trust the
> > PKI-in-the-sky. (See, for example,
> > http://government.zdnet.com/?p=8257 )
> > 
> 
> What do you think of a bank whose branch-employees hand out business
> cards containing a fingerprint for use with OTR? The user can go home
> and visit the bank's website (using an OTR transport mechanism), at
> which point a dialog would ask them if they want to trust the given
> fingerprint or not. They can compare it to what is on the business card,
> and the server can be authenticated.
> 
> The bank's servers (seeing that you are unverified) can ask you a
> question only you would know via the shared-secret OTR feature. After
> this point, your fingerprint would become trusted on the bank's end and
> you won't have to go through that again unless you lose access to the
> key (by using a different computer, etc).
> 
> Assuming that the code for this was written and incorporated in to
> most browsers/OSs, this would be very practical solution to the root
> CA problem described in the zdnet article above.
> 
> One potential issue is that people are terribly passive and complacent,
> and they think that if they aren't doing anything wrong that they have
> nothing to hide. I guess we can't code away those problems.

I think most people understand that their banking should be protected.

Your example use case doesn't involve deniability/repudiation or forward
secrecy, so it would seem to be just as good with normal TLS:

The bank hands out its TLS cert's (really its public key's) fingerprint
in its branch.  Users generate self-signed client certs, and associate
the fingerprint of that cert to their account via some secret known only
to them.

Then the only browser change would have to be "for these vital websites,
I'm going to type in the public key fingerprint manually, rather than
trusting a CA".

I bet no one would do it, though.

A friend of mine actually called his bank one day and asked to verify
the fingerprint of the (then SSL) certificate.  He was completely unable
to speak to anyone who knew what he was talking about.

   - Ian


From matthias.andree at gmx.de  Sat Apr 24 06:54:37 2010
From: matthias.andree at gmx.de (Matthias Andree)
Date: Sat, 24 Apr 2010 12:54:37 +0200
Subject: [OTR-users] Request: Pidgin plugin should request refresh if other
	user offline
Message-ID: <op.vbnxxbmj1e62zd@merlin.emma.line.org>

Here's the situation:

0. Linux Pidgin with 3.2.0 otr plugin on either end, using Jabber.

1. Users Alice and Bob negotiate a secure connection and chat for a while.
2. Bob logs off
3. Alice sends a message, which gets encrypted because of (1)
4. Bob logs on from a different machine and sees there was an encrypted
message he couldn't decrypt.
=> boom.

I think I recall that under such circumstances, the overall setup at one
point used to automatically retransmit Alice's message after
re-negotiating the encryption, but this doesn't happen here.

Proposal: the plugin should tell Alice that Bob has disconnected and she
should terminate the private conversation and re-establish it.

Thank you.

-- 
Matthias Andree


From ian at cypherpunks.ca  Sat Apr 24 17:15:29 2010
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Sat, 24 Apr 2010 17:15:29 -0400
Subject: [OTR-users] Request: Pidgin plugin should request refresh
	if	other user offline
In-Reply-To: <op.vbnxxbmj1e62zd@merlin.emma.line.org>
References: <op.vbnxxbmj1e62zd@merlin.emma.line.org>
Message-ID: <20100424211529.GZ27515@yoink.cs.uwaterloo.ca>

On Sat, Apr 24, 2010 at 12:54:37PM +0200, Matthias Andree wrote:
> Here's the situation:
>
> 0. Linux Pidgin with 3.2.0 otr plugin on either end, using Jabber.
>
> 1. Users Alice and Bob negotiate a secure connection and chat for a while.
> 2. Bob logs off
> 3. Alice sends a message, which gets encrypted because of (1)
> 4. Bob logs on from a different machine and sees there was an encrypted
> message he couldn't decrypt.
> => boom.
>
> I think I recall that under such circumstances, the overall setup at one
> point used to automatically retransmit Alice's message after
> re-negotiating the encryption, but this doesn't happen here.
>
> Proposal: the plugin should tell Alice that Bob has disconnected and she
> should terminate the private conversation and re-establish it.

Hmm.  That's supposed to be what happens now.  When Bob logs off in step
2, his pidgin is supposed to send messages to all of his OTR
conversations informing the other side that he's disconnected.  That's
when Alice should see the "Bob has terminated his OTR conversation; you
should do the same" message, and Alice's side switches to Finished.

Now if Bob *crashes* in step 2, I agree that the offline-stored message
Alice sends in step 3 won't be readable by Bob if Bob has discarded his
session.  That's the intended behaviour.

   - Ian


From matthias.andree at gmx.de  Sun Apr 25 06:30:32 2010
From: matthias.andree at gmx.de (Matthias Andree)
Date: Sun, 25 Apr 2010 12:30:32 +0200
Subject: [OTR-users] Request: Pidgin plugin should request refresh if
 other user offline
In-Reply-To: <20100424211529.GZ27515@yoink.cs.uwaterloo.ca>
References: <op.vbnxxbmj1e62zd@merlin.emma.line.org>
	<20100424211529.GZ27515@yoink.cs.uwaterloo.ca>
Message-ID: <20100425103032.GA8469@merlin.emma.line.org>

On Sat, 24 Apr 2010, Ian Goldberg wrote:

> On Sat, Apr 24, 2010 at 12:54:37PM +0200, Matthias Andree wrote:
> > Here's the situation:
> >
> > 0. Linux Pidgin with 3.2.0 otr plugin on either end, using Jabber.
> >
> > 1. Users Alice and Bob negotiate a secure connection and chat for a while.
> > 2. Bob logs off
> > 3. Alice sends a message, which gets encrypted because of (1)
> > 4. Bob logs on from a different machine and sees there was an encrypted
> > message he couldn't decrypt.
> > => boom.
> >
> > I think I recall that under such circumstances, the overall setup at one
> > point used to automatically retransmit Alice's message after
> > re-negotiating the encryption, but this doesn't happen here.
> >
> > Proposal: the plugin should tell Alice that Bob has disconnected and she
> > should terminate the private conversation and re-establish it.
> 
> Hmm.  That's supposed to be what happens now.  When Bob logs off in step
> 2, his pidgin is supposed to send messages to all of his OTR
> conversations informing the other side that he's disconnected.  That's
> when Alice should see the "Bob has terminated his OTR conversation; you
> should do the same" message, and Alice's side switches to Finished.

That part works.

> Now if Bob *crashes* in step 2, I agree that the offline-stored message
> Alice sends in step 3 won't be readable by Bob if Bob has discarded his
> session.  That's the intended behaviour.

It may be the intended behavior with the protocol, but assume Alice is
really Aunt Tille, holds no MSc in Computer Science, and cannot be
bothered to remember that there is a difference between Bob finishing
the conversation and Bob logging off.

Can the OTR plugin notice that the chat partner has gone offline? If so,
that should also "Finish" the OTR conversation, or, if that is not
desireable, it should at least happen if Alice goes idle. Renegotiating
the keys after Alice went shopping for two hours would not hurt, would
it?

I understand that we do not want to send unencrypted messages in such
cases without warning. But "mandatory OTR" might allow us to at least
make sending messages impossible if Bob is offline.  Whether Bob cannot
decode or Alice cannot send, I'd clearly prefer the latter case.

Thanks for listening
Matthias


From ian at cypherpunks.ca  Sun Apr 25 20:06:58 2010
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Sun, 25 Apr 2010 20:06:58 -0400
Subject: [OTR-users] Request: Pidgin plugin should request refresh
	if	other user offline
In-Reply-To: <20100425103032.GA8469@merlin.emma.line.org>
References: <op.vbnxxbmj1e62zd@merlin.emma.line.org>
	<20100424211529.GZ27515@yoink.cs.uwaterloo.ca>
	<20100425103032.GA8469@merlin.emma.line.org>
Message-ID: <20100426000658.GH27515@yoink.cs.uwaterloo.ca>

On Sun, Apr 25, 2010 at 12:30:32PM +0200, Matthias Andree wrote:
> > 2, his pidgin is supposed to send messages to all of his OTR
> > conversations informing the other side that he's disconnected.  That's
> > when Alice should see the "Bob has terminated his OTR conversation; you
> > should do the same" message, and Alice's side switches to Finished.
> 
> That part works.
> 
> > Now if Bob *crashes* in step 2, I agree that the offline-stored message
> > Alice sends in step 3 won't be readable by Bob if Bob has discarded his
> > session.  That's the intended behaviour.
> 
> It may be the intended behavior with the protocol, but assume Alice is
> really Aunt Tille, holds no MSc in Computer Science, and cannot be
> bothered to remember that there is a difference between Bob finishing
> the conversation and Bob logging off.
> 
> Can the OTR plugin notice that the chat partner has gone offline? If so,
> that should also "Finish" the OTR conversation, or, if that is not
> desireable, it should at least happen if Alice goes idle. Renegotiating
> the keys after Alice went shopping for two hours would not hurt, would
> it?
> 
> I understand that we do not want to send unencrypted messages in such
> cases without warning. But "mandatory OTR" might allow us to at least
> make sending messages impossible if Bob is offline.  Whether Bob cannot
> decode or Alice cannot send, I'd clearly prefer the latter case.

The trouble is that some people go offline, but keep their pidgin
running, and so keep their session keys.  They *want* their messages to
remain readable when they get back online.  So we implemented the "if
you quit your pidgin, the OTR session will close; if you just go
offline, it won't" mechanism.

Personally, I'd prefer if IM networks didn't let you send messages to
offline parties, since they're not "instant"; that's what email is for.
But my personal preferences are neither here nor there.  ;-)

The way it is now, Bob ends up receiving a message from Alice he cannot
read -- and is informed of that fact; he could try to contact Alice to
find out what it was.  If Alice was unable to send the message, Bob
wouldn't even know that she tried.  Which is better?  I don't think it's
100% either way.

   - Ian


From gmaxwell at gmail.com  Sun Apr 25 20:20:54 2010
From: gmaxwell at gmail.com (Gregory Maxwell)
Date: Sun, 25 Apr 2010 20:20:54 -0400
Subject: [OTR-users] Request: Pidgin plugin should request refresh if
	other user offline
In-Reply-To: <20100426000658.GH27515@yoink.cs.uwaterloo.ca>
References: <op.vbnxxbmj1e62zd@merlin.emma.line.org>
	<20100424211529.GZ27515@yoink.cs.uwaterloo.ca>
	<20100425103032.GA8469@merlin.emma.line.org>
	<20100426000658.GH27515@yoink.cs.uwaterloo.ca>
Message-ID: <j2me692861c1004251720t4a913520wf36359b8b63b61d3@mail.gmail.com>

On Sun, Apr 25, 2010 at 8:06 PM, Ian Goldberg <ian at cypherpunks.ca> wrote:
> The trouble is that some people go offline, but keep their pidgin
> running, and so keep their session keys. ?They *want* their messages to
> remain readable when they get back online. ?So we implemented the "if

This brings up a minor peeve of mine, ? not a significant enough one
that that I've felt like fixing it myself but:

Far end logs off cleanly.  OTR shuts down.   Later I come back and
type into the IM window. The message doesn't send, instead it just
outputs a notice that OTR was shut down.   I can happily type into
this box for sometime before noticing that it's not working.  Worse?
I've lost what I wrote because the text doesn't appear in the history.

I totally get and appreciate that you don't want one side thinking the
channel is OTR protected and blabbering away into a clear-text
deactivated stream.  ... and that messages which are never sent should
probably not show up in the history  (otherwise I might never notice
that my messages are not going out! :) )....

But?  could it just attempt to initiate a new session in this case?
then send the message, and not bother me with the fact that the other
side logged out at all?

Obviously this could result in the far end getting OTR spam that they
can't handle until I shut the session, but even in that worst case it
is no more work than what I have to do now for every case. The
OTR-spam issue also already exists if the far end changes clients
without shutting down, so this wouldn't really make it any worse.

I could see security issue if a e.g. a known contact logs off and
someone else logs on with their account from another client, and you
don't notice.   But if they logged off uncleanly OTR will happily
renegotiate as it...


From matthias.andree at gmx.de  Mon Apr 26 09:38:12 2010
From: matthias.andree at gmx.de (Matthias Andree)
Date: Mon, 26 Apr 2010 15:38:12 +0200
Subject: [OTR-users] Request: Pidgin plugin should request refresh	if
 other user offline
In-Reply-To: <20100426000658.GH27515@yoink.cs.uwaterloo.ca>
References: <op.vbnxxbmj1e62zd@merlin.emma.line.org>	<20100424211529.GZ27515@yoink.cs.uwaterloo.ca>	<20100425103032.GA8469@merlin.emma.line.org>
	<20100426000658.GH27515@yoink.cs.uwaterloo.ca>
Message-ID: <4BD59744.5020600@gmx.de>

Am 26.04.2010 02:06, schrieb Ian Goldberg:

> The trouble is that some people go offline, but keep their pidgin
> running, and so keep their session keys.  They *want* their messages to
> remain readable when they get back online.  So we implemented the "if
> you quit your pidgin, the OTR session will close; if you just go
> offline, it won't" mechanism.

Fine.

> Personally, I'd prefer if IM networks didn't let you send messages to
> offline parties, since they're not "instant"; that's what email is for.
> But my personal preferences are neither here nor there.  ;-)

Such an "refuse to send if other end offline" inside the OTR plugin would make
sense. I could configure Aunt Tillie's Pidgin that way and she knows she can't
send and has to use mail instead.

> The way it is now, Bob ends up receiving a message from Alice he cannot
> read -- and is informed of that fact; he could try to contact Alice to
> find out what it was.  If Alice was unable to send the message, Bob
> wouldn't even know that she tried.  Which is better?  I don't think it's
> 100% either way.

Now if Alice is offline by the time Bob receives the online message, we're dead
in the water.  If Alice is online, the clients could re-negotiate and then
re-send the messages since Bob went offline.  I think this somehow used to work
that way, but doesn't ATM.

-- 
Matthias Andree


From paul at cypherpunks.ca  Tue Apr 27 13:49:28 2010
From: paul at cypherpunks.ca (Paul Wouters)
Date: Tue, 27 Apr 2010 13:49:28 -0400 (EDT)
Subject: [OTR-users] Request: Pidgin plugin should request refresh if
 other user offline
In-Reply-To: <20100426000658.GH27515@yoink.cs.uwaterloo.ca>
References: <op.vbnxxbmj1e62zd@merlin.emma.line.org>
	<20100424211529.GZ27515@yoink.cs.uwaterloo.ca>
	<20100425103032.GA8469@merlin.emma.line.org>
	<20100426000658.GH27515@yoink.cs.uwaterloo.ca>
Message-ID: <alpine.LFD.1.10.1004271344361.28245@newtla.xelerance.com>

On Sun, 25 Apr 2010, Ian Goldberg wrote:

> Personally, I'd prefer if IM networks didn't let you send messages to
> offline parties, since they're not "instant"; that's what email is for.
> But my personal preferences are neither here nor there.  ;-)

google talk does exactly that. offline msgs are emailed.

> The way it is now, Bob ends up receiving a message from Alice he cannot
> read -- and is informed of that fact; he could try to contact Alice to
> find out what it was.  If Alice was unable to send the message, Bob
> wouldn't even know that she tried.  Which is better?  I don't think it's
> 100% either way.

What i dont like is the race condition. I type, user goes offline, otr goes
into finished state, i hit return, msg is not send AND no longer present in
my message window. I cant even cut and paste it into email anymore :)

Paul


From paul at darkrain42.org  Tue Apr 27 14:45:54 2010
From: paul at darkrain42.org (Paul Aurich)
Date: Tue, 27 Apr 2010 11:45:54 -0700
Subject: [OTR-users] Request: Pidgin plugin should request refresh if
 other user offline
In-Reply-To: <j2me692861c1004251720t4a913520wf36359b8b63b61d3@mail.gmail.com>
References: <op.vbnxxbmj1e62zd@merlin.emma.line.org>	<20100424211529.GZ27515@yoink.cs.uwaterloo.ca>	<20100425103032.GA8469@merlin.emma.line.org>	<20100426000658.GH27515@yoink.cs.uwaterloo.ca>
	<j2me692861c1004251720t4a913520wf36359b8b63b61d3@mail.gmail.com>
Message-ID: <4BD730E2.2030507@darkrain42.org>

And Gregory Maxwell spoke on 04/25/2010 05:20 PM, saying:
> Worse?
> I've lost what I wrote because the text doesn't appear in the history.

With the input area focused, press Ctrl-Up (this shortcut is
Pidgin-specific, though I suspect other clients offer such functionality)

~Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20100427/54e5ed6f/attachment.pgp>

From gdt at ir.bbn.com  Tue Apr 27 20:07:16 2010
From: gdt at ir.bbn.com (Greg Troxel)
Date: Tue, 27 Apr 2010 20:07:16 -0400
Subject: [OTR-users] Request: Pidgin plugin should request refresh if
	other user offline
In-Reply-To: <j2me692861c1004251720t4a913520wf36359b8b63b61d3@mail.gmail.com>
	(Gregory Maxwell's message of "Sun, 25 Apr 2010 20:20:54 -0400")
References: <op.vbnxxbmj1e62zd@merlin.emma.line.org>
	<20100424211529.GZ27515@yoink.cs.uwaterloo.ca>
	<20100425103032.GA8469@merlin.emma.line.org>
	<20100426000658.GH27515@yoink.cs.uwaterloo.ca>
	<j2me692861c1004251720t4a913520wf36359b8b63b61d3@mail.gmail.com>
Message-ID: <rmizl0oe8y3.fsf@fnord.ir.bbn.com>


Gregory Maxwell <gmaxwell at gmail.com> writes:

> Far end logs off cleanly.  OTR shuts down.   Later I come back and
> type into the IM window. The message doesn't send, instead it just
> outputs a notice that OTR was shut down.   I can happily type into
> this box for sometime before noticing that it's not working.  Worse?
> I've lost what I wrote because the text doesn't appear in the history.
>
> I totally get and appreciate that you don't want one side thinking the
> channel is OTR protected and blabbering away into a clear-text
> deactivated stream.  ... and that messages which are never sent should
> probably not show up in the history  (otherwise I might never notice
> that my messages are not going out! :) )....
>
> But?  could it just attempt to initiate a new session in this case?
> then send the message, and not bother me with the fact that the other
> side logged out at all?

Agreed.  There's no good reason why this case should behave differently
From no OTR session and "OTR required" configured for that peer.  (Well,
I don't use that, but negotiating a session and retrying would really be
nice.  At least putting the message in the history with "NOT SENT: foo"
so you can cut/paste it again.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20100427/bb254c28/attachment.pgp>