[OTR-dev] OTR-dev Digest, Vol 75, Issue 1

[Ian Goldberg]

On Wed, May 06, 2015 at 01:49:13PM +0100, Peter Fairbrother wrote:
> On 06/05/15 11:51, Ian Goldberg wrote:
> >On Wed, May 06, 2015 at 12:11:53AM +0200, Allan Nordhøy wrote:
> >>Change the colours and you have all modes. Red for "not private", Yellow
> >>for "unverified" and Green for "authenticated".
> >
> >Unfortunately, one can't use only a colour change to indicate something
> >like this, for the sake of people who cannot see the colours.
> 
> 
> 
> I'm not very familiar with OTR, but - a "not private" mode? And two
> other modes? Is that wise?
> 
> Fifth Principle of Information Security Design: "Modes and choices
> are bad in crypto protocols, they give users choices which they are
> not qualified to make. It is your job to be clever, not the user's."
> 
> Now OTR's clients are probably mostly a bit above the usual luser, but ..

Yes, totally agree.  For many OTR users, who might be using it
unintentionally because their IM client just ships with it by default,
say, OTR will just protect their conversations against passive
eavesdroppers without them needing to know anything.

The mode indicators (at least "Not Private") come in because we're not
providing a secure messaging network ab initio.  Instead, you're talking
to your existing contacts, who may or may not be equipped to encrypt
your conversation.  So while it is of course best to make a system that
*cannot* send unencrypted messages, there are compromises one needs to
make when deploying a security/privacy layer on top of an existing
system.  (Which is why you should design security and privacy *into* the
system, and not bolt it on top.  But we didn't get to design AIM, ICQ,
or XMPP.)

   - Ian