[Telepathy] Telepathy Support for OTR - Round 2

[WolfRage]

First sorry for the long delay between emails. I was traveling and once
I did get home I needed time to adjust to the new addition to the
family. I also had to catch myself back-up to speed on OTR and
Telepathy.
I am going to respond to all three of the emails that I received back
all at once using the standard notation, hopefully this will bring every
one back up to speed. Sorry for the overly long email. 
I will also be posting this working email to the bug post, bug #16891,
which should meet everyones requirements.

> > On Wed, 2010-12-22 at 03:11 +0430, WolfRage wrote:
> > Hello Developers of Telepathy,
> > 
> > This is the beginning of many emails to come as we discuss and iron
out the details of OTR support in Telepathy.
> 
> \o/ :)
> 
> > This is my thought process or plan so far: If the CM that is being
used
> >  has OTR built into then OTR will be available, but not started, it
can
> >  be activated via the D-Bus. By available I mean that the CM will
> >  provide the preferences below signifying that the capability for
OTR
> >  exists. User's will have preferences implemented through:
> 
> Hard to look at things just by the property names, especially for
those
> on the list that haven't discussed things with you on the telepathy
irc
> channel :) (btw it's org.freedesktop.Telepathy.Connection, not
> Connections)

I felt this was the best way to discuss the properties, as it is the
way 
that I was introduced to them. Also if some one seriously wants to
provide input
to the OTR portion of telepathy I feel they should take some time to
understand
the architecture of telepathy as I have. Also thank you for the
correction I will
use the correct property in the future.
> 
> >  org.freedesktop.Telepathy.Connections.Interface.OTR.Advertise(b)
> >  {PROPOSED}
> 
> This is, i assume, about actively advertising OTR in direct text chat
by
> using the spaces and tabs morse code thingy (and not about advertising
> it in, say, your xmpp disco capabilities)?

Yes, this will decied whether or not that happens as a setable property,
defaulting
to false.
> 
> >
org.freedesktop.Telepathy.Connections.Interface.E2ESecurity.Opportunistic(b)
> >  {PROPOSED}
> 
> And this one would be about opportunistically enable E2E security
> without the user asking for it.

Yes
Advertise will be to have the program show it has OTR capabilities.
Opportunistic will
tell the system to enable OTR if the other program Advertises OTR. 
> 
> 
> > Default settings for the Securable properties of a OTR aviable
channel will be:
> >
org.freedesktop.Telepathy.Channel.Interfaces.Securable.Encrypted(b)=FALSE
> >
org.freedesktop.Telepathy.Channel.Interfaces.Securable.Verified(b)=FALSE
> >
org.freedesktop.Telepathy.Channel.Interfaces.Securable.Upgradeable(b)=TRUE
> >
org.freedesktop.Telepathy.Channel.Interfaces.Securable.EncryptionRequired(b)=FALSE {PROPOSED}
> >
org.freedesktop.Telepathy.Channel.Interfaces.Securable.EncryptionInterface(s)="OTR" {PROPOSED}
> 
> Does this refer to yet another interface on the channel that indicate
> some OTR specific bits about the encryption ? And if so which ones?

Securable has been added by Simon and so I am simply extending his
interface with 
a few more properties for OTR.
> 
> >
org.freedesktop.Telepathy.Channel.Interfaces.Securable.EncryptionState(u)=0 {PROPOSED}
> >
org.freedesktop.Telepathy.Channel.Interfaces.Securable.AuthenticationChannel(o)=org.freedesktop.Telepathy.Channel.Interface.OTRAuthentication {PROPOSED}
> 
> That should just be pointing to a channel object path, not an
interface.

OK, I was just following the convention created by Cosimoc. I will
correct this.
> 
> As a general nitpick i'm not sure if Securable isn't too general,
> something that would indicate that this is e2e security would be good.

