[HN Gopher] Zero-Knowledge Middleboxes: enforce network policies...
       ___________________________________________________________________
        
       Zero-Knowledge Middleboxes: enforce network policies on encrypted
       traffic
        
       Author : self
       Score  : 59 points
       Date   : 2022-04-17 15:44 UTC (7 hours ago)
        
 (HTM) web link (eprint.iacr.org)
 (TXT) w3m dump (eprint.iacr.org)
        
       | Terry_Roll wrote:
       | Some of the citations are factually incorrect, do people actually
       | check this papers out before they get published?
       | 
       | Dodgy Science & whitepapers!
        
         | paulgrubbs wrote:
         | Author of the paper here - can you be more specific about which
         | citations are factually incorrect?
        
       | cesarb wrote:
       | 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.
        
       | josephcsible wrote:
       | 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.)
        
         | matheusmoreira wrote:
         | I hope these cat and mouse games end someday. We don't want
         | anyone enforcing "policies" on us. Maybe one day we'll have
         | technology that will finally render them powerless.
        
       | Pelam wrote:
       | 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.
        
       | doomrobo wrote:
       | 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)
        
       | jedisct1 wrote:
       | The paper was presented last year at sdns://2021:
       | https://youtu.be/ihFmYs3Bi_c
        
       | elij wrote:
       | 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.
       | 
       | Obviously some work is needed in the host IP stack for per packet
       | tagging (DCSP/traffic class) rather than per socket and then
       | flushing.
        
       ___________________________________________________________________
       (page generated 2022-04-17 23:01 UTC)