Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

QUIC – Will It Replace TCP/IP?

brighttalk.com

Post reply on HN
Print view View original

121–130 of 142 posts

Re: QUIC – Will It Replace TCP/IP?

#121

Post by tialaramex »

anfilt wrote: post #113
ocdtrekkie wrote: post #51

Earlier quoted context omitted.

My concern with Google engaging standards bodies is that if Google is the monopoly on all sides, the standards body has little choice but to eventually accept it: Google didn't wait for an IETF standard to implement it in both their monopoly-scale browser and their monopoly-scale services and then declare that a large portion of Internet traffic was now already using QUIC. I am aware there have been some revisions be…

The IETF has shown it's self less prone to rubber stamping. W3C is a whole other case. Problem is unlike IETF which anyone can chime in on a standard. W3C is members only and most the members are companies. Most these companies use googles web browser so they just kinda go along with it.

The W3C was conceived from the outset for corporations. It even has the word consortium in its name. Personal membership was added much later.

It's actual normal for Standards Organizations to look like this. If anything by their standards the W3C is very liberal. ISO's members are UN member states for example. Want a delegation to ISO to disagree with how an ISO standard works? Create a sovereign entity, seize control over an appreciable amount of the world and force other sovereign entities to accept you as an equal or you can't. The SI units are controlled by Conférence Générale des Poids et Mesures which only has countries as members - some countries don't even get full membership. Don't like the kilogram? Unless you are literally a country too bad.

The IETF is the far outlier, it might even question whether it is indeed a Standards Organization at all. After all it doesn't have any members, (the Internet Society has members but the IETF does not) and so perhaps its "standards" are only "standard" the way English is standard: a bunch of loose conventions, some honoured more consistently than others. Nobody pretends there's a "Standards Organization" for English after all.

Re: QUIC – Will It Replace TCP/IP?

#122

Post by folmar »

JoshTriplett wrote: post #7
tyingq wrote: post #3

They would need some incentives to make it work in big orgs that have MITM and/or restrictive firewalls.

Ideally those incentives would be combined with disincentives for those organizations to continue breaking the web. A combination of the two seems more likely to be successful than either alone.

Many organizations use "the web" as you refer only marginally. The MITM the Outside game works great if you consider the Outside untrusted and only whitelist what you need. Other traffic (both ways) gets inspected for viruses, phishing, information exfiltration, software/hardware call home and whatnot and denied unless proven innocent. This is easier on the users than blocking the outside outright while providing reasonable protection.

Re: QUIC – Will It Replace TCP/IP?

#123

Post by tialaramex »

ocdtrekkie wrote: post #51
mmm_grayons wrote: post #24

Earlier quoted context omitted.

The fact that it originated in Google doesn't make it some kind of proprietary protocol. It's subject to the usual IETF process, just like others, and is a public draft: https://tools.ietf.org/html/draft-ietf-quic-transport-22

My concern with Google engaging standards bodies is that if Google is the monopoly on all sides, the standards body has little choice but to eventually accept it: Google didn't wait for an IETF standard to implement it in both their monopoly-scale browser and their monopoly-scale services and then declare that a large portion of Internet traffic was now already using QUIC. I am aware there have been some revisions be…

> I am aware there have been some revisions between gQUIC and QUIC as being prepared for standardization

I mean... are you though? Because this feels like if somebody told me they are aware there are "some changes" between "Nothing Lasts Forever" and "Die Hard". I mean, yeah, "some" -- like the "hero" cop is actually a hero because Bruce Willis didn't want to play a washed-up alcoholic nutjob whose paranoid fantasies come true... Wait that's a pretty different story isn't it?

