Slashdot: John Gilmore Analyzes NSA Obstruction of Crypto In IPSEC

[D. Hugh Redelmeier]

| From: James Knott <james.knott-bJEeYj9oJeDQT0dZR+AlfA at public.gmane.org>
| 
| William Muriithi wrote:
| > But from reading around,  it looks like their biggest win was making
| > sure ipsec was not part ipv6.
| 
| My understanding was that IPSec was designed to be used with IPv6, but
| not required.  It was then adapted to IPv4.  Making IPSec a required
| part would really cause issues with accessing public sites in the manner
| we normally do.  It's also more suitable for setting up static links
| than using it on an ad hoc basis to access web servers.  SSL/TLS is much
| better in that regard.

It's complicated, but you are wrong :-)

The FreeS/WAN Opportunistic Encryption based on IPSec would work
resonably well for public sites.  (I wrote much of the code that did
it.)

Encryption is easy, authentication is hard.

In the case of ad hoc connections, the question becomes: just what are
you authenticating?  "Is this the stranger that I think it is?" kind
of encapsulates the problem.

SSL/TLS authenticates via a certificate chain.  There's a tree of
trust.  Those trees get subverted.  Verisign, for example, was run by
ex-NSA folks (we thought that this was not an accident).

FreeS/WAN Opportunistic Encryption used the IP address as identity and
authenticated using public keys distributed through the Reverse DNS
system.  (NAT wasn't common when this was designed.)  We assumed that
people would get to populate their reverses.  Remember, the internet
was a network of peers.

The internet has evolved.  We're mostly partitioned into clients
(without fixed IP addresses) and servers.  Clients are second class
and in the majority.  Peer-to-peer is demonized (pirates!) and
consumers are blocked from being first class by ISP terms of service
etc.  And all of us let that happen.

FreeS/WAN OE was designed so that both sides would be authenticated.
That's doesn't really work with NAT etc.  But one-sided authentication
(which is all that SSL/TLS manages) isn't a stretch.  It is a reduction
in security.

The code worked.  It took too long to get there (partly my fault). But
almost nobody adoped OE.  The userland code does get a lot of use for
VPNs, but not OE (Libreswan, Strongswan, Openswan).

The OE code is broken in current releases.  Partly because of the
broken kernel code that Gilmore mentions.  I can vouch for the
intransigence of the kernel developer.  I felt it was ego, not NSA, at
the root of that problem.  US crypto export regulations played a part.

We really needed DNSSec to protect against active man-in-the-middle
attacks.  Without it we could prevent pasive MITM attacks.  We got
involved a bit in trying to push it forward.  I thought it was a
scandal that it wasn't deployed 15 years ago.

If we were to redo OE again, I'd make the identity-to-be-authenticated
a domain name, not an IP address.  I'd use DNSSec to distribute public
keys (hey -- it does already).  The IP stack doesn't really support
that perfectly, but I have an idea of how to make it work without
replacing the stack (using NAT as a tool for good!).
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists