Hacker News Reader

Comment by e1ven | Hacker News Reader

I'm curious why this is tied to DNS-over-HTTPS.

It looks like Cloudflare is including a public key in the DNS lookup, which is used to encrypt the SNI information.

Couldn't this key be stored in a TXT record for normal DNS lookups as well?

If the public key was stored in a TXT record and accessed via regular DNS, then someone snooping the connection could see that you made a DNS lookup for that domain, and could make the reasonable assumption that you were about to make a request to said domain.

Not if you use DNS-over-HTTPS, as is required to turn this on in Firefox

right, DNS-over-HTTPS solves this particular problem.

Could also use DoT - DNS over TLS.

Otherwise, this sounds suspiciously a lot like DANE, which cert authorities hate, since there would be no use for them.

https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

Except for DNS standards aficionados, pretty much everyone hates DANE, including people who hate CAs. Here's a level-headed take:

https://www.imperialviolet.org/2015/01/17/notdane.html

One thing to pay attention to in Langley's post about DANE is that he says they can't do this reliably without a way to do DNS that doesn't break when you do anything more interesting than A lookups.

This thread is about eSNI. Guess what, eSNI can't be done reliably without a way to do DNS that doesn't break when you do anything more interesting than A lookups.

Fortunately, Firefox has a solution for that, DoH.

Wait, which of those two identical problems does it solve? Oh right, both of them.

DoH drastically reduces the impetus for the deployment of DNSSEC; it is essentially the 2018 answer to DNSCurve/DNSCrypt. Google and the Chrome team have been pretty clear about what they think about DANE's prospects moving forward.

And, of course, you're misrepresenting Langley's blog post when you suggest that the only reason DANE isn't in Chrome is because of lookup reliability. Readers can just read the piece for themselves (it's good, and interesting!) and come to their own conclusions.

And definitely read the post by Thomas Ptacek linked to from that article: https://sockpuppet.org/blog/2015/01/15/against-dnssec/. He makes the excellent point that DNSSEC (and thus DANE) doesn't get rid of CAs at all - it just makes whoever controls the domain into a defacto CA. Yeah, Comodo behaved badly as a CA - so, the browsers are in the process of no longer trusting it; imagine if DANE were in widespread use and Verisign behaved badly - the browsers really couldn't do anything about it at all unless they wanted to stop supporting .com - which is impossible.

"Let's get rid of CAs!" Sounds great. "Let's replace the CAs with a less accountable set of companies and governments that are harder to punish for bad behavior" doesn't sound so great. But thats what DANE is.

Thomas Ptacek (the guy whose blog post you've linked) agrees with Thomas Ptacek (tptacek, the guy whose sub-thread you're replying to)? Not exactly a revelation.

Also Thomas has rejected the suggestion that the parts of his post that are now hopelessly wrong should be mentioned in the FAQ he prominently links. So, that post is wrong and explicitly won't be fixed, you should not rely on the "facts" in it unless you want to get laughed at.

Your mention of Comodo suggests you're badly confused. The Symantec hierarchy is in the process of being distrusted by the Mozilla and Google root programmes, not Comodo.

As to .com, it already _is_ run very badly and we already do have to put up with that because there is no way to fix it. Don't put new things in .com unless you're comfortable with for-profit companies screwing you over whenever it suits them. DNSSEC can't make that worse, it's already terrible.

That's worth emphasising - DNSSEC cannot make you more dependent on your registry operators, because you are already entirely dependent on those registry operators anyway. If the operator could be leaned on by spooks (seems plausible) that is already true today.

> Thomas Ptacek (the guy whose blog post you've linked) agrees with Thomas Ptacek (tptacek, the guy whose sub-thread you're replying to)? Not exactly a revelation.

Lol, I didn't read the username.

> So, that post is wrong and explicitly won't be fixed, you should not rely on the "facts" in it unless you want to get laughed at.

