13 ms·

Internet protocols are changing

458 points by nmjohn 9y ago

ilaksh 9y ago
It seems that widely deploying TLS 1.3 and DOH can provide an effective technical end-around the dismantling of net neutrality. So we should be promoting and trying to deploy them as widely as possible. Of course, they can still block or throttle by IP, so the next step is to increase deployment of content-centric networking systems.
- jstanley 9y ago
  By content-centric networking systems do you mean IPFS et al?
  - ilaksh 9y ago
    Yes, IPFS, but actually there a huge number of perhaps lesser-known projects that do all sorts of things with content-oriented-networking. It's been a pretty big research topic.
- topspin 9y ago
  It seems to me that all of the changes described in this story will contribute to thwarting intermediaries and their agendas. HTTP/2 and its "effective" encryption requirement are proof against things like Comcast's nasty JavaScript injection[1]. QUIC has mandatory encryption all the way down; even ACKs are encrypted, obviating some of the traditional throttling techniques. And as you say TLS 1.3 and DOH further protect traffic from analysis and manipulation by middlemen. Perhaps our best weapon against Internet rent seekers and spooks is technical innovation. It is astonishing to me that Google can invent QUIC, deploy it on their network+Chrome and boom! 7% of all Internet traffic is QUIC. Traditional HTTP over TCP and traditional DNS are becoming a ghetto protocol stack; analysis of such traffic is sold to who knows whom, the content is subject to manipulation by your ISP, throttling is trivial and likely to become commonplace with Ajit Pai et al. Time to pull the plug on these grifters and protect all the traffic. [1] https://news.ycombinator.com/item?id=15890551 https://news.ycombinator.com/item?id=15890551
  - zb3 9y ago
    But I, as an user, want to be able to block domains, inject scripts and see what Chrome is sending to Google on my own devices (which is what Google doesn't want me to do). That's why I can't support these protocols...
    - JoshTriplett 9y ago
      You, as a user, absolutely can. An ISP or network administrator who does not control the endpoints, on the other hand, cannot, by design. That's a feature.
      - fiddlerwoaroof 9y ago
        What if I want to use my router to block telemetry domains? Or other malware sites? It’s looking like the only way forward is running my own CA to mitm all encrypted traffic.
        JoshTriplett 9y ago
        > It’s looking like the only way forward is running my own CA to mitm all encrypted traffic. Correct. Middleboxes should be presumed hostile; if you control the endpoints you can install a MITM CA, but it's safer to put what you want directly on the endpoint.
        aoeusnth1 9y ago
        That seems superior anyway - you could keep blocking domains even when you're on the go.
        kuschku 9y ago
        Can I? On Android, apps now can decide if they want to accept user-installed CAs, or not. So if an app is hostile (say, all the Google apps), then I have no way to intercept their traffic anymore.
- lathiat 9y ago
  Unfortunately not really; Net Neutrality mostly focuses around the semi-bigger services who in most cases will have at least one of a dedicated AS number; dedicated IP ranges or dedicated physical network links they can limit the capacity of. Which is traditionally how the game has been played. Think Netflix/Comcast.. no hiding what that traffic is.
- ori_b 9y ago
  > It seems that widely deploying TLS 1.3 and DOH can provide an effective technical end-around the dismantling of net neutrality. If you don't think about it, it may seem that way. But until everyone sends all their data over tor, or some other system that obscures which IP you're trying to get to, it's still easy to filter. There's (within epsilon of) zero motion I've seen towards obscuring IP addresses, for good reason.
jandrese 9y ago
> When a protocol can’t evolve because deployments ‘freeze’ its extensibility points, we say it has ossified. TCP itself is a severe example of ossification; so many middleboxes do so many things to TCP — whether it’s blocking packets with TCP options that aren’t recognized, or ‘optimizing’ congestion control. > It’s necessary to prevent ossification, to ensure that protocols can evolve to meet the needs of the Internet in the future; otherwise, it would be a ‘tragedy of the commons’ where the actions of some individual networks — although well-intended — would affect the health of the Internet overall. On the other hand, I've done a fair bit of work getting TCP based applications to behave properly over high latency high congestion (satellite or radio usually) links and QUIC makes me nervous. In the old days you could put a TCP proxy like SCPS in there and most apps would get an acceptable level of performance, but now I'm not so sure. It seems like everybody assumes you're on a big fat broadband pipe now and nobody else matters.
- peterwwillis 9y ago
  > It seems like everybody assumes you're on a big fat broadband pipe now and nobody else matters. This is intentional. The powers that be have an interest in moving everyone to faster networks, and they effectively control all new web standards, and so build their protocols to force the apps to require faster, bigger pipes. This way they are never to blame for the new requirements, yet they get the intended benefits of fatter pipes: the ability to shove more crap down your throat. It's possible to cache static binary assets using encrypted connections, but I am not aware of a single RFC that seriously suggests its adoption. It is also to the advantage of the powers that be (who have the financial means to do this) to simply move content distribution closer to the users. As the powers that be don't provide internet services over satellite or microwave, they do not consider them when defining the standards.
  - jjrh 9y ago
    Not sure who "The powers that be" are, but anyone can propose and contribute to IETF standards. They are called "Request for Comment" for a reason.
    - 9y ago
shalabhc 9y ago
Another interesting protocol, perhaps underused, is SCTP. It fixes many issues with TCP, in particular it has reliable datagrams with multiplexing and avoiding head-of-line blocking. I believe QUIC is supposed to be faster at connection (re)estabishment. https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
- dragontamer 9y ago
  SCTP is a superior protocol, but it isn't implemented in many routers or firewalls. As long as Comcast / Verizon routers don't support it, no one will use it. It may be built on top of IP, but TCP / UDP levels are important for NAT and such. Too few people use DMZ and other features of routers / firewalls. Its way easier to just put up with TCP / UDP issues to stay compatible with most home setups.
  - pfranz 9y ago
    To your point, IPv6 has been around 20 years, the whole time we know we're running out of IPv4 addresses and adoption is still around 20%. However, the high turnover for mobile phones has allowed more aggressive changes to the networking stack. Perhaps this, in addition to IPv6, would make something like SCTP easier to adopt widely?
    - 24gttghh 9y ago
      "Still" seems a bit disingenuous when considering the current trajectory IPv6 adoption is on. [0] Yah it's happening slowly, but it does seem to be pushing ahead. [0] https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html
      - pfranz 9y ago
        How is that disingenuous? I don't think it matters what the curve looks like when it spans 10 years and ends up at 20%. There were implementations released 10 years previous to the graph's start. I wasn't implying it would never happen, just that even for something that's inevitable like IPv6, adoption is glacial.
deleted 9y ago
[deleted]
jjjaslin7 9y ago
Best Buy Online – Flights, Hotel, Tours & Travels, Fashion, Health & Beauty and Electronics https://buff.ly/2na35ma https://buff.ly/2na35ma Amazing sale online shopping - Click Links Best places to buy Apple products on Black Friday https://buff.ly/2hSjypp https://buff.ly/2hSjypp Shop Online - Global Marketplace Merchant Explorer https://buff.ly/2A9URwS https://buff.ly/2A9URwS Shop Online - Global Marketplace https://buff.ly/2zCAag2 https://buff.ly/2zCAag2 Cheap Flights, Hotels, Tours & Travels - Book Online - Global Merchant Explorer https://buff.ly/2iLFD9Y https://buff.ly/2iLFD9Y Fashion Shopping - Global Merchant Explorer – Shop Online https://buff.ly/2hR49pu https://buff.ly/2hR49pu Buy Online - Global Merchant Explorer - Shopping Deals https://buff.ly/2iLmh4V https://buff.ly/2iLmh4V Black Friday! – Buy Online - Best Deals and Sales https://buff.ly/2hPiYJ6 https://buff.ly/2hPiYJ6 Best Deals and Sales for the Black Friday! – Buy Online https://buff.ly/2A45rYv https://buff.ly/2A45rYv Shopping Deals - Buy Online - Merchant Explorer https://buff.ly/2iMyyGr https://buff.ly/2iMyyGr Dresslily - Christmas Sale - Official Shop - 75%OFF, Global Free Shipping https://buff.ly/2hOBWiM https://buff.ly/2hOBWiM Lookupfare - Cheap Flights, Flight Deals, Christmas Travel Deals! - Book Online https://buff.ly/2j59IRi https://buff.ly/2j59IRi Grand Sale - Christmas Shopping Deals - Buy Online - Merchant Explorer https://buff.ly/2B72lAi https://buff.ly/2B72lAi Merchant Explorer - Shopping Deals - Buy Online https://buff.ly/2iurihY https://buff.ly/2iurihY Ho! Ho! Ho! Book on Christmas Eve – OneTravel – Great Deals on Global Flights! – Holiday Travel Deals https://buff.ly/2mnotUf https://buff.ly/2mnotUf Belle Lily – Christmas Sale – Clothing, Shoes & Accessories – Shop Online https://buff.ly/2mll48u https://buff.ly/2mll48u OneTravel - Great Deals on Global Flights! - Holiday Travel Deals - Save On Vacation Package https://buff.ly/2yXeydZ https://buff.ly/2yXeydZ Grand Offer – Hotels, Flights, Tours & Travels https://buff.ly/2yYa6fi https://buff.ly/2yYa6fi Kinokuniya Offers – Buy Online – http://bit.do/dRJq3 http://bit.do/dRJq3 https://buff.ly/2mmusZI https://buff.ly/2mmusZI Xmas Sales & Deals : Christmas Holiday Collection – Shop Online https://buff.ly/2Az6oFj https://buff.ly/2Az6oFj Grand Offer – Fashion, Health & Beauty, Electronics, Mobile Apps (CPI), Travels and Other https://buff.ly/2AA1Kqj https://buff.ly/2AA1Kqj
frut 9y ago
This is just depressing. Sure, sell us out to big corporations by not implementing proper features in protocols like HTTP/2 so we can get tracked for decades to come. Yet, represent freedom by yet another cool way to "fool" governments. When historians look back at what happened to the Internet, or even society, they are going to find that organizations like the IETF was to busy with romantic dreams of their own greatness to serve the public. It's like people leaned nothing from Snowden.
- xingped 9y ago
  What features are missing that should be implemented?
  - teddyh 9y ago
    Not the OP, but omitting support for SRV records in HTTP/2 was a terrible missed opportunity, as I’ve written about here before: https://news.ycombinator.com/item?id=8404788 https://news.ycombinator.com/item?id=8404788 https://news.ycombinator.com/item?id=8550133 https://news.ycombinator.com/item?id=8550133 I quote myself: “It really is no surprise that Google is not interested in this, since Google does not suffer from any of those problems which using SRV records for HTTP would solve. It’s only users which could more easily run their own web servers closer to the edges of the network which would benefit, not the large companies which has CDNs and BGP AS numbers to fix any shortcomings the hard way. Google has already done the hard work of solving this problem for themselves – of course they want to keep the problem for everybody else.”
    - stock_toaster 9y ago
      Yeah, I agree that this was a really unfortunate omission.
    - Shoothe 9y ago
      I would also like to see SRV record support in HTTP/2 but IIRC Mozilla did some telemetry tests and found out that a significant amount of DNS requests for SRV records failed for no reason (or probably for reasons mentioned in this submission). Unfortunately I can't find a source link for that claim right now.
peterwwillis 9y ago
> For example, if Google was to deploy its public DNS service over DOH on www.google.com and a user configures their browser to use it, a network that wants (or is required) to stop it would have to effectively block all of Google (thanks to how they host their services). Which will result in all of Google being blocked by schools, businesses, and entire nations. Which, as Google is relied upon more and more, means less access to things like mail, documents, news, messaging, video content, the Android platform, etc. Thanks.
- jlgaddis 9y ago
  Nah, many of them can't -- won't -- block Google over this. A huge number of them are absolutely reliant on Google, for things like (org-wide) Google Mail, Google Docs, ChromeBook deployments, and so on -- not to mention basic Google search.
  - norin 9y ago
    What about China or the EU? They can surely block Google?
    - inimino 9y ago
      China has, for many years. The EU is unlikely to.
gumby 9y ago
Let's just hope that future innovations (and, more perniciously, "innovations") reinforce the end-to-end principle. A major weakness of the 2017 Internet is its centralization. The DNS-over-http discussion in this post mention that in passing, though I wonder if this treatment might not be worse than the disease.
- ocdtrekkie 9y ago
  The DOH example, in particular, only conveys it's benefits if centralized to something governments are hesitant to block. This is an example of "innovation" specifically designed to centralize. There's maybe a handful of companies with enough influence that countries would hesitate to block in order to block DOH.
adictator 9y ago
Isn't ws:// also a new-ish protocol that is not supported yet by many browsers natively at least?
- enzanki_ars 9y ago
  https://caniuse.com/#feat=websockets https://caniuse.com/#feat=websockets Most nativity support it now.
- scott_karana 9y ago
  WebSockets leverages TCP and is based on/compatible with HTTP. Nothing new about it, at least in the sense the article is discussing.
signa11 9y ago
the author is responsible for the 418 teapot incident in the early 2000's. though i am sure he is a swell guy :)
- stmw 9y ago
  Indeed, he was great in web services standards back in the day, and still a good writer. ;-)
