5 ms·

Email security is a bolt-on and can't be relied on in any way. You cannot run a mail server that forces STARTSSL or TLS because you inevitably have important ma

Email security is a bolt-on and can't be relied on in any way. You cannot run a mail server that forces STARTSSL or TLS because you inevitably have important mail that comes from or goes to a server that can't or won't send it to you encrypted. And PGP only encrypts the body of the message, and not the metadata, the concealment of which in transit is crucial for privacy. I believe there is an RFC for encrypting headers, but it has no traction. I think the reason some people talk about starting over is because of this. The minimum level of security of email must be allowed to fall back to is "no security."

zAy0LfpBZLC8mAC 13y ago
Well, I would agree that the non-encryption of end-to-end headers with PGP is somewhat of a bug. Other than that, I think those are all examples of problems that are not actually email problems. Whether you can force TLS/STARTTLS doesn't really matter. First, you cannot ever force anyone to keep something secret, they can always publish a secret that they know somehow and thus make it not be a secret anymore. You can always offer STARTTLS though, so if the other side wants to keep a secret secret from eavesdroppers, they then can do so. That does not help against People in the Middle, of course, as they can strip out the STARTTLS offer. But being able to "force" STARTTLS doesn't help you either, as that would only force the middleperson to speak TLS to you. If you wanted to force authenticated communication that protects you from MitM, you would first have to set up some authentication mechanism. On a server-by-server basis, you can already do that. If you wanted to do it globally, we would need a reliable global PKI. Such a thing does not exist and is extremely hard to build--and in particular, it's not an "email problem". Reliable authentication is mostly a hard social problem. As for metadata encryption: Well, that pretty much is impossible by definition, except maybe through mix networks. You cannot simply encrypt the information that needs to be readable in order to route the message to the destination. Even if you deliver a message via TLS to my MX, the mere fact that your mail server looks up my domain MX and then connects to it already tells an eavesdropper all the meta information there is. And if you solve that by instead doing all the routing inside gmail or some other big provider, you obviously haven't solved anything, as now google can see, sell, and be subpoenaed for this information. Also, "security" is a word without any meaning. You can only be secure against particular attacks/risks, and securing a system against a particular risk often is in conflict with securing it against another risk, so you can only ever achieve one or the other, and it's often a difficult decision which risk to take. In the case of email, you could very easily secure the system against spam, for example: Just have a government agency that licences email server operators and shuts down any that engage in spamming. The side effect: Email is not the slightest bit secure against government censorship anymore. And yet again, there is a social problem at the core, not a technical one. There are reasons why email is so "insecure". And as I wrote above: It's not that people didn't think about it. It's more likely that those who suggest that starting over could help solving the problems haven't really thought through it. In particular the "security" problems of email are extremely hard problems, and they are hard for social and political reasons, not for technical reasons.
- A_COMPUTER 13y ago
  Your argument seems to be that if there isn't perfect security, then it's worthless. I'm arguing for sane minimum standards so Jane Q. Random sitting somewhere on the network between me and my recipient can't just run Snort and read the shit out on their screen. So that the connection can't be easily routed to somewhere else and grab the data. With email as it is today, these things are possible for a reasonably intelligent middle schooler. Yeah, CA system is shit. but they are better than nothing. I don't trust it won't be compromised by a government NSL, but I trust it enough that I'll pay for ebay crap over SSL at a coffee shop and not worry that the guy next to me is sniffing my credit card number. Here's what starting over means to me: you don't break something that basically works. If you start adding incompatible changes to email, then it splits the network. Instead create a parallel network with minimum standards attached to it (for instance,) and maybe nobody will use it but it also won't break anything.
binaryapparatus 13y ago
Exactly. I'd like to see 'new' email protocol built built on non-optional foundations. When we use http over SSL/TLS, browser either shows padlock icon or does not show padlock icon. While implementation has its occasional flaws and bugs, specification does have defined on/off state, not many optional layers in between. We can make any communication channel secure, by adding layers of encryption, no problem with that. But unless it is defined deep down as a part of the standard, it all ends with no security at all and no means to be sure what happened with the message along the way. Having headers exposed is one of the reasons why I raised initial concern. It is part of the specification and unlikely to go away by building on top of the standard.
- zAy0LfpBZLC8mAC 13y ago
  No, "adding layers of encryption" does not equal "security". For encryption to provide real security, you need to solve key distribution, which for all practical purposes is unsolved. And no, when you claim that HTTPS has "not many optional layers in between" that mostly suggests that you just treat it as a black box rather than that there is no complexity there. The simplicity is in the user interface only, and that is arguably broken because it does not actually reliably reflect actual security. Really, once again, you mostly make the impression that you don't really understand the problems with email and just think that it's broken because it's old. Anyone with that attitude is likely to just repeat all the same mistakes that we've been through with email, and in the end not solve any of the actual problems.
  - binaryapparatus 13y ago
    There is no way in hell I could be accidentally misquoted and misunderstood, three out of three 'arguments' in single post. Yeah, let's pretend that I have no idea what I am talking about -- much easier than acknowledging any kind of flaw in actual foundation of the architecture. I can't be any more clear than what I already said. If you decide to take an easy road and kill the messenger, no problem with that. I don't have any intention to continue with this discussion indefinitely, especially if it turns out to ad hominem. History teaches that killing the messenger does not make problem go away. You see it or not, decide to ignore it or not... fine by me.

