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

[Greg Troxel]

  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 <gdt at ir.bbn.com>