> Absolutely true, but this does lead to a qualititve advantage for open standard / open source solutions where you externalise the costs of additional implemen

> Absolutely true, but this does lead to a qualititve advantage for open standard / open source solutions where you externalise the costs of additional implementations. This subject doesn't seem like the most attractive for open-source solutions. Especially when it comes to supporting legacy enterprise systems. This feels more like a case of a consortium of companies creating a standards body. > looking at the deployment issues middlesboxes have caused for TLS1.3 and QUIC (snip) My point is that software is much cheaper and more flexible (in the long run) than hardware. I don't think middle-boxes as ETS intends them need hardware acceleration. As such, they could just as easily be implemented in software. This would give the same software-flexibility as modifying endpoints, with the advantage of only needing to support a few systems in your network rather than every single one. I'd expect the same ossification and bad behavior in software middleboxes as we have had so far. But honestly, I see the same thing happening by supporting this on the end-points. I'd summarize my position as follows: If we want to support inspection of traffic by network owners, I see real advantages to selectively breaking forward secrecy for them. But that is a big if. We might be better off just telling those network owners to suck it up and MitM everything.