(In reply to comment #71)
> > It currently
> > cannot go back to NOT_PRIVATE because I don't support ending the otr
> > session, but could add a "/otr end" for that. pidgin can do that.
> 
> Please don't. In Pidgin, maybe that feature is OK, because typically only
> one UI handles a window (Pidgin's D-Bus API aside). In Telepathy, where more
> than one UI can be interested in a channel, that feature would be an
> unlikely security flaw: if I type "the secret password is weasel" and for
> some reason another process turns off OTR just as I hit Enter, that's Bad™.

I actually added Stop method (/otr stop in empathy) because when the other side (pidgin) stop the OTR session we have to let user disconnect as well to continue in plaintext, otherwise he can't send messages anymore. Or do you think user should close the chat window and open it again in that case? Having that stop method is useful for testing as well :)

IMO those methods must always be called on explicit user action, if you have bad apps running on your bus session, you lost already.

> If the remote peer can turn off OTR, then that elevates that situation to a
> remotely exploitable security flaw, but AIUI the design of OTR doesn't allow
> that to happen.

Remote end can stop otr and you won't be able to send messages anymore until you stop/start it locally again.

> > It is the same information, the string is utf8 (ascii even) to display, the
> > ay is hex form (20 bytes, not utf8).
> 
> All hex is UTF-8, because hex is a subset of ASCII, and ASCII is a subset of
> UTF-8... or do you mean binary?

Sorry, mean binary, yes. 20 bytes of randomness.

> As for the human-readable version, do I infer correctly that it is not just
> hex, but instead an OTR-specific encoding that is easier to transcribe or
> more dense or something?

It looks like "82AAB578 4FB98B0B AECD3BA4 6083CFE2 E152AD73" so that's actually simple hex with spacing. The formatting can easily be re-implemented client-side, but it's cheap enough to just provide it over dbus.

> > I think if the other end stops the OTR session then trustlevel goes to
> > FINISHED but you'll still be sending encrypted messages and the other side
> > (pidgin-otr) will say "I received an encrypted messages, have no idea what
> > it contains". Need to try that scenario to check.
> 
> My understanding is that OTR publishes the temporary key at the end in order
> to provide deniability (although when I looked at the security properties of
> OTR and XTLS a few years ago I couldn't work out what extra deniability this
> actually provides...) and so continuing to encrypt messages with it would be
> Very Bad? But I could be wrong.

I was wrong indeed. When other end stops the session TrustLevel goes to FINISHED (added a patch to make that happen) and you are not able to send messages anymore, you get an error message back. I think it publish the private key indeed.

> > pidgin-otr says 0 for xmpp as well. OTR encryption can expand a bit the size
> > of messages, but that's not new that user sending huge text could not be
> > interoperable. I don't think gabble tries to prevent it anywhere.
> 
> Fair enough. I thought OTR had some sort of transparent chunking mechanism
> that might actually make OTR-over-XMPP more compatible with crap servers
> than just sending text over XMPP :-)

OTR can fragment messages on protocols where it matters. We can indeed make it more interoperate thanks to that... If you have any sensible value in mind? Not blocker anyway.

(In reply to comment #72)
> (In reply to comment #69)
> > It can be done later. ATM the policy is MANUAL and it's the right thing
> > until we have an explicit option. I would consider this non-blocker future
> > enhancement.
> 
> That's OK, but only if MANUAL specifically means "do not initiate *or
> accept* OTR sessions without user input".

It will always accept if remote starts the session. Do you think that's merge blocker? I'm a bit lazy to add a CM param, add UI in empathy, and goa/uoa doesn't make possible to add settings for facebook/google... I'm already tired just thinking about all that :(

Simpler solution if you insist: make it per-channel and reject remotely initiated OTR before we call Start method.

> (In reply to comment #70)
> > I would consider this non-blocker future enhancement. Atm I'm not proposing
> > the spec to be included in tp-spec, only private to gabble<>empathy.
> 
> I don't like private APIs. They have a nasty habit of becoming de facto
> public APIs as soon as you commit them (and we only recently managed to get
> rid of Renaming being a private API, despite it not having changed for 5
> years).
> 
> We have API versioning now, so if it's good enough to merge, it's good
> enough for the spec.

I would merge it in spec-next where we don't have that bus-name hack. Ok?