From a quick skim of this paper, I see no mention of ossification. The biggest advantage of the current "encrypt all the things" push is that protocol evolution is no longer constrained by middleboxes; making the contents of the encrypted connection transparent again, even in a zero-knowledge way, means that once again important parts of the protocol become frozen. For instance, the paper says "[...] Many extensions to this basic request format have been developed during the long lifetime of DNS, but they don’t affect the invariant that we rely on, namely that the DNS question starts at the thirteenth byte of the request. [...]", and as far as I understand from my cursory reading, then goes on to depend on that fact. Which means that future extensions to the protocol which change that offset, which might depend on encrypted connections being truly end-to-end and therefore only the endpoints having to understand them correctly, would then break unless all middleboxes (and in this case, also the complex zero-knowledge proof mechanisms) are upgraded.

Prevention of ossification isn't just a neat side effect of the "encrypt all the things" approach, it's the stated goal, and absolutely necessary.

Normally, I'd agree with your concern, but I'm not worried about this specific one, because it seems entirely impractical and should thus remain an academic exercise:

> Clients send the middlebox zero-knowledge proofs that their traffic is policy-compliant

- this requires integrating software with the clients sending the traffic

> performance is in striking distance of practicality; an example ... In such configurations ... client latency to create a proof is several seconds.

In other words, it's still entirely impractical. This is rounded off by:

> On the other hand, clients may have to store hundreds of MBs depending on the underlying zero-knowledge proof machinery, and for some applications, latency is tens of seconds.

hedgehog

The performance of ZK systems is improving rapidly, for example the startup I'm at has one which is likely already much faster than what the authors used (development is ongoing): https://github.com/risc0/risc0

The security implications of current decrypting MITM middleboxes are pretty bad so it's worth going to some lengths to find an alternative.