I am willing to change it, but I think this will be a larger discusion
with Simon. 
> 
> > The Object org.freedesktop.Telepathy.Channel.Type.PeerAuthentication
> >  {DRAFT} will be inherited by
> >  org.freedesktop.Telepathy.Channel.Interface.OTRAuthentication
> >  {PROPOSED}
> > 
> > The Object org.freedesktop.Telepathy.Authentication.Proposal {DRAFT}
> >  will be inherited by
> >  org.freedesktop.Telepathy.Authentication.Proposal.OTR {PROPOSED}
> 
> Why is there a need for OTR specific interfaces here? How does OTR
> autthentication/verification differ from say XTLS? Also if we're
calling
> the channel property Verified we should probably use that jargon in
> these names as well.

This is a tough one to answer, as I have briefly learned about XTLS, but
my focus is on OTR. However I do believe that there are many
differences,
for one the handshake is very different from that of XTLS. OTR conducts
it's
handshake in plaintext and continues to establish the secure stream
completly
on top of the chat, not as a seperate stream. So the protocol for the
two
are quite different in both behavior and initiation. 
> > 
> > Please note: I am recommending that
> >  org.freedesktop.Telepathy.Channel.Interfaces.Encryptable {DRAFT} be
> >  renamed, or that some of the properties and methods be moved to
> >  org.freedesktop.Telepathy.Channel.Interfaces.Securable as DRAFT
> >  properties.
> 
> That's fine that's why it's a draft.
> 
> > I am looking for feedback on what people's thoughts on this plan so
far
> >  are, also any suggestions and ideas that people have for input will
be
> >  reviewed by myself. 
> > 
> > I still have a lot of developer reading to do, I have been working
my
> >  way into and through the documentation for OTR, and Telepathy. I
also
> >  need to do some code familiarization for Butterfly, but things are
> >  progressing smoothly as I have time I will continue to absorb all
that
> >  I can. I have so far taken the e2e-encryption spec branch that was
> >  created by cosimoc and re-based it against the current spec branch.
I
> >  will continue to keep my branch up to date as I work, I hope that
> >  re-base at least once a month, to reduce the headaches when we
finally
> >  to try to merge the OTR branch back in.
> 
> Please don't take the big-bang approach, start requesting merging for
> bits and pieces ASAP. It's fine to have DRAFT specification in
> telepathy-spec and ditto in CMs. For the process to work well, merging
> bits and pieces that can be reviewed is important :)

To be honest I did not understand this comment, completely. I think I
am 
only scratching the surface of what needs to be done. So far I am only
doing spec work, which is what I was told should be done before I code.
I agree with that as it will reduce the errors and the number of changes
that I make to my code. Which hopefully will make the code stable
faster.
But once this email is underway, I will begin typing up the code
changes,
and then get them to you and the others for review.
> 
> >  There is obviously still lots
> >  of work to be done just on Spec alone before I begin to program
> >  anything. I plan on programming support for OTR in Butterfly CM
first
> >  as it is programmed in python, the language I am most comfortable,
> >  then I will port it to Haze (libpurple) and latter to the other
CM's. 
> 
> 
> 
> -- 
> Sjoerd Simons <sjoerd.simons at collabora.co.uk>
> Collabora Ltd.
Thank you Sjoerd for your comments. 

-----------Next is the Email from Simon----------------

> On Wed, 22 Dec 2010 at 03:11:19 +0430, WolfRage wrote:
> > My purpose here is to patch this bug #296867 (Launch Pad) which is
bug
> > #16891 on the Free Desktop Bugzilla.
> 
> FWIW, Telepathy's official bug tracking is via freedesktop.org, so we
generally
> consider fd.o bug numbers to be the important one; Launchpad bugs are
> specific to Ubuntu (or other projects hosted on Launchpad, which we're
not).

