RFC8890: The Internet Is for End Users
mnot.net
mnot.net
For example: The task force MUST prioritize... the user MAY expect...
I neither like DoH nor in general arguments of the form "X is not political, we only decide on merits".
However, in this case, I really wonder if the IETF's contribution is political: DoH on it's own is highly so, but to my understanding, the politics are in the decision to design an encrypted, centralized and block-proof alternative to DNS with preselected servers and automatically deploy it to millions of users. But those points belong the initial requirements and the deployment process - not so much the technical details of implementation.
That DoH is a standard makes some difference, but not very much. I think we'd have roughly the same problems (though maybe with less publicity and discussion) if this was some properietary Chrome thing that was fully developed inside Google.
Or to put it differently, assuming it was already decided that something like DoH should be built, is there still political power in the follow-up discussions about how it should be built?
DoH doesn't prevent filtering. Sure, it doesn't respect OS or Network-enforced settings, but that's kind of the whole point of its existence.
> ...DNS for centralised network management.
DoT (and DNSCrypt?) would arguably be the better alternatives in these cases.
So, use-cases are absolutely being addressed in DNS' case at the very least.
> I really wonder if the IETF's contribution is political: DoH on it's own is highly so...
I think DoH and ESNI are exactly the kind of response expected from a tech firm like Mozilla: Fight for its users and invest in the right technology that helps keep the Internet global despite the many efforts to dismantle it, not just by governments but by big tech in equal measure. In fact it is big tech that sells "cyber security" solutions to these governments in the first place: A trillion dollar market opportunity [0].
Look no further than ITU to see how anti-user, pro-corporate, pro-government politically-influenced technology standards can be [1]. Things might take a steep dive given Google's [2] and Facebook's [3] recent inroads in the Communications industry. This pro-user political engagement from Mozilla et al is more than welcome, in my opinion.
[0] https://foundationcapital.com/cybersecurity-the-next-trillio...
[1] https://news.ycombinator.com/item?id=23416269
The reason the internet exists at all is that it provided a way around / relief from this level of control and that it allowed independent innovation to happen. In a way this was a happy accident because a lot of the funding for the R&D behind this came out of cold war era defense projects which were very much not about the free flow of information. So, it would be a stretch that this is working as intended. But it was successful exactly because of that and the IETF brought together the right parties to ensure it kept enabling this.
More strict networks ultimately failed to compete because users and companies found that they needed to tap into this free flow of information. The fact that countries like China, Russia, North Korea, etc. are on the internet at all (grudgingly and with all the restrictions that they try to enforce) is because they need to be. They are also part of the world economy for the same reason. And as much as they'd like to tell others what the value of their own currencies should be relative to $, renminbi, euro, etc.; they have no choice but to leave that to market forces. Of course it doesn't stop them from trying to influence and manipulate that. Nor does it stop anyone else from doing so. But ultimately it leads to either hyper inflation or people just swallowing their pride and accepting or paying in dollars for stuff they buy (e.g. oil) or sell on the international market. The internet is the same; it's a take it or leave it kind of thing. Either you are on it or you are not.
It is a bit of neutral ground where mutually hostile entities looking to control, monitor, and manipulate each other can conduct their business (some of it very bad business). It works precisely because things like https prevent man in the middle attacks, certificates keep us honest (to some extent). All the other technical tooling the IETF standardized to ensure third parties don't mess with private interactions between two parties trying to have some meaningful interaction is there for just that reason. Of course the tools are far from perfect and there's an arms race between intelligence agencies to exploit loop holes, bugs, design flaws, etc. The IETF's role is to address these issues, not to create more of them to enable authoritarian regimes to gain an edge over other nations or their own citizens.
So, DNS over HTTPS is a good thing and exactly the right thing for the IETF to be standardizing because it fixes a problem with what they previously standardized (i.e. DNS). It's controversial because it takes away power from countries actively abusing that power. But the fact that others are exploiting protocol weaknesses in DNS is fundamentally a bug and not a feature. You could argue DNS over HTTPS is not a perfect solution or that better solutions exist but not that the role of the IETF is to enable the Chinese to have a say in what people (in or outside China) lookup via DNS. That's not their role. If the Chinese, the Australians, etc. want to block people that choose to configure their browsers to use this (or browsers that do this by default), that is of course their good right. But enabling that kind of self isolation is not a core IETF function.
I'd say it's controversial because it breaks a wide arrange of setups and features that rely on DNS, giving power from local administrators over to Google, Cloudflare et al.
If the only thing it did was prevent governments from spying, there'd be a lot less fuss about it.
DoH is a great tool for end users to be able to disregard their pipes and preserve their own individual privacy. An ISP network admin is not the administrator of the private customer machines that are connected downstream.
In an enterprise/commercial setting, there are valid reasons for filtering employees' use of DNS (legal compliance, e.g.).
I can no longer install e.g. PiHole to filter out ad servers globally for all devices on my network.
These are some of the issues caused by DoH, I'm sure there are others.
This is because OSs are ossified. They need to move along or get left behind, they decided to be left behind.
I'd also remind you that DNS wasn't very configurable even before, plenty of devices I've seen that ignore DHCP DNS, NTP and domain. Even if they should respect them. DoH is no exception to the general type of behaviour that already exists.
This type of position has the veneer of forward thinking, but it is precisely backward. The core value of an OS or a network protocol is consistency. Do not break things that work. Do not change what doesn't need changing.
Exactly. Things don't work, the only way to fix it is to change it. It has a few negative consequences but they're already here and standing still won't make it better. If OSs start having the features needed, the control will return. But as long as some people are dragging their feet, throwing tantrums, ignoring the large majority for which it's a positive change, it's going to be a tiresome long process.
Wait, your solution to buggy devices is to treat the bug as acceptable and deploy it more widely?!
DoH just prevents you from hijacking someone else's dns.
DNS over HTTPS is controversial because the current implementations take power from the end users (by moving the resolver out of libc who’s configuration and often implementation is controlled by end users and into certain applications where the user is lucky if the app allows them to adjust the parameters, especially if the interface is stable and intuitive. They really have to because cramming http and tls into libc is a bit crazy.) Furthermore it concentrates power and data into the hands of a couple of organizations where previously using their resolvers was optional. At this point I’m not entirely sure I trust Google any more than most foreign governments or even my own.
You seem to not trust Google. Nobody is saying you should or must. Other DNS servers are available. Set up your own one if you must. You have that power. If you are smart enough to actually know how to set up DNS now, you should be able to figure out how to configure that to use https. It's not rocket science.
If not, maybe it's a good thing that your browser stops blasting your DNS queries unencrypted over a public network to absolutely anybody that can be bothered to listen in. This would include all the 3 letter acronym security agencies that you can name (domestic and foreign ones), big ad driven companies, your local police, and everybody else with or without the cooperation from your friendly neighborhood operators or arm twisting of the incompetent politicians representing which ever government is governing wherever you live. The best you can hope for to protect you from that is a combination of incompetence and indifference.
This power is illusory. If Google decides Chrome will no longer allow changing DNS providers, game over for 60% of internet users. Consider how it's no longer possible to block ads the way you want to in Chrome with manifest 3.
Even without DoH, Google could just as easily have decided to hardwire DNS for Chrome to 8.8.8.8 or to switch Chrome to their own home-grown proprietary name resolution protocol. They don't need a public standard for that.
And if they do that for Android, or Microsoft does the same for Windows, game over for 90% of internet users. Banning DoH doesn't fix that.
It is already not possible to avoid DoH to Google servers with chromecast
Yes, which means that effectively they don't have the power.
Not sure about that:
https://en.wikipedia.org/wiki/ARPANET#Debate_on_design_goals
Baran's seminal work on packet-switching was a RAND C2 study whose concepts were rejected by the extant defence contractors as impractical. When DARPA later wanted to interconnect it's collection of computers to create ARPANET for researchers, Baran's theoretical ideas were dusted off and the rest is history.
https://www.rand.org/about/history/baran.html
Nukes were definitely part of the Zeitgeist:
In 1962, a nuclear confrontation seemed imminent. The United States and the Union of Soviet Socialist Republics (USSR) were embroiled in the Cuban missile crisis. Both were in the process of building hair-trigger nuclear ballistic missile systems. Each country pondered post-nuclear attack scenarios.
U.S. authorities considered ways to communicate in the aftermath of a nuclear attack. How could any sort of “command and control network” survive? Paul Baran, a researcher at RAND, offered a solution: design a more robust communications network using “redundancy” and “digital” technology.
If you'd like to standardise a way to require DNS-over-HTTPS in supporting software, and convince operating system distributors to generally ship it, I'm fairly sure Firefox would be up for using that rather than its current mechanism, similar to how it uses system proxy settings. As it is there is no such standard.
There already is a standard way for me to tell all the programs which run on my system which DNS servers to use: /etc/resolv.conf. Any program which does not respect the values I set there is disobeying me.
Sure there is:
nameserver 127.0.0.1
where I choose to run a nameserver which uses DNS-over-HTTPS on 127.0.0.1:53.RFC8890 explicitly refers to "the interests of that child's parents or guardians" when the child is using a web browser, although individual system configuration is not within the remit of the IETF.
RFC 8484 makes no reference to how DNS-over-HTTPS should be configured, and in the face of widespread DNS hijacking, enforcing DNS-over-HTTPS in browsers may have been the correct solution - but that doesn't mean we can't do better by defining a standard (perhaps under the remit of the Free Desktop XDG group), encouraging operating system vendors to ship secure DNS configured by default, and then convincing Firefox et al to use that standard.
Yes, but is there a facility to force the browser to use your server or will Google re-write Chomium to "bypass" "rogue" DoH servers which filter content Google doesn't wish them to filter?
I try to stay away from politics as much as possible, except on this matter. I like this.
This Web site requires a more modern browser to operate securely; please upgrade your browser.
The truth is it just requires SNI server_name in the ClientHello. I don't send SNI except on sites that require it. Not every site is on a shared IP; some still use dedicated IPs. So I am the end user reading HTTP headers.I always thought this addtional "message" from mnot.net was somewhat presumptive for an IETF person who claims to be some sort of user advocate. This is the kind of thing I usually see from web developers telling you to "upgrade" your browser or turn on Javascript for the best "user experience", not IETF folks. Maybe it's a default on some server software, not custom.
His site does TLS1.3 but it doesn't do ESNI/ECH so I guess some browsers (or other clients) can be a little "too modern".
except it's a lie. SNI isn't "more secure", it leaks information to a possible MITM.
BTW - if this site did not use SNI, and only served one website at https://www.mnot.net, then connecting to www.mnot.net's IP address at port 443 would be plenty good evidence that you're accessing https://www.mnot.net. The SNI privacy leak only really comes into play when you're accessing something behind a CDN or a shared hosting provider, which put enough sites behind each IP that simply accessing that IP isn't a privacy leak in itself.
Not using SNI isn't a more secure option. By definition you can't be doing standards compliant TLS 1.3 - which would be the most secure option - since sending SNI for host names is mandatory in TLS 1.3.
Also, in assuming that multiple hosts can instead be distinguished down in/ up in the HTTP layer you actually do make some things less secure. The TLS session binding doesn't apply to the application layer, so when you write Host: www.example.com in HTTP that does not bind your TLS session to the name www.example.com, whereas if you send SNI for www.example.com then the remote server needs to actively decide by policy if it's safe not to bind that. Are you actually going to get exploited this way? Probably not, but neither are bad guys anxious to find out somehow which of the services on Mark's server you wanted.
[nix-shell:~]$ nslookup redbot.org
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: redbot.org
Address: 45.79.113.165
Name: redbot.org
Address: 2600:3c01::f03c:92ff:fe89:3e33
[nix-shell:~]$ nslookup www.mnot.net
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
www.mnot.net canonical name = cloud.mnot.net.
Name: cloud.mnot.net
Address: 45.79.113.165
Name: cloud.mnot.net
Address: 2600:3c01::f03c:92ff:fe89:3e33ESNI-enabled lighttpd, nginx or apache: https://185.24.233.103
ESNI-enabled CDN: https://www.cloudflare.com/ssl/encrypted-sni/
This would in theory ensure that any attacker could only assume the client is accessing at least one service on the target machine.
Setting aside the obvious risk that one of the services could claim to be one of the others, this obviously comes with some other technical limitations.
Again, it's not like the site is doing anything wrong, it just shouldn't be blaming the user for something that's obviously just a technical limitation of the technology being used.
Not much additional risk there when both site's TLS connections are already handled by the same process.
RFC 8446, page 7:
"All handshake messages after the ServerHello are now encrypted. The newly introduced EncryptedExtensions message allows various extensions previously sent in the clear in the ServerHello to also enjoy confidentiality protection."
The truth is that Server Name Indication (SNI), the ability to operate multiple hostnames with SSL/TLS on a single host, is one of the few backwards incompatible features of the modern web.
The efficiency and flexibility of container and virtual machine server instances offered by Infrastructure-as-a-Service providers like Amazon AWS make the support of non-SNI clients a difficult proposition.
In all honesty, maybe that would be the better alternative, if the only other option is US tech companies deciding unilaterally for the whole internet.
In our fiat monetary system, all new money which enters the economy comes from banks as credit; companies then compete against each other to earn the biggest possible share of that newly printed credit. This means that new money doesn't originate from consumers (so-called end users), all new money originates from institutions... So why would companies care about end users (consumers) when all the new money they get actually comes from financial institutions??? Why not get money straight from the source; cater to the paymasters and use consumers as pawns?
These days, it makes more financial sense to manipulate consumers to please financial institutions than to manipulate financial institutions to please consumers... The dynamics are out of whack. That's why we need UBI urgently - Make consumers the source of all new currency, this would force big companies to forget about cheap institutional money and focus on consumers. Let consumers be the paymasters of the economy.
This game of allowing banks to decide who gets access to cheap credit and who doesn't is inevitably going to lead to the kind of corruption we've seen over the past decade.
> The Internet isn't value-neutral, and neither is the IETF. We want the Internet to be useful for communities that share our commitment to openness and fairness. We embrace technical concepts such as decentralized control, edge-user empowerment and sharing of resources.
> If the IETF were to only decide upon technical merit, how would it balance these interests?
> Over the years, these questions have become increasingly urgent, because it isn’t viable to make decisions that have political outcomes but explain them using only technical arguments.
The article explains that that is necessary but not sufficient. It goes on to argue this with examples and explicit justifications. It even has an entire section dedicated to explaining why having it your way would not work.
I'm not sure where your comment is coming from though. Who are you to decide how they will do their work? It seems they have decided for themselves and it's in conflict with what you want. Then we don't know why you want this because you haven't provided any reason, reference to authority or any other clues.
From my perspective, the IETF and their standards don't exist in a vacuum and their actions have consequences, sometimes of an ethical nature. They seem to agree. It seems prudent that they come to a consensus on what their ethics are, document them and try to abide by them. It's just a case of having a consistent and open policy on a matter which can't be avoided. That is, they will do right or wrong whether they document their intention or not since their actions sometimes have such ethical consequences. Why stick one's head in the sand?
QUIC is a vastly superior transport to TCP in every technical regard. What exactly makes it a "purely corporate needs fulfilling step backwards for human people", if you don't mind adding some context to this extremely vague statement/opinion?
It is, despite the partial liberation from Google itself by the ietf, still a google attempt to control what HTTP and the web are. Google should not. Protocols should be generic. Layers should layers not just squashed all into one so youtube videos pull up faster on your mobile phone. There's more to the web, and the internet, than fixing mobile latency issues.
Building TLS into the protocol rather than having a plaintext protocol wrapped in a generic TLS stream isn't that weird -- it's how MySQL does it.
> QUIC is what happens when corporations define standards so their own services can be run cheaper
1) Google is not the only one who would be able to run their services cheaper. That is as plain a fact as it could be. Do you think Google is the only company who needs to serve massive amounts of content? In what way is energy and computation efficiency "harming" the internet?
> The transport layer shouldn't be "aware" of what it is transporting
2) In what way is QUIC "aware" of what it's transporting?
> It shouldn't be a gigantic heap of things
3) QUIC is not a "gigantic heap of things" any more than TLS or SCTP is. It is an L7 protocol hosted on UDP, just like TLS is an L7 protocol hosted on TCP.
> It is already impossible for anyone but Google (or another mega-corp) itself to make a browser that works with "modern" sites. This piles on to that
4) This has nothing to do with browsers, and QUIC has nothing that relates exclusively to browsers. Also, the idea that competing in the browser space is will be harder because you need to implement a new transport is laughable. Browser complexity derives from HTML/CSS/WebApps/etc, and QUIC is not only insignificant by comparison, but also a much less volatile feature that wont need to be "evolving" all of the time.
> Protocols should be generic
5) QUIC is absolutely, 100% generic? I'm not sure where you're getting the idea that it isn't from...
> Layers should be layers
6) Except when the layers are horribly misplaced of course; then you get into the situation we're in with TCP where we have hard-coded definitions for how control flow will work during a given session, what the session is, how you always need a new handshake to start a new one even if on the same host, and then you need to work around all this bullshit by starting a crapton of TCP connections to multiplex streams like HTTP/1.1 does...
7) In what way is QUIC not a layer?
8) That is a horrible argument. Nothing is keeping the IETF from standardizing QUIC at the same level as UDP/TCP/SCTP, you just have to look at IPv6 and SCTP's adoption to understand what happens when you try to change a protocol that deep in the stack.
> There's more to the web, and the internet, than fixing mobile latency issues
9) Sure... If you ignore that unlike when TCP was standardized, mobile devices represent 50% of all publicly routed internet traffic, and that all of these devices are dropping packets, triggering retransmissions, and congesting the network for everyone (including non-mobile devices), then there is no probelm at all!
That is also known as the tactic 5 year olds use when faced with a problem: closing their eyes and pretending it doesn't exist.
10) I'm not sure where you got the impression that QUIC only brings benefits to mobile latency, but that is also patently false