mikevm 9y ago
Regarding throughput, see UDT (http://udt.sourceforge.net/ http://udt.sourceforge.net/) which does reliable data transfer over UDP.
feelin_googley 9y ago
"DOH" is not going to work very well as an anti-censorship protection unless they also fix the SNI problem in TLS.
wojcikstefan 9y ago
This reads less like “Internet protocols are changing” and more like “Google is changing the Internet to their own benefit”.
- kaplun 9y ago
  Do these specific changes from Google impact negatively the community? Otherwise, IMHO good ideas, are good ideas regardless where they come from.
  - ori_b 9y ago
    Yes, generally they're some combination of overly complicated technically, difficult to use without layers and layers of heavy dependencies, are poorly thought out, or solve Google-specific use cases.
    - zAy0LfpBZLC8mAC 9y ago
      Well, the complexity is a problem, but I don't really see that as Google's fault. The only chance to evolve the network is by building on stuff that works despite all the hostile middle boxes, and that necessarily requires quite a bit of complexity, unfortunately. In the long term, it seems to me like QUIC is a better idea than everyone individually having to work around idiocies all over the internet, as that is not exactly a zero-complexity game either.
jedisct1 9y ago
I'm pretty excited about DNS over TLS. Ahaha no, that's so tacky, I meant DNS over QUIC of course. Sorry, I meant iQUIC. Ah no, it's not even there, but it will suck compared to DOH, DNS over HTTPS.
provost 9y ago
No mention of BGP in the article?
sarmad123 9y ago
good to see
collinmanderson 9y ago
> Finally, we are in the midst of a shift towards more use of encryption on the Internet, first spurred by Edward Snowden’s revelations in 2015. Personally, I'd say it was first spurred by Firesheep back in 2010, but the idea of encrypting all websites, even content-only websites may have been Snowden related.
g-clef 9y ago
I'm really struck by how hostile to enterprise security these proposals are. Yes, I know that the security folks will adapt (they'll have to), but it still feels like there's a lot of baby+bathwater throwing going on. DNS over HTTP is a prime example: blocking outbound DNS for all but a few resolvers, and monitoring the hell out of the traffic on those resolvers is a big win for enterprise networks. What the RFC calls hostile "spoofing" of DNS responses enterprise defenders call "sinkholing" of malicious domains. Rather than trying to add a layer of validation to DNS to provide the end user with assurance that the DNS request they got really is the name they asked for (and, in theory, allow the enterprise to add their own key to sign sinkhole answers) instead DOH just throws the whole thing out...basically telling enterprise defenders "fuck your security controls, we hate Comcast too much to allow anyone to rewrite DNS answers." "Fuck your security controls, we hate Comcast" is, I think, a bad philosophy for internet-wide protocols. (That's basically what the TLS 1.3 argument boils down to also...and that's a shame.)
- slrz 9y ago
  As implemented, all these "enterprise security" things are mostly indistinguishable from malicious attacks. Of course they break when you start tightening security. Forging DNS responses is a horrible idea (and already breaks with DNSSEC). I have a hard time to comprehend how this can be considered a reasonable security measure.
  - g-clef 9y ago
    > I have a hard time to comprehend how this can be considered a reasonable security measure. OK, let's walk it through. Task: block access to "attacker.com" and all it's subdomains. Reason: Maybe it's a malware command and control, maybe it's being used for DNS tunneling, whatever. Blocking a domain that's being used for malicious behavior is a reasonable thing for an enterprise to want to accomplish. Option 1: Block by IP at the firewall. Problems: Attackers can simply point the domain to another IP, so you're constantly playing whack-a-mole and constantly behind the attacker. Also, if it's a DNS tunnel the DNS answer is what's interesting, not the traffic to the actual IP. Result: Fail, doesn't solve the problem. Option 2: Block by DNS Name at the firewall. Problems: Requires the firewall to understand the protocols involved, which they have shown themselves to be inconsistent at, at the best of times. Also, doing regex on every DNS query packet(in order to find all subdomains) doesn't scale. Result: Fail, doesn't scale. Option 3: Block with local agent. Problems: Tablets, phones, appliances, printers can't run a local agent. Result: Fail. Not complete coverage Option 4: Block outbound DNS except for approved resolvers, give those resolvers an RPZ feed of malicious domains. Problem: Clients have to be configured to use those resolvers, but otherwise none. Result: Pass. It's standards compliant, and DNSSec isn't an issue since the resolver never asks for the attackers DNS answer, so they never get the chance to offer DNSSec. That's why option 4 (or some variant of it) is popular in enterprises. It accomplishes the task in a standards-compliant way, and covers the entire enterprise in a way that scales well. DOH blows this up. So, the question becomes: in a world with DOH, how is an enterprise supposed to completely and scalably block access to "attacker.com" and all its subdomains? So far, the answer has been "you don't." I think that is a really shitty answer to someone who's trying to accomplish something reasonable.
