empathy needs to support OTR encryption

Bug #296867 reported by goto on 2008-11-11
This bug affects 342 people
Affects Status Importance Assigned to Milestone
Empathy
Confirmed
Wishlist
Nominated for Trunk by onny
One Hundred Papercuts
Undecided
Unassigned
libtelepathy
Confirmed
Wishlist
empathy (Fedora)
Won't Fix
Unknown
empathy (Ubuntu)
Wishlist
Unassigned
Declined for Maverick by Sebastien Bacher
libtelepathy (Ubuntu)
Wishlist
Unassigned
Declined for Maverick by Sebastien Bacher

Bug Description

Binary package hint: empathy

Hello,
I just tried empathy (the Intrepid version) and it looked very solid and stable. There were a few minor things that could be improved (e.g. automatically resizing the contact list), but that is not the topic here.
The reason why I won't switch to empathy from pidgin is the missing OTR support (http://www.cypherpunks.ca/otr/ ). This is a really important feature because no one should read your messages.
There were others with the same idea (links at the bottom).
Would be so great if it could support that important encryption standard.
Thanks for helping out!

Links:
https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/253452/comments/2
http://lists.cypherpunks.ca/pipermail/otr-users/2008-September/001479.html
http://bugs.freedesktop.org/show_bug.cgi?id=16891

Yeah, encryption is a must for me, too. This the only reason using Pidgin instead of telepathy for me.

The draft Messages UI should theoretically allow anything that has a MIME type.
The underlying protocol support is another story, however.

C-library[1] and python binding[2] are availible, too. So "only" the telepathy glue is needed. After that minor extensions to the different user interfaces really make it functional.

[1] http://www.cypherpunks.ca/otr/README-libotr-3.2.0.txt
[2] http://python-otr.pentabarf.de/

goto (gotolaunchpad) wrote :

Binary package hint: empathy

Hello,
I just tried empathy (the Intrepid version) and it looked very solid and stable. There were a few minor things that could be improved (e.g. automatically resizing the contact list), but that is not the topic here.
The reason why I won't switch to empathy from pidgin is the missing OTR support (http://www.cypherpunks.ca/otr/ ). This is a really important feature because no one should read your messages.
There were others with the same idea (links at the bottom).
Would be so great if it could support that important encryption standard.
Thanks for helping out!

Links:
https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/253452/comments/2
http://lists.cypherpunks.ca/pipermail/otr-users/2008-September/001479.html
http://bugs.freedesktop.org/show_bug.cgi?id=16891

Pedro Villavicencio (pedro) wrote :

that's a telepathy request

Changed in empathy:
importance: Undecided → Wishlist
status: New → Triaged
Changed in libtelepathy:
status: Unknown → Confirmed

if given some mentoring, i could spend some time implementing it.b

