On 6/8/20 2:09 AM, Nick Hilliard wrote:
Michael Thomas wrote on 08/06/2020 01:21:
well, it could send it to the wrong port, but i'll guess that tls is
on to that problem. i mean, it kind of sounds like you're saying the
transport checksum failing isn't a big deal? creating a gigantic
window would certainly not be a good thing in the face of congestion.
transport mode ipsec wouldn't suffer those kinds of problems.
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?
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.
Mike
