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

[Paul Wouters]

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.

> 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.

> 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.

> 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.

> 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.

Paul