8 ms·

I'm really happy to see QUIC pushed, not because I personally have a use for it but because it's a battering ram against network non-neutrality and what I've co

• throwaway29303 6y ago
  I believe they'll still be able to do those things, though. It's just a matter of time. The slowing and spying that is. It won't be as easy, but I believe it'll be feasible. It's the typical arms race. Or as last resort they'll legislate either to end or weaken it. I hope I'm mistaken, though.
  • sanxiyn 6y ago
    I predict MITM will be normalized and no amount of "MITM is bad for security!" will work.
    • vntok 6y ago
      Cloudflare's MITM is normalized and very good for security.
      • shockinglytrue 6y ago
        Centralizing the log files for the majority of Internet services in the hands of a few companies will never be good for security
        • vntok 6y ago
          That's a laugh. Are you seriously implying people who benefit freely* from Cloudflare's state of the art network firewalls and anti-ddos shields are somehow more at risk than others because they contracted with a particular security provider instead of rolling their own security? That assertion will require lots of hard evidence because the vast majority of indicators indicate otherwise. * free or less than 20$/mo
          • shockinglytrue 6y ago
            This read more like an advert than a comment, and that is certainly the most loaded question I've ever seen in written English. Giant centralized troves of personal data are a huge risk to everyone. Civilization pivots and mutates rapidly, and it's clear to nobody at any particular time which way it may lean next, or whether it will lean toward them or on top of them. If anyone had told you there'd be global mass beheadings of century-old statues 3 weeks ago, I suppose you'd have been laughing then too.
      • BiteCode_dev 6y ago
        Except if cloudflare is part of a PRISM like program, associated with a gag order. In which case they have pwn half the planet security.
        • vntok 6y ago
          Are you aware "PRISM-like programs" apply to every single US based webserving entity? Why are you calling Cloudflare out when there's thousands of companies who are subject to the very same risk? Is it possible that PRISM programs bear no relevance at all to this conversation?
• Traubenfuchs 6y ago
  I see a chicken egg problem: Why would developers/companies abandon non-QUIC versions of their software if there is a significant chance users can't use it? (If they even implement it under those conditions at all.)
  • cryptonector 6y ago
    Because the semantics of HTTP don't change in /2 and /3, you can always put a reverse proxy in front to bridge versions.
  • Orphis 6y ago
    You don't, you run them in parallel to HTTP/3 and it shouldn't add any cost for you. The work is done in the browser (or any client) to fallback to whatever works. Then, in a few years, when you notice that most of the traffic is done over QUIC, you still won't do anything as it has no significant cost anyway and helps the few % of people who haven't upgraded their network. And customers who can use it won't notice much as your website still works anyway, but your latency metrics should be better for those users.
• shockinglytrue 6y ago
  > Now all those traffic shaping middle-boxes are worthless No reasonable implementation of encrypted SNI has been proposed or standardized. Those middleboxes are still more than useful AFAIK in QUIC there is some light obfuscation of the ClientHello, but it is not intended to be an anti-filtering measure, middleboxes can still fish out any presented name with a little bit of new code
  • tialaramex 6y ago
    What about EKR's https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ ... do you feel is unreasonable?
    • shockinglytrue 6y ago
      Unsurprisingly for a spec from Fastly & CloudFlare, the privacy offered is predicated on the existence of large centralized providers that due to their size cannot be blocked. One outcome of this design is that if you want to offer truly private service to an end user, you must have a relationship with one of these providers, otherwise your traffic, even if it implements the spec, becomes easily identifiable as its EKR config was served by some unique non-shared infrastructure. In practical terms I guess it is reasonable, but viewed from the angle of how the Internet was originally intended to work, it is obviously abhorrent and self-serving.
      • tialaramex 6y ago
        eSNI can only effectively prevent people from distinguishing things which aren't otherwise distinguishable anyway. This is not a forgetfulness potion, if you already know by some other means where I'm going then eSNI doesn't fix that. If cat-videos.example and elect-bob.example are just names for the same IP 10.20.30.40 then we can use eSNI to prevent eavesdroppers discovering which you visited and that's all. But if you've got 10.20.30.40 assigned by your ISP for your personal web server then eSNI can't hide that, you can use eSNI to prevent eavesdroppers learning whether visitors were looking at snakes-control-nasa.example or soup-does-not-exist.example but if all you host are crazy conspiracy theory sites then they don't need to know which one is which to block all of them, that's just how IP works. The configuration for eSNI is delivered over DNS, so it's up to you to choose how you want get secure DNS.
