Suggestions for a more privacy conscious email provider

Tue Dec 5 03:52:16 UTC 2017

On Dec 4, 2017, at 5:22 PM, Naslund, Steve <SNaslund at medline.com> wrote:

> There are all kinds of factual issues with the arguments in the referenced document.
> 
> 1.  During Desert Storm I personally sent hundreds of STU-IIIs to the sandbox.  They didn't go in diplomatic pouches, they went as Air Force cargo like everything else.

Maybe not all of them went the way I described, but there were public stories at the time regarding ones that had been sent in diplomatic pouches, and which was confirmed by the government.  I wasn't concerned about the STU-IIIs that got sent the "normal" way, and therefore I did not mention them.

What really concerned me at the time was that it was totally okay to send them in a wide variety of ways before they were keyed, but they had to be sent via diplomatic pouches once they had been keyed, in order to get around our own export controls regarding munitions.

Today, I know a bit more about what "keying" means than I did then, but not much more.  I guess if you're using shared secrets everywhere, it becomes really important to protect those shared secrets against everyone, including other members of our own government.

> 2.  Treason is not applicable here because there must be a declared war.  Treason requires interaction with a declared enemy during a time of war.  I know that term gets thrown around haphazardly lately but it is a very specific legal term.

Okay, so treason was the wrong term.  I grant you that.  In fact, I granted that in my previous message.

Let's get over that word.

> 3.  Asking a government agency act as the KDF is so demonstrably brain damaged we don't even need to go into the problems with that.  They have shown that:

At the time, I think it was reasonable to at least mention using a government agency as a Key Escrow agent, if only to point out one possible solution.

Key Escrow has had a lot more research since 1992, and we've learned a lot of lessons since then.

> 4.  Sending a device or technology out of the US does not equal an export under ITAR.  In your example, if a device is going to be used by US Government employees or military personnel and kept under their control, it is not an export.  As a matter of fact a US company can use export restricted software and hardware in foreign countries in most cases if it is under to control of US Nationals.  i.e. US company can use high encryption licenses for Cisco devices inside of China branch offices to secure their VPN connections.  My company has this in writing, we did all of the appropriate export paperwork and then was told it was unnecessary since the software remains under the control of US nationals (of course they know that all the foreign intel agencies already have it so they are not worried about James Bond sneaking in the middle of the night to reverse engineer it).

The rules regarding the exportation of strong crypto have changed since 1992.  Although it now looks like maybe they're soon going to be going back the other direction.

However, for the moment, it is still a non-sequitur to apply the rules of exportation under modern law to something that was written in 1992.

> 5.  The DirNSA has a vested interest in the collection of intelligence and the security of US GOVERNMENT systems as his primary responsibilities.  Securing US private entities is way down his list of priorities and if in conflict with his primary missions will take a back seat.  Not treason my friend just focus on his mission.

I believed at the time that he was causing Very Grave Harm to National Security Interests, through their actions to try to force the standardization on poor encryption algorithms and prohibit the use of strong crypto.

As far as that statement goes, I believe that it is as true and applicable today as it was in 1992.

--
Brad Knowles <brad at shub-internet.org>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: Message signed with OpenPGP
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20171204/82dfb6c3/attachment.sig>