11 ms·

Google is not Requesting For Comments at all. It is imposing its things. Despite the fancy number, this is not an RFC at all, in the ancient sense of the acrony

Google is not Requesting For Comments at all. It is imposing its things. Despite the fancy number, this is not an RFC at all, in the ancient sense of the acronym, nor it has the same design principles of simplicity and orthogonality.

xanathar 5y ago
QUIC has been an IETF draft for years and they were definitely accepting contributions and feedback, and a lot of efforts were not driven by Google at all. As far as orthogonality goes, it seems to be pretty orthogonal to different kind of uses, I'm not sure why you're saying it's not. On simplicity it's definitely not simple, but given the problems it is trying to solve it's probably as simple as it could be.
jeltz 5y ago
I have spoken with Daniel Stenberg about this and if I recall correctly he disagreed and said that the QUIC which ended up being standardized is quite different from Google's QUIC.
- KirillPanov 5y ago
  I'd be interested in knowing what major design directions were changed/deleted/added.
  - tialaramex 5y ago
    For example, gQUIC has its own custom encryption "QUIC crypto" while as you will see in these RFCs the final IETF QUIC design uses the existing TLS 1.3 (existing now, it didn't exist when Google made gQUIC) for encryption. Or at a philosophical level, gQUIC is an HTTP replacement, it doesn't do anything else except a better HTTP, so it doesn't need to care about any features you might want for, say, SMTP or IMAP or IRC unless it wanted them for HTTP. gQUIC knows about HTTP headers. But the IETF QUIC is a replacement for TCP not HTTP. That's why there's an entire HTTP/3 standard in this bundle of RFCs which sits on top of QUIC as its first "customer".
    - KirillPanov 5y ago
      Thanks for the reply! It's coming back now; I definitely remember reading some early drafts and thinking "boy it's sad this is just HTTP 3.0-rc1". I always liked SCTP; I'm glad IETF-QUIC has moved back towards being (sort of) SCTP-over-UDP as well as a better HTTP. On the encryption front I don't remember reading about a non-TLS version (I probably missed it). I'm kinda sad that got dropped. TLS is just crazy complicated in ways that are unnecessary for non-web things like ssh and wireguard.... X.509 and the whole certificate authority trainwreck. I really hope we get a "QUIC with non-TLS encryption" at some point in the future.
      - tialaramex 5y ago
        I don't buy the theory that the Web PKI or some equivalent is "unnecessary for non-Web things". If anything I think there have been a few places where there's a nasty security gap because somebody didn't just stuff the Web PKI in there, even though it wasn't necessarily a perfect fit, because what we got instead was nothing ie no security. An example of that first: Does your phone try to connect to SomeBrand WiFi networks? How does it know if this is a "real" SomeBrand WiFi network? It doesn't. In some scenarios this means you leak valid credentials for the "real" SomeBrand to bad guys. In most cases you at least leak identity information. That's not great news. If the WiFi network was named example.com the WiFi AP could of course present a certificate for example.com, leveraging the Web PKI. Now, there are people who want to do QUIC without TLS, mostly what they want to do is NOISE. Like this: https://www.cryptologie.net/article/467/quic-noise-nquic/ https://www.cryptologie.net/article/467/quic-noise-nquic/ But again, I think something like SSH is the exception and the Web PKI is more applicable to most uses for QUIC.
  - janaiyengar 5y ago
    @KirillPanov -- you might find this article useful: https://www.fastly.com/blog/maturing-of-quic https://www.fastly.com/blog/maturing-of-quic
    - KirillPanov 5y ago
      Thanks! After reading the link you provided, I found out that gQUIC's FEC (Forward Error Correction) was removed from IETF-QUIC, which is a minor bummer. But it appears that the removal is not permanent, and that it was removed mainly because it is something that can be added later ("QUIC 1.1") in a backward-compatible way. The other really interesting part was the "spin bit". It's intuitively clear how it could be used by ISPs to monitor the latency impact of their decisions. Unfortunately the cynic in me knows somebody will find a way to use it for fingerprinting. Room 641A really ruined the ISP's credibility in a permanent way.
becauseiam 5y ago
Although Google did come up with the original specification their influence over the IETF specifications is not overarching nor absolute; gQUIC is substantially different from IETF QUIC which has caused Google themselves to have implementation and interop issues in their deployments. OS vendors, CDNs, academic researchers, and individuals have all contributed to the resulting specifications that have emerged in a standards body that is by far the most open as the requisite to participate is a functioning email address. All matters and decision making are publicly available for observation and scrutiny. There is no requirement for people to implement this protocol and it won't be appropriate to every use case that exists today. TCP, UDP, HTTP/1.1, and HTTP/2 are not going away - all continue to undergo standardisation, research, and new implementations. (Disclosure: I'm not a Google employee, but I have participated in the QUIC and httpbis working groups)