I understand, I was simply stating that I filed my bug via Launchpad and
that
is the bug that I initially set out to fix. I do understand that
telepathy
is not a launchpad project, and will use the Free Desktop bug number
from now
on.
> 
> We usually do this sort of discussion on a fd.o bug report so it's
easier to
> find (mailing list archives split by month aren't very useful for
long-running
> projects). If you don't mind, I'll direct subsequent discussion to the
> relevant bugs - anyone who's interested in following it can add
themselves to
> the bugs' Cc lists.

OK I will post this and future discussion there as well and I agree
mailing-list
can be hard to follow.
> 
> You may find it easier to discuss things in email / on bugs if you
abbreviate
> org.freedesktop.Telepathy to ofdT throughout :-) I've done that when
quoting
> you, for a bit more clarity.

Glad to not have to type out ofdT any more thanks for the abreviation. 
> 
> > ofdT.Connections.Interface.OTR.Advertise(b) {PROPOSED}
> 
> (It's Connection, not Connections.)

Noted, thank you.
> 
> This would presumably be a ConnectionManager parameter [1] with the
> Conn_Mgr_Param_Flag_DBus_Property flag indicating that it's also the
name of
> a D-Bus property [2]?
> 
> [1]
<http://telepathy.freedesktop.org/spec/Connection_Manager.html#Method:RequestConnection>
> [2]
<http://telepathy.freedesktop.org/spec/Connection_Manager.html#Flags:Conn_Mgr_Param_Flags>
I will need to research this and get back to you.
> 
> > Default settings for the Securable properties of a OTR aviable
channel
> > will be:
> 
> (D-Bus terminology: these are properties.)
> 
> > ofdT.Channel.Interfaces.Securable.Encrypted(b)=FALSE
> > ofdT.Channel.Interfaces.Securable.Verified(b)=FALSE
> > ofdT.Channel.Interfaces.Securable.Upgradeable(b)=TRUE
> 
> (It's Channel.Interface, not Interfaces.)

Noted, thanks.
> 
> Upgradeable=TRUE doesn't seem to tell us whether it's possible to make
> Encrypted become true, or whether it's possible to make Verified
become true,
> or both. Perhaps Encryptable, Verifiable as separate properties?

When I was thinking of these properties, I think that Encrypted tells us
if the channel
is currently encrypted, same with verified. But Upgradeable indicates
that they can
be encrypted.
I created them to use more boolean values and less unsigned integer
values. 
We discussed this as a better way to limit the choices for a property.
These would replace
ofdT.Channel.Interface.Encryptable.DRAFT.EncryptionState and
ofdT.Channel.Interface.Encryptable.DRAFT.EncryptionStateChanged
> 
> > ofdT.Channel.Interfaces.Securable.EncryptionRequired(b)=FALSE
{PROPOSED}
> 
> This is presumably requestable (includable in a channel request) but
can't
> otherwise be changed?
> 
> I'm not sure that we need this property - we could just say that
putting
> Encrypted=TRUE in a channel request means encryption is required? In
practice
> the recommended thing would be to say Encrypted=TRUE, Verified=TRUE
(to require
> both), or not mention either of them (to have the default behaviour -
> opportunistic encryption if you don't mind server-side logs becoming
useless,
> or no encryption if you want server-side logs to be useful).

Interesting, I felt that the two properties would only be set to true
once that
had been confirmed, that is the way Cosimoc intended any ways.
But for EncryptionRequired, this would be false, as OTR can encrypt
virtually
any chat(IM) protocol. But you are right it may not be needed. 
> 
> I suppose if you'd enabled opportunistic encryption, it might even
make
> sense to say Encrypted=FALSE in a channel request, to turn off
opportunistic
> encryption for this one channel (so that it can usefully be logged by
your
> server), but that's pretty obscure.

OK.
> 
> >
ofdT.Channel.Interfaces.Securable.EncryptionInterface(s)="OTR" {PROPOSED}
> 
> Shouldn't the value of this property be a D-Bus interface name, such
as
> ofdT.Channel.Interface.OTRAuthentication?