I haven't analyzed everything in that blog post. However, the case it makes against DANE I think is convincing. I linked to that blog post since it was the one that made me realized that DANE was a bad idea when I was briefly a DANE enthusiast a few years ago.

> Your mention of Comodo suggests you're badly confused.

I accidentally slipped and used the wrong CA - I think "badly confused" is a bit strong for a slip of the tounge.

> Don't put new things in .com unless you're comfortable with for-profit companies screwing you over whenever it suits them.

It sound like you are also arguing that DANE is a bad idea.

> DNSSEC can't make that worse, it's already terrible.

I don't think I said anything to the contrary.

I'm real confused by the aggressive tone - it seems like you agree with everything of substance I wrote and the things you don't agree with are things that I didn't actually say.

You keep alluding to parts of that post that are outdated, but you never provide specifics.

I appreciate and will remember the concession that security for .COM is hopeless.

Actually I keep providing specifics which you ignore, for example the blog post declares that DNSSEC is "unsafe" because it can cause hostnames to be revealed and you give the example of Bank of America, owners of the bankofamerica.com domain for which you say such a policy "does not work so well".

But today actually FQDNs like 14021-nonprod.bankofamerica.com or whkgm04ye.hktskcy.apac.bankofamerica.com are not just accessible if you brute force DNS, they're automatically published, because Bank of America heavily relies, in fact, on the Web PKI and its issuers log the certificates.

It seems very strange to focus on the security for .COM when my point is that that entire TLD is badly run, it's like you're focused on how good the lock is on the front door (somebody call Deviant Ollam) at Lehman Brothers when the actual problem was they've invested all this money in worthless mortgage securities.

That's simply false. Bank of America's public servers with TLS certificates are logged (which, by the way, is also an operational security problem for them), but their other services are not.

You've picked an odd point to quibble with, since there's not only NSEC and NSEC3 but now, after the last RWC, a proposed NSEC5 to address this supposed non-problem.

> "Let's get rid of CAs!" Sounds great. "Let's replace the CAs with a less accountable set of companies and governments that are harder to punish for bad behavior" doesn't sound so great. But thats what DANE is.

The common counter-point is that, because nearly every CA does domain validation, the owners of the DNS keys are already capable of getting arbitrary certs. Therefore, DANE does not give DNS key owners more power; all it does is take out the CA's as a potential failure point. And really, as long as a cert attests that "You are talking to the owner of this domain" the power over certs is always going to lie with those who control the DNS system.

A possible response is that just taking power from the CA's but leaving power with the DNS key owners is not good enough. This does make some sense. It is not entirely clear to me how we will take this power from the DNS system though. The best bet are CT-logs, which will allow after-the-fact detection of any falsely issued certs. Notably though, attribution between CA's and the DNS system isn't solved here. Perhaps if CA's store the relevant signed DNS response, we could attribute the attack to the DNS system.

Not if that someone can intercept traffic from my computer -> public site and can't intercept my computer -> dns server.

And since DNS queries are commonly cached locally (i.e. dns server == my computer a reasonable percentage of the time) that's not even a rare occurrence.

Someone could still make a very reasonable assumption based on IP addresses and response sizes, which is where I believe the primary focus would shift if by some chance this encrypted SNI becomes impossible to circumvent. But also someone could just block DNS-over-HTTPS requests altogether and force Firefox into cleartext DNS and therefore circumvent encrypted SNI.

It also centralizes DNS requests at Cloudflare's POPs (a company from a mass surveillance, secret orders happy, police country by the way).

No, none of it addresses privacy and security, probably only makes it worse.

It's time to admit there is no future for privacy and security without overlay networks.

> someone could just block DNS-over-HTTPS requests altogether

If you are going to block DoH you’ll need to block all HTTPS traffic altogether, don’t you? I mean unless you are just blocking traffic to some list of known DoH providers.