xanathar 5y ago

QUIC has been an IETF draft for years and they were definitely accepting contributions and feedback, and a lot of efforts were not driven by Google at all. As far as orthogonality goes, it seems to be pretty orthogonal to different kind of uses, I'm not sure why you're saying it's not. On simplicity it's definitely not simple, but given the problems it is trying to solve it's probably as simple as it could be.

jeltz 5y ago

I have spoken with Daniel Stenberg about this and if I recall correctly he disagreed and said that the QUIC which ended up being standardized is quite different from Google's QUIC.

KirillPanov 5y ago
I'd be interested in knowing what major design directions were changed/deleted/added.
- tialaramex 5y ago
  For example, gQUIC has its own custom encryption "QUIC crypto" while as you will see in these RFCs the final IETF QUIC design uses the existing TLS 1.3 (existing now, it didn't exist when Google made gQUIC) for encryption. Or at a philosophical level, gQUIC is an HTTP replacement, it doesn't do anything else except a better HTTP, so it doesn't need to care about any features you might want for, say, SMTP or IMAP or IRC unless it wanted them for HTTP. gQUIC knows about HTTP headers. But the IETF QUIC is a replacement for TCP not HTTP. That's why there's an entire HTTP/3 standard in this bundle of RFCs which sits on top of QUIC as its first "customer".
  - KirillPanov 5y ago
    Thanks for the reply! It's coming back now; I definitely remember reading some early drafts and thinking "boy it's sad this is just HTTP 3.0-rc1". I always liked SCTP; I'm glad IETF-QUIC has moved back towards being (sort of) SCTP-over-UDP as well as a better HTTP. On the encryption front I don't remember reading about a non-TLS version (I probably missed it). I'm kinda sad that got dropped. TLS is just crazy complicated in ways that are unnecessary for non-web things like ssh and wireguard.... X.509 and the whole certificate authority trainwreck. I really hope we get a "QUIC with non-TLS encryption" at some point in the future.
    - tialaramex 5y ago
      I don't buy the theory that the Web PKI or some equivalent is "unnecessary for non-Web things". If anything I think there have been a few places where there's a nasty security gap because somebody didn't just stuff the Web PKI in there, even though it wasn't necessarily a perfect fit, because what we got instead was nothing ie no security. An example of that first: Does your phone try to connect to SomeBrand WiFi networks? How does it know if this is a "real" SomeBrand WiFi network? It doesn't. In some scenarios this means you leak valid credentials for the "real" SomeBrand to bad guys. In most cases you at least leak identity information. That's not great news. If the WiFi network was named example.com the WiFi AP could of course present a certificate for example.com, leveraging the Web PKI. Now, there are people who want to do QUIC without TLS, mostly what they want to do is NOISE. Like this: https://www.cryptologie.net/article/467/quic-noise-nquic/ https://www.cryptologie.net/article/467/quic-noise-nquic/ But again, I think something like SSH is the exception and the Web PKI is more applicable to most uses for QUIC.
- janaiyengar 5y ago
  @KirillPanov -- you might find this article useful: https://www.fastly.com/blog/maturing-of-quic https://www.fastly.com/blog/maturing-of-quic
  - KirillPanov 5y ago
    Thanks! After reading the link you provided, I found out that gQUIC's FEC (Forward Error Correction) was removed from IETF-QUIC, which is a minor bummer. But it appears that the removal is not permanent, and that it was removed mainly because it is something that can be added later ("QUIC 1.1") in a backward-compatible way. The other really interesting part was the "spin bit". It's intuitively clear how it could be used by ISPs to monitor the latency impact of their decisions. Unfortunately the cynic in me knows somebody will find a way to use it for fingerprinting. Room 641A really ruined the ISP's credibility in a permanent way.

becauseiam 5y ago

Although Google did come up with the original specification their influence over the IETF specifications is not overarching nor absolute; gQUIC is substantially different from IETF QUIC which has caused Google themselves to have implementation and interop issues in their deployments. OS vendors, CDNs, academic researchers, and individuals have all contributed to the resulting specifications that have emerged in a standards body that is by far the most open as the requisite to participate is a functioning email address. All matters and decision making are publicly available for observation and scrutiny. There is no requirement for people to implement this protocol and it won't be appropriate to every use case that exists today. TCP, UDP, HTTP/1.1, and HTTP/2 are not going away - all continue to undergo standardisation, research, and new implementations. (Disclosure: I'm not a Google employee, but I have participated in the QUIC and httpbis working groups)