On Mon, Jun 08, 2020 at 09:59:19AM -0700, Michael Thomas wrote: > On 6/8/20 2:09 AM, Nick Hilliard wrote: > > Michael Thomas wrote on 08/06/2020 01:21: > > in their current incarnations, transport mode ipsec and tcp-ao aren't > > deployable at scale in the same way that tls is. > > why would you say that? what layer the crypto is performed seems sort of > irrelevant: rsa, aes and sha don't care who calls them. i assume that you > can hack ipsec to emulate clients not having certs. what's left? TLS is trivial to deploy: change your apps. IPsec has no notion of "connections" -- well, there's RFC5660, but that basically never got implemented (I suppose it's never too late) -- so it's hard to apply. TCP-AO requires an out of band key exchange mechanism which I guess could be IKE, but is that implemented? > > Regarding transport layer integrity, there are distant echoes of the old > > circuit-switched vs packet-switched arguments going on here. tcp/ip > > made circuit switching redundant by loosening its assumptions about > > transport layer reliability. I wonder are we now seeing something > > similar with TLS, which no longer depends on either underlying transport > > or ip header integrity by pushing data stream integrity management > > higher up the stack. > > Quic seems to have done the opposite by moving it down. But do I trust > higher levels to deal with congestion avoidance correctly? Not at all. > That's a tragedy of the commons waiting to melt down. Eh? No, QUIC / HTTP/3 switches to UDP, but integrity protection happens at the application layer, not at the UDP or IP (IPsec) layers. I do expect UDP-based Internet protocols to handle congestion avoidance. Nico --
