[Cryptography] IPsec is worse than unusable (Re: TLS/DTLS Use Cases)

[Nico Williams]

On Wed, Apr 02, 2014 at 06:57:01PM -0400, Paul Wouters wrote:
> On Wed, 2 Apr 2014, Nico Williams wrote:
> >Actually, IPsec fails to do exactly what you say.  That is a key failure
> >of IPsec's.  There are no "IPsec sockets", nor "TCP w/ IPsec sockets".
> 
> Trivial to add as a netlink library function in libnl if people cared
> about it.

Can you share some details?  Off-list perhaps.  I'd greatly appreciate
it.

The basic thing to implement is RFC5660.  Then you can add APIs on top.

> >A TCP SYN and SYN+ACK (etc...) for the same TCP connection can easily be
> >sent to different peers altogether even though using IPsec!
> >
> >The reason is a combination of statelessness in IPsec[*] and that
> >authenticating IP addresses is ETOOHARD, so the typical IPsec
> >configuration says "anyone with certs from these issuers can claim any
> >IP addresses from these ranges".  This fails to scale.
> 
> Various methods for tracking overlapping IPs are available in the kernel
> stacks. KLIPS has SAref tracking, NETKEY/XFRM has sec_path.

Tracking IP address overlaps is not the issue.  See below.

> >There are ways to fix all this, but it's ETOOLATE for IPsec.
> 
> We'll see. Writing security into every application hasn't been that
> great of a success either.

Sure, I grant that and _wish_ it had gone differently.

> >And anyways, in-band key exchange and authentication (TLS, SSH, and
> >friends) have won out over out-of-band (IKE) key exchange.  Tragic or
> >not, it is what it is.
> 
> Great success there too. ssh doesn't even have rollover support without
> DNSSEC. And a single RST packet kills the connection. I'll take IPsec
> to protect that raw TCP stuff.
> 
> TLS, well. sheesh. GnuTLS, openssl, apple bug. It seems a great
> way to ensure all your applications suffer from the same security holes.

In terms of scalable deployment SSH and TLS have IPsec beat by light
years.  There's no contest.

Even in terms of actual security offered, a deployed protocol that has
issues (e.g., TLS) is clearly much better than a non-deployed protocol
that has issued (e.g., IPsec).

Even if IPsec deployment as specified had become widespread, its
security offering would be necessarily much less than that of TLS
because of the issues I described.  Unless, of course, widespread
deployment were to lead to those issues being noticed and addressed,
but since it didn't happen...

> >PS: I know I must sound like a broken record about this, but it's worth
> >   repeating
> 
> No it's not.
> 
> >   Perhaps it's worth writing a paper/RFC on this topic just so we can
> >   just point at it every time misconceptions about IPsec come up.  But
> >   there's no positive value in writing such a thing.
> 
> If you'd write the draft, you'd encounter the disagreements. Perhaps
> that would help you personally see your opinion is rather simplistic and
> wrong.

Partially done already :)  RFC5660 covers some of this, specifically the
lack of binding of packet flows to the initial node IDs for the life of
the packet flow.  RFC5660 also specifies a [local] fix for this.

RFC5660 made it past WG, IETF, and IESG reviews.  The work item also
passed WG charter review.  If you don't agree, well, it's a request for
comments, please send some!  :)

http://tools.ietf.org/html/rfc5660

The right place to send comments today would be the ipsecme WG and the
RFC author(s) (singular in this case, and yours truly, but I'm on the
ipsecme list already).

Nico
--