Michael Thomas wrote on 08/06/2020 18:37:
Uh, why are you selling apps so short? An app is capable of making library calls for TLS but incapable of making the OS calls for IPsec? That's just silly.
Difficult to see how this was inferred? :-)
The only reason, imo, that tls took hold is because it beat ipsec to the market. By the time ipsec was well supported, nobody cared any more.
ssl, then later tls, took hold because it was designed for, and therefore easily applied to tcp sessions and because there was a lot of effort put into creating ancillary frameworks, e.g. the pki, sensible APIs, etc. This push towards application usability made it transparent to the protocol consumer, whether that be granny, or 14yo whizz-kid, or someone trying to do some online shopping.
Obviously you're technically correct that an app can call any library function and that it matters little to a CPU or the data, or the network layer whether it's rsa, aes or sha - or ipsec, or tls or whatever. But the success of tls came down to usability, or more specifically use-transparency: security could be implemented without people even being aware of it and shifting people from unencrypted to encrypted data transfer was a easy as configuring a server-side redirect. Conversely configuring and managing ipsec still creates thundering headaches even for experienced operators.
There are plenty of reasons that security protocols in particular end up being unusable in practice - usually for sound reasons, none of which were individually wrong, but the outcome is invariably byzantine. It's often the usability of a system which determines success, not the systems' other technical merits.
Nick
