[liberationtech] Firesheep: Making the Complicated Trivial

[Gregory Maxwell]

On Tue, Oct 26, 2010 at 7:53 PM, Daniel Colascione
<dan.colascione at gmail.com> wrote:
> I was waiting for someone to bring up tcpcrypt: while it does encrypt
> each connection, it doesn't authenticate the identity of the other
> party.

Authentication can't be done on a general one-size fits all basis, or
at least it can't be done well. Good, _usable_ authentication is
application (and _user interface_) specific.

Requiring users of an IM application to obtain and install third party
validated X.509 certificates in order to have a private chat session
is just as unacceptable as it would be to use a  question/answer
shared secret to authenticate a website.

Contrary to your statement— TCPcrypt, or rather the TCPcrypt model,
doesn't fail to provide authentication. Instead it provides the
appropriate hooks so that an application can implement its own
transport-bound domain specific authentication on top of the
ephemerally keyed secured connection.  The TCPcrypt package contains
example applications that do this.

As an analogy, TCP also provides no mechanism to obtain a username and
password even though a great many services running over TCP need that.
Fortunately those applications don't have to provide the
retransmission and reordering which is common to all TCP connections.
And, even better than that, TCPcrypt provides generic hooks to
facilitate secure authentication of whatever type is best suited.

This is a highly elegant design which would be attractive even if no
one would ever use TCPcrypt without authentication.

This model should allow the operating cost of authentication to be
dramatically lowered in many cases. E.g. Using a zero-knowledge shared
secret protocol for authenticating a service which is already password
protected is a free operation for the user.

So with TCPcrypt you get always on strong protection against passive
attacks, and a good infrastructure for bootstrapping up to full
authentication.  Moreover, from the outside authenticated and
non-authenticated connections look the same. By the time an attacker
discovers that authentication is in use it's too late to decide to not
attack a connection. So even if many tcpcrypt users did not use
authentication (a sad outcome) the ones that do would provide a
significant disincentive to attacking them.

> Without this authentication, encryption is only a minor
> speedbump for an attacker. Using ARP/NDP-poisoning or wireless-specific
> techniques, an attacker can intercept connections between users and
> external sites, and having done that, he can read these connections
> just as well as if they'd been sent in the clear.

Authentication is essential but I fear that you're overstating your
case here.  Active and passive attacks are fundamentally different.
Active attacks leave footprints, they can be detected after the fact.
They can involve more significant legal risks beyond the risk of
detection.

You can not deploy an enormous secret surveillance infrastructure and
get away with it if you're forced to make active attacks— if crypto
(even un-authed) were widely deployed there would be little incentive
to fund the creation of these kinds of system.

Encryption without authentication simply changes the economics of
violating a person's confidentiality. That change has value even if it
doesn't get us any closer to authentication (and TCPcrypt does get us
closer to that).

We should be careful to _never_ call unauthenticated encryption
"secure" — crypto should just be done transparently, pervasively, and
without the users knowledge... and this part is critical...  because
it CAN be, while authentication can't usually be provided without
costs to the users.

The difficulty in deploying crypto+auth is almost entirely in the
authentication part. Authentication is harder to design, hard to
deploy, and hard to maintain.  Consequentially we don't have pervasive
crypto at all and are completely vulnerable to active as well as
undetectable passive attacks and mass surveillance. By comparison,
crypto itself is pretty much free— just some protocol sausage making —
even desktop hardware can do gigabits/sec of the stuff.

> As others have mentioned, the only true solution is pervasive
> end-to-end encryption _with_ authentication (and preferably perfect
> forward secrecy). Everything else is a temporary half-measure.

The technology to have everything on the internet encrypted has been
available since the early 90s... and it's be cheap enough (in terms of
software complexity and CPU usage) to be effectively free almost as
long.  Yet the internet is not pervasively encrypted today.  I don't
think that I'm going out on a limb in saying that yourn no-compromises
 "you must always have both or nothing" is equivalent to saying "you
should have nothing".

I don't think TCPcrypt is a compromise "half-step" at all. Instead,
it's a good full step forward which strongly facilitates taking a
second step beyond that. If someone is willing enable to go the whole
enchilada crypto+auth then it will be no harder with TCPcrypt, if they
aren't at least we get closer to the goal.

Food for though, I hope.
Cheers,