shawndrost 9y ago
ELI5: Does DOH threaten the great firewall?

458 points by nmjohn 9y ago

It seems that widely deploying TLS 1.3 and DOH can provide an effective technical end-around the dismantling of net neutrality. So we should be promoting and trying to deploy them as widely as possible. Of course, they can still block or throttle by IP, so the next step is to increase deployment of content-centric networking systems.

jstanley 9y ago
By content-centric networking systems do you mean IPFS et al?
- ilaksh 9y ago
  Yes, IPFS, but actually there a huge number of perhaps lesser-known projects that do all sorts of things with content-oriented-networking. It's been a pretty big research topic.
topspin 9y ago
It seems to me that all of the changes described in this story will contribute to thwarting intermediaries and their agendas. HTTP/2 and its "effective" encryption requirement are proof against things like Comcast's nasty JavaScript injection[1]. QUIC has mandatory encryption all the way down; even ACKs are encrypted, obviating some of the traditional throttling techniques. And as you say TLS 1.3 and DOH further protect traffic from analysis and manipulation by middlemen. Perhaps our best weapon against Internet rent seekers and spooks is technical innovation. It is astonishing to me that Google can invent QUIC, deploy it on their network+Chrome and boom! 7% of all Internet traffic is QUIC. Traditional HTTP over TCP and traditional DNS are becoming a ghetto protocol stack; analysis of such traffic is sold to who knows whom, the content is subject to manipulation by your ISP, throttling is trivial and likely to become commonplace with Ajit Pai et al. Time to pull the plug on these grifters and protect all the traffic. [1] https://news.ycombinator.com/item?id=15890551 https://news.ycombinator.com/item?id=15890551
- zb3 9y ago
  But I, as an user, want to be able to block domains, inject scripts and see what Chrome is sending to Google on my own devices (which is what Google doesn't want me to do). That's why I can't support these protocols...
  - JoshTriplett 9y ago
    You, as a user, absolutely can. An ISP or network administrator who does not control the endpoints, on the other hand, cannot, by design. That's a feature.
    - fiddlerwoaroof 9y ago
      What if I want to use my router to block telemetry domains? Or other malware sites? It’s looking like the only way forward is running my own CA to mitm all encrypted traffic.
      - JoshTriplett 9y ago
        > It’s looking like the only way forward is running my own CA to mitm all encrypted traffic. Correct. Middleboxes should be presumed hostile; if you control the endpoints you can install a MITM CA, but it's safer to put what you want directly on the endpoint.
      - aoeusnth1 9y ago
        That seems superior anyway - you could keep blocking domains even when you're on the go.
        kuschku 9y ago
        Can I? On Android, apps now can decide if they want to accept user-installed CAs, or not. So if an app is hostile (say, all the Google apps), then I have no way to intercept their traffic anymore.
lathiat 9y ago
Unfortunately not really; Net Neutrality mostly focuses around the semi-bigger services who in most cases will have at least one of a dedicated AS number; dedicated IP ranges or dedicated physical network links they can limit the capacity of. Which is traditionally how the game has been played. Think Netflix/Comcast.. no hiding what that traffic is.
ori_b 9y ago
> It seems that widely deploying TLS 1.3 and DOH can provide an effective technical end-around the dismantling of net neutrality. If you don't think about it, it may seem that way. But until everyone sends all their data over tor, or some other system that obscures which IP you're trying to get to, it's still easy to filter. There's (within epsilon of) zero motion I've seen towards obscuring IP addresses, for good reason.

jandrese 9y ago

> When a protocol can’t evolve because deployments ‘freeze’ its extensibility points, we say it has ossified. TCP itself is a severe example of ossification; so many middleboxes do so many things to TCP — whether it’s blocking packets with TCP options that aren’t recognized, or ‘optimizing’ congestion control. > It’s necessary to prevent ossification, to ensure that protocols can evolve to meet the needs of the Internet in the future; otherwise, it would be a ‘tragedy of the commons’ where the actions of some individual networks — although well-intended — would affect the health of the Internet overall. On the other hand, I've done a fair bit of work getting TCP based applications to behave properly over high latency high congestion (satellite or radio usually) links and QUIC makes me nervous. In the old days you could put a TCP proxy like SCPS in there and most apps would get an acceptable level of performance, but now I'm not so sure. It seems like everybody assumes you're on a big fat broadband pipe now and nobody else matters.

peterwwillis 9y ago
> It seems like everybody assumes you're on a big fat broadband pipe now and nobody else matters. This is intentional. The powers that be have an interest in moving everyone to faster networks, and they effectively control all new web standards, and so build their protocols to force the apps to require faster, bigger pipes. This way they are never to blame for the new requirements, yet they get the intended benefits of fatter pipes: the ability to shove more crap down your throat. It's possible to cache static binary assets using encrypted connections, but I am not aware of a single RFC that seriously suggests its adoption. It is also to the advantage of the powers that be (who have the financial means to do this) to simply move content distribution closer to the users. As the powers that be don't provide internet services over satellite or microwave, they do not consider them when defining the standards.
- jjrh 9y ago
  Not sure who "The powers that be" are, but anyone can propose and contribute to IETF standards. They are called "Request for Comment" for a reason.
  - 9y ago

shalabhc 9y ago

Another interesting protocol, perhaps underused, is SCTP. It fixes many issues with TCP, in particular it has reliable datagrams with multiplexing and avoiding head-of-line blocking. I believe QUIC is supposed to be faster at connection (re)estabishment. https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...

dragontamer 9y ago
SCTP is a superior protocol, but it isn't implemented in many routers or firewalls. As long as Comcast / Verizon routers don't support it, no one will use it. It may be built on top of IP, but TCP / UDP levels are important for NAT and such. Too few people use DMZ and other features of routers / firewalls. Its way easier to just put up with TCP / UDP issues to stay compatible with most home setups.
- pfranz 9y ago
  To your point, IPv6 has been around 20 years, the whole time we know we're running out of IPv4 addresses and adoption is still around 20%. However, the high turnover for mobile phones has allowed more aggressive changes to the networking stack. Perhaps this, in addition to IPv6, would make something like SCTP easier to adopt widely?
  - 24gttghh 9y ago
    "Still" seems a bit disingenuous when considering the current trajectory IPv6 adoption is on. [0] Yah it's happening slowly, but it does seem to be pushing ahead. [0] https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html
    - pfranz 9y ago
      How is that disingenuous? I don't think it matters what the curve looks like when it spans 10 years and ends up at 20%. There were implementations released 10 years previous to the graph's start. I wasn't implying it would never happen, just that even for something that's inevitable like IPv6, adoption is glacial.

deleted 9y ago

[deleted]

jjjaslin7 9y ago

Best Buy Online – Flights, Hotel, Tours & Travels, Fashion, Health & Beauty and Electronics https://buff.ly/2na35ma https://buff.ly/2na35ma Amazing sale online shopping - Click Links Best places to buy Apple products on Black Friday https://buff.ly/2hSjypp https://buff.ly/2hSjypp Shop Online - Global Marketplace Merchant Explorer https://buff.ly/2A9URwS https://buff.ly/2A9URwS Shop Online - Global Marketplace https://buff.ly/2zCAag2 https://buff.ly/2zCAag2 Cheap Flights, Hotels, Tours & Travels - Book Online - Global Merchant Explorer https://buff.ly/2iLFD9Y https://buff.ly/2iLFD9Y Fashion Shopping - Global Merchant Explorer – Shop Online https://buff.ly/2hR49pu https://buff.ly/2hR49pu Buy Online - Global Merchant Explorer - Shopping Deals https://buff.ly/2iLmh4V https://buff.ly/2iLmh4V Black Friday! – Buy Online - Best Deals and Sales https://buff.ly/2hPiYJ6 https://buff.ly/2hPiYJ6 Best Deals and Sales for the Black Friday! – Buy Online https://buff.ly/2A45rYv https://buff.ly/2A45rYv Shopping Deals - Buy Online - Merchant Explorer https://buff.ly/2iMyyGr https://buff.ly/2iMyyGr Dresslily - Christmas Sale - Official Shop - 75%OFF, Global Free Shipping https://buff.ly/2hOBWiM https://buff.ly/2hOBWiM Lookupfare - Cheap Flights, Flight Deals, Christmas Travel Deals! - Book Online https://buff.ly/2j59IRi https://buff.ly/2j59IRi Grand Sale - Christmas Shopping Deals - Buy Online - Merchant Explorer https://buff.ly/2B72lAi https://buff.ly/2B72lAi Merchant Explorer - Shopping Deals - Buy Online https://buff.ly/2iurihY https://buff.ly/2iurihY Ho! Ho! Ho! Book on Christmas Eve – OneTravel – Great Deals on Global Flights! – Holiday Travel Deals https://buff.ly/2mnotUf https://buff.ly/2mnotUf Belle Lily – Christmas Sale – Clothing, Shoes & Accessories – Shop Online https://buff.ly/2mll48u https://buff.ly/2mll48u OneTravel - Great Deals on Global Flights! - Holiday Travel Deals - Save On Vacation Package https://buff.ly/2yXeydZ https://buff.ly/2yXeydZ Grand Offer – Hotels, Flights, Tours & Travels https://buff.ly/2yYa6fi https://buff.ly/2yYa6fi Kinokuniya Offers – Buy Online – http://bit.do/dRJq3 http://bit.do/dRJq3 https://buff.ly/2mmusZI https://buff.ly/2mmusZI Xmas Sales & Deals : Christmas Holiday Collection – Shop Online https://buff.ly/2Az6oFj https://buff.ly/2Az6oFj Grand Offer – Fashion, Health & Beauty, Electronics, Mobile Apps (CPI), Travels and Other https://buff.ly/2AA1Kqj https://buff.ly/2AA1Kqj

frut 9y ago

This is just depressing. Sure, sell us out to big corporations by not implementing proper features in protocols like HTTP/2 so we can get tracked for decades to come. Yet, represent freedom by yet another cool way to "fool" governments. When historians look back at what happened to the Internet, or even society, they are going to find that organizations like the IETF was to busy with romantic dreams of their own greatness to serve the public. It's like people leaned nothing from Snowden.

xingped 9y ago
What features are missing that should be implemented?
- teddyh 9y ago
  Not the OP, but omitting support for SRV records in HTTP/2 was a terrible missed opportunity, as I’ve written about here before: https://news.ycombinator.com/item?id=8404788 https://news.ycombinator.com/item?id=8404788 https://news.ycombinator.com/item?id=8550133 https://news.ycombinator.com/item?id=8550133 I quote myself: “It really is no surprise that Google is not interested in this, since Google does not suffer from any of those problems which using SRV records for HTTP would solve. It’s only users which could more easily run their own web servers closer to the edges of the network which would benefit, not the large companies which has CDNs and BGP AS numbers to fix any shortcomings the hard way. Google has already done the hard work of solving this problem for themselves – of course they want to keep the problem for everybody else.”
  - stock_toaster 9y ago
    Yeah, I agree that this was a really unfortunate omission.
  - Shoothe 9y ago
    I would also like to see SRV record support in HTTP/2 but IIRC Mozilla did some telemetry tests and found out that a significant amount of DNS requests for SRV records failed for no reason (or probably for reasons mentioned in this submission). Unfortunately I can't find a source link for that claim right now.

peterwwillis 9y ago

> For example, if Google was to deploy its public DNS service over DOH on www.google.com and a user configures their browser to use it, a network that wants (or is required) to stop it would have to effectively block all of Google (thanks to how they host their services). Which will result in all of Google being blocked by schools, businesses, and entire nations. Which, as Google is relied upon more and more, means less access to things like mail, documents, news, messaging, video content, the Android platform, etc. Thanks.

jlgaddis 9y ago
Nah, many of them can't -- won't -- block Google over this. A huge number of them are absolutely reliant on Google, for things like (org-wide) Google Mail, Google Docs, ChromeBook deployments, and so on -- not to mention basic Google search.
- norin 9y ago
  What about China or the EU? They can surely block Google?
  - inimino 9y ago
    China has, for many years. The EU is unlikely to.

gumby 9y ago

Let's just hope that future innovations (and, more perniciously, "innovations") reinforce the end-to-end principle. A major weakness of the 2017 Internet is its centralization. The DNS-over-http discussion in this post mention that in passing, though I wonder if this treatment might not be worse than the disease.

ocdtrekkie 9y ago
The DOH example, in particular, only conveys it's benefits if centralized to something governments are hesitant to block. This is an example of "innovation" specifically designed to centralize. There's maybe a handful of companies with enough influence that countries would hesitate to block in order to block DOH.

adictator 9y ago

Isn't ws:// also a new-ish protocol that is not supported yet by many browsers natively at least?

enzanki_ars 9y ago
https://caniuse.com/#feat=websockets https://caniuse.com/#feat=websockets Most nativity support it now.
scott_karana 9y ago
WebSockets leverages TCP and is based on/compatible with HTTP. Nothing new about it, at least in the sense the article is discussing.

signa11 9y ago

the author is responsible for the 418 teapot incident in the early 2000's. though i am sure he is a swell guy :)

stmw 9y ago
Indeed, he was great in web services standards back in the day, and still a good writer. ;-)

