"Clients must not use any form of unencrypted communication."

[subliun]

"communication" needs to be explicitly defined. I'm assuming this means "unencrypted data must not be sent over the network", in which case it should say that.

[nurupo]

Why limit communication to only "network"? What if my client communicated with something through a file on disk?

Also, thinking about that a bit deeper, a client could communicate with other application through shared memory or a file, and then that application (not the client) would communicate through network in encrypted manner using that information, maybe on client's behalf, or maybe without client actually intending that. Is that acceptable or not?

[JFreegman]

Give me a reasonable example of some form of Tox-related communication that is not synonymous with "sending data over the network" (and we then need to define what "network" means in this context).

It's better to use generalized terminology here because it covers more ground and prevents loopholes. Remember, this isn't a legal document. If anyone is ever genuinely confused about a rare case we haven't though of, they can simply ask someone.

[tux3]

I'd like some clarifications on this point, it seems unreasonably restrictive (and impossible if interpreted pedantically).

For example qTox will downloads updates unencrypted (but signed), encryption would not achieve anything since it's obvious anyways that someone downloading from the qTox update server ... is downloading a qTox update.

Then there's all kind of pedantic edge cases that are more or less acceptable. What about the part of toxdns3 that's unencrypted, what happens if my users wants qTox to save some files on a network filesystem, what if some backup service is active and the qTox log gets sent in plaintext to some cloud provider, etc.

I think that something like "Clients must not send any sensitive information unencrypted" would be more practical.

[JFreegman]

@tux3

For example qTox will downloads updates unencrypted (but signed), encryption would not achieve anything since it's obvious anyways that someone downloading from the qTox update server ... is downloading a qTox update.

Is there a good reason why it doesn't use HTTPS? It's just a matter or principle. Everything should be encrypted because we can't predict how adversaries might use that data to their advantage.

What about the part of toxdns3 that's unencrypted

toxdns3 is deprecated, and is going to be removed from the core soon. I believe @subliun is removing DNS support from toxme.io by the new year. You should be thinking about porting qtox to use the HTTPS API asap.

what happens if my users wants qTox to save some files on a network filesystem

Whose network filesystem? If the data is potentially visible to a device not owned by the tox user in question then it should be encrypted.

what if some backup service is active and the qTox log gets sent in plaintext to some cloud provider, etc.

As far as security is concerned, you shouldn't be using a cloud service for anything, ever - much less using it to store plaintext logs. The fact that you're asking this question is exactly why this clause needs to be worded the way it is.

I think that something like "Clients must not send any sensitive information unencrypted" would be more practical.

Almost any form of data could be considered "sensitive" in the wrong hands. Metadata is often just as useful as actual content.

[tux3]

Is there a good reason why it doesn't use HTTPS? It's just a matter or principle. Everything should be encrypted because we can't predict how adversaries might use that data to their advantage.

To save on expensive server resources, mostly. The update server (currently disabled in production) runs on an ARM toaster with unmetered bandwidth, that I pay for out of my own pocket.

toxdns3 is deprecated, and is going to be removed from the core soon. I believe @subliun is removing DNS support from toxme.io by the new year. You should be thinking about porting qtox to use the HTTPS API asap.

That's good to know.

Whose network filesystem? If the data is potentially visible to anyone but the tox user then it should be encrypted.

NFS, Google Drive, what have you. Since Tox doesn't have multi-device support I've seen some people use a network FS to share their Tox profile instead. The files might or not be encrypted in transit but this is essentially sharing the plaintext files with other systems. I think that this should be allowed if the user clearly chose to go down that road, since clearly the data only goes to systems the user implicitly trusts, but the current formulation seems unclear to me on that point.

As far as security is concerned, you shouldn't be using a cloud service for anything, ever - much less using it to store plaintext logs. The fact that you're asking this question is exactly why this clause needs to be worded the way it is.

qTox by default stores an anonymized plaintext log that contains as only sensitive information times of events and a lower bound on the number of contact you have, the rest is meaningless debug info. This is not meant to be shared publicly and qTox of course doesn't send it to cloud services itself, but that log file helps in debugging.

Howether the decision of the user to use cloud services isn't something qTox can control. I've heard of Windows 8 having some bultin sync function that I think uploads Appdata in particular, if this is true that's worrying. I can't magically encrypt the unencrypted profiles and the qTox log in case the user decides to use cloud services.

