On 09-Jun-20 07:02, 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. Unless someone says "multicast". Brian > 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. > >
