Ch.Type.ClientAuthentication: it would be good to document what is TargetHandle and TargetHandleType will look like. 0 and 0 ?

It doesn't seem to be possible to "upgrade" an encrypted channel. For example, if we have a lockdown icon in Empathy's chat window or something, does that mean Empathy will have to request a new channel and replace it by the insecure one?

(In reply to comment #1)
> Ch.Type.ClientAuthentication: it would be good to document what is TargetHandle
> and TargetHandleType will look like. 0 and 0 ?

Yeah, that's the idea; the ClientAuthentication channel is anonymous and the requesting channel would be added to its TargetChannels.

> It doesn't seem to be possible to "upgrade" an encrypted channel. For example,
> if we have a lockdown icon in Empathy's chat window or something, does that
> mean Empathy will have to request a new channel and replace it by the insecure
> one?

Right; I didn't originally take into account this use case, but as there's really nothing in the interfaces requiring that a channel should only be encrypted at creation time, this could probably be easily solved by adding a method to the Encryptable interface:

- UpgradeToEncrypted (s: EncryptionInterface)

which at the same time sets EncryptionRequired to True, EncryptionInterface to the provided interface, and fires up the authentication machine.

I will update my branch according to your comments.

General comments:

Every property should either hyperlink to the signal that provides its change notification, or say that it is immutable for the lifetime of the object, or say that it can change but has no change notification (in the latter case, which should be unusual, you should explain when it would make sense to poll it).

(In reply to comment #0)
> To accomplish that, I added basically three fundamental types to the
> specification: the Encryptable interface, the ClientAuthentication channel
> type, and the Authentication.Proposal transient object. On top of them I also
> drafted some protocol-specific implementations.

Terminology: of these, I'd say only Authentication.Proposal is a fundamental type (i.e. least derived object - the others appear on a Channel), and if you say "the Encryptable channel interface" or "Chan.I.Encryptable" it's easier to see what's going on at a glance :-)

There are lots of mentions of "Encryption" and "Authentication" here where I'm not sure that the usage is actually valid - it seems strange for EncryptionInterface to have Chan.I.XTLSAuthentication as a value. Perhaps this indicates that the interface should be called Chan.I.XTLSEncryption, Chan.I.XTLSSecurity or just Chan.I.XTLS, or that the property should be called something else.

EncryptionInterface should document what sort of interface it could be, perhaps with wording like "The interface that will appear on a Chan.T.ClientAuthentication channel representing the encryption mechanism, such as Chan.I.XTLSAuthentication".

AuthenticationChannel needs to be "nullable" - in Telepathy we do this by reserving the object path '/' to be the pseudo-null value (see ofdT.Account.Connection for appropriate wording). Otherwise, there's no sane value for the property at times when there's no authentication channel (and every property must have a value at all times, even if that value is useless).

Relatedly, I suspect EncryptionStateChanged should have signature (u: State, o: Authentication_Channel) so AuthenticationChannel has change notification?

> I thought this being a requestable property here could also play nice with the
> fact that a CM could advertise the possible protocols in
> RequestableChannelClasses.

Yeah, about that. It's worth documenting what a CM is expected to have in its RCCs (so that clients probing for support will look for the right things). As far as I can see, for your current proposal, that text would look something like this:

-------------------------------->8-----------------------------------

A connection manager supporting end-to-end secured channels should include EncryptionRequired in the allowed properties of each requestable channel class that supports this.

The connection manager should also duplicate the "basic" requestable channel class once for each supported value of the EncryptionInterface property, with that property added to the fixed set.

For instance, if you support encrypting text channels with either XTLS or OTR, and you support StreamedMedia channels which cannot be encrypted, you might have these requestable channel classes:

Fixed = { ...ChannelType: ...Text, ...TargetHandleType: CONTACT }
Allowed = [ ...TargetHandle, ...TargetID, ...Chan.I.Encryptable.EncryptionRequired ]

Fixed = { ...ChannelType: ...Text, ...TargetHandleType: CONTACT, ...Chan.I.Encryptable.EncryptionInterface: ...Chan.I.XTLSAuthentication }
Allowed = [ ...TargetHandle, ...TargetID, ...Chan.I.Encryptable.EncryptionRequired ]

Fixed = { ...ChannelType: ...Text, ...TargetHandleType: CONTACT, ...Chan.I.Encryptable.EncryptionInterface: ...Chan.I.OTRAuthentication }
Allowed = [ ...TargetHandle, ...TargetID, ...Chan.I.Encryptable.EncryptionRequired ]

Fixed = { ...ChannelType: ...StreamedMedia, ...TargetHandleType: CONTACT }
Allowed = [ ...TargetHandle, ...TargetID, ...Chan.T.StreamedMedia.InitialAudio ]

-------------------------------->8-----------------------------------

I'm a little worried about potential combinatorial explosion if we go in this direction for EncryptionInterface, though...

I wonder whether it's actually appropriate for clients that upgrade to e2e to specify how in UpgradeEncryption? It seems to be a design goal that Empathy can flip the "encrypt me" bit and Seahorse or something can pop up to do the actual crypto handshaking? If that's the case, then we could detect from handlers' filters, or perhaps handler capability tokens, what sorts of handshake we have UI for.

An alternative API for upgrades would be for a second channel to pop up, replacing the first, using a more general form of Conference (Chan.I.Continuable?). Naive clients not understanding Continuable would handle it as if it was a new channel. That approach is probably harder to work with for clients, but might lead to easier conceptual design.

> The method does nothing if EncryptionRequired  is already True.

This implicitly assumes that there are only two levels of encryption/authentication - "not enough to mention" (which includes "none") and "fully secure" - and it doesn't matter which specific mechanism you're using. This is probably true, but it's worth thinking about.

> ----------------------------
> Ch.Type.ClientAuthentication
> ----------------------------
> 
> It's the channel that will be dispatched to authenticate the encryption
> process. The base object also keeps track of the channels around that use this
> authentication, by using the TargetChannels property.
> 
> Channel.Interface.XTLSAuthentication is an XTLS interface for this kind of
> channel, and one might also write Channel.Interface.OTRAuthentication on the
> same line.

The Description could do with an overview of this object's life cycle: when you'll get one, how you proceed, and when you can consider it dead.

AuthenticationProposals and XTLSAuthenticationStateReason should document what their change notification is (looks like the answer is ProposalsReceived and XTLSAuthenticationStateReason, respectively).

Is it valid for ProposalsReceived to be emitted with a set of proposals that is smaller than the previous value of AuthenticationProposals? (My guess: no. Please answer in the form of a spec patch :-)

In each XTLS_Authentication_State it would be good to document where to go next, with a hyperlink. My guesses:

* Not_Started: you say SendMechanisms but you're missing a <tp:member-ref>

* L_M_S: just wait

* R_M_R: call methods on the AuthenticationProposals?

* Success: Close()?

* Failed: Abort()?

How does XTLSAuthentication.Abort() differ from Channel.Close()? When would you call one? When would you call the other? Should Abort() take some sort of reason code?

Are there any sensible values for XTLS_Authentication_State_Change_Reason that are less vague than "Rejected" or "Error"?

The Mechanism type's name is far too vague. Authentication_Mechanism, please - remember that types are a flat namespace (this one would come out as TP_STRUCT_TYPE_MECHANISM in current telepathy-glib).

SendMechanisms' argument should probably be documented as Mechanism[] rather than Mechanism_List? (Either works, I believe.)

> -------------
> Auth.Proposal
> -------------
> 
> It's a transient object that can be used to complete the authentication step.
> Each proposal implements one interface, which defines the protocol-specific
> methods to accept it.
> 
> How exactly the proposal objects are used and constructed is up to the
> interface of the ClientAuthentication channel.
> 
> I drafted implementation for Auth.Proposal.X509 and Auth.Proposal.SRP, to be
> used with the XTLSAuthentication interface.

Proposal.Interface should perhaps be Proposal.Type or Proposal.ProposalType, consistent with Channel.ChannelType (the model is that channels have exactly one type, and n interfaces). Proposal should probably have an Interfaces property for future expansion, too.

X509
====

X509 should have a brief overview of how to operate it in its Description (just mentioning all the methods in the right order would be valuable). A hyperlink to the appropriate RFC or XEP would be extremely valuable.

X509_Authentication_State_R_C_R should hyperlink Accept.

In X509StateChanged, what does "a good path for accepting a remote certificate or sending one" mean? Does it mean "the handler should respond according to the state, perhaps by accepting a remote certificate or sending a local certificate"?

Is RemoteCertificate mutable? (Guess: yes.) What is its value if there is no remote certificate yet? (Guess: '/'.) What is its change notification?

Likewise for LocalCertificate. If there is no change notification, that's probably OK, but you should explicitly say so.

Is RequestedIdentity mutable? What is its change notification?

Is LocalX509Fingerprint mutable? What is its change notification?

Which properties are valid to pass to SendMechanisms and which are mandatory? (Guess: LocalCertificate is optional, LocalX509Fingerprint is mandatory.)

SRP
===

Are there any less vague error codes that could be used?

There is an error code for Invalid_Username but I don't see any mention of a username anywhere in the interface?

This badly needs an introduction, if only via a hyperlink to the relevant RFC, to explain what "password" means in this context. Based on spec meetings, my understanding is that the two parties are meant to communicate out of band (phone call, in person, etc.) and agree on a password.

> There's a last object, which is Ch.Type.ClientTLSConnection, which is a way to
> exchange TLS certificates between clients; this is usually needed after SRP,
> and a channel of this kind would use the same Encryptable/ClientAuthentication
> process described before to signal that the exchange is linked to a previously
> authenticated session.

ClientTLSConnection doesn't seem like the right name for its functionality, if it's meant to pop up with EncryptionRequired=TRUE already - it's not establishing any sort of TLS'd connection, just exchanging certs. ClientCertificateExchange, perhaps?

What is the target handle type of a ClientTLSConnection? I assume only CONTACT makes sense?

The introduction should explain how the two possibilities (incoming and outgoing) work.

Say what requestable channel classes are expected?

Is RequestedIdentity our identity, or that of the other guy?

Is Incoming redundant with Requested? If so, we can delete it.

ReceiveCertificate() and ProvideCertificate() should raise a specified error (Invalid_Argument, probably) if called on a channel of the wrong direction.

Did you get the Requested semantics of ProvideCertificate and ReceiveCertificate backwards? They look backwards to me but perhaps I'm not seeing it clearly enough.

Why is the received certificate a TLSCertificate and not just a Certificate_Data[]? I can't see what it would mean to accept or reject it at this stage, since it's just being provided for future reference?

(In reply to comment #2)
> (In reply to comment #1)
> > Ch.Type.ClientAuthentication: it would be good to document what is TargetHandle
> > and TargetHandleType will look like. 0 and 0 ?
> 
> Yeah, that's the idea; the ClientAuthentication channel is anonymous and the
> requesting channel would be added to its TargetChannels.

I think it would make sense to have TargetHandleType=CONTACT and TargetHandle set, if it is guaranteed that the THT and TH of every target channel will match those values. In practice, I suspect that will always be true, since we are after all authenticating with a specified client?

Client already means something different in Telepathy, so I wonder whether we should be calling these something different, perhaps chosen from:

* EndToEndAuthentication
* EndAuthentication
* PeerAuthentication

I quite like PeerAuthentication as a name for this, actually.

Simon, thanks for the great review! I fixed your comments in my branch.
Below is some feedback to your open questions.

The only thing among your comments that I did not touch are the added error reasons you asked for Ch.I.XTLS and Auth.Proposal.I.SRP, because either I'm not sure what to add (in XTLS case, more specific details for the error are available on the protocol-specific interface of the chosen proposal object) or can't really find other relevant error codes (in SRP case; GnuTLS also has only Invalid_Username and Invalid_Password as SRP-specific errors. OTOH it's true that other TLS errors could happen there, but do we really need this level of detail there?)

(In reply to comment #3)

> I wonder whether it's actually appropriate for clients that upgrade to e2e to
> specify how in UpgradeEncryption? It seems to be a design goal that Empathy can
> flip the "encrypt me" bit and Seahorse or something can pop up to do the actual
> crypto handshaking? If that's the case, then we could detect from handlers'
> filters, or perhaps handler capability tokens, what sorts of handshake we have
> UI for.

I think it's not a bad thing to let clients decide which interface they should upgrade with, but you're right in saying that doesn't need to be mandatory. So, I made it optional, and it works similarly to what happens if the Encryptable channel is requested with EncryptionRequired = True but an empty AuthenticationInterface.

> An alternative API for upgrades would be for a second channel to pop up,
> replacing the first, using a more general form of Conference
> (Chan.I.Continuable?). Naive clients not understanding Continuable would handle
> it as if it was a new channel. That approach is probably harder to work with
> for clients, but might lead to easier conceptual design.

Doesn't this break the 'not having to handle more than one channel for encryption' rule? Also, I'm not sure what you don't like in UpgradeEncryption().

> This implicitly assumes that there are only two levels of
> encryption/authentication - "not enough to mention" (which includes "none") and
> "fully secure" - and it doesn't matter which specific mechanism you're using.
> This is probably true, but it's worth thinking about.

Yeah, you're right from an Encryptable interface point of view (you're either encrypted or you aren't), though the real degree of encryption/authentication is not something you can easily condense into a property, and in this model it is given for a channel by this encryptable bit combined with protocol-specific information (you could e.g. be encrypted on a leap-of-faith authentication, ...). OTOH I don't think it makes any real use allowing to call UpgradeEncryption() on an already encrypted channel (the only good reason to do so would be 'get even better encryption', but that's hard to define and tricky to get for the reasons I outlined before).

> Proposal.Interface should perhaps be Proposal.Type or Proposal.ProposalType,
> consistent with Channel.ChannelType (the model is that channels have exactly
> one type, and n interfaces). Proposal should probably have an Interfaces
> property for future expansion, too.

I changed this to Proposal.ProposalType for consistency with Channel, but didn't add the Interfaces property yet, as I'm not sure what it would be useful for right now.
Maybe we can always add it later if it's needed?

> ClientTLSConnection doesn't seem like the right name for its functionality, if
> it's meant to pop up with EncryptionRequired=TRUE already - it's not
> establishing any sort of TLS'd connection, just exchanging certs.
> ClientCertificateExchange, perhaps?

Yes, I renamed it to ClientCertificateExchange.

> Did you get the Requested semantics of ProvideCertificate and
> ReceiveCertificate backwards? They look backwards to me but perhaps I'm not
> seeing it clearly enough.

No, it's not backwards. I hope I made it super-clear how it works now in its description.

> Why is the received certificate a TLSCertificate and not just a
> Certificate_Data[]? I can't see what it would mean to accept or reject it at
> this stage, since it's just being provided for future reference?

Good point, I changed that.

(In reply to comment #4)
> * PeerAuthentication
> 
> I quite like PeerAuthentication as a name for this, actually.

I chose this too.

Cosimo isn't actively working on this right now, so back to NEW / the mailing list as assignee. WolfRage seems interested in picking up the generic end-to-end infrastructure for Bug #16891, though.

I'm going to split this bug up: Bug #29904 is the generic infrastructure needed for both OTR and XTLS, and I'll clone a bug for the XTLS-specifics.

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

Created attachment 44884 [details]
A diagram showing current spec changes for E2E.

Please review initial patch and provide me with feedback. Please note this is my first submittal to an open source project so you may need to guide me a little in your comments; sorry that means extra work on the part of the reviewer. 
This is to provide an initial framework for end-to-end security by providing a means for authentication and encryption, both will be extended in the future to provide some standard methods of authentication and encryption.
I have also attached a diagram to better show what I am going for, I needed it to prevent myself for making changes in to many places. 
A few ideas for discussion: Perhaps it would be better to move the ofdT.channel.Interface.Authentication.Draft method and properties into ofdT.channel.Interface.Secureable.Future do you agree or should the two remain separate. I think they should be together as Secureable better implies a channel that is both authenticated and encrypted this secure. This would also simplify API changes.


GIT repo
https://gitorious.org/wolfrage-telepathy/otr/commits/e2e-otr

Created attachment 44888 [details]
Shows Proposed E2E solution

This document shows the Proposed E2E solution. With this the general steps for establishing a secured connection would be:
1: Check the Upgradeable property to ensure the channel can be upgraded. (Assuming True; next step)
2: Set the property EncryptionInterface and call method Secure.
3: Watch the EncryptionState property; once verified set Encrypted property to True. (Or depreciate this duplicate property.)
4: Set the property AuthenticationInterface and call method Authenticate.
5: Watch the EncryptionState property; once verified set Verified property to True (As the channel is now secured because it is both Encrypted and Authenticated).
Please provide feedback, thank you. 
More work to complete incorporate OTR is too follow.

Please review Spec Changes here: http://gitorious.org/wolfrage-telepathy/otr
I may need a lot of feedback as it is my first submission. Thank you.

A related thread starts here:

http://lists.freedesktop.org/archives/telepathy/2012-June/006122.html

That thread discusses using SRTP for XMPP/Jingle sessions. What about ZRTP which is another option?

See http://xmpp.org/extensions/xep-0262.html

Feedback on ZRTP's security properties would be appreciated; it isn't entirely clear to me what ZRTP's security model is. Please see the list of security properties in <http://lists.freedesktop.org/archives/telepathy/2012-June/006122.html> for a useful starting point: which of those properties does ZRTP-over-Jingle have?

From a brief look at the specifications, it looks to me as though ZRTP is an alternative to DTLS as a layer over SRTP, providing (at least) confidentiality from passive attackers, integrity, and what I called "weak authentication" in that email (i.e. if you trust the path followed by your XMPP messages, then you can trust that you are talking to the peer you think you are), and perfect forward secrecy.

It appears to have several ways to get from weak to strong authentication: PGP or X.509 signatures, its own interactive handshake (the "short authentication string") analogous to SMP in OTR, or ssh-style key-continuity. Which of these are actually used in practice?

I'm not sure whether it has anonymity or replay protection. Feedback welcome.

Ideally, Telepathy UIs would not have to distinguish between ZRTP and DTLS, except possibly by one of them having more "security feature" flags than the other (if their security properties differ). However, it appears the authentication handshake has to be interactive at least some of the time (as for OTR); and if both are implemented, there's probably a need for a way to choose whether to try to use ZRTP or DTLS, and which set of long-term credentials (if any) to present.

Hopefully much of the Farsight work needed for DTLS+SRTP and ZRTP+SRTP, and some of the Telepathy design needed for each of XTLS, DTLS, ZRTP and OTR, would be the same?

One possible starting point for use of ZRTP would be to encrypt Jingle calls opportunistically and transparently, without worrying about whether the IM server can perform a man-in-the-middle attack or signalling that the call is encrypted; that would not be full end-to-end security, but it would at least get calls up to the same security status as IMs and presence ("if you trust your server, the peer's server and the hops between them, then everything is fine"), and it could be done in parallel with the (rather tricky) design for how the authentication bits work, I think.

I suspect most of the things I said later in the email thread apply equally if you replace DTLS with ZRTP (and TLS-SRP with the short authentication strings) throughout. Authentication is hard, authentication where the UI is in another process doubly so.

Supporting both ZRTP and DTLS for Call channels would have the disadvantage that we have to be able to choose (somehow) which one to use for a particular call. If one of them is "strictly better than" the other, that's easy, but if each of them has desirable properties that the other does not, then we have to know (somehow) which properties the user values more...

> Supporting both ZRTP and DTLS for Call channels would have the disadvantage that we have to be able to choose (somehow) which one to use for a particular call.

The benefit though is compatibility with more clients, some of which may already support ZRTP, but may be not Jingle over DTLS.

Hi,

What's the current status on this? Is there something I can help with? Unfortunately I'm neither a telepathy developer nor experienced with glib and crypto code, but if someone is willing to give me a helping hand, I might still be able to help.

I think https://en.wikipedia.org/wiki/2013_mass_surveillance_scandal should be a good reason to speed up support for OTR.

One more vote on this one.
I am on
KDE Telepathy Contact List
Version 0.6.3
Using KDE Development Platform 4.11.60
(OpenSUSE)
And though not a developer - i am willing to test ahem early release candidates :-)
While reading about encryption attempts on telepathy, i see some protocol centric approaches, which i think is a bad idea, since work then has to be done for each protocol. A strong feature of OTR, is that it crypt just about anything, and that changing crypto scheme should be "easy" (even selectable?)
But for now only many good ideas are around, and little accessible to users.
Personally i do not hold a lot for the ssl that some protocols propose, in this scenario, but still it is better than nothing.

I started a bounty for the addition of ZRTP support to Telepathy.
https://freedomsponsors.org/core/issue/464/support-end-to-end-encryption-and-authentication

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/79.