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.
Can’t wait for the corporate security industry to get hold of this. Yet another way to make corporate policy compliant workstations slower and less usable than a 10 year old linux box.
I hope someone finds a way to completely break this. Otherwise, imagine when the censors get ahold of it. (If you're not convinced this is a bad thing, read "their traffic is policy-compliant" as "they aren't trying to visit any Web pages that acknowledge that the Tiananmen Square Massacre occurred", for example.)
The paper was presented last year at sdns://2021: <a href="https://youtu.be/ihFmYs3Bi_c" rel="nofollow">https://youtu.be/ihFmYs3Bi_c</a>
I like this idea and this is very much the future. I wish it wasn't out of band and these proofs could be embedded in the relatively small address space of IP headers. This also lets us take advantage of merchant silicon for branching logic.<p>Obviously some work is needed in the host IP stack for per packet tagging (DCSP/traffic class) rather than per socket and then flushing.
TL;DR This is a way for admins to enforce network policies without needing to see the decrypted traffic. You can use this to enforce domain blocklists for DNS over HTTPS: client proves their requested domain is not banned (a few sec) and middlebox verifies (a few millisec)
tldr: paper is an attempt of applying crypto/blockchain related ZK-SNARKs to network security.<p>But modern network security and firewalling is completely different and became very advanced. Nobody is blocking http port by port nowadays. Modern NGFWs are capable of decrypting/encrypting TLS traffic transparently for the end user and server and inspecting traffic for policy compliance based on any attribute in the request payload. and it runs on dedicated ASICs on specialized network appliances in realtime.<p>Just another crypto tech looking for a problem to solve