On Mon, Jun 08, 2020 at 11:23:09AM -0700, Michael Thomas wrote:
> ssl had the advantage that it 1) beat ipsec to market, and 2) wasn't subject
> to API differences from OS layer calls like IPsec was, and with quite a bit
> of churn as i recall too. it's really too bad, imo. we wouldn't have had to
> do the contortions of dtls, for example. and now there's this problem. none
> of them are earth shattering, but it would have been cleaner.
You can sprinkle TLS anywhere you have an octet stream. You can
sprinkle DTLS anywhere you have datagram flows. No need for OS support
-- it will just work. IPsec? IPsec requires OS support.
Also, IPsec got a lot of things wrong. It's simply not usable at
Internet scale as originally intended because... it's IP-layer, so it
deals in discrete packets and IP addresses. Well, discrete packets do
not define application connections/sessions[*], IP addresses are too
dynamic and useless for authentication and authorization[**], and
configuration is ETOOHARD.
As you can see, a dozen years ago was already too late, but our idea
then was to
- construct protection guarantees for packet flows using IPsec,
- to use anonymous or anonymous-like key exchanges to key IPsec,
- and to use channel binding from application layer protocols that can
authenticate more useful names than IP addresses.
Nico
[*] In the IPsec architecture, RFC 4301, there is no guarantee that the
packets making up a TCP connection, say, will have anything like
similar protection for the lifetime of the TCP connection.
Everything about how a TCP conenction is protected by IPsec depends
entirely on *configuration* with no standard interfaces _at all_ for
applications to manipulate said configuration.
[**] Yes, in RFC 4301 you're supposed to specify things like trust
anchors and policies like "any peer with a certificate from this CA
can _claim_ IP addresses in the following prefixes/ranges". This
_cannot_ scale to Internet scale.
Giving up on authentication and authorization in the RFC 4301
scheme (BTNS, RFC 5387) and constructing logical packet flows with
consistent protection during their lifetimes (RFC 5660), fixes the
problem. It didn't get implemented -- even if it had been, TLS was
already king. This would all have to have happened at least half a
decade earlier, if not a whole decade earlier, to have had a
chance.
What was particularly appealing at one point was the possibility of
having ESP offload in NIC HW. The lower in the stack the crypto
happens, the easier it is to offload it.