Almost any form of data could be considered "sensitive" in the wrong hands. Metadata is often just as useful as actual content.

However encryption doesn't suppress metadata. If I take my example of the qTox update server again, which is really my main motivation here, with or without encryption an attacker doesn't have to be a 3 letter agency to guess why you're connecting to an update server. I'm certainly not arguing your point that all data can be meaningful to an attacker, I'm arguing that encrypting everything is not always possible, and sometimes not a solution.

[JFreegman]

@tux3

To save on expensive server resources, mostly. The update server (currently disabled in production) runs on an ARM toaster with unmetered bandwidth.

HTTPS isn't that resource intensive. Also, in the future the project will hopefully have enough resources to host the update server for you if necessary.

NFS, Google Drive, what have you. Since Tox doesn't have multi-device support I've seen some people use a network FS to share their Tox profile instead. The files might or not be encrypted in transit but this is essentially sharing the plaintext files with other systems. I think that this should be allowed if the user clearly chose to go down that road, since clearly the data only goes to systems the user implicitly trusts, but the current formulation seems unclear to me on that point.

Sending a plaintext tox profile over the network leaves you vulnerable to MITM attacks and possible identity theft. Allowing users to shoot themselves in the foot because they don't know any better is something we don't want to do. For the same reason, we don't have an option to disable Toxcore encryption.

edit: I should add that as I said below, we can't control what users do with their tox profile outside of the scope of client behaviour.

This is not meant to be shared publicly and qTox of course doesn't send it to cloud services itself, but that log file helps in debugging. [...] I can't magically encrypt the unencrypted profiles and the qTox log in case the user decides to use cloud services.

This doesn't relate to this particular clause as long as qTox isn't the one sending the data to the cloud service. Storing plaintext logs on the device is fine as far as the TCS is concerned. What the user does with those logs is out of our hands.

However encryption doesn't suppress metadata.

Client update information is metadata. Just because we can't think of a use for it doesn't mean someone else won't. I'll grant you that it's unlikely in this particular case, but we can always make compromises and exceptions on a case by case basis. In my view this is much better than watering down the TCS and having clients get away with potentially dangerous behaviour. At least this way we're forced to scrutinize it.

[tux3]

@JFreegman

HTTPS isn't that resource intensive. Also, in the future the project will hopefully have enough resources to host the update server for you if necessary.

I run Tor relays on the same box, and turns out for an ARM toaster encryption is pretty damn expensive. I have one mostly unused core out of four that is currently dedicated to the qTox update server. If the project wants to buy me a TLS cert and some CPU time, I'll be more than happy to oblige :)

Sending a plaintext tox profile over the network leaves you vulnerable to MITM attacks and possible identity theft. Allowing users to shoot themselves in the foot because they don't know any better is something we don't want to do. For the same reason, we don't have an option to disable Toxcore encryption.

I think we obviously agree here, I was mostly thinking about the use case of people (securely) syncing their unencrypted profiles between devices due to Tox lacking multi-device support. I have to store some unencrypted information, I can't prevent people from doing stupid things with it, and as long as we agree that users storing those files on a network drive is none of my business, everything is fine.

This doesn't relate to this particular clause as long as qTox isn't the one sending the data to the cloud service. Storing plaintext logs on the device is fine as far as the TCS is concerned. What the user does with those logs is out of our hands.

That's also how I see it.

Client update information is metadata. Just because we can't think of a use for it doesn't mean someone else won't. I'll grant you that it's unlikely in this particular case, but we can always make compromises and exceptions on a case by case basis. In my view this is much better than watering down the TCS and having clients get away with potentially dangerous behaviour. At least this way we're forced to scrutinize it.

Again, I'm not disputing that any and all data could be meaningful to an attacker, even metadata. However I think that my wording is not more dangerous than your wording, and your wording blocks some real use cases. If a client developer is so ignorant of security that they would send sensitive info unencrypted, then you have bigger problems and the wording of the TCS will not change that.

As it is, the wording is not literally enforceable, if you want to be pedantic toxcore itself sends unencrypted local discovery pings several times per second, so clearly there will always be some part left to interpretation. What bothers me is that enforcing some stupid "encrypt everything!" rule is not security, you can't just magically make a system secure by sprinkling some HTTPS pixie dust on top of it.

