[Bug 29904] Support end-to-end encryption and authentication

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=29904

--- Comment #7 from WolfRage <sites at wolfrageweb.com> 2011-02-11 05:36:47 PST ---
> > 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?

>From what I read in cosimoc's spec, the answer is no, and this is the way it 
would be set. But since that is draft we can change that so that it makes 
more sense.
> 
> > ofdT.Channel.Interfaces.Securable.EncryptionState(u)=0 {PROPOSED}
> 
> Moved from the Encryptable proposal, presumably?

Yes and this may be better than the other methods above.
> 
> > ofdT.Channel.Interfaces.Securable.AuthenticationChannel(o)=ofdT.Channel.Interface.OTRAuthentication {PROPOSED}
> 
> I assume you mean "the object path of a channel implementing
> OTRAuthentication"?

Yes, how would I properly show that for the spec?
> 
> For generic E2E support, this would in fact have to be the object path of
> a channel implementing both ofdT.Channel.Type.PeerAuthentication and the
> interface mentioned in the EncryptionInterface property (which would
> be either OTR or XTLS to start with).

OK, thank you, but how should it look?
> 
> > Please note: I am recommending that ofdT.Channel.Interfaces.Encryptable
> > {DRAFT} be renamed, or that some of the properties and methods be moved
> > to ofdT.Channel.Interfaces.Securable as DRAFT properties.
> 
> Encryptable should indeed be called Securable - I made that change while
> adding a partial version of it to the spec. For E2E support, you'll probably
> need the rest of the interface.

I agree and I like what you had added so far, just hoping to enhance it
further.
> 
> The DRAFT thing only works at a per-interface granularity, so the way to do
> this would be to have something like this:
> 
> ofdT.Channel.Interface.Securable (stable)
> ofdT.Channel.Interface.Securable.DRAFT (not stable)
> 
> and move properties from the draft to the stable one as they become stable.

OK I appreciate that insight and will make sure I type it correctly in the
spec.
> 
> > 1. git://gitorious.org/wolfrage-telepathy/otr.git  My git branch for Spec, re-based with Origin.
> 
> For those following along at home, the web interface for that branch is
> <http://gitorious.org/wolfrage-telepathy/otr>. Some quick notes about that:
> 
> Your commits that say "Re-basing the file forward" seem to have lost their
> original commit messages? Commit messages should briefly describe what changed
> (first line) and why (subsequent lines, after an empty line). Browse
> through the git history to see how they work in practice.

I fixed much of this by not rebasing.
> 
> You seem to have committed the conflict marker lines (starting with <<<<<<<,
> =======, >>>>>>>), which isn't how they're meant to work (and will break
> processing of the XML). When you get conflict markers, it means that changes
> made in one commit conflicted with changes from another commit, and git
> couldn't work out what the desired result is. The intention is that you work
> out how to merge the two sets of changes ("resolve the conflict"), delete
> the conflict markers and commit the result.
> 
> For instance, if a commit from you and a commit from Cosimo both added some
> text, the right conflict resolution might be to add both bits of text - unless
> your text and Cosimo's text contradict each other or are redundant, in which
> case you might choose one and delete the other.

OK I understand a little better, but as you have seen GIT is not my strong
suite,
perhaps in the future I will get better with GIT.
> 
>     S

-----------Next is the second Email from Sjoerd----------------

> On Mon, 2011-01-03 at 11:48 +0000, Simon McVittie wrote:
> > 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).
> > 
> > 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.
> > 
> 
> Yeah, but people don't. I'd really prefer it if we used the mailing-list
> to get at least a rough consensus and afterward have the details worked
> out on bugreport. Mailinglists really have a much higher visibility for
> people so are easier to take part in for the casual observers that don't
> want to subscribe to lots of bugs :)

Hopefully posting in both areas will suffice and will not bloat the bug too
much. 
> 
> -- 
> Sjoerd Simons <sjoerd.simons at collabora.co.uk>
> Collabora Ltd.

In closing, I will be updating Cosimoc's spec and will post that to my 
GIT in the coming days, and we will change it as we go. Because 
I have enough of a start that I should begin putting it all into writing.
Looking forward to all replies and thank you all for your help.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.