• ocdtrekkie 6y ago
  My main issue with it is exactly your preference: It is built primarily for the purpose of circumventing networking standards and norms, mostly for the benefit of big tech companies and the detriment of everyone else. QUIC is a political measure, not a standards improvement.
  • jeffbee 6y ago
    QUIC hides flow control parameters from the network and takes control away from the operating system, vesting more control in the application. It is the perfection of the end-to-end argument. There's nothing political about it.
    • the_duke 6y ago
      > and takes control away from the operating system That's just because QUIC is a new, not yet specified protocol, isn't it? Kernels will get support eventually. Microsoft is actually already shipping some code. [1] Browsers will probably switch to OS facilities once they are mature enough and provide a performance benefit. [1] https://www.windowslatest.com/2018/04/03/microsoft-to-add-support-for-googles-quic-fast-internet-protocol-in-windows-10-redstone-5/ https://www.windowslatest.com/2018/04/03/microsoft-to-add-su...
      • jeffbee 6y ago
        It's not abundantly clear that there can be a performance benefit from moving QUIC into the kernel. Indeed, there is no performance benefit from having TCP in the kernel. That's why one of the most common tactics in high-performance networking is to move the TCP stack into userspace. The end-to-end argument in IP networking evolved in a time (the 1970s and 1980s) when a host could reasonably be considered the endpoint. Now hosts are so big and powerful that it's no longer reasonable to draw the boundary around them. The individual process running on the host is the true endpoint, and having the application in charge of its own network flow control is the natural evolution of things.
        • 6y ago
• gruez 6y ago
  >Now all those ISPs, IT departments, and cloud providers that de-prioritize or outright block UDP will get "bug reports" about things being "slow" or not working. Doubt it. I suspect that browsers have some sort of happy eyeballs algorithm for determining whether to use http/3 specifically because some networks don't handle it well. In those cases it'll fall back to http 1.1. >Now all those traffic shaping middle-boxes are worthless How so? how is TCP 80/443 and UDP 80/443 harder to traffic shape than TCP 80/443 alone? > and your ISP can no longer spy on your requests to gather marketing data about you. That's more encryption (ie. https) than switching to http/3. Also, encryption is already mandatory for http/2 (for most browsers).
  • humblebee 6y ago
    Curious, why fallback to /1.1 over /2?
    • tialaramex 6y ago
      So far as I can see they won't. Because QUIC (and thus HTTP/3) is always encrypted your fallback is always a TLS connection. Modern TLS agrees the sub-protocol to use (in this case h2 = HTTP/2) early with ALPN. If that ALPN sub-protocol isn't available that same connection just becomes HTTP/1.1 (over TLS) instead. So there's no reason to fall all the way to HTTP/1.1 without asking if HTTP/2 is available.
  • zrm 6y ago
    > Doubt it. I suspect that browsers have some sort of happy eyeballs algorithm for determining whether to use http/3 specifically because some networks don't handle it well. On day zero? Sure. But then good networks will slowly enable UDP/443 anyway, and have good cover because it's The Web, and eventually it'll be enabled on more than 90% of networks. Then a few non-browser applications that use QUIC/HTTPS will decide that 90% is good enough and start to not support TCP anymore, causing trouble for the holdouts and getting it enabled on 95% of networks. Then even more applications will do that. At some point the browsers can put up a warning when fallback happens, telling the user that their network is degrading performance. Eventually the number of networks that don't support it is small enough that nobody supports fallback anymore. > How so? how is TCP 80/443 and UDP 80/443 harder to traffic shape than TCP 80/443 alone? They can't mess with window sizes and such because they're inside the encrypted payload.
• MertsA 6y ago
  It would have been great if they would have used the opportunity to leverage SCTP instead of building it into QUIC. They could have defaulted to plain jane SCTP on IPv6 and tunnel it in UDP for IPv4. That would have been the perfect opportunity to drive adoption of SCTP while implementations of all sorts of middleboxes are still young enough to be swayed into supporting it. We could have all of the benefits of QUIC but with proper layer separation and multi-homing, and the ability to build future applications on it.
  • api 6y ago
    You can't "drive adoption" of anything new in the basic IP protocol space. You're kicking a dead mule. ISPs and IT departments don't care and have little reason to say anything but "no" or "its on the road map" (forever). The present IP stack is fixed in amber, and we'll be lucky to see IPv6 complete adoption. At this point I'd give IPv6 a 50/50 chance of failure. Reasons for this: * No upstream incentive due to little or no competition and not enough "killer apps." * Security FUD: if it's new then it might allow something currently not understood. * ISP desire to control traffic and prohibit anything new. * First thing IT will do if there's a problem is "turn the new thing off." (This happens a lot with IPv6 even if IPv6 is not a cause.) * Vendors with a vested interest in treating the disease (supporting technical debt) rather than curing the patient (actually fixing the problem, reducing the need for complex solutions). My point in the original comment was that QUIC might help stop further ossification by making UDP actually necessary. Otherwise we face the potential for removal of UDP and even removal of non-standard TCP ports, eventually leading to "http only" networks. ISPs and IT departments would like that since less capability equals less support queries and less to monitor. If IP were re-designed today I would suggest at least non-cryptographic but difficult to efficiently modify authentication of all fields (e.g. keyed or nonced checksums), and obfuscation (fast minimal encryption?) of everything under the IP header. No NAT, and nothing useful to filter on. If it's visible and mutable it will become ossified since people will MITM it. That way there would be no choice but to fix endpoint security instead of deploying firewalls and no choice but to adopt IPv6 instead of NAT. You couldn't temporarily work around fundamental problems by nerfing the net. I think there's a general principle here. If easy short term fixes that incur long term technical debt are allowed, they will be deployed. If such a hack is deployed in a federated or decentralized system, it becomes permanent unless extra-systemic means (e.g. legislation or financial incentives) are used to force it to be removed. Therefore federated and decentralized systems should not permit such hacks. Front load the pain by forcing the problem to actually be fixed. This is one thing block chains kind of get right. Everything is cryptographically hashed and authenticated. You can't modify state unilaterally. You either have a compliant node or you don't, and changes must be adopted globally either as soft or hard forks.
• unethical_ban 6y ago
  At $work, udp/443 is blocked to the internet specifically because our corporate proxy can't deal with QUIC and Chrome tries using it a lot. Companies have a legal and moral imperative to see what content is leaving their network, and until some combination of host/network governance is developed to only allow pre-authorized traffic to egress, MITM boxes will need to be supported.
  • JoshTriplett 6y ago
    > Companies have a legal and moral imperative to see what content is leaving their network, and until some combination of host/network governance is developed to only allow pre-authorized traffic to egress, MITM boxes will need to be supported. "a legal and moral imperative"? No. Such networks are security threats and should be repeatedly broken until they give up. It will become increasingly expensive to even try. And an increasing number of security researchers will find ways to make maintaining MITM technologies more difficult and less transparent. You can block spam and outbound attacks without MITMing traffic. MITMing traffic is not about protecting the outside world in any way. It's technology sold to companies out of fear (or misguided regulatory requirements). One day it will go the way of the virus scanner: dead, worse than useless, and only existing to satisfy a decreasing number of corporate checkboxes.
    • unethical_ban 6y ago
      You completely ignore the concept of data breaches and preventing them. You complain about the alleged problem, "man in the middle" technologies, without any proposed solution. Let me be clear: If you do not think private companies and businesses have a right, and sometimes an obligation, to secure and monitor the traffic on their networks, then you are flat out incorrect, and this conversation can end. If you agree they need to monitor data, but that MITM technologies are a societal risk more than a benefit, I am all ears. Host-based data scanning at an OS level; signed traffic that the network can trust has been scanned by authorized hosts (so rogue hosts don't send traffic out); and so on. edit: I don't think your message is consistent, but I think that is not a sign of malice. You say "Companies have no legal or moral need to see what content is leaving their network" then say "You can block spam and outbound attacks without MITMing traffic." You seem to be equating "See the content leaving their network" with "MITM", but then say later that companies can "prevent outbound attacks" without MITM. The #1 threat for many companies is data loss. How do you propose DLP gets accomplished with zero access to the network?
• allarm 6y ago
  The majority of shaping/policing happens on layers below layer 7 - most of the shapers will be working as before. Also since most of the modern web traffic is TLS encrypted, your ISP already can’t spy on you - unless they are doing some kind of a TLS proxy, which is trivial to notice.