DoH must be bootstrapped somehow to get IP addresses to make requests to. This is where it can be blocked. Either blocking DNS query or a known IP address or just an IP address with suspiciously tiny responses that responds to active probing requests as a DoH server. It's very hard to hide that fact, you need to actively fight those blocking attempts. And if it's done by some government, corporations just bend over backwards to help censorship, like they did in cases of Signal and Telegram recently for example.

>This is where it can be blocked. Either blocking DNS query or a known IP address or just an IP address with suspiciously tiny responses that responds to active probing requests as a DoH server.

This works great in theory but if it takes off then Google and Cloudflare can simply decide to serve DNSoHTTPS requests over their existing service IP space and you're left with the choice of block the internet or allow encrypted DNS lookups.

As far as government comments you're never going to deploy public infrastructure inside a state and be able to avoid the state so it's pointless to bring anything about that up.

Are there even any DoH resolvers you can run yourself? unbound only supports DoT. It's a shame that they had to invent yet another standard.

This makes things a lot more complex to run in a lan. Especially since you also need certificates and put them into the browser trust store. Just to avoid leaking SNI.

The problem was DoTLS was too easily blocked, even by accident with networks that only allowed their DNS server on 53, HTTP on 80, and HTTPS on 443. Easiest way to fix it without giving network administrators a choice unless they control both the devices and the network was to make it ride over HTTPs. Unfortunately I think that means DoTLS is likely to become unused even though it is technically a "cleaner" protocol implementation.

As far as resolvers you can run yourself everyone and their brother has made one - facebook, cloudflare, cordens, dnscrypt, your cousin's brother's sister on Github. Literally all there is to it is rewriting well formed datagrams into well formed JSON and back.

There is no practical difference between blocking port 853 and blocking port 443 to well-known IPs. Each client that wants to use DNS using any protocol will have to contact it by IP first, and that IP has to be provisioned somehow. The same mechanism used for provisioning can be used for blocking.

> There is no practical difference between blocking port 853 and blocking port 443 to well-known IPs.

I'm going to split this up into two answers:

1) The problem for "coffee shop" guest style networks isn't so much that they care to purposefully block this type of DNS as much as it's already blocked by accident and it isn't going to get unblocked any time soon since (realistically) nobody manages these networks post deployment. At least until 8 years later when something breaks or it becomes to unreliable and then is replaced by the next in-a-box solution they bought for 80 dollars.

2) This assumption of blocking works somewhat decently until Google or Cloudflare just decide to enable DNSoHTTPS on their main service IPs. Then you have the choice of blocking most of the internet or not spying on your customer's data. Now as a business if you own the devices and the network you can manage your devices appropriately with an explicit proxy or SSL intercept but general ISP/guest wifi tracking becomes an order of magnitude more difficult to do cost effectively.

I'm concerned mostly with 2, but in small businesses category. Many of them do not have proxy, SSL intercept or MDM (they manage their computers using plain old AD, plus some BYOB devices), and having to get one significantly ups the ante for them.

They've always had to get one if they wanted the security/monitoring, this just makes an implementation of how to get around lazy security a standard.

However, neither of them is fully transparent or autoconfigurable, especially for users that roam among networks. Local DNS resolver, while not 100% bulletproof, did the job acceptably.

> having to get one significantly ups the ante for them.

I see this as a good thing. I do sympathize with small businesses that, when gaping holes in internet security are closed, are forced to retire technologies that exploited those holes. And I'm not being sarcastic about being sympathetic - businesses in this position would probably rather be spending their money on something else. But, these are security issues that impact everyone and leaving them unfixed just because it will negatively impact a group isn't a reasonable option.

So preload the list of IPs in the OS.

That's the easy case, if they are preloaded in the OS, they are well-known by definition and can be blocked statically.

The dynamically discovered ones are the next step in the game, but you still have to start somewhere, either with well-known IP or at least legacy DNS.

Reply on news.ycombinator.com