Google was welcome to not use IETF protocols before (and sometimes they didn't) and it'll be welcome to not use IETF protocols afterwards (and likely sometimes they won't).

The IETF has no enforcement arm, it exists so that people can agree on things they all want to do. Or, they don't agree on what to do and then they do whatever they want. Lots of people want a better TCP with encryption, enhanced privacy, a way to avoid head-of-line blocking and a fold-away double bed and the QUIC working group has, starting with Google's experiment over two dozen drafts ago, been trying to build one. Some of its participant are from Google (which is great, they have some really smart guys) and of course most are not. You can and should contribute.

Re: QUIC – Will It Replace TCP/IP?

#124

Post by tialaramex »

mmm_grayons wrote: post #120
tialaramex wrote: post #117

Earlier quoted context omitted.

TLS is designed to let you replace the provided peer authentication, people have looked at drafts to hook a PAKE into TLS 1.3 in the past but those drafts have expired. There has more recently been interest in trying again. You can even (though it's discouraged) just make the right noises to get appropriate enumerated values reserved for your mechanism, and ship it, without the hassle (valuable as it would be for act…

There is already an older PAKE in TLS, TLS-SRP. It doesn't apear to be well-loved [0] and I don't know enough about the IP situation to use it confidently, so I've been looking through the CFRG reviews on PAKE candidates [1] to get more info. I mentioned certs because they're a pain to manage and are generally how people do TLS, though there are a few PSK options [2]. Your right that implementing a secure RSA protoco…

You can't use the stuff you linked with TLS 1.3, and of course you can't use an older TLS version in QUIC. It's possible you knew those things, but I want to make sure.

My recent experience with the password manager that was linked on HN shows me that even an abuse-resistant API like Sodium cannot stop people being idiots. (The author believs some random passwords aren't "unique enough" so they have written a bunch of code on top of Sodium to avoid passwords like '4K2m_chmJ$gD' which they feel wouldn't be suitable because it has the letter 'm' more than once...)

Re: QUIC – Will It Replace TCP/IP?

#125

Post by JoshTriplett »

ocdtrekkie wrote: post #116
JoshTriplett wrote: post #102

Earlier quoted context omitted.

If you want to reverse-engineer those devices, do that in a reverse-engineering lab; you may need to dissect the device to figure out what it's doing. Alternatively, run more open devices. If you want to run those devices in production, put them in a separate network or VLAN where they can't see anything they don't need to see.

The problem is that as you advocate for encrypted communications with mysterious cloud endpoints, they just refuse to work unless they can talk to Google or other bad actors in secrer. Trust is unraveled by the unfortunate mistake of letting the PKI structure become the ultimate definition of trust in the world. As it is, don't Chromecasts refuse to function if they can't reach 8.8.8.8? Add encrypted DNS to prevent i…

If you want to treat a company as a "bad actor", don't have a device they built and supply all the software for on your network or give it access to anything you don't want it to have.

(And the PKI infrastructure is the best thing we have; I'd certainly like to see it replaced with something even better.)

Re: QUIC – Will It Replace TCP/IP?

#126

Post by Carpetsmoker »

EdSchouten wrote: post #72
doublerabbit wrote: post #53

As it seems like we won't be rolling out IPv6 anytime soon, why would this replace TCP?

Unlike IPv6, QUIC requires (almost?) no buy-in from network operators/ISPs.

Which is pretty much the entire point of QUIC, since updating gazillions of network appliances to support newer versions of TCP is rather hard and will take decades, if not longer. With QUIC, that's no longer needed.

Re: QUIC – Will It Replace TCP/IP?

#127

Post by ocdtrekkie »

JoshTriplett wrote: post #125
ocdtrekkie wrote: post #116

Earlier quoted context omitted.

The problem is that as you advocate for encrypted communications with mysterious cloud endpoints, they just refuse to work unless they can talk to Google or other bad actors in secrer. Trust is unraveled by the unfortunate mistake of letting the PKI structure become the ultimate definition of trust in the world. As it is, don't Chromecasts refuse to function if they can't reach 8.8.8.8? Add encrypted DNS to prevent i…

If you want to treat a company as a "bad actor", don't have a device they built and supply all the software for on your network or give it access to anything you don't want it to have. (And the PKI infrastructure is the best thing we have; I'd certainly like to see it replaced with something even better.)

"Just don't use untrustworthy hardware and software" isn't really viable when Windows, MacOS, iOS, and Android (incl. Play Services) are all proprietary closed source operating systems, covering over 90% of all consumer computing devices. Before you include all of the IoT space, which also tend to be proprietary.

So creating a system where I, as a consumer, have no way to inspect the communication my devices undertake removes my rights and safety in deference to companies that really just want to make it harder to block ads.

I take issue with this entire model. The fact that PKI has had piles of issues with bad actors who are supposedly supposed to be bastions of trust doesn't give any example this is a system we should trust, much less have browsers force people to utilize and scare people off avoiding.

Re: QUIC – Will It Replace TCP/IP?

#128

Post by mmm_grayons »

tialaramex wrote: post #124
mmm_grayons wrote: post #120

Earlier quoted context omitted.

There is already an older PAKE in TLS, TLS-SRP. It doesn't apear to be well-loved [0] and I don't know enough about the IP situation to use it confidently, so I've been looking through the CFRG reviews on PAKE candidates [1] to get more info. I mentioned certs because they're a pain to manage and are generally how people do TLS, though there are a few PSK options [2]. Your right that implementing a secure RSA protoco…

You can't use the stuff you linked with TLS 1.3, and of course you can't use an older TLS version in QUIC. It's possible you knew those things, but I want to make sure. My recent experience with the password manager that was linked on HN shows me that even an abuse-resistant API like Sodium cannot stop people being idiots. (The author believs some random passwords aren't "unique enough" so they have written a bunch o…

I hadn't checked compatibility and wasn't aware they no longer included SRP. It's not the best PAKE, but to my knowledge, not cryptographically broken (Apple uses it for a bunch of stuff, IIRC). Thanks for letting me know.

And you're right, that's pretty dopey with the password manager. I understand the point of password security measures, but just do something like pam cracklib. There's no such thing as an idiot-proof library. Honestly, that looks like the developer was being kind of lazy, using a constant size for things like max password length.

My only point here is that there are libraries that are well-tested, secure, and at least as idiot-proof as openssl. The increased ability to do the protocol wrong with something like libsodium is balanced by the increased ability to do the crypto wrong with something like openssl.

Re: QUIC – Will It Replace TCP/IP?

#129

Post by bawolff »

coder543 wrote: post #106
takeda wrote: post #96

Earlier quoted context omitted.

TCP/IP != TCP TCP/IP is a name for the Internet Protocol Suite[1], which UDP ironically is part of. If someone talks about one protocol replacing another they should be aware of this distinction, and this title makes me believe the author doesn't know what he is talking about. [1] https://en.wikipedia.org/wiki/Internet_protocol_suite

That's not the singular definition of TCP/IP, as you're seemingly so intent on believing. TCP and IP are separable[1], so it logically makes sense to have "TCP/IP" mean that you're using them together, rather than meaning some arbitrary suite of protocols that may have nothing to do with TCP specifically. Cloudflare, which is obviously a major industry player, defines TCP/IP the same way that the webinar authors and…

I don't think your cloudflare link supports your position. CF talks about "The TCP/IP relationship..." - in context they are clearly referring to tcp and ip as two separate nouns, not as a single noun to refer to the internet suite. Context can modify word meaning-using that as an example really doesn't say anything about the term "tcp/ip" in general.

Fwiw Wikipedia also thinks tcp/ip means the protocol suite https://en.wikipedia.org/wiki/Internet_protocol_suite (edit: i guess other person already said that, i didnt notice)

Edit2: otoh, i think this whole argument is pedantic and its clear what the original article meant.

Re: QUIC – Will It Replace TCP/IP?

#130

Post by takeda »

coder543 wrote: post #106
takeda wrote: post #96

Earlier quoted context omitted.

TCP/IP != TCP TCP/IP is a name for the Internet Protocol Suite[1], which UDP ironically is part of. If someone talks about one protocol replacing another they should be aware of this distinction, and this title makes me believe the author doesn't know what he is talking about. [1] https://en.wikipedia.org/wiki/Internet_protocol_suite

That's not the singular definition of TCP/IP, as you're seemingly so intent on believing. TCP and IP are separable[1], so it logically makes sense to have "TCP/IP" mean that you're using them together, rather than meaning some arbitrary suite of protocols that may have nothing to do with TCP specifically. Cloudflare, which is obviously a major industry player, defines TCP/IP the same way that the webinar authors and…

No, TCP/IP is just a name of the suite, there's no such thing as UDP/IP, just because person who wrote the cloudflare glossary invented it doesn't mean it is an accepted term.

Frankly UDP over any other protocol than IP makes very little sense, UDP header literally are just 4 fields:

   - source port
   - destination port
   - length of the datagram
   - checksum
that's it, and just ports by themselves are not really useful for anything.

The name TCP/IP comes because TCP and IP protocols were created together and closely coupled. Soon they were separated and other protocols were added (UDP, ICMP, IGMP, ARP and many others), but the name stayed.

The TCP/IP name stands for the protocol suite, and things like UDP/IP were invented by people who didn't understand its meaning.

Here are definitions from ICANN: https://icannwiki.org/TCP/IP

Many other authoritative places:

Bunch of RFCs (this one is from 90s): https://tools.ietf.org/html/rfc1180

https://computerhistory.org/profile/vint-cerf/

This term was used essentially from the beginning of the Internet: http://www.columbia.edu/~rh120/other/tcpdigest_paper.txt

Post reply on HN