mikevm 9y ago

Regarding throughput, see UDT (http://udt.sourceforge.net/ http://udt.sourceforge.net/) which does reliable data transfer over UDP.

feelin_googley 9y ago

"DOH" is not going to work very well as an anti-censorship protection unless they also fix the SNI problem in TLS.

wojcikstefan 9y ago

This reads less like “Internet protocols are changing” and more like “Google is changing the Internet to their own benefit”.

kaplun 9y ago
Do these specific changes from Google impact negatively the community? Otherwise, IMHO good ideas, are good ideas regardless where they come from.
- ori_b 9y ago
  Yes, generally they're some combination of overly complicated technically, difficult to use without layers and layers of heavy dependencies, are poorly thought out, or solve Google-specific use cases.
  - zAy0LfpBZLC8mAC 9y ago
    Well, the complexity is a problem, but I don't really see that as Google's fault. The only chance to evolve the network is by building on stuff that works despite all the hostile middle boxes, and that necessarily requires quite a bit of complexity, unfortunately. In the long term, it seems to me like QUIC is a better idea than everyone individually having to work around idiocies all over the internet, as that is not exactly a zero-complexity game either.

jedisct1 9y ago

I'm pretty excited about DNS over TLS. Ahaha no, that's so tacky, I meant DNS over QUIC of course. Sorry, I meant iQUIC. Ah no, it's not even there, but it will suck compared to DOH, DNS over HTTPS.

provost 9y ago

No mention of BGP in the article?

sarmad123 9y ago

good to see

collinmanderson 9y ago

> Finally, we are in the midst of a shift towards more use of encryption on the Internet, first spurred by Edward Snowden’s revelations in 2015. Personally, I'd say it was first spurred by Firesheep back in 2010, but the idea of encrypting all websites, even content-only websites may have been Snowden related.

g-clef 9y ago

I'm really struck by how hostile to enterprise security these proposals are. Yes, I know that the security folks will adapt (they'll have to), but it still feels like there's a lot of baby+bathwater throwing going on. DNS over HTTP is a prime example: blocking outbound DNS for all but a few resolvers, and monitoring the hell out of the traffic on those resolvers is a big win for enterprise networks. What the RFC calls hostile "spoofing" of DNS responses enterprise defenders call "sinkholing" of malicious domains. Rather than trying to add a layer of validation to DNS to provide the end user with assurance that the DNS request they got really is the name they asked for (and, in theory, allow the enterprise to add their own key to sign sinkhole answers) instead DOH just throws the whole thing out...basically telling enterprise defenders "fuck your security controls, we hate Comcast too much to allow anyone to rewrite DNS answers." "Fuck your security controls, we hate Comcast" is, I think, a bad philosophy for internet-wide protocols. (That's basically what the TLS 1.3 argument boils down to also...and that's a shame.)