It's fine to have some rules, and of course we don't want people sending Tox profiles unencrypted over the network. But when it comes to security, I'll take individual decisions over stupid business processes and rules any day.

Edit: I forgot to address that here, but I'd like to repeat that encrypting the client update process doesn't make the metadata disappear. Even with HTTPS or with all the crypto you want short of onion routing, it's still plainly visible to an attacker what you connect to and they have an almost always correct guess of what exactly you downloaded just by looking at the file size. There's no info HTTPS can hide here.

[JFreegman]

However I think that my wording is not more dangerous than your wording, and your wording blocks some real use cases.

Like I said, we can always look at exceptions on a case by case basis. We have no intentions of being unreasonable. We just don't want to end up arguing with client developers who want to dispute our idea of what constitutes as sensitive information.

If a client developer is so ignorant of security that they would send sensitive info unencrypted, then you have bigger problems and the wording of the TCS will not change that.

qTox (and a few other clients) used to send toxdns requests in plaintext. I recall a few people even trying to argue that it wasn't a big deal, or that allowing users to consent was an acceptable workaround. Those were cases where this clause would have come in quite handy. I made a big fuss about it on IRC, but it would have been nice to have had official legitimacy in my complaints so that action could be taken sooner. Come to think of it, that's exactly why I worded this clause as I did.

if you want to be pedantic toxcore itself sends unencrypted local discovery pings several times per second

The TCS relates only to client behaviour.

what bothers me is that enforcing some stupid "encrypt everything!" rule is not security, you can't just magically make a system secure by sprinkling some HTTPS on top of it. Encryption does not protect metadata.

I think that's a bit of a straw man argument. No one said that encryption is equivalent to security. However, attempting to achieve security with holes in the encryption scheme is risky, and something that we want to avoid as our default position.

[tux3]

Like I said, we can always look at exceptions on a case by case basis. We have no intentions of being unreasonable. We just don't want to end up arguing with client developers who want to dispute our idea of what constitutes as sensitive information.

I'm not sure I understand that part correctly. If the intent is to look at exceptions on a case by case basis, then shouldn't the wording reflect this, and will you not end up arguing regardless of the wording?

qTox (and a few other clients) used to send toxdns requests in plaintext. I recall a few people even trying to argue that it wasn't a big deal, or that allowing users to consent was an acceptable workaround. Those were cases where this clause would have come in quite handy. I made a big fuss about it on IRC, but it would have been nice to have had official legitimacy in my complaints so that action could be taken sooner. Come to think of it, that's exactly why I worded this clause as I did.

I'll admit that I implemented toxdns1 as per the STS, and that was a mistake, I should never have implemented it in the first place. I might have too much trust in my users when I allow them to consent to stupid things, and I appreciate your honesty here. However I recall taking action swiftly after the issue was raised and reaching a consensus on IRC, the first consensus being to warn the user, then we later decided to remove the feature entirely. If you have an issue with the decision that was taken, you're absolutely right, but if you wanted it taken sooner you only had to speak.

The TCS relates only to client behaviour.

You're right.

I think that's a bit of a straw man argument. No one said that encryption is equivalent to security. However, attempting to achieve security with holes in the encryption scheme is risky, and something that we want to avoid as our default position.

That's not an unreasonable position to take, and I'm glad I only hit on a straw man. It remains that as a client dev I'm not overjoyed by the unclear status of possible exceptions. If you're going to start making exceptions, then please reflect that in the wording, otherwise I can not take risks and have someone rightfully turn the wording against me later on. I think that the current wording is too restrictive, but if you want to keep it that way, let's at least make the situation unambiguous.

[JFreegman]

If you're going to start making exceptions, then please reflect that in the wording, otherwise I can not take risks and have someone rightfully turn the wording against me later on. I think that the current wording is too restrictive, but if you want to keep it that way, let's at least make the situation unambiguous.

That's a fair point. I'll make it a point to bring it up at the next committee meeting.

[Zer0-One]

@tux3 you are coming to the meeting, right?

[tux3]

@Zer0-One Is it on mumble?

[GrayHatter]

@tux3 yes

[tux3]

Alright. I'll need a new login for the Mumble server then, it won't accept my old one.

[Zer0-One]

@tux3 give it a try now

[tux3]

@Zer0-One Thanks, I registered again.