(Note to myself: maemo.org downstream ticket at https://bugs.maemo.org/show_bug.cgi?id=1921 )

Downgrading priority; there are more pressing spec issues, and I think that supporting encryption on protocols like XMPP where it can be done cleanly (rather than as misc. sent in the regular plain text stream) is a higher priority.

in my experience this is why i myself and most people i know still use pidgin, though everybody believes telepathy would be nicer.

Re-lowering priority. Daniel: while it's a shame that this is keeping you from using Telepathy, there really are higher-priority spec issues. Also see point 2.1 on <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>: the priority field is to help developers track the relative priorities of bugs, not for voting on how important you think a bug is.

Changed in empathy:
status: Unknown → New
Raybuntu (raybuntu) wrote :

+1 That's a must have feature! Without this Emphaty can never replace Pidgin.

jaduncan (jaduncan) wrote :

I'd agree this is extremely important. Any chance of a comment on this from the devs?

Bernd Schlapsi (bernd-sch) wrote :

+1 This is also a important feature for me. OTR should be supported before it replaces Pidgin in Ubuntu!

Laurent Bigonville (bigon) wrote :

This is not releated to libtelepathy

Changed in libtelepathy (Ubuntu):
status: Triaged → Invalid

I consider Telepathy to be completely broken for my purposes unless it interoperates properly with OTR on other clients. If you want to do a better version of OTR with deniability in XMPP, go right ahead. Just make sure that the old way still works.

Adium having built in OTR support has been a fantastic boon.

I will discourage everybody I know from using Empathy and uninstall it on systems I administrate until this is fixed. This should have been thought of in the very beginning and been a feature in the program since its inception. Bad security is unforgivable.

You treating this as a low priority bug tells me a whole lot about what kinds of things the Empathy development team thinks is important, and good security is apparently not an important consideration.

(In reply to comment #9)

Eric:

I will actively discourage everybody I know from reading your drivel until you resolve your issue by rolling up your sleeves and adding this feature. You should have considered doing this yourself ever since you decided to bitch about it here.

Your unwillingness to fix this yourself tells me a whole lot about what kinds of things you think are important, and apparently good security is not an important consideration.

(In reply to comment #9 (of Eric Hopper))
> I will discourage everybody I know from using Empathy and uninstall it on
> systems I administrate until this is fixed. This should have been thought of
> in the very beginning and been a feature in the program since its inception.

As the Empathy developers are more knowledgeable with what users want, or at
least have better tools to gather the information, I guess they have different
list of priorities of tasks to work on.

> Bad security is unforgivable.

This is the kind of program where security is good-to-have feature. The OTR can
be added later, once the basis is stable.

> You treating this as a low priority bug tells me a whole lot about what kinds
> of things the Empathy development team thinks is important, and good security
> is apparently not an important consideration.

Nobody is against good security. It is just a matter of percentage of users
that are needed to be catered to first. As the developer's resources are
scarce, they need to judge carefully where to direct theirs efforts.

At this point empathy is barely suitable for everyday work (which is important
for about 90% of users), whereas security is important for about 5% of users.

I have to disagree. Although I fully understand the fact that no developer is willing to take up that task, security should be a priority for all users. For me security is part of the basis. A chat client without encryption I do not consider to be functional. I dont chat with people sho do not use encryption. I think Telepathy is more than stable, as it is already part of GNOME and Empathy is going to be the default chat client for Ubuntu 9.10. I would have It is also true, that OTR is broken by design. but it works and I dont know of any client which provides a sane implementation of a chat encryption bedides the ones using OTR.

So again its only up to current and upcoming developers to decide if they are going to implement OTR, but I consider it much more important than providing a lot of chat protocols.

(In reply to comment #12)
> OTR is broken by design. but it works

This is not a good justification for an encryption scheme. :)

Well, yes, but name me any other existing chat encrpytion that actually works. There are many standards out there which are far from perfect. GIF wasnt perfect, but it was used. Most of the protocol standards liek MSN or AIM are broken by design also. But they are used and are already implemented.

(In reply to comment #14)
> Well, yes, but name me any other existing chat encrpytion that actually works.
> There are many standards out there which are far from perfect. GIF wasnt
> perfect, but it was used. Most of the protocol standards liek MSN or AIM are
> broken by design also. But they are used and are already implemented.
>

I have no stance for and against OTR encryption and I don't know what OTR encryption is about behind the scenes. I will therefore judge only by your words.

You seem strangely interested in security... provided by (by your own words) a broken security layer? Do you really think that providing broken security, and lulling people into false sense of security is better than providing no "security" at all?

And to others. I am not a Telepathy developer... but seriously guys, flaming developers while not being ready to get yourselves on the line? If you find it useful and especially if you find it critical, do it yourself. Otherwise, feel free to keep using Pidgin until you get this critical feature, which Thilo considers broken by design.

I think there's room for other improvements before encryption, because I, and many other home users, find it unnecessary. Encryption is not important for majority of people on this world.

Take your tinfoil hats off, people, nobody's going to eat your brains. And if you really need it for your company, well, either you or your company can invest resources into Telepathy. I personally don't find OTR important, and I'm sure most users don't, either. And I don't consider myself completely paranoia-free.

If other clients provide you security, use those. Or use email+GPG for even more security. Filing a request is fine. Posting a comment supporting the request is fine. Attacking people like some of you did is not fine.

(In reply to comment #15)
> You seem strangely interested in security... provided by (by your own words) a
> broken security layer? Do you really think that providing broken security, and
> lulling people into false sense of security is better than providing no
> "security" at all?

OTR's brokenness is due to the fact that it is a hacky kludge on top of existing IM protocols, not because it has any security flaws. It's inelegant and ugly, but it works.

I'm all for an elegant solution. But I don't think it should take a backseat to interoperability. I know that the various IM protocols are also mostly a bunch of ugly kludges as well. But that doesn't stop them from being implemented.

> And to others. I am not a Telepathy developer... but seriously guys, flaming
> developers while not being ready to get yourselves on the line? If you find it
> useful and especially if you find it critical, do it yourself. Otherwise, feel
> free to keep using Pidgin until you get this critical feature, which Thilo
> considers broken by design.
>
> I think there's room for other improvements before encryption, because I, and
> many other home users, find it unnecessary. Encryption is not important for
> majority of people on this world.

I am worried because Empathy appears to be getting a huge userbase and being used as the default IM client for a number of distributions without having a feature I think is incredibly important and should've been built in at the start, almost especially because most users don't really care about it.

Most people will not care about encryption. Most people also do not care about ACID database semantics. But anybody who made a database lacking the latter feature (i.e. Microsoft Access) would be roundly and justly flamed. Especially if they managed to somehow get that database into general use.

There are a whole host of features that users do not care about but are critical pieces of infrastructure. One of the things that most pleases me about Adium is that the developers understood and so many of my friends who have no clue or desire for encryption end up using it anyway because they use Adium.

> If other clients provide you security, use those. Or use email+GPG for even
> more security. Filing a request is fine. Posting a comment supporting the
> request is fine. Attacking people like some of you did is not fine.

Email encryption is nearly a lost cause. But with Adium and a couple of other popular IM clients supporting OTR, widespread IM encryption was beginning to happen. I don't think activists in Iran should have to worry about which IM client their friends are using in order to avoid being snooped on. I don't think their choice of IM client should be able to be used to single them out for special treatment by their government. All new IM clients should just do the right thing out of the box.

Widespread support for good encryption is not something I care about because I am especially paranoid about my own IM conversations. It's because I care about the pernicious effects of all IM conversations being potentially public knowledge.

Eric, flaming is not going to give you anything.

If you need OTR so much, either propose a patch, or don't use Empathy.

OTR is not going to happen if nobody gives a patch. End of discussion.

Omnifarious (omnifarious) wrote :

I will not use empathy until it has OTR support. It is worthless to me. I don't care if the maintainers think they can think of something better. Unless they can get it adopted by other popular IM clients, I want OTR. And it's not better unless it also has the deniability that OTR provides.

(In reply to comment #17)
> Eric, flaming is not going to give you anything.
>
> If you need OTR so much, either propose a patch, or don't use Empathy.
>
> OTR is not going to happen if nobody gives a patch. End of discussion.

Even if you, or any Empathy developers, don't plan to implement OTR, it's still an important feature and the priority should be set to high.

Or you don't agree it's an important feature? If that's the case I can provide evidence.

"priority" is the priority that we, the current Telepathy developers, give to implementing OTR. If it's a high priority for *you*, you're welcome to implement it, or hire someone to implement it; but it's not a high priority for *us*, and so it stays priority=low in Bugzilla.

I think helping the XMPP Standards people to provide end-to-end encryption (implementing <http://xmpp.org/extensions/inbox/xtls.html> or something like it, and advancing it to Recommended status) is a much better use of developer time; it'll result in a better protocol, with a well-defined security model, that does not conflict with the protocol's normal extensibility mechanisms.

(In reply to comment #19)
> I think helping the XMPP Standards people to provide end-to-end encryption
> (implementing <http://xmpp.org/extensions/inbox/xtls.html> or something like
> it, and advancing it to Recommended status) is a much better use of developer
> time; it'll result in a better protocol, with a well-defined security model,
> that does not conflict with the protocol's normal extensibility mechanisms.
>

OTR also works over non-XMPP networks (I use primarily over AIM). That's something that this XMPP standard can never achieve.

I'm not taking sides - just stating some (hopefully) useful facts.

(In reply to comment #16)

> I am worried because Empathy appears to be getting a huge userbase and being
> used as the default IM client for a number of distributions without having a
> feature I think is incredibly important and should've been built in at the
> start, almost especially because most users don't really care about it.

By far the overwhelming majority of IM clients in use are those provided by the protocol vendors, and I can assure you, they don't ship with OTR. Empathy's userbase is growing, but it's stil early days and it's likely not going to dwarf the others anytime soon.

> Most people will not care about encryption. Most people also do not care
> about ACID database semantics. But anybody who made a database lacking the
> latter feature (i.e. Microsoft Access) would be roundly and justly flamed.

No, they should not be flamed, and this is the reason your posts are so inappropriate: you think that because feature X is missing, developers should be flamed. Developers in a number of projects work on a voluntary basis, and in my opinion deserve some semblance of respect for their contributions, not being hassled by the likes of you.

> There are a whole host of features that users do not care about but are
> critical pieces of infrastructure.

OTR is not a generally accepted critical piece of infrastructure.

> Email encryption is nearly a lost cause. But with Adium and a couple of other
> popular IM clients supporting OTR, widespread IM encryption was beginning to
> happen.

Back up your unqualified assertions about encryption uptake with some verifiable facts.

> I don't think activists in Iran should have to worry about which IM client
> their friends are using in order to avoid being snooped on.

Perhaps a nice utopian vision of the future, but not the basis for a rational discussion. This is an unqualified "oh-won't-someone-please-think-of-the-X" appeal to emotion without presenting reasonable facts or arguments to base it on.

It sounds like you have strong convictions. Strong enough though only to sound off about it here and not really do anything about it. If these objectives are so important to you, why aren't you writing your own OTR extension now?

> I don't think their choice of IM client should be able to be used to single
> them out for special treatment by their government. All new IM clients should
> just do the right thing out of the box.

Reality: People's choices in the technology adoption affect their security. You can't control the proliferation of technology, and you can't control people's choices. You lose on both counts.

> Widespread support for good encryption is not something I care about because I
> am especially paranoid about my own IM conversations. It's because I care
> about the pernicious effects of all IM conversations being potentially public
> knowledge.

You only care enough about it to flame the volunteer developers who are working on the IM technology -- not enough to actually do anything about it yourself and contribute to make it better. Oh right, you're also boycotting Empathy/Telepathy and telling all your friends not to use it.

Hello all,

since I am the creator of this "bug", I feel obliged to calm the waves a bit and add a plea for seriousness in this discussion.

What some developers might call "broken by design" is probably the backside of OTR being a technology that just works with each and every IM protocol out there, even the worst ones like MSN and Yahoo. I presume, providing such a bandwidth of features just wont go without some kludgy solutions.
    In my daily life (and in the life of many others I would bet) practical solutions are what counts and what is needed. OTR is a practical solution.
As a contract worker for several German companies I can tell you that in many European IT departments OTR has become the de facto standard for on-the-fly exchange of information bits like the casual end user password and similar stuff of more-than-zero triviality.
To the best of my knowledge, all current versions of OTR provide no "false security" when properly used and the fact that they might not be working very elegant "under the hood" is actually the bit that is of "minor importance" to me.

For me, the important point is that I totally depend on a cross-protocol encryption solution for IM that "just works" in my daily life and so do many other people. OTR is already here and has been for several years now. And despite the fact that there might be more or less obvious and more or less major disadvantages to OTR from the developers POV, *not* *one* single viable alternative has come to my attention in the last years that is not forcing users to use a specific IM protocol or even a specific OS platform.

Conclusion: Unless proven otherwise I'd like to state as a FACT that in the field of IM privacy, OTR has become the de-facto standard. At least in Europe it is very widely deployed and often expected to be available. And there are just no alternatives available at all which work cross-protcol and cross-platform.
  From my POV this means there is also (currently) no alternative available to implementing OTR for every IM UA that wants to be taken seriously.

Thank you for reading.

OTR is a must-have feature.

You can not replace pidgin with empathy while not supporting OTR.

It's the only widespread encryption technology that works protocoll independend.

I like empathy and think it has a lot of potential to be a really nice piece of software but lacking support for encryption will force me to use pidgin instead.

I will not use empathy without OTR support either. The statement of the developers is absurd - they think, that their users dont need it and the only other option is to wait until there is native support in some protocol, which most users dont use or even know about. So thank you for telling me, that I dont need OTR and should convince all my chat-buddies to switch to jingle, but I prefer I to choose what to do with my computer, so until there is OTR support for empathy I will use Pidgin.

Ronald Pottol (ronaldpottol) wrote :

OTR support is critical. It needs to be there, and it needs to be something that other people are using. I guess I need to go back to pidgin.

alien8 (fb-alien8) wrote :

There are many good arguments as to why otr support should be high priority in this thread, and others, and to as to why many people consider leaving out otr-support a very bad idea. We
Google: telepathy otr and you'll see a lot of them.

My view: Should be a default out-of-the-box, as it works with all protocols. Almost everyone in my contactlist uses otr now-a-days, and no, they are not all "nerds". We use otr at work too.

164747 (jacquet-david) wrote :

I totally agree, OTR is eminent. I can se no reason denying users their right to privacy. The OTR should work for all communacations within empathy, text, audio, video, and all protocols.

if someone would like to create a plugin, does somebody know good documentation
first on creating telepathy or empathy plugins ( C or Python, C++)
and second on using libotr??
please comment or
directly to <email address hidden>

haeger (haeger-the-terrible) wrote :

Encryption is an absolut ko-creterion. So i have two reasons why pidgin will remain on my system:

1.) The Devs of empathy told me on irc that i have to trust the people how run the communication-server! Or i have to set up an own server! That's both totally out of the question for the average user. Sometime i get the impression that some devs are ignorant.

2.) I can't understand how a piece of software which trample on users privacy can make it into ubuntu. Using tubes to control remote desktops without encryption is a great security issue.

The underlying idea of empathy/telepathy may be good. But really important things are ignored. To move the responsibility to ONE protocol (jabber ) which may implement encryption in the future is really unsatisfying.

Omnifarious (omnifarious) wrote :

Not to mention that the proposed idea for implementing encryption over Jabber doesn't give the same level of privacy guarantees as OTR, nor is it actually as nice a standard in a lot of other ways.

The average user will never generate an X.509 certificate for themselves. Anything based on that kind of technology is broken from the start. It's like making an email application that requires the user be in X.500 directory before it delivers mail.

Miron Cuperman (devrandom) wrote :

Added package empathy from Ubuntu, as this represents a regression from Intrepid.

Also, there seems to be no plugin system in empathy / telepathy, so it's no clear how to proceed with implementing an OTR plugin.

@24: AFAIK there is not even a plugin API available yet.

Changed in empathy (Ubuntu):
status: New → Triaged
importance: Undecided → Wishlist
Changed in empathy (Fedora):
status: Unknown → Confirmed
Changed in empathy (Fedora):
status: Confirmed → Won't Fix
Changed in empathy:
status: New → Confirmed
DaveW (dave-stricklers) on 2010-05-05
Changed in empathy (Ubuntu):
status: Triaged → In Progress
status: In Progress → Confirmed
Changed in empathy (Ubuntu):
status: Confirmed → Triaged
status: Triaged → Confirmed
status: Confirmed → Triaged
Changed in libtelepathy:
importance: Unknown → Wishlist
Changed in empathy:
importance: Unknown → Wishlist
Changed in libtelepathy (Ubuntu):
assignee: nobody → Jordan Farrell (wolfrage)
status: Invalid → In Progress
Chris Wilson (notgary) on 2010-12-14
Changed in hundredpapercuts:
status: New → Invalid
Changed in libtelepathy:
importance: Wishlist → Unknown
Changed in libtelepathy:
importance: Unknown → Wishlist
komputes (komputes) on 2012-03-20
tags: added: css-sponsored-p
Changed in libtelepathy (Ubuntu):
assignee: Jordan Farrell (wolfrage) → nobody
status: In Progress → Incomplete
Pander (pander) on 2012-07-12
tags: added: 12.10
Pander (pander) on 2012-11-19
tags: added: encryption
Pander (pander) on 2012-11-19
Changed in libtelepathy (Ubuntu):
status: Incomplete → Confirmed
Pander (pander) on 2013-10-23
tags: added: 14.04
removed: 12.10
tags: added: im
161 comments hidden view all 241 comments

(In reply to comment #54)
> > trust_level_to_str(): I'd mention "encrypt using OTR" to be clearer and
> > avoid confusion my server encryption.
>
> Fixed.

return _("The conversation is currently unencrypted.");

I'd say "unencrypted with OTR" to stay coherent and crystal clear.

Your branch looks good to me. I'm fine merging it to Empathy master as soon as the Gabble branch lands.

From a (very) quick look on the Gabble branch, it seems that all the channel messages are now sent through OTR (if built with it), even when it has not been activated. Is that really what we want?

Also, shouldn't we use it only for contact channels?

(In reply to comment #56)
> From a (very) quick look on the Gabble branch, it seems that all the channel
> messages are now sent through OTR (if built with it), even when it has not
> been activated. Is that really what we want?

Yes, that's what pidgin-otr does as well. That's because all received messages needs to be parsed by OTR first because it will catch message starting with "?OTR?" because when receiving that it means the other side wants to start an OTR session. In that case the message is considered as internal OTR protocol message and it returns ignore=true so we don't dispaly that to the user.

We could avoid passing sending messages to OTR when session is not started indeed. I didn't do that because OTR will just return a copy of the initial message so it doesn't change anything (just wasting CPU cycles), and I prefer not adding any conditions to make damn sure we never have the case where we send something that didn't got encrypted first.

> Also, shouldn't we use it only for contact channels?

I don't think OTR can be used on MUC, or at least that's out of scope for now.

Download full text (3.6 KiB)

Just doing the spec right now:

> The extra DBus channel interface is implemented using GDBus
> so it needs to be exported on a different bus name.

Ugh. Can we not do strange hacks like this, please? Either use the extensions mechanism, or save it for 1.0.

+ <interface name="im.telepathy.v1.Channel.Interface.OTR1"
+ tp:causes-havoc="experimental">
+ <tp:added version="Gabble 0.UNRELEASED">(Gabble-specific)</tp:added>

If doing this in 0.x, please use o.fd.Channel.Interface.OTR1 and add it to telepathy-spec (OK to go via extensions/ until we do the spec -> tp-glib dance, though).

In 1.0, certainly add it to the spec.

+ A simple D-Bus API <a
+ href="https://otr.cypherpunks.ca/">Off The Record</a>.

"... API for <a..."

+ <p>The current trust level of this channel:
+ 0=TRUST_NOT_PRIVATE, 1=TRUST_UNVERIFIED, 2=TRUST_PRIVATE,
+ 3=TRUST_FINISHED</p>

This deserves a <tp:enum> and documentation.

I assume the meanings go something like this:

TRUST_NOT_PRIVATE: not using OTR at all? (Can we also see this when using OTR but something has gone wrong?)
(o.fd.Channel.I.Securable.Encrypted=FALSE, o.fd.Channel.I.Securable.Verified=FALSE)

TRUST_UNVERIFIED: the channel is encrypted, but you might be talking to a man-in-the-middle instead of the peer you expected. (o.fd.Channel.I.Securable.Encrypted=TRUE, o.fd.Channel.I.Securable.Verified=FALSE)

TRUST_PRIVATE: the channel is encrypted, and the user has indicated that the peer's key fingerprint is trusted to belong to that peer.
(o.fd.Channel.I.Securable.Encrypted=TRUE, o.fd.Channel.I.Securable.Verified=TRUE)

TRUST_FINISHED: this channel is over, nothing more should be sent or received on it.
(o.fd.Channel.I.Securable.Encrypted and o.fd.Channel.I.Securable.Verified keep their previous values?)

What are the possible state transitions? I assume "can only increase"?

+ type="(say)" access="read">
+ <p>User's current fingerprint. The first element is a human readable
+ fingerprint that can be displayed to the user so he can communicate it
+ to the other end by other means so he can trust it. The 2nd element is
+ the fingerprint raw data.</p>

Are these literally the hex and binary versions of the same digest, or do they have different information content? (Or is the string version some OTR-specific thing that is easier to transcribe than hex?)

+ <property name="RemoteFingerprint"
+ tp:name-for-bindings="Fingerprint"
+ type="(say)" access="read">
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">

What value does this take when the channel is not using OTR? ('', [])?

When we're in the UNVERIFIED state, am I right in thinking that we are cryptographically guaranteed to have the right fingerprint for who we're talking to, but the thing that is unverified is that the fingerprint belongs to the person we wanted to talk to? (i.e. if we're talking to a man-in-the-middle, this would be the fingerprint of the man-in-the-middle's key, right?)

Is it possible for this to change? (Presumably from ('', []) to non-empty, at the same time that the trust changes to UNVERIFIED or PRIVATE?)

After this has become non-empty, can it change further? (I would hope not.)

I think it would also be useful to spec that one of...

Read more...

Implementation in Gabble:

+ /* FIXME: There should be no sender for a notification, but setting handle to
+ * 0 makes empathy crash atm. */
+ tp_message_mixin_take_received (G_OBJECT (self),
+ tp_cm_message_new_text (base_conn,
+ tp_base_channel_get_target_handle (base_chan),
+ TP_CHANNEL_TEXT_MESSAGE_TYPE_NOTICE, text));

Is this a message from the OTR library, something like "*** Verified peer fingerprint: <email address hidden> ***"?

I think using the target handle for this is OK semantically.

However, I suspect remote users can spoof this by sending their own NOTICE. Messages coming from the OTR library should have a distinctive message header that an OTR-literate UI can take as evidence that they were locally-generated.

Ideally, that distinctive message header should be a machine-readable version of the message, so OTR-literate UIs (Empathy) can discard the untranslated version from Gabble and display something translated. We've always had a policy of putting UI strings and their translations in the UIs, not the CMs.

+ return g_variant_new ("(s@ay)", display_fp,
+ g_variant_new_fixed_array (G_VARIANT_TYPE_BYTE, fp_raw, 20,
...
+ guchar our_fp_raw[20];

The magic number 20 makes me nervous. Isn't there a constant for "length of a raw OTR fingerprint in bytes" in libotr?

If there really isn't, #define'ing our own would be better than nothing.

+static void
+otr_inject_message (void *opdata,
+ const gchar *accountname,
+ const gchar *protocol,
+ const gchar *recipient,
+ const gchar *message)
+{
+ inject_message (opdata, message);
+}

Is @message text/plain or text/html? Telepathy can only do text/plain at the moment, so if it's text/html, we need to strip tags, then unescape entities (&stuff;).

+static gint
+otr_max_message_size (void *opdata,
+ ConnContext *context)
+{
+ return 0;
+}

We should probably give some guess at what's generally interoperable.

+ msg = otrl_proto_default_query_msg (get_self_id (self), OTRL_POLICY_DEFAULT);

Do we need to update what otr_policy() would return here, too?

+ bus_name = g_strconcat (tp_base_connection_get_bus_name (base_conn),
+ ".OTR", NULL);

I suppose this isn't *so* bad, but the spec should tell the API user where to find this name.

+ content = wocky_node_get_content_from_child (node, "body");
+
+ err = otrl_message_sending (userstate, ui_ops_p, self,
+ get_self_id (self), "xmpp", get_target_id (self),
+ priv->instag, content, NULL, &new_content,
+ OTRL_FRAGMENT_SEND_ALL_BUT_LAST, NULL,
+ NULL, NULL);

Does otrl_message_sending() expect @content to be text/plain or text/html? If it expects text/html, we need to escape special characters with g_markup_escape_text().

Similarly, is @new_content text/plain or text/html? If text/html, we need to strip tags and unescape entities.

+gchar *
+gabble_im_channel_otr_receiving (GabbleIMChannel *self,
+ const gchar *content)

Same here.

(In reply to comment #50)
> Could we also get a config option that turns this whole feature on/off? I
> ask because some industries (like the one where I work) require that all
> electronic communications related to the business get recorded and reviewed
> by compliance officers and made available to regulatory agencies upon
> request.

I think we do need a connection parameter to control this. I think the possible sensible settings are:

- never use OTR, behave exactly as though it was not implemented

- start an OTR conversation if the local user or remote peer explicitly requests it

- try to start OTR conversations automatically

I think that would be most comprehensible as two booleans: something like "enable-otr" (default false initially, default true after a couple of releases) and "enable-opportunistic-otr" (not implemented in Xavier's patch, but someone could add it).

The writer of Comment #50 would explicitly set enable-otr to false; the people getting excited about this bug would explicitly set enable-otr to true, and when implemented, probably also set enable-opportunistic-otr to true.

I would really like im-channel to implement o.fd.Telepathy.Securable - as a starting point we can have the two booleans not be requestable, and just have them set by the OTR code calling a new gabble_im_channel_indicate_security (GABBLE_SECURABLE_ENCRYPTED|GABBLE_SECURABLE_VERIFIED) (or only one of those, or neither of those, as appropriate).

I notice we never specified how those properties did change notification, because our only use of them so far was for SASL channels. Let's retcon them to "they emit PropertiesChanged" in the 0.x and 1.0 spec.

Corner cases:

What happens when we try to send a message and the channel is already TRUST_FINISHED? I think we should refuse, for the rest of the lifetime of that channel (until Close()), to avoid the security flaw where we send messages to a channel that just closed.

What happens when we close a channel locally? I think the answer should be "we terminate the OTR session, and start from an unsecured state next time" - even if the channel is in fact going to respawn due to unacknowledged messages. This means the channel needs to reset its Encrypted flag, Verified flag and all OTR state when it respawns. We will still be able to tell the rescued messages were encrypted/verified because the header that I suggested adding will say so.

What happens if I'm talking to <email address hidden>/Laptop using OTR, and I receive a message from <email address hidden>/Phone without OTR? I hope the answer is "libotr deals with it and reports OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED". Is it safe (as in, not a security vulnerability) to rely on that?

What happens when we receive a message and the channel is already TRUST_FINISHED? I hope the answer is "libotr deals with it and reports OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED". Is it safe (as in, not a security vulnerability) to rely on that?

(In reply to comment #59)
> Ideally, that distinctive message header should be a machine-readable
> version of the message, so OTR-literate UIs (Empathy) can discard the
> untranslated version from Gabble and display something translated. We've
> always had a policy of putting UI strings and their translations in the UIs,
> not the CMs.

The more I think about this, the more I think Gabble should not contain translated strings. It's OK for it to contain strings in the C locale (international English), but all translation should be taking place somewhere that already needs to be translated - the UIs.

As a purely practical thing, Gabble does not have any of the translation machinery, so those strings aren't going to be translated anyway.

Is the OtrlMessageEvent enum sufficiently stable that we can use it in the D-Bus API directly? That would probably be the easiest way. The only other information we need to put in the message header is:

- for OTRL_MSGEVENT_SETUP_ERROR: gcry_strerror (err)
  (perhaps { "otr-error": that string })

- for various codes: the username or account name, which the UI already
  knows anyway

- for OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED: the unencrypted message
  (perhaps { "otr-unencrypted-message": that string })

- for OTRL_MSGEVENT_RCVDMSG_GENERAL_ERR: the message
  (perhaps { "otr-error": that string })

+static void
+otr_handle_smp_event (void *opdata,
+ OtrlSMPEvent smp_event,
+ ConnContext *context,
+ unsigned short progress_percent,
+ gchar *question)
+{
+ DEBUG ("UNIMPLEMENTED\n");
+}

Is this OK/allowed? Should we at least tell libotr "no, I don't implement SMP"?

en_GB speaker review of strings:

+ notify (self, _("An error occurred when encrypting your message and "
+ "not sent."));

This sentence no verb.

Maybe "... and it was not sent"?

+ notify (self, _("Your message was not sent because %s closed their "
+ "connection. Either close your private connection, or refresh it."),
+ context->username);

What does that last sentence mean in Telepathy terms? If it means "you should close this channel" (i.e. close the Empathy window), perhaps "Close this conversation and try again"? (Or perhaps we should even auto-close the channel, but we're trying to get away from self-closing channels.)

+ err_msg = g_strdup (_("You transmitted an unreadable encrypted message."));

Thought bubble: "no, I'm pretty sure I didn't" :-) If this happens, it's presumably either Gabble's fault, or one of the user's other resources, not anything the user themselves typed.

"Internal error: transmitted an unreadable..." instead, maybe?

Same for "You transmitted a malformed data message.".

After fixing the obvious things, it would also be good to get someone who understands the OTR protocol and/or libotr to review this (particularly the things I raised in Comment #59 and Comment #62). I don't think there's any such person among the main Telepathy developers, but perhaps one of the 49 people in Cc can give an informed review?

A brief glance at Empathy:

+ return _("The conversation is currently encrypted with "
+ "OTR but the remote contact has not been "
+ "authentified");

There is no such word. I think you mean "authenticated" and/or "identified".

Download full text (10.6 KiB)

(In reply to comment #58)
> Just doing the spec right now:
>
> > The extra DBus channel interface is implemented using GDBus
> > so it needs to be exported on a different bus name.
>
> Ugh. Can we not do strange hacks like this, please? Either use the
> extensions mechanism, or save it for 1.0.

I don't want to block on 1.0, and I don't want to write obsolete code with tp-glib's codegen. So that's the necessary evil in the meantime.

> + <interface name="im.telepathy.v1.Channel.Interface.OTR1"
> + tp:causes-havoc="experimental">
> + <tp:added version="Gabble 0.UNRELEASED">(Gabble-specific)</tp:added>
>
> If doing this in 0.x, please use o.fd.Channel.Interface.OTR1 and add it to
> telepathy-spec (OK to go via extensions/ until we do the spec -> tp-glib
> dance, though).

I can change the iface name but it doesn't matter much. I would like to avoid extensions/ nightmare though, I don't want to write code using that in master and port it again in next.

> In 1.0, certainly add it to the spec.

Yep, planned to include that in the tp1.0 spec, and consider it private between gabble and empathy in the meantime.

> + A simple D-Bus API <a
> + href="https://otr.cypherpunks.ca/">Off The Record</a>.
>
> "... API for <a..."
>
> + <p>The current trust level of this channel:
> + 0=TRUST_NOT_PRIVATE, 1=TRUST_UNVERIFIED, 2=TRUST_PRIVATE,
> + 3=TRUST_FINISHED</p>
>
> This deserves a <tp:enum> and documentation.

I didn't write it because gdbus-codegen does not use it. Opened https://bugzilla.gnome.org/show_bug.cgi?id=729762 already. But I'll add it in our spec in the meantime anyway, even if it's just for the html version of our spec.

> I assume the meanings go something like this:
>
> TRUST_NOT_PRIVATE: not using OTR at all? (Can we also see this when using
> OTR but something has gone wrong?)
> (o.fd.Channel.I.Securable.Encrypted=FALSE,
> o.fd.Channel.I.Securable.Verified=FALSE)

yes

> TRUST_UNVERIFIED: the channel is encrypted, but you might be talking to a
> man-in-the-middle instead of the peer you expected.
> (o.fd.Channel.I.Securable.Encrypted=TRUE,
> o.fd.Channel.I.Securable.Verified=FALSE)

yes

> TRUST_PRIVATE: the channel is encrypted, and the user has indicated that the
> peer's key fingerprint is trusted to belong to that peer.
> (o.fd.Channel.I.Securable.Encrypted=TRUE,
> o.fd.Channel.I.Securable.Verified=TRUE)

yes

> TRUST_FINISHED: this channel is over, nothing more should be sent or
> received on it.
> (o.fd.Channel.I.Securable.Encrypted and o.fd.Channel.I.Securable.Verified
> keep their previous values?)

I *think* (need to double check) that in that case you'll still be sending encrypted messages but the other side won't be able to decrypt them and will display a message "The encrypted message received from %s is unreadable, as you are not currently communicating privately.".

> What are the possible state transitions? I assume "can only increase"?

I think it can only increase unless the local user did something. Like it can go from PRIVATE to UNVERIFIED if user types "/otr untrust". 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.
...

(In reply to comment #60)
> (In reply to comment #50)
> > Could we also get a config option that turns this whole feature on/off? I
> > ask because some industries (like the one where I work) require that all
> > electronic communications related to the business get recorded and reviewed
> > by compliance officers and made available to regulatory agencies upon
> > request.
>
> I think we do need a connection parameter to control this. I think the
> possible sensible settings are:
>
> - never use OTR, behave exactly as though it was not implemented
>
> - start an OTR conversation if the local user or remote peer explicitly
> requests it
>
> - try to start OTR conversations automatically
>
> I think that would be most comprehensible as two booleans: something like
> "enable-otr" (default false initially, default true after a couple of
> releases) and "enable-opportunistic-otr" (not implemented in Xavier's patch,
> but someone could add it).
>
> The writer of Comment #50 would explicitly set enable-otr to false; the
> people getting excited about this bug would explicitly set enable-otr to
> true, and when implemented, probably also set enable-opportunistic-otr to
> true.

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.

(In reply to comment #61)
> I would really like im-channel to implement o.fd.Telepathy.Securable - as a
> starting point we can have the two booleans not be requestable, and just
> have them set by the OTR code calling a new
> gabble_im_channel_indicate_security
> (GABBLE_SECURABLE_ENCRYPTED|GABBLE_SECURABLE_VERIFIED) (or only one of
> those, or neither of those, as appropriate).
>
> I notice we never specified how those properties did change notification,
> because our only use of them so far was for SASL channels. Let's retcon them
> to "they emit PropertiesChanged" in the 0.x and 1.0 spec.

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.

Download full text (5.1 KiB)

(In reply to comment #68)
> I can change the iface name but it doesn't matter much. I would like to
> avoid extensions/ nightmare though, I don't want to write code using that in
> master and port it again in next.

OK. I still would prefer to use o.fd.T for the 0.x version though.

> > This deserves a <tp:enum> and documentation.
>
> I didn't write it because gdbus-codegen does not use it.

Makes sense, but the documentation value is worth it.

> I *think* (need to double check) that in that case you'll still be sending
> encrypted messages but the other side won't be able to decrypt them and will
> display a message "The encrypted message received from %s is unreadable, as
> you are not currently communicating privately.".

It would make sense to get an OTR expert to confirm that how we're handling this is secure.

> > What are the possible state transitions? I assume "can only increase"?
>
> I think it can only increase unless the local user did something. Like it
> can go from PRIVATE to UNVERIFIED if user types "/otr untrust".

Ah, that's a good point. Please document that transition (although it can only happen because the user did something odd - but that odd thing might make sense as an "undo" mechanism).

I suppose this means that Securable.Verified can turn off as a result of an "undo" button, too...

> 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™.

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.

> 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?

If the machine-readable fingerprint is like "adc83b19e793491b1c6e" (20 hex digits encoding 80 bits of entropy) that should be a string. If it's like "\xad\xc8..." (20 bytes encoding 160 bits of entropy, most likely a SHA-1) that should indeed be an 'ay'.

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?

> 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 thi...

Read more...

(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".

(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.

(In reply to comment #68)
> It doesn't matter, if the message is in the form "?OTR:<base64>" then it
> puts new_content to whatever the original message was (html or not). OTR
> doesn't change anything if user wants to send html message as plaintext,
> empathy will escape when displaying them.

Are you saying that in this message

<message>
  <body>?OTR:123123123</body>
</message>

the recipient is expected to decrypt 123123123 and treat the result as plain text, but in this message

<message>
  <html xmlns='http://jabber.org/protocol/xhtml-im'>
    <body xmlns='http://www.w3.org/1999/xhtml'>
      ?OTR:456456456
    </body>
  </html>

the recipient is expected to decrypt 456456456 and treat the result as HTML? Or what?

There must be a rule you can use to determine whether the decrypted content is text/plain or text/html. "Text that may contain HTML" is not a well-formed concept - either the message "&lt;" is a 4 character reply to "remind me how you escape < in HTML?", or it's a single U+003C LESS-THAN SIGN character. It can't be both.

It is entirely possible that the rule is "do whatever Pidgin does", which in practice probably means it's always treated as HTML - that's what my review comments assume.

(In reply to comment #62)
> Corner cases:
>
> What happens when we try to send a message and the channel is already
> TRUST_FINISHED? I think we should refuse, for the rest of the lifetime of
> that channel (until Close()), to avoid the security flaw where we send
> messages to a channel that just closed.

Just tested, OTR refuse to send and a message is displayed.

"""
<email address hidden>: Your message was not sent because <email address hidden> closed their connection. Either close your private connection, or refresh it.
"""

> What happens when we close a channel locally? I think the answer should be
> "we terminate the OTR session, and start from an unsecured state next time"
> - even if the channel is in fact going to respawn due to unacknowledged
> messages. This means the channel needs to reset its Encrypted flag, Verified
> flag and all OTR state when it respawns. We will still be able to tell the
> rescued messages were encrypted/verified because the header that I suggested
> adding will say so.

I don't end the otr session yet (adding a patch now to do that). pending messages are already decrypted so user won't know if they were sent privately or not. Indeed adding the fingerprint in the message parts can be helpful. otoh I would consider this future enhancement, when a new chat window arrives if there is no message telling its private the user should just assume it's not. He can always start a new otr session and ask to repeat to be sure. IMO that's corner case so it's not that bad if user needs to ask repeating.

> What happens if I'm talking to <email address hidden>/Laptop using OTR, and I
> receive a message from <email address hidden>/Phone without OTR? I hope the answer
> is "libotr deals with it and reports OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED". Is
> it safe (as in, not a security vulnerability) to rely on that?

I didn't test what happens with multiple resources, tbh. But if for any reason something unencrypted arrives, it raises OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED.

> What happens when we receive a message and the channel is already
> TRUST_FINISHED? I hope the answer is "libotr deals with it and reports
> OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED". Is it safe (as in, not a security
> vulnerability) to rely on that?

it does indeed raise OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED.

Download full text (4.7 KiB)

(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 transparen...

Read more...

Voilà, added commits to fix most of your comments. What's missing:

1) handle html, I'm not sure to understand what you mean or why it is that important... Maybe you can make the changes that you want?

2) Find a solution if we don't want the other end to be able to initiate an OTR session without approving it first.

3) Fix string spelling. Maybe you can patch them yourself, as I'm not native? :)

Anything else I missed in those long comments?

(In reply to comment #76)
> 1) handle html, I'm not sure to understand what you mean or why it is that
> important... Maybe you can make the changes that you want?

Looking into it. The more important direction (don't send plain text where HTML is expected, so that parts of messages that happen to look <a bit like html tags> aren't silently ignored) is easy, it just needs g_markup_escape_text().

The other direction (don't send HTML where plain text is expected) is more difficult, but libxml should be able to do it; and if we don't, the failure mode is that a user sees HTML markup instead of plain text, which isn't *so* bad.

> 2) Find a solution if we don't want the other end to be able to initiate an
> OTR session without approving it first.

I think a CM parameter is the only way to do this. It'll work for MC-stored accounts (which includes all Haze accounts and all "unbranded" accounts like generic Jabber/IRC, even if GOA is used), and for UOA-stored accounts.

I agree that GOA's account parameter storage limitations mean it won't work for GOA-stored Google Talk or Facebook accounts, or GOA-stored Windows Live accounts in the unlikely event that Microsoft bring back their XMPP bridge. If you want communications privacy, Google and Facebook are probably not the ideal option anyway... and that GOA issue is not something that Telepathy can fix in any case.

> 3) Fix string spelling. Maybe you can patch them yourself, as I'm not
> native? :)

Sure.

Security issue: it isn't at all clear to me what "trust" means here. In something like GPG or SSL, the trusted assertion is "the key whose fingerprint is ...63c7cc90 is controlled by 'Simon McVittie <email address hidden>'" or "the key whose fingerprint is ... is controlled by the administrators of bugs.freedesktop.org" - it binds a key to a somewhat human-comprehensible identity (name and email address, or domain name). I would have automatically assumed that the same was true in OTR - binding a key fingerprint to a JID (or whatever else the identifier is, in non-XMPP protocols) - but that doesn't seem to be happening here. Instead, we're saying "I trust this fingerprint" but it isn't clear what property of the fingerprint we're trusting. In particular, we don't seem to be binding a fingerprint to a JID.

Concretely, suppose I talk to <email address hidden> and you present key ID 12345678 [1]. I verify out-of-band that that is really your key ID (perhaps by phoning you or receiving GPG-signed email) and mark it as trusted. Next, I talk to <email address hidden> who presents key ID fedcba98, and again, I mark it as trusted. Now Guillaume hijacks your XMPP account, and when I next try to talk to you, Guillaume presents key ID fedcba98. I have "trusted" that key, so my UI doesn't indicate that anything is wrong - but it isn't your key, it's Guillaume's!

How does OTR typically deal with this situation? Do OTR users memorize key IDs and ignore the JIDs and contact names presented by the UI, or does the Pidgin OTR plugin store pairs (JID, key ID) and warn the user if an unexpected pairing is found, or does "trust" here mean "I trust this person not to impersonate any of my other contacts"?

[1] in real life the key ID would be longer than that, but you get the idea

(In reply to comment #58)
> + type="(say)" access="read">
>
> Are these literally the hex and binary versions of the same digest, or do
> they have different information content? (Or is the string version some
> OTR-specific thing that is easier to transcribe than hex?)

I'm not particularly happy about this type duplicating the information: whenever there's duplication, there's the possibility that the duplicates don't agree. I can see why you did it, though - the OTR library doesn't seem to have a function to convert a human-readable digest back into binary (although we could easily write one), so you currently need the binary digest in order to set trust.

If possible I'd prefer to stick to one encoding or the other, consistently - either always a string (which I think is what I'd prefer), or always a byte-array. At the moment we only put the string form in message headers, not the byte-array.

I'm tempted to implement a function to turn the string into binary (decode hex, ignore whitespace, report an error unless it has exactly 40 hex digits) and just use strings throughout.

> I think it would also be useful to spec that one of the forms of the remote
> fingerprint will appear in the message header (0'th part) of each individual
> message, perhaps { "otr-remote-fingerprint": a string }. That would make it
> easy for someone to do either of these things in a race-condition-free way:
>
> * record in the Logger that the messages were encrypted/verified
> * give the Logger a configuration setting "[ ] do not log OTR messages"
> (which it would recognize by seeing that they have an OTR remote
> fingerprint

You added otr-sender-fingerprint to received messages. I think we should also add a fingerprint to messages that were sent during an OTR session, so that we can associate the logged session with the fingerprint (or avoid logging them at all), too.

For now I'm changing it to otr-remote-fingerprint, because that's always the easier one to get - we could use otr-sender-fingerprint and otr-recipient-fingerprint if there's some reason that's better, but just having one seems easier.

(In reply to comment #50)
> Could we also get a config option that turns this whole feature on/off?

Still needed, IMO.

(In reply to comment #61)
> I would really like im-channel to implement o.fd.Telepathy.Securable

Non-blocker but still desirable. Given what I said in Comment #78, I think we can set Encrypted when OTR is active, but we can't set Verified in any case, because the thing that Securable says we Verified (that the key with which we're encrypting belongs to the contact identified by the Channel's Target_ID) does not seem to be what OTR actually verifies.

(In reply to comment #78)
> In particular, we don't seem to
> be binding a fingerprint to a JID.

On closer inspection of libotr, it seems we are indeed binding a (remote username, local account name, protocol) tuple to a fingerprint; the API just doesn't make that obvious.

I've made most of the changes I wanted but haven't had time to test them yet. Use at own risk:

http://cgit.freedesktop.org/~smcv/telepathy-gabble/log/?h=untested-otr

Still to do:

* testing (in particular, send "&lt;" and "<a message that resembles HTML>"
  in both directions between Empathy and Pidgin, and check that neither is
  misinterpreted)

* review from someone who understands libotr

* Empathy: make sure OTR notifications are presented in a way that
  peers cannot fake. Because Empathy doesn't support HTML messages yet,
  distinctive formatting would be enough.

* string-only handling of fingerprints (emit strings to D-Bus,
  parse hex -> binary when asked to trust a fingerprint from D-Bus)

Nice to have, but not blockers:

* TPAW UI for the enable-otr boolean parameter (for now, early adopters
  can turn it on with mc-tool - but I think real UI *is* a blocker for
  switching the default to be enabled)

* Chan.I.Securable.{Encrypted,Verified} integration

* enable-opportunistic-otr boolean parameter, and UI for the same
  (it will end up looking very similar to enable-otr, but with different
  handling in im-channel*.c)

> fp_data = g_variant_get_data (fp_variant);
> fp = otrl_context_find_fingerprint (context, (guchar *) fp_data, 0, NULL);

I'm still considering "use string fingerprints with error-checking" to be a merge blocker, because I don't think this code is OK for the case where fp_data has length != 20 bytes. I think TrustFingerprint("DEADBEEF") should raise InvalidArgument, whereas TrustFingerprint("12345678 12345678 12345678123456781234578") (with any whitespace) should work.

If you strongly prefer the binary encoding, I'd be OK with making TrustFingerprint([a number of bytes other than 20]) an InvalidArgument, but I think string fingerprints are going to be nicer to deal with.

(In reply to comment #81)
> I've made most of the changes I wanted but haven't had time to test them
> yet. Use at own risk:
>
> http://cgit.freedesktop.org/~smcv/telepathy-gabble/log/?h=untested-otr

I did not manage to start an OTR session with this branch.
The '/otr start' command was displaying "OTR:$blob" in empathy-chat.

I did manage to start a session using Xavier's branch but noticed the following bug:
- Start an OTR session between Empathy and Pidgin
- In Pidgin using the OTR menu pick "End private conversation"
- Try sending a message from Empathy. The message doesn't reach Pidgin and this error is displayed: "Your message was not sent because <email address hidden> closed their connection. Either close your private connection, or refresh it."

(In reply to comment #83)
> I did manage to start a session using Xavier's branch but noticed the
> following bug:
> - Start an OTR session between Empathy and Pidgin
> - In Pidgin using the OTR menu pick "End private conversation"
> - Try sending a message from Empathy. The message doesn't reach Pidgin and
> this error is displayed: "Your message was not sent because
> <email address hidden> closed their connection. Either close your
> private connection, or refresh it."

Fwiw, I think I've seen the same message in pidgin when chatting with an adium user who closed the conversation window or something like that.

(In reply to comment #83)
> I did manage to start a session using Xavier's branch but noticed the
> following bug:
> - Start an OTR session between Empathy and Pidgin
> - In Pidgin using the OTR menu pick "End private conversation"
> - Try sending a message from Empathy. The message doesn't reach Pidgin and
> this error is displayed: "Your message was not sent because
> <email address hidden> closed their connection. Either close your
> private connection, or refresh it."

It's not a bug, it's a feature. User must acknoledge that he's not in private chat anymore by typing "/otr stop" or "/otr start".

(In reply to comment #83)
> I did not manage to start an OTR session with this branch.
> The '/otr start' command was displaying "OTR:$blob" in empathy-chat.

You need to set "enable-otr=true" in your CM parameters, otherwise OTR is disabled in Simon's branch. There is magic mc-tool command for that, did not try yet.

Why is the patch protocol-specific?

Would it be possible to use the same code for the new gnome-chat application which will likely replace Empathy?

As far as I understood it can used with gnome-chat or whatever client using telepathy library - once it's upstreamed of course.

(In reply to comment #88)
> As far as I understood it can used with gnome-chat or whatever client using
> telepathy library - once it's upstreamed of course.

Ah, that's great! Also, why was it necessary to make it protocol-specific? OTR is supposed to be useful for any sychronous messaging

(In reply to comment #87)
> Why is the patch protocol-specific?

Telepathy does not have any central point where OTR can be done for all protocols and all UIs simultaneously. We can either do it once per protocol backend, or once per UI. Once per UI would break the ability to log OTR messages or have them appear correctly in more than one UI (e.g. both Empathy and GNOME Shell). Every attempt at implementing OTR in Telepathy has had the plan to do it once per protocol backend; this implementation is no different. In practice, like most new features, everyone prototyped it in the XMPP protocol backend first, because that's the one that works best.

I think the approach that is most likely to yield results in a finite time is to get the XMPP implementation high-quality and mergeable first, then expand to the other protocols; then any implementation mistakes in the first implementation will hopefully not be repeated, and the rest will be a simple matter of "pretty much what Gabble did". Using a library for common code, or adding functionality to libotr, would be fine too, but that's an implementation detail.

Anyone interested in this could add similar glue to telepathy-haze to cover the various proprietary protocols (AOL, etc.). It might have seemed more natural to go for -haze first, but -haze uses libpurple, which is not really designed for things that aren't shaped like Pidgin, so it can be awkward to get right and doesn't make a great place for prototyping. The missing protocol backends after that would be telepathy-salut for link-local XMPP, telepathy-idle for IRC, and telepathy-rakia for SIP. I think it'd make sense to do -haze and maybe -salut. I'm not sure -idle or -rakia is necessarily worthwhile, but if people do use OTR on those protocols in practice, sure, why not.

(In reply to comment #87)
> Would it be possible to use the same code for the new gnome-chat application
> which will likely replace Empathy?

The majority of the glue between Telepathy and libotr (as exemplified here by patches to Gabble), and the design: yes, it lives in the protocol backend(s).

The UI: no, the UI code in Empathy is specific to Empathy. gnome-chat would need to provide a way to enable/disable OTR and mark fingerprints as trusted, and to be properly secure, it would need to display the notifications from libotr in a way that cannot be spoofed by contacts.

Hi

I am currently working on OTR support for KDE Telepathy. There are some
features we would like to have:
- otr policy settings
- a way to generate a new private key for account
- possibility to manage known fingerprints (trust/distrust)
- two additional ways of peer authentication (shared secret and
question-answer)

Realization of the first three points would require adding a new interface
to gabble. I imagine it as an extension of connection interface providing
settings individually for every account. Would using gdbus codegen just
like in case of the currently implemented otr channel be acceptable here? I
suppose that adding these features would mean some major changes in the
current implementation which is completely closed in the channel interface.

There are also things that need to be fixed as stated above:

> Still to do:
>
> * testing (in particular, send "&lt;" and "<a message that resembles
HTML>"
> in both directions between Empathy and Pidgin, and check that neither is
> misinterpreted)
>
> * review from someone who understands libotr
>
> * string-only handling of fingerprints (emit strings to D-Bus,
> parse hex -> binary when asked to trust a fingerprint from D-Bus)

I understand that they have to be done first before introducing new changes?

(In reply to comment #91)
> Realization of the first three points would require adding a new interface
> to gabble. I imagine it as an extension of connection interface providing
> settings individually for every account. Would using gdbus codegen just
> like in case of the currently implemented otr channel be acceptable here?

You could make it go "next to" the Connection just like Xavier's code produces an object "next to" the Channel, yes.

(Unfortunately, the fact that, in general, telepathy-glib uses the deprecated dbus-glib instead of GDBus is not going to get fixed, unless someone with a lot more time available than me picks it up. See the various "Telepathy 1.0" bugs for details.)

> I
> suppose that adding these features would mean some major changes in the
> current implementation which is completely closed in the channel interface.

Making behind-the-scenes C function calls between the Connection and Channel objects is fine.

> There are also things that need to be fixed as stated above:
> ...
> I understand that they have to be done first before introducing new changes?

Yes, I think that would be better than hoping they will be fixed later.

I consider those fixes to be merge blockers for these branches, because I don't want to add an interop and security feature that, on closer inspection, turns out to be non-interoperable or insecure :-)

What is the status of this project? Is it dead?

god (humper) wrote :

As good as dead if you care about security. Luckily there are plethora of alternatives out there with OTR support. See http://otr.im for details.

Displaying first 40 and last 40 comments. View all 241 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.