Subject: [perpass] The scope of the problem

From: Watson Ladd <[email-masked]>
Date: Mon, 16 Sep 2013 12:34:43 -0700

I would like to explain the extent to which a pervasive passive
adversary is able to find things out. Naturally a few hours with
wireshark is sufficient to see that a lot of data passes over the wire
unencrypted. But what exactly can we learn?

First off, web browsing. We see what sites are accessed and when from
DNS queries, which are not encrypted. From HTTP accesses we learn what
plugins, fonts, and languages are suggested or installed, which can
uniquely identify a computer.

Email is worse: even if the connection to the mail provider is
encrypted, the mail will go out on port 25 for transport. STARTLS is
nice, but isn't everywhere, and it is a pain to deploy. Even S/MIME
and PGP offer limited protection: quite a lot has been written on how
PGP doesn't protect what you think it does, more than just headers.
(For instance a signature doesn't actually identify the intended
recipient, leading to fun and games). The world of many email
providers making clients on your machine second-class citizens makes
key management tough.

IRC is regrettably mostly cleartext. Given that it is a public forum,
it is hard to imagine this being a major problem, but deploying it
securely is tough.

NFS I do not believe can be encrypted by means short of deploying
IPsec. UDP based protocols require hackery, and so every standard has
its own system, not ideal for security. VoIP leaks information from
the compression.

Custom applications do not routinely check TLS certificates, or
properly deal with the attacks that are possible. Do we know that all
autodownloaders properly check signatures?

What can we do to solve this problem?
First, we can make standards that have encryption that is easy to
deploy in a wide range of organizational scenarios, and provides the
abstractions that people expect of secure channels, immune to all
attacks and manipulations other than possible replay. (Replay is fine
in email: humans are likely to recognize it. But it is not okay in
TLS!) We need to make this bulletproof.

Secondly, we can make these new standards have advantages that lead to
them being widely deployed. SSH replaced Telnet because of port
forwarding, not security. It also eliminated the need for typing in
passwords with ssh-agent. Web-agent could do the same.

Thirdly, all cryptography should provide easy to understand
abstractions like secure channels, and be implemented cleanly. OpenSSL
needs to be refactored. It should be easy to deploy cryptography, and
easy for developers to use securely. We should have one, or maybe 2
standards, rather than a menagerie of ad-hoc, poorly specified,
unanalysable hacks.

Doing these three things will lead to cryptography being easy to
deploy, having benefits when deployed beyond security, and make it
easy to deploy *correctly*.

These issues extend beyond the scope of standards, but can in part be
addressed by them. If we have standards that are "plug and play" then
committees will use them, rather than some ad-hoc mess. TLS has done a
good job, but more is required, particularly for UDP.
Sincerely,
Watson Ladd