[OTR-dev] initial otr usability comments

[Ian Goldberg]

Great comments!

On Sat, Dec 18, 2004 at 10:41:03AM -0500, Greg Troxel wrote:
> It would be nice to be able to store (locally) per-buddy state that
> only encrypted messsages may be sent, and when trying to send do KE
> first and then send.  Or, to invoke KE when a chat window is opened.

We ran into a problem with this.  Some users have multiple machines;
some of them have OTR installed, and some don't.  The way it's set up
now, the first message you send to a buddy (for whom you already have a
OTR fingerprint) will have a tag attached to it that the other side (if
it is in fact running OTR) will recognize, and start the KE.  So just
sending "hi" as your first message (unencrypted) will start OTR.

> I would like a little more of a warm fuzzy that traffic is being
> encrypted.  Somehow marking the chat window on a per-line basis would
> be nice.  Perhaps adding [otr] to the screen name, so it shows up
> 
>   joe [otr]: test message
> 
> instead of
> 
>   joe: test message

Yeah, the problem is that there's a limited amount of stuff plugins can
do.  When we look at the localhost proxy to support other
platforms/clients, it's even less.  Munging the screen name *is*
something a proxy could do, though, so long as clients don't "know" that
chars like [ and ] are illegal in screen names.  We also need to make
sure that the "is secure" marker can't be forged.  [So just putting the
text in red, for example, wouldn't work.]

> If it makes sense to mark authentication, confidentiality, and
> repudiability separately (doesn't seem so in this case), then perhaps
> [acr], as a stab at a more general interface.

It doesn't.

> It seems that 'refresh keys' should push the mac keys to enable
> forging, this might be pointed out more srongly in the user
> documentation.

'Refresh keys' does not in fact push the MAC keys; it just reminds the
other side of the current set of DH keys.  But if the other side has
stopped OTR for some reason (like they quit gaim and restarted), it'll
cause a new OTR session to start.

> The JID showed up in a mailto: link, and probably that should be
> xmpp:, as it is a separate namespace sort of.  I realize this may be a
> gaim issue, and on top of that it is messy.  (My JID is not a valid
> email address.)

That really is a gaim issue.  OTR doesn't deal with that at all.

> It seems there should be a way to end a private conversation in such a
> way that the other party is told this and it is all graceful.

This is actually a security issue.  It was a design decision to *not*
have an OTR session be closable via a network event.  That way, (1) an
attacker can't possibly force you into an unprotected state, and (2) you
won't run into the problem of typing a message you think will be sent
securely, when all of a sudden, the other guy closes the session, you
press Enter, and your message is sent in the clear.

> I don't understand (as a UI issue), how or if when I close a chat
> window the MAC keys are disclosed.

The MAC keys are actually changed and disclosed on a much more frequent
basis than "one conversation".  It actually happens every time the
speaker in the conversation changes.  [So if you're taking turns writing
messages, for example, the keys change (and the old ones are disclosed)
every message.]

> It would be nice to be able to use gpg dsa keys for otr such that one
> could have a signature on an otr key from the WOT.  For many of the
> people that I would like to use OTR with I already have gpg keys that
> I believe.

For now, we're leaving that up to the user to do himself, so as to not
have a dependency on gpg:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The OTR fingerprint for otr4ian on AIM is
C5D70FB3 135CB595 F2F31E01 88884CEF BDD73BD9

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBxFjp3tZOuyuofFwRAhn5AJkBC3141pudLtg4yYsiXn/u84O7/gCglIsY
RP1vN6adlXi85fsk1Yi5W5Q=
=AnZB
-----END PGP SIGNATURE-----

   - Ian