On 6/8/20 12:02 PM, Nico Williams wrote:
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.
Yes, but that's also the reason a long on the tooth transport checksum
becomes a concern. any cryptographic hash is good enough to detect errors.
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.
Yes, but that's a feature not a bug in this particular case. I really
don't find it believable app developers would have had a hard time with
making the OS calls needed anymore than making the calls that the TLS
libraries require. And as always: when something is widely used, it gets
care and feeding. So if ipsec is still clunky, and says it's because
it's not being widely used, and the niche cases of vpn's can suck it up.
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.
Had SSL/TLS not come along first, there would been immense pressure to
make this all work.
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.
These are OS implementation details, right? There is nothing inherently
impossible about filtering on 4-tuples where the app supplies the root
CA it likes to IKE, right? I mean, that's what TLS is doing, but it's
just doing it implicitly from the OS layer filtering.
Mike
