[liberationtech] Firesheep: Making the Complicated Trivial

Gregory Maxwell gmaxwell at gmail.com
Wed Oct 27 12:50:23 PDT 2010


On Wed, Oct 27, 2010 at 1:45 PM, Chris Palmer <chris at eff.org> wrote:
> On Oct 26, 2010, at 5:33 PM, Gregory Maxwell wrote:
>
>> 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.
>
> The only thing that matters is what the user story is: How are people to understand the security guarantee, detect when it has been broken, and know what to do when it has been broken? TCPcrypt's story seems to be "we have no story, and that's a feature".
>
> http://www.faqs.org/docs/artu/ch01s04.html
>
> """But the cost of the mechanism-not-policy approach is that when the user *can* set policy, the user *must* set policy. Nontechnical end-users [I prefer the term "people" --- CP] frequently find Unix's profusion of options and interface styles overwhelming and retreat to systems that at least pretend to offer them simplicity."""
>
> The biggest security problem on the internet right now is usability. No more half-measures and geek sideshows, please.

I am extremely disappointed by your dismissive response— I would have
hoped at least a blow by blow counter argument.  Now I'm mostly left
repeating myself because you basically said nothing.

Not trying to put authentication in the transport layer is _essential_
to usability because all authentication methods have user interface
implications.  Do you disagree?

Currently there is no easy to use way for you and I to mutually
authenticate each other. Should the whole world be able to trivially
and passively eavesdrop, profile, and modify our private conversations
simply because we can't _both_ be bothered to go through the 20
minutes of work or so that it would take to meaningfully validate each
others PGP keys?  Should our non-email/file communications all be
insecure because (other than OTR) not a single one of the applications
available to us supports a form of authentication which is likely to
be usable and meaningful for the kind of relationship that you and I
have personally (e.g. we're random strangers on the internet, who
happen to be on a common mailing list)?


It would be great if the transport could also provide authentication,
but it simply can't because the transport is common to many
applications and different applications have fundamentally different
authentication requirements. The failure to recognize this is a
significant part of why SSL has failed to secure the internet, why
IPSEC-OE has failed to secure the internet, and why there is no end in
sight to these failures to secure the _entire_ internet.

Basic confidentially, however, is needed by everything regardless of
the authentication scheme in use (including 'none') and the transport
is in an excellent position to provide it.  TCPcrypt gives you that,
and as a bonus improves the security of all legacy applications.  Not
enough to call them secure, but it's an important improvement.

Our failure to even achieve basic confidentiality has spurred a
billion dollar aggregate of industries related to massive surveillance
and traffic modification. This failure must be stopped urgently,
because the longer it continues the more money (and thus lobbying
power) will appear behind support for keeping the internet insecure
and the more legacy devices will be deployed which will slow our our
ability to discontinue offering insecure connections (and the
resulting downgrading-attacks that come from that inability).

There is no "user story" here:  Every connection should be ephemerally
keyed and encrypted completely without the users knowledge. Not just
most. Not dependent on "policy". There should be no regular user
exposed configuration. It _should_ apply to everything because it
_can_ be applied to everything without any configuration. That should
be our starting point.  It doesn't make everyone secure, but it slays
the industry of insecurity.

On that base we can then add application appropriate authentication as
quickly as we can get people to adopt it— but unlike the
confidentially authentication simply can't be transparent to the
users, so this adoption will always be rate limited by UI-design and
user tolerance.



More information about the liberationtech mailing list