17 ms·

Working Group Last Call: QUIC protocol drafts

137 points by pimterry 6y ago

api 6y ago
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 come to call "network nerfing." 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. Now all those traffic shaping middle-boxes are worthless, and your ISP can no longer spy on your requests to gather marketing data about you. The Internet is an IP network, not a TCP/80 and TCP/443 network.
- 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.
mekster 6y ago
Is http/3 completely transparent to the current network and no network that is capable of handling http/1 and 2 would have any problem handling it?
- shockinglytrue 6y ago
  Far from it. It's quite likely going to be over 5 years if not a decade before it would be possible to run a pure-HTTP3 service without risking connectivity problems The problem is similar to the IPv6 transition, except thanks to the browser monopolies, it's possible at least for network providers to quickly feel significant pressure to fix their networks. But there will always be some networks that will never be fixed edit: for those inexplicably downvoting this, please pay attention to the parent comment's question, and the Internet's long chequered history of adopting new protocols in any setting. TCP port 443 isn't going to magically disappear overnight, or indeed any time soon. This is evidently true because it has been true for all prior transitions. Mail still flows to many places unencrypted despite the standardization of STARTTLS 21 years ago. The long tail has only gotten much longer in those intervening 21 years.
  - cryptonector 6y ago
    HTTP/2 and HTTP/3 do not change the semantics of HTTP. That means you can run reverse proxies to server HTTP/1 services as /2 and/or /3 and vice-versa. As a result the transition will be a lot easier than the transition to IPv6. I expect that the transition in corporate networks will be faster -- the opposite of the IPv6 case -- because there is a lot of appeal to HTTP/3.
    - the_duke 6y ago
      > because there is a lot of appeal to HTTP/3 I thought the primary appeal of HTTP/3 is for mobile clients, and bad connections in general, because it circumvents TCP head of line blocking and connections can persist across networks. That doesn't feel terribly relevant in corporate networks. (not disputing that it's not comparable to the v6 transition)
microcolonel 6y ago
Hopefully the state of UDP will improve.
The_rationalist 6y ago
I wonder how much different would it be if HTTP/3 was based on SCTP instead of on UDP. https://en.m.wikipedia.org/wiki/Stream_Control_Transmission_Protocol https://en.m.wikipedia.org/wiki/Stream_Control_Transmission_... In a parallel universe: https://tools.ietf.org/html/draft-natarajan-http-over-sctp-02 https://tools.ietf.org/html/draft-natarajan-http-over-sctp-0... It might be that http 4 experiment this
- bawolff 6y ago
  It wouldn't be adopted due to middle boxes, so all the difference?
  - The_rationalist 6y ago
    Until middleboxes support SCTP, UDP encapsulation is a possible solution That would mean that HTTP3 enable HTTP4 towards STCP
- Avamander 6y ago
  Maybe in the future someone will make an implementation. But right now I don't see it happening, SCTP has too many problems with deployment.
- FlyingAvatar 6y ago
  I see UDP as superior in general, and don't see a good reason to use SCTP at this point for any real use case. IMO, it's a "good thing" for applications (or types of application) to have control over the Transmission Layer since the characteristics that each type of application might desire is different. Want your app to use raw UDP sockets? Easy. Want to use QUIC? Use a QUIC library. HTTP/3? Use and HTTP/3 library. If it all used SCTP, you are locked in to its feature set and are likely to end up with new problems similar to what we see with TCP. I could possibly UDP/QUIC taking over TCP in a long, long while, but SCTP is not likely to ever be usefully supported because there isn't a compelling reason to do it.
The_rationalist 6y ago
Where are the benchmarcks? HTTP 2 gave ~X2 faster performance. I believe that HTTP3 will give far less, especially against tcp fast open
- Avamander 6y ago
  How many actually have TFO enabled?
  - The_rationalist 6y ago
    In a few years most of middle boxes should supports TFO. So when HTTP3 implementations will be mature, TFO should too. The advantages of HTTP3 over it are uncertain
- deleted 6y ago
  [deleted]
- jlouis 6y ago
  More importantly, also look at networks that are bad.
