[OTR-dev] Flaw in OTR Protocol (with workaround!)

[Ian Goldberg]

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