slrz 9y ago
As implemented, all these "enterprise security" things are mostly indistinguishable from malicious attacks. Of course they break when you start tightening security. Forging DNS responses is a horrible idea (and already breaks with DNSSEC). I have a hard time to comprehend how this can be considered a reasonable security measure.
- g-clef 9y ago
  > I have a hard time to comprehend how this can be considered a reasonable security measure. OK, let's walk it through. Task: block access to "attacker.com" and all it's subdomains. Reason: Maybe it's a malware command and control, maybe it's being used for DNS tunneling, whatever. Blocking a domain that's being used for malicious behavior is a reasonable thing for an enterprise to want to accomplish. Option 1: Block by IP at the firewall. Problems: Attackers can simply point the domain to another IP, so you're constantly playing whack-a-mole and constantly behind the attacker. Also, if it's a DNS tunnel the DNS answer is what's interesting, not the traffic to the actual IP. Result: Fail, doesn't solve the problem. Option 2: Block by DNS Name at the firewall. Problems: Requires the firewall to understand the protocols involved, which they have shown themselves to be inconsistent at, at the best of times. Also, doing regex on every DNS query packet(in order to find all subdomains) doesn't scale. Result: Fail, doesn't scale. Option 3: Block with local agent. Problems: Tablets, phones, appliances, printers can't run a local agent. Result: Fail. Not complete coverage Option 4: Block outbound DNS except for approved resolvers, give those resolvers an RPZ feed of malicious domains. Problem: Clients have to be configured to use those resolvers, but otherwise none. Result: Pass. It's standards compliant, and DNSSec isn't an issue since the resolver never asks for the attackers DNS answer, so they never get the chance to offer DNSSec. That's why option 4 (or some variant of it) is popular in enterprises. It accomplishes the task in a standards-compliant way, and covers the entire enterprise in a way that scales well. DOH blows this up. So, the question becomes: in a world with DOH, how is an enterprise supposed to completely and scalably block access to "attacker.com" and all its subdomains? So far, the answer has been "you don't." I think that is a really shitty answer to someone who's trying to accomplish something reasonable.

shawndrost 9y ago

ELI5: Does DOH threaten the great firewall?