RE: [exim] Securing Email for the prying eyes of any governm…

On Thursday, January 13, 2005 11:26 PM Greg A. Woods wrote:

>> And of course you have a totally differrent approach that will work
>> in real life with all companies, does not use signatures, detects
>> 100% of all viruses while letting pass all wanted attachments...
>
> Yeah, it's called a security policy.

Which typically is at least 80% human driven and not technically driven. Unless of course you manage to get rid of exe-downloads, activec, java, javascript etc. Or unless you are absolutely sure that your entire staff really obeys the security polica 100%.

> No, it's usually implemented primarily by an auditor with a big stick.
> (though appropriate selection of technology helps ease the pain)

Ease: yes. But it will not make the big stick go away and the big stick usually is reactive and not proactive...

>> When they detect viruses they do solve a problem.
>
> No, they do not solve any problem -- they merely mask one
> tiny aspect of the real problems.

If you define problem the way you are then you are right. My definition of this problem is: How to technically ensure that no (or few) viruses enter/spread in the company. Of course this does not replace a security policy and is not intended to. But unless the entire world changes within a few days and Microsoft and a lot of other developers get rid of all security flaws, things like virus scanners and centrally personal firewalls are quite necessary and do a reasonable job.

>> It was you who then suggested that real security can only be achieved
>> by using complete end-to-end security. That contradicts what you are
>> saying now.
>
> Huh? No, I've never strayed from saying end-to-end security
> through the likes of PGP or S/MIME is the only real solution
> for the problem we're discussing in this thread.

Then excuse my obvious lack of language skills that lead me to believe you did. Let me cite:

JPK> Sure there is. Depending on your/the customers need. If you trust your
JPK> internal network/mail server there is no real problem.

GW> Huh? We're talking here about security over public networks, not what might happen
GW> once the mail has been received (though to some extent that's quite important too).

If a company MTA receives the mail in a secure fashion (that is over TLS or IPSEC) which makes it extremely hard for others (including the government) to read this communication, this mail then analyzed by the gateway (virus/spam) and stored in the company message store (Notes, Exchange, Courier whatever) that resides in the trust network, this pretty much covers the "once the mail has been received" bit for me. And it is not end-to-end/MUA-to-MUA encryption, is it?

> Keeping all e-mail from the prying eyes of any government
> requires, amongst other things, good MUA-to-MUA security
> using public key cryptography. Other mechanisms _can_ take
> over once the mail has been received (and successfully decrypted).

The only big difference between MUA-to-MUA or MTA-to-MTA security here is that the government could of course get a search warrant and confiscate your mailserver. In most countries this is not very easy and if they really get such a search warrant they typically have a very good rightful reason for it. In this case: Let them have the data for gods sake!

Of course the other difference would be a poorly implemented internal network with lots of backdoors.

> Any company that gets themselves into that scenario deserves
> what they get. It should never happen that way in the first place.

Interesting. You are praying MUA-to-MUA security with personal keys. Since you did not answer the question in any way let me ask it again: What happens if one of the key-employees gets ill and needs to go to the hospital for a month? And very important data was sent to him only? Your security policy can be the best in the world, if a customer decides to be dumb and send his e-mail to one person only you will surely not tell him to f... off because you told him to do otherwise, would you?

> Remember we're talking about keeping e-mail from the prying
> eyes of any government. We seem to agree that goal requires
> public key cryptography, e.g. as implemented by PGP.

No we do not. We agree that PGP and likes are _one_ solution to this particular problem/goal. My statement is that there are other solutions that could have a similar effect without the possible drawbacks of MUA-to-MUA public key cryptography.

> This
> goal also requires that there be no use of key escrow
> technology (which could of course be subverted by powerful
> enemies such as a government). So far so good.

Instead of repeating this over and over again: How is an escrow key (that is not know to the government) commonly subverted by your powerful enemy?

> However if the company security policies don't solve your
> proposed dilema properly before it becomes a problem then
> their policies are inadequate.

It is a simple and very common problem. What can a security policy do to circumvent this completely?

> There are many possible
> solutions that would work quite well. None compromise the
> end-to-end security of e-mail transactions over public
> networks. In fact there are so many possible viable
> solutions it's pointless for me to bother describing any one
> or any few since the appropriateness of any given choice
> depends almost entirely on the precise goals, security, and
> privacy, needs inside the company in question.

Lame excuse. The scenario is presented clearly enough. The company wants to make sure, people outside the company cannot easily read the e-mail traffic they have with partners outside their company. Of course the information in this e-mail belongs to the company and not the person receiving the information therefore the company also wants to make sure that no information is lost if staff leave the company (etc.). And tehy do not want to embarrass themselve by contacting the sender with a "sorry but that person has been fired and we cannot read the mails you sent him last week, can you please resend it?" mail.

> (You could pay my going rate to help analyze the risks,
> threats, and requirements and help write a suitable security
> policy of course. :-)

Sure. Do you pay mine?

>> If a company sets up advanced decryption keys, how exactly is that a
>> back-door for the government?
>
> If you haven't figured that out yet then take a look at the
> real world again! ;-)

Same old story. No argument just paranoia. I can think of some ways don't worry. We are talking about a scenario like this: Every key in the company is created in a way that only the combination of two other keys (let's say CEO and CTO) can "break" the key. Neither one is giving his key to the government.

I am aware that using ADKs results in weaker keys. Question: Are the resulting keys so inefficient and insecure that the big bad government simply flips a button and reads your mail in real time? I sincerly doubt this.

Regards,
JP