zAy0LfpBZLC8mAC 13y ago

Well, I would agree that the non-encryption of end-to-end headers with PGP is somewhat of a bug. Other than that, I think those are all examples of problems that are not actually email problems. Whether you can force TLS/STARTTLS doesn't really matter. First, you cannot ever force anyone to keep something secret, they can always publish a secret that they know somehow and thus make it not be a secret anymore. You can always offer STARTTLS though, so if the other side wants to keep a secret secret from eavesdroppers, they then can do so. That does not help against People in the Middle, of course, as they can strip out the STARTTLS offer. But being able to "force" STARTTLS doesn't help you either, as that would only force the middleperson to speak TLS to you. If you wanted to force authenticated communication that protects you from MitM, you would first have to set up some authentication mechanism. On a server-by-server basis, you can already do that. If you wanted to do it globally, we would need a reliable global PKI. Such a thing does not exist and is extremely hard to build--and in particular, it's not an "email problem". Reliable authentication is mostly a hard social problem. As for metadata encryption: Well, that pretty much is impossible by definition, except maybe through mix networks. You cannot simply encrypt the information that needs to be readable in order to route the message to the destination. Even if you deliver a message via TLS to my MX, the mere fact that your mail server looks up my domain MX and then connects to it already tells an eavesdropper all the meta information there is. And if you solve that by instead doing all the routing inside gmail or some other big provider, you obviously haven't solved anything, as now google can see, sell, and be subpoenaed for this information. Also, "security" is a word without any meaning. You can only be secure against particular attacks/risks, and securing a system against a particular risk often is in conflict with securing it against another risk, so you can only ever achieve one or the other, and it's often a difficult decision which risk to take. In the case of email, you could very easily secure the system against spam, for example: Just have a government agency that licences email server operators and shuts down any that engage in spamming. The side effect: Email is not the slightest bit secure against government censorship anymore. And yet again, there is a social problem at the core, not a technical one. There are reasons why email is so "insecure". And as I wrote above: It's not that people didn't think about it. It's more likely that those who suggest that starting over could help solving the problems haven't really thought through it. In particular the "security" problems of email are extremely hard problems, and they are hard for social and political reasons, not for technical reasons.

A_COMPUTER 13y ago
Your argument seems to be that if there isn't perfect security, then it's worthless. I'm arguing for sane minimum standards so Jane Q. Random sitting somewhere on the network between me and my recipient can't just run Snort and read the shit out on their screen. So that the connection can't be easily routed to somewhere else and grab the data. With email as it is today, these things are possible for a reasonably intelligent middle schooler. Yeah, CA system is shit. but they are better than nothing. I don't trust it won't be compromised by a government NSL, but I trust it enough that I'll pay for ebay crap over SSL at a coffee shop and not worry that the guy next to me is sniffing my credit card number. Here's what starting over means to me: you don't break something that basically works. If you start adding incompatible changes to email, then it splits the network. Instead create a parallel network with minimum standards attached to it (for instance,) and maybe nobody will use it but it also won't break anything.

binaryapparatus 13y ago

Exactly. I'd like to see 'new' email protocol built built on non-optional foundations. When we use http over SSL/TLS, browser either shows padlock icon or does not show padlock icon. While implementation has its occasional flaws and bugs, specification does have defined on/off state, not many optional layers in between. We can make any communication channel secure, by adding layers of encryption, no problem with that. But unless it is defined deep down as a part of the standard, it all ends with no security at all and no means to be sure what happened with the message along the way. Having headers exposed is one of the reasons why I raised initial concern. It is part of the specification and unlikely to go away by building on top of the standard.

zAy0LfpBZLC8mAC 13y ago
No, "adding layers of encryption" does not equal "security". For encryption to provide real security, you need to solve key distribution, which for all practical purposes is unsolved. And no, when you claim that HTTPS has "not many optional layers in between" that mostly suggests that you just treat it as a black box rather than that there is no complexity there. The simplicity is in the user interface only, and that is arguably broken because it does not actually reliably reflect actual security. Really, once again, you mostly make the impression that you don't really understand the problems with email and just think that it's broken because it's old. Anyone with that attitude is likely to just repeat all the same mistakes that we've been through with email, and in the end not solve any of the actual problems.
- binaryapparatus 13y ago
  There is no way in hell I could be accidentally misquoted and misunderstood, three out of three 'arguments' in single post. Yeah, let's pretend that I have no idea what I am talking about -- much easier than acknowledging any kind of flaw in actual foundation of the architecture. I can't be any more clear than what I already said. If you decide to take an easy road and kill the messenger, no problem with that. I don't have any intention to continue with this discussion indefinitely, especially if it turns out to ad hominem. History teaches that killing the messenger does not make problem go away. You see it or not, decide to ignore it or not... fine by me.