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

[Greg Troxel]

Ian Goldberg <ian at cypherpunks.ca> 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 <gdt at ir.bbn.com>