The threat you're worried about doesn't require that an IETF Working Group spend years defining a new protocol, whether that's QUIC or TLS 1.3 itself. Any bozo could roll their own Noise-based encrypted protocol and it wouldn't be decrypted by whatever edge "security" you think is protecting you.
Worse, chances are that a belief you presently have "control over the things that go out of my own network" but believe TLS 1.3 would hurt that means you're relying on "Next Generation Firewall" type technologies which are hopelessly broken.
If you go stare at the TLS 1.3 "compatibility" changes in later drafts (particularly Draft 28 IIRC) you'll see that it's basically the equivalent of wearing a boiler suit with an embroidered "OTIS Lifts" logo to get waved through the gate check without needing a pass. Except the boiler suit says "TLS 1.2 Session Resumption". It didn't require the IETF to do this, presumably Bad Guys have been doing it for years without writing a document explaining how.
The recurring theme in people's TLS 1.3 horror stories is that they were being eaten by cannibals all along, but TLS 1.3 asked them why they can't feel their legs...
Example: Palo Alto and Cisco both shipped products that trip the TLS 1.3 downgrade detection feature. They were told about this months ago, but of course they waited until the last moment (indeed for PAN they still haven't shipped a fix for some supported versions) because it's just a compatibility problem...
Except, it's not - the only way to trip that downgrade detection "by mistake" is to not choose random numbers where the TLS 1.0, 1.1 and 1.2 standards all say that it's imperative to use random numbers. If those numbers are instead copied from somewhere predictable (which they are in affected Cisco and Palo Alto systems) then much of the security of your TLS connections through these "security" devices was illusory.
Worse, chances are that a belief you presently have "control over the things that go out of my own network" but believe TLS 1.3 would hurt that means you're relying on "Next Generation Firewall" type technologies which are hopelessly broken.
If you go stare at the TLS 1.3 "compatibility" changes in later drafts (particularly Draft 28 IIRC) you'll see that it's basically the equivalent of wearing a boiler suit with an embroidered "OTIS Lifts" logo to get waved through the gate check without needing a pass. Except the boiler suit says "TLS 1.2 Session Resumption". It didn't require the IETF to do this, presumably Bad Guys have been doing it for years without writing a document explaining how.
The recurring theme in people's TLS 1.3 horror stories is that they were being eaten by cannibals all along, but TLS 1.3 asked them why they can't feel their legs...
Example: Palo Alto and Cisco both shipped products that trip the TLS 1.3 downgrade detection feature. They were told about this months ago, but of course they waited until the last moment (indeed for PAN they still haven't shipped a fix for some supported versions) because it's just a compatibility problem...
Except, it's not - the only way to trip that downgrade detection "by mistake" is to not choose random numbers where the TLS 1.0, 1.1 and 1.2 standards all say that it's imperative to use random numbers. If those numbers are instead copied from somewhere predictable (which they are in affected Cisco and Palo Alto systems) then much of the security of your TLS connections through these "security" devices was illusory.