- jayd16 6y ago
  Its kind of an apples and oranges comparison, isn't it? If you care about failure modes and head of line blocking then HTTP/3 has features HTTP/2 does not.
- microcolonel 6y ago
  "Faster" is a hard comparison to make. QUIC resolves issues that will be more important to some networks than others.
  - The_rationalist 6y ago
    I'm talking about average browsing like to ALEXA
Avamander 6y ago
Hm, I don't see any mention of ESNI (TLS ECH), is there a good reason it isn't recommended/mandated by the standards?
- tialaramex 6y ago
  eSNI isn't finished and time resolutely insists on moving in one direction, so a document which says "Use this thing that will exist in the future" isn't useful today.
  - LunaSea 6y ago
    Hasn't it already been implemented in Firefox?
    - detaro 6y ago
      there is an implementation in Firefox (although I don't know if it matches the current state of the spec draft) that unsurprisingly is gated behind an about:config flag.
    - dathinab 6y ago
      isn't finished => the standard of it isn't finished so implementations might not to change quite a bit over time and might not be compatible with each other
- rrll22 6y ago
  Currently up to draft-ietf-dnsop-svcb-httpssvc and draft-ietf-tls-esni They're designed more slowly than HTTP3.
baby 6y ago
My only problem is why force TLS when we have better protocols nowadays. We did some research on using noise (in addition to TLS) but I’m not sure anyone really pushed for this to be considered officially (cf nQUIC)
- Skunkleton 6y ago
  There is nothing precluding HTTP/3.1 from switching up some aspect of the protocol. TLS was probably selected here because it is mature and well supported.
  - baby 6y ago
    The problem is in how the specs are deeply mixed with TLS. We advocated for the specs to be more flexible so that we could extend QUIC to be specified with noise as well but I don’t believe that has happened. Also TLS was selected because of regulations. Which is damning to say the least.
    - Skunkleton 6y ago
      > Also TLS was selected because of regulations. I would like to read more about this. Link?
- microcolonel 6y ago
  The benefit of TLS is widely deployed certificate infrastructure. If you could find a way to keep the server certificate infrastructure intact while cutting out most of the ugliness of TLS, that'd probably be a workable solution. FWIW though, TLS 1.3 (the only currently supported TLS in QUIC, AFAIK) is a lot less hairy than TLS 1.2 and earlier; and most of the primitives are the same as you would use for noise (i.e. standard AEADs like ChaCha20-Poly1305).
  - baby 6y ago
    X509/DER parsing has been known as the most dangerous code in the world (https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-...) Sure support is good but so is PGP’s
jacobush 6y ago
I thought it would be some sort of last stand of QUIC drives.
exabrial 6y ago
All I would like is an unencrypted version of QUIC for low overhead stuff where privacy/security isn't a concern such as experimental, CAN, or air-gapped networks. This has been staunchly rejected unfortunately :/
- michaelbuckbee 6y ago
  I'd like that too, but I think we've all also seen when there's an "easy" workaround it's too often neglected. I'm hopeful that the hard _requirement_ to have encryption will force better management and security.
- bawolff 6y ago
  There are reasons for that beyond crypto-everywhere-goodness - in the main use case crypto helps prevent middleboxes from messing with things which is critical for its success.
  - DaiPlusPlus 6y ago
    Funny that - I thought the advantage of unencrypted HTTP was so that middleboxes could do things like caching (squid, etc) and outbound deep packet inspection to prevent information leaks in corporate environments.
    - axaxs 6y ago
      Middleboxes can still do that, assuming they have a valid SSL certificate. But that obviously makes it a -trusted- middlebox, not say, your ISPs middlebox.
      - ta17711771 6y ago
        That almost sounds like security.
        tialaramex 6y ago
        If they actually do this correctly† then sure, you get security in the sense that you decided to trust My Corp Monkey Proxy to do whatever corporate monkeying, and nobody else can meddle with that. †The correct way to proxy HTTPS is wire a client and server with your meddling code in between, your client negotiates a TLS connection to say https://news.ycombinator.com/ https://news.ycombinator.com/ and it decides exactly what is sent and can see in plaintext exactly what's received. Users make TLS connections to your server and it presents them with a certificate it made, maybe claiming to be news.ycombinator.com and signed by My Corp Monkey Proxy then passes through some requests to the client we described. But it's much cheaper not to do this, and all of the other things you might do to achieve the same goal are insecure or break the protocol or both. So there's a big financial incentive to destroy security, while often ironically claiming to be improving security e.g. anti-phishing. For example choosing random number is hard yet at the same time essential for security - so several major vendors sold products that just didn't. When they turned A->B into A->M->B with their product as M, they'd just re-use the random numbers from the other conversation in the pair. This had been destroying security for all their customers for years, but we only found out they were doing it because it broke with TLS 1.3 final. Specifically when a TLS 1.3 server (but not draft versions for important compatibility reasons) talks to a client that doesn't agree to TLS 1.3 it scribbles the letters "DOWNGRD" over part of the random number field. Since the client supposedly doesn't know TLS 1.3 it shouldn't care, DOWNGRD is a ludicrously unlikely "random" choice but so is "FCKTRMP" or "KICKASS" and those don't mean anything in older TLS versions either. But if the client really does speak TLS 1.3 and has somehow been tricked into negotiating an old version, this weird choice of "random" number signals it's a trick and it will disconnect. The affected "proxies" would tell a nice shiny new Chrome or Firefox (which can speak TLS 1.3 and thus are looking out for DOWNGRD) that they only knew TLS 1.2, fair enough. And they'd tell servers, say www.google.com, the same thing. But the TLS 1.3 capable servers would scribble DOWNGRD into their random number field, and then because these "proxies" weren't actually assembled from a separate client and server but just re-used all the numbers, the DOWNGRD gets copied into data received in Chrome, and it disconnects because it has seemingly detected an active attack.
eadan 6y ago
How well does QUIC perform over networks with relatively high packet loss? It seems like Aspera (https://www.ibm.com/products/aspera https://www.ibm.com/products/aspera) is the industry standard for high performance WAN transfers, but it's a proprietary protocol. I'm wondering if QUIC performs better than HTTP1/2 in this respect?
- bawolff 6y ago
  That is the use case its targeting (relative to http/2)
  - fulafel 6y ago
    The drafts don't seem to mention that this use case would be at the forefront or better than with HTTP/2, got any pointers? Generally high loss is not well tolerated by internet protocols, so high loss networking technologies tend to handle forward error correction and retransmissions in protocol layers below IP.
- atesti 6y ago
  How does Aspera work? How is it possible to be 1000x faster? Is it? TCP works by slowing the data rate when data loss happens. On purpose, to be fair! I think it's not that hard to write a program/protocl that blasts out a big file over UDP and just sends all the parts as packets, then waits for the receiver to assemble a big list of missing packets, send them back and have the sender blast out everything again at a high rate. But this would be at the expense of all the other TCP connections. Wasn't QUIC changed to be so called "TCP friendly", that means that it has the same back off behaviour as TCP so that if you are in a crowded hot spot every tcp stream has a fair chance? (On the other site, google and some other companies have a huge initial TCP window size and try (or tried?) to send e.g. the whole google homepage with like 8 1500 byte packets at once, also trying to get a better ux than other, again on the expense of other TCP streams) Looks like using Aspera is unfair and only works if a few people do it.
  - eadan 6y ago
    My understanding is that the protocol underlying Aspera (FASP) uses UDP for the main data transfer and a TCP connection for coordination. By using UDP for data transfer it's not restricted to the ACK ranges imposed by TCP which can hinder throughput on networks with relatively high packet loss. Its throughput is not necessarily achieved by being a "bad citizen" but by having full control over how and when it communicates lost packets. Since QUIC is also over UDP, perhaps we now have more flexibility on ACK windows etc. Btw. there are open protocols like Tsunami UDP (https://en.wikipedia.org/wiki/Tsunami_UDP_Protocol https://en.wikipedia.org/wiki/Tsunami_UDP_Protocol) that try to fill the same niche
jakeogh 6y ago
HTTP/3 spin bit: https://news.ycombinator.com/item?id=20990754 https://news.ycombinator.com/item?id=20990754

137 points by pimterry 6y ago

api 6y ago

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 come to call "network nerfing." 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. Now all those traffic shaping middle-boxes are worthless, and your ISP can no longer spy on your requests to gather marketing data about you. The Internet is an IP network, not a TCP/80 and TCP/443 network.

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.

mekster 6y ago

Is http/3 completely transparent to the current network and no network that is capable of handling http/1 and 2 would have any problem handling it?

shockinglytrue 6y ago
Far from it. It's quite likely going to be over 5 years if not a decade before it would be possible to run a pure-HTTP3 service without risking connectivity problems The problem is similar to the IPv6 transition, except thanks to the browser monopolies, it's possible at least for network providers to quickly feel significant pressure to fix their networks. But there will always be some networks that will never be fixed edit: for those inexplicably downvoting this, please pay attention to the parent comment's question, and the Internet's long chequered history of adopting new protocols in any setting. TCP port 443 isn't going to magically disappear overnight, or indeed any time soon. This is evidently true because it has been true for all prior transitions. Mail still flows to many places unencrypted despite the standardization of STARTTLS 21 years ago. The long tail has only gotten much longer in those intervening 21 years.
- cryptonector 6y ago
  HTTP/2 and HTTP/3 do not change the semantics of HTTP. That means you can run reverse proxies to server HTTP/1 services as /2 and/or /3 and vice-versa. As a result the transition will be a lot easier than the transition to IPv6. I expect that the transition in corporate networks will be faster -- the opposite of the IPv6 case -- because there is a lot of appeal to HTTP/3.
  - the_duke 6y ago
    > because there is a lot of appeal to HTTP/3 I thought the primary appeal of HTTP/3 is for mobile clients, and bad connections in general, because it circumvents TCP head of line blocking and connections can persist across networks. That doesn't feel terribly relevant in corporate networks. (not disputing that it's not comparable to the v6 transition)

microcolonel 6y ago

Hopefully the state of UDP will improve.

The_rationalist 6y ago

I wonder how much different would it be if HTTP/3 was based on SCTP instead of on UDP. https://en.m.wikipedia.org/wiki/Stream_Control_Transmission_Protocol https://en.m.wikipedia.org/wiki/Stream_Control_Transmission_... In a parallel universe: https://tools.ietf.org/html/draft-natarajan-http-over-sctp-02 https://tools.ietf.org/html/draft-natarajan-http-over-sctp-0... It might be that http 4 experiment this

bawolff 6y ago
It wouldn't be adopted due to middle boxes, so all the difference?
- The_rationalist 6y ago
  Until middleboxes support SCTP, UDP encapsulation is a possible solution That would mean that HTTP3 enable HTTP4 towards STCP
Avamander 6y ago
Maybe in the future someone will make an implementation. But right now I don't see it happening, SCTP has too many problems with deployment.
FlyingAvatar 6y ago
I see UDP as superior in general, and don't see a good reason to use SCTP at this point for any real use case. IMO, it's a "good thing" for applications (or types of application) to have control over the Transmission Layer since the characteristics that each type of application might desire is different. Want your app to use raw UDP sockets? Easy. Want to use QUIC? Use a QUIC library. HTTP/3? Use and HTTP/3 library. If it all used SCTP, you are locked in to its feature set and are likely to end up with new problems similar to what we see with TCP. I could possibly UDP/QUIC taking over TCP in a long, long while, but SCTP is not likely to ever be usefully supported because there isn't a compelling reason to do it.

The_rationalist 6y ago

Where are the benchmarcks? HTTP 2 gave ~X2 faster performance. I believe that HTTP3 will give far less, especially against tcp fast open

Avamander 6y ago
How many actually have TFO enabled?
- The_rationalist 6y ago
  In a few years most of middle boxes should supports TFO. So when HTTP3 implementations will be mature, TFO should too. The advantages of HTTP3 over it are uncertain
deleted 6y ago
[deleted]
jlouis 6y ago
More importantly, also look at networks that are bad.
jayd16 6y ago
Its kind of an apples and oranges comparison, isn't it? If you care about failure modes and head of line blocking then HTTP/3 has features HTTP/2 does not.
microcolonel 6y ago
"Faster" is a hard comparison to make. QUIC resolves issues that will be more important to some networks than others.
- The_rationalist 6y ago
  I'm talking about average browsing like to ALEXA

Avamander 6y ago

Hm, I don't see any mention of ESNI (TLS ECH), is there a good reason it isn't recommended/mandated by the standards?

tialaramex 6y ago
eSNI isn't finished and time resolutely insists on moving in one direction, so a document which says "Use this thing that will exist in the future" isn't useful today.
- LunaSea 6y ago
  Hasn't it already been implemented in Firefox?
  - detaro 6y ago
    there is an implementation in Firefox (although I don't know if it matches the current state of the spec draft) that unsurprisingly is gated behind an about:config flag.
  - dathinab 6y ago
    isn't finished => the standard of it isn't finished so implementations might not to change quite a bit over time and might not be compatible with each other
rrll22 6y ago
Currently up to draft-ietf-dnsop-svcb-httpssvc and draft-ietf-tls-esni They're designed more slowly than HTTP3.

baby 6y ago

My only problem is why force TLS when we have better protocols nowadays. We did some research on using noise (in addition to TLS) but I’m not sure anyone really pushed for this to be considered officially (cf nQUIC)

Skunkleton 6y ago
There is nothing precluding HTTP/3.1 from switching up some aspect of the protocol. TLS was probably selected here because it is mature and well supported.
- baby 6y ago
  The problem is in how the specs are deeply mixed with TLS. We advocated for the specs to be more flexible so that we could extend QUIC to be specified with noise as well but I don’t believe that has happened. Also TLS was selected because of regulations. Which is damning to say the least.
  - Skunkleton 6y ago
    > Also TLS was selected because of regulations. I would like to read more about this. Link?
microcolonel 6y ago
The benefit of TLS is widely deployed certificate infrastructure. If you could find a way to keep the server certificate infrastructure intact while cutting out most of the ugliness of TLS, that'd probably be a workable solution. FWIW though, TLS 1.3 (the only currently supported TLS in QUIC, AFAIK) is a lot less hairy than TLS 1.2 and earlier; and most of the primitives are the same as you would use for noise (i.e. standard AEADs like ChaCha20-Poly1305).
- baby 6y ago
  X509/DER parsing has been known as the most dangerous code in the world (https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-...) Sure support is good but so is PGP’s

jacobush 6y ago

I thought it would be some sort of last stand of QUIC drives.

exabrial 6y ago

All I would like is an unencrypted version of QUIC for low overhead stuff where privacy/security isn't a concern such as experimental, CAN, or air-gapped networks. This has been staunchly rejected unfortunately :/

michaelbuckbee 6y ago
I'd like that too, but I think we've all also seen when there's an "easy" workaround it's too often neglected. I'm hopeful that the hard _requirement_ to have encryption will force better management and security.
bawolff 6y ago
There are reasons for that beyond crypto-everywhere-goodness - in the main use case crypto helps prevent middleboxes from messing with things which is critical for its success.
- DaiPlusPlus 6y ago
  Funny that - I thought the advantage of unencrypted HTTP was so that middleboxes could do things like caching (squid, etc) and outbound deep packet inspection to prevent information leaks in corporate environments.
  - axaxs 6y ago
    Middleboxes can still do that, assuming they have a valid SSL certificate. But that obviously makes it a -trusted- middlebox, not say, your ISPs middlebox.
    - ta17711771 6y ago
      That almost sounds like security.
      - tialaramex 6y ago
        If they actually do this correctly† then sure, you get security in the sense that you decided to trust My Corp Monkey Proxy to do whatever corporate monkeying, and nobody else can meddle with that. †The correct way to proxy HTTPS is wire a client and server with your meddling code in between, your client negotiates a TLS connection to say https://news.ycombinator.com/ https://news.ycombinator.com/ and it decides exactly what is sent and can see in plaintext exactly what's received. Users make TLS connections to your server and it presents them with a certificate it made, maybe claiming to be news.ycombinator.com and signed by My Corp Monkey Proxy then passes through some requests to the client we described. But it's much cheaper not to do this, and all of the other things you might do to achieve the same goal are insecure or break the protocol or both. So there's a big financial incentive to destroy security, while often ironically claiming to be improving security e.g. anti-phishing. For example choosing random number is hard yet at the same time essential for security - so several major vendors sold products that just didn't. When they turned A->B into A->M->B with their product as M, they'd just re-use the random numbers from the other conversation in the pair. This had been destroying security for all their customers for years, but we only found out they were doing it because it broke with TLS 1.3 final. Specifically when a TLS 1.3 server (but not draft versions for important compatibility reasons) talks to a client that doesn't agree to TLS 1.3 it scribbles the letters "DOWNGRD" over part of the random number field. Since the client supposedly doesn't know TLS 1.3 it shouldn't care, DOWNGRD is a ludicrously unlikely "random" choice but so is "FCKTRMP" or "KICKASS" and those don't mean anything in older TLS versions either. But if the client really does speak TLS 1.3 and has somehow been tricked into negotiating an old version, this weird choice of "random" number signals it's a trick and it will disconnect. The affected "proxies" would tell a nice shiny new Chrome or Firefox (which can speak TLS 1.3 and thus are looking out for DOWNGRD) that they only knew TLS 1.2, fair enough. And they'd tell servers, say www.google.com, the same thing. But the TLS 1.3 capable servers would scribble DOWNGRD into their random number field, and then because these "proxies" weren't actually assembled from a separate client and server but just re-used all the numbers, the DOWNGRD gets copied into data received in Chrome, and it disconnects because it has seemingly detected an active attack.

eadan 6y ago

How well does QUIC perform over networks with relatively high packet loss? It seems like Aspera (https://www.ibm.com/products/aspera https://www.ibm.com/products/aspera) is the industry standard for high performance WAN transfers, but it's a proprietary protocol. I'm wondering if QUIC performs better than HTTP1/2 in this respect?

bawolff 6y ago
That is the use case its targeting (relative to http/2)
- fulafel 6y ago
  The drafts don't seem to mention that this use case would be at the forefront or better than with HTTP/2, got any pointers? Generally high loss is not well tolerated by internet protocols, so high loss networking technologies tend to handle forward error correction and retransmissions in protocol layers below IP.
atesti 6y ago
How does Aspera work? How is it possible to be 1000x faster? Is it? TCP works by slowing the data rate when data loss happens. On purpose, to be fair! I think it's not that hard to write a program/protocl that blasts out a big file over UDP and just sends all the parts as packets, then waits for the receiver to assemble a big list of missing packets, send them back and have the sender blast out everything again at a high rate. But this would be at the expense of all the other TCP connections. Wasn't QUIC changed to be so called "TCP friendly", that means that it has the same back off behaviour as TCP so that if you are in a crowded hot spot every tcp stream has a fair chance? (On the other site, google and some other companies have a huge initial TCP window size and try (or tried?) to send e.g. the whole google homepage with like 8 1500 byte packets at once, also trying to get a better ux than other, again on the expense of other TCP streams) Looks like using Aspera is unfair and only works if a few people do it.
- eadan 6y ago
  My understanding is that the protocol underlying Aspera (FASP) uses UDP for the main data transfer and a TCP connection for coordination. By using UDP for data transfer it's not restricted to the ACK ranges imposed by TCP which can hinder throughput on networks with relatively high packet loss. Its throughput is not necessarily achieved by being a "bad citizen" but by having full control over how and when it communicates lost packets. Since QUIC is also over UDP, perhaps we now have more flexibility on ACK windows etc. Btw. there are open protocols like Tsunami UDP (https://en.wikipedia.org/wiki/Tsunami_UDP_Protocol https://en.wikipedia.org/wiki/Tsunami_UDP_Protocol) that try to fill the same niche

jakeogh 6y ago

HTTP/3 spin bit: https://news.ycombinator.com/item?id=20990754 https://news.ycombinator.com/item?id=20990754