Metadata is the real data
standardnotes.org
standardnotes.org
Suppose you encrypt all your SMTP/SUBMIT traffic. If your upstream is a commercial provider, then they will be subject to subpoenas. If you run your own upstream, then watching who it connects to will often be sufficient to gather metadata of interest.
Consider TLS. Before you can use it you must have used DNS. Today all DNS resolution goes in the clear. So game over right there. Eventually your client's DNS communication with a shared recursive resolver will not be in the clear, but the operator of that resolver will be subject to subpoenas, so game still over. Let's say we did deploy DJB's encrypted DNS solution. Well, you can still see which domains people are talking to, roughly, at least as long as they don't share nameservers, and if they do... You can see where this is going. Now let's say you did get DNS resolution securely anyways, well, now you have to connect to some IP address, and if it's not hosting many services, then game over, and if it is hosting many services, then SNI will be game over anyways (TLS 1.3 requires SNI). SNI cannot be encrypted.
The problem really is that metadata can't really be encrypted.
Mind you, criminals are defeated by data encryption -- mostly anyways.
And forcing governments to use subpoenas does mean increasing the cost of metadata gathering. Plus there won't be infinite retention requirements, perhaps. So, encryption does help somewhat, which means we must do it -- it's just not a complete solution.
The operator of the resolver cache is supposed to be the user, not some third party (e.g., OpenDNS/Cisco, etc.).
IOW, the cache is meant to be running on the user's computer not some third party computer (e.g., OpenDNS/Cisco, etc.).
Using remote (i.e. third party) recursive resolver caches has never been recommended. If anyone is recommending that then they are ignoring the advice of the original author.
(There are other reasons to use a local cache, even if not to encrypt outgoing queries, e.g., it reduces/eliminates the risk of cache poisoning.)
If you look, you may find there are implementations that did follow the author's advice, e.g., a resolver that only accepts queries from 127.x.x.x.
What is missing to have a complete encrypted DNS solution? Authoritative nameservers that implement the system.
The recursive part of the system already works. It is controlled locally by users.
Authoritative nameservers for www sites however are run by third parties. Cooperation is needed.
As for TLS, there may be an alternative encryption solution forthcoming. Similar to encrypted DNS, it will be a small program running on the user's computer that encrypts outgoing packets. An ssl wrapper sort of like stunnel but better. It will not rely on establishing an "encrypted tunnel" like TLS. It will encrypt each packet separately.
I run a private root and a private nameserver that serves encrypted DNS packets from a datacenter. "Pseudo authoritative": the zone contains the third party addresses I need. All DNS queries are encrypted. Sent from localhost resolver to private nameserver. Nothing in the clear. That is how it works.
There will always be metadata gathering on the internet (access logs). But there does not have to be unencrypted (DNS) packets or third party DNS resolvers.
But it can be obfuscated enough to be, in practice, virtually useless. A single VPN service provides no anonymity. Tor provides some anonymity, using onion routing. There are three relays in normal circuits. Each of them knows where data comes from, and where it's going to. But with at least three, the entry and exit relays don't know each other.
But there are vulnerabilities. The relay early bug allowed CMU researchers to communicate between their malicious entry and exit relays, and so de-anonymize users and onion services. That bug is fixed, but of course there may be others.
However, onion routing can also be applied to VPN services. I'm typing this through a nested chain of VPNs. And one can readily use Tor via nested VPN chains. So adversaries would need to compromise multiple servers in different jurisdictions, walking through Tor and VPNs, in order to identify me. Or they could exploit intercepts from network edges with traffic analysis. But it wouldn't be easy.
With 10 Mbps, you should be able to get 3-5 Mbps through nested VPNs. I use UDP for all of them, so there's no retransmission chaos. As you add VPNs to the chain, bandwidth doesn't necessarily go down. But rtt increases, of course.
Yes, but I suppose you could decrease the signal-to-noise ratio by doing random DNS searches.
And once you set up the router, the cost of configuration is zero.
DNSSEC does NOT encrypt requests nor responses.
Communications on the Internet are public by default; this is something that human civilization never experienced before. If you want to make your conversation or your behavior private, you have to encrypt it.
But there were many other things that human civilization never experienced before, and we adapted.
Right to encryption is, indeed, an essential natural right. People who deny it are the same people who think that everybody should have a government-supplied monitoring camera in every room of every home, and fail to understand what's wrong with it.
Is there no right to encrypt? Because no government can actually prevent you from encrypting anything and the maths behind cryptography are openly taught and researched in all modern states. So are you saying that governments should never have the right to compel you to decrypt what you encrypted (by, for example, a fine or a prison term)?
IMO the battle over privacy and crypto is well documented by Steven Levy: https://en.wikipedia.org/wiki/Crypto:_How_the_Code_Rebels_Be...
As one concrete example, Netscape's SSL implementation was originally shipped in two versions - the 'secure' US version, and a severely compromised international download version, due to export controls on the encryption method used.
I'd also argue it's still not fully 'open' in the US - there's still a legal requirement to notify the government of any open source release of new cryptographic technologies, and some restrictions on distribution still exist. I also don't think it's a major stretch to imagine we are just one more San Bernadino style tragedy away from the first western government legislating to ban/compromise cellphone storage encryption, especially with the current US and UK political climates. One can only hope after San Bernadino that Apple has began preparing in earnest for that fight - I can't see any other big players having the moral conviction.
https://www.apache.org/dev/crypto.html
https://en.wikipedia.org/wiki/Crypto_Wars
https://en.wikipedia.org/wiki/Export_of_cryptography_from_th...
No need to bring Netscape from the past, Oracle's Java 8 ships with crippled crypto and you need to download additional jar from their site after accepting that you are not exporting it to "bad" countries [0]. What's funny is that the jar contains only configuration and it's super easy to adjust it manually.
[0]: https://stackoverflow.com/questions/6481627/java-security-il...
Positive rights, like healthcare or Social Security, are a thing that you are not born with that is given to you. The government does not have to provide you with encryption software in order for you to encrypt.
That is to say, I think you are correct and that right does exist.
Conflating the term "metadata" with "descriptive metadata" and "metadata retention" makes it harder for data archives to get people to provide "structural metadata" (aka. the real metadata), that effectively describes the schemas and data structures of academic and open government data.
Yes, descriptive metadata retention is a huge problem, but say that instead of abbreviating terms in a way that obfuscates the issue use the full term.
I find it refreshing writing in markdown for minimal formatting, and the interface gets out of your way to let you write.
I'd give it a try if you're wondering!
Confidentiality - First, Fourth, and Fifth Amendments
Integrity - First and Fourth Amendments
Availability - First and Fourth Amendments