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

Encrypted SNI Comes to Firefox Nightly

blog.mozilla.org

Post reply on HN
Print view View original

61–70 of 155 posts

Re: Encrypted SNI Comes to Firefox Nightly

#61

Post by vetinari »

lilyball wrote: post #52
the8472 wrote: post #49

Earlier quoted context omitted.

> (and, separately, pick from any DNS provider that supports DOH). But why do I have to? I already have a trusted DNS resolver operated by myself wired to my OS. Why require the whole DoH rube goldberg machinery to let me try ESNI?

If your browser is talking to a DNS resolver wired to your OS, that doesn't change what any upstream network observer sees, since they can observe DNS requests generated by your OS-level DNS resolver exactly as they would observe DNS requests generated by your browser. DOH isn't about trust. It's about preventing network observers from figuring out what sites you visit by observing the DNS requests you make.

There isn't anything that would prevent the local resolver to talk upstream using DoH.

Same privacy, minus cloud companies that try to insert themselves as middleman.

Re: Encrypted SNI Comes to Firefox Nightly

#62

Post by tialaramex »

tptacek wrote: post #22
toomuchtodo wrote: post #20

Earlier quoted context omitted.

I don't disagree there are problems with not involving commercial stakeholders in the standardization process, and your Heartbleed example is poignant. I feel that there is a middle ground that would be more beneficial to all stakeholders in the long run. I'm just asking for some balance. The implementations of today evolve into the legacy systems that will need to be supported and maintained for years, if not decade…

Yes, and I think what you're looking at now is balance. The way standards are supposed to work is that companies (among other users) come up with features that they want, and get them working, and then the IETF is supposed to hammer out agreement on how to make those features interoperate. And that's it. It was never the idea that IETF was meant to be an Internet legislature adjudicating what features can and can't b…

Let's take TLS as an example. Nalini and co. wanted at first to put back RSA in TLS 1.3, they wanted that feature, the TLS Working Group felt that their charter effectively ruled it out. In your opinion was this working group acting as an "Internet legislature" by not having RSA in TLS 1.3?

Gradually Nalini's lot discovered a very important thing about the IETF: It is not a democracy. They tried sending more and more people, attempting the same thing that made Microsoft's Office into an ISO standard - pack the room with people who vote how you tell them. But there aren't any votes at the IETF, you've just sent lots of people half way around the world to at best get recruited for other work and at worst embarrass themselves and you.

After they realised that stamping their feet, even if in large numbers, wouldn't get RSA back in TLS 1.3, they came up with an alternate plan for what was invariably named "transparency" (when you have a bad idea, give it a name that sounds like a good idea, see also: most bills before US Congress) but is of course always some means to destroy forward secrecy or to enable some other snooping.

Now, IMNSHO the Working Group did the right thing here by rejecting these proposals on the basis that (per IETF best practice) "Pervasive Monitoring is an Attack". Was this, again, the "Internet legislature" since Nalini and co. wanted to do it and they'd expected as you've described that if they wanted to do it the IETF should just help them achieve that goal?

Well if you're sad for Nalini there's a happy ending. The IETF, unlike a legislature, has no power whatsoever to dictate how the Internet works.

ETSI (a much more conventional standards organisation) took all the exciting "Transparency" work done by Nalini's group and they're now running with it. They haven't finished their protocol yet, but in line with your vision it enables all the features they wanted, re-enables RC4 and CBC and so on. They've published one early draft, but obviously ETSI proceedings (again unlike the IETF) happen behind closed doors.

You are entirely welcome to ignore TLS 1.3 and "upgrade" to the ETSI proposal instead. Enjoy your "freedom" to do this, I guess?

Re: Encrypted SNI Comes to Firefox Nightly

#63

Post by tptacek »

tialaramex wrote: post #62
tptacek wrote: post #22

Earlier quoted context omitted.

Yes, and I think what you're looking at now is balance. The way standards are supposed to work is that companies (among other users) come up with features that they want, and get them working, and then the IETF is supposed to hammer out agreement on how to make those features interoperate. And that's it. It was never the idea that IETF was meant to be an Internet legislature adjudicating what features can and can't b…

Let's take TLS as an example. Nalini and co. wanted at first to put back RSA in TLS 1.3, they wanted that feature, the TLS Working Group felt that their charter effectively ruled it out. In your opinion was this working group acting as an "Internet legislature" by not having RSA in TLS 1.3? Gradually Nalini's lot discovered a very important thing about the IETF: It is not a democracy. They tried sending more and more…

After Heartbleed, a lot of things in the TLS ecosystem got better. CFRG is now chaired by Kenny Paterson, and he and others ran interference for an academically-grounded rebuild of TLS for 1.3. Google beat the living shit out of OpenSSL, and expedited the deployment of 1.3.

I agree: the 1.3 process is better than what came before it. But it's the exception that proves the rule: the 1.3 process was a reaction to the sclerotic handling of security standards at IETF prior to it.

My point is simple and, I think, pretty obviously correct: you can't look back over the last 10-15 years of standards group work and assume that either IETF approval or multi-party cooperation within IETF is a marker of quality. And that's as it should be: it's IETF's job to ensure interop, not to referee all protocol design. More people should work outside of the IETF system.

Re: Encrypted SNI Comes to Firefox Nightly

#64

Post by vetinari »

zamadatix wrote: post #60
the8472 wrote: post #23

Earlier quoted context omitted.

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…

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.

Re: Encrypted SNI Comes to Firefox Nightly

#65

Post by zamadatix »

vetinari wrote: post #64
zamadatix wrote: post #60

Earlier quoted context omitted.

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…

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.

Re: Encrypted SNI Comes to Firefox Nightly

#66

Post by tialaramex »

tptacek wrote: post #13
erinnh wrote: post #7

Earlier quoted context omitted.

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.

Re: Encrypted SNI Comes to Firefox Nightly

#67

Post by vetinari »

zamadatix wrote: post #65
vetinari wrote: post #64

Earlier quoted context omitted.

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…

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.

Re: Encrypted SNI Comes to Firefox Nightly

#68

Post by eridius »

vetinari wrote: post #61
lilyball wrote: post #52

Earlier quoted context omitted.

If your browser is talking to a DNS resolver wired to your OS, that doesn't change what any upstream network observer sees, since they can observe DNS requests generated by your OS-level DNS resolver exactly as they would observe DNS requests generated by your browser. DOH isn't about trust. It's about preventing network observers from figuring out what sites you visit by observing the DNS requests you make.

There isn't anything that would prevent the local resolver to talk upstream using DoH. Same privacy, minus cloud companies that try to insert themselves as middleman.

DOH does not rely on cloud companies. The requirement for DOH has nothing to do with cloud companies "try[ing] to insert themselves as middleman". You certainly could argue that ESNI should be used even if DNS isn't done over DOH, in case you trust the network path to your recursive resolver and you trust the recursive resolver itself to be using DOH, but that also has nothing to do with cloud companies. I admit I'm not sure why ESNI requires DOH (it's not particularly useful without DOH, but that's not an argument to disable it); my guess is simply due to the additional resource usage necessary to process ESNI requests, and so Firefox doesn't want to put this additional load on the server if there's no practical benefit to doing so. Ideally, using an OS-level resolver would have a way to tell the browser that the recursive resolution was encrypted (whether via DOH or something else it doesn't really matter), but I'm not aware of any way to do that at the moment.

Re: Encrypted SNI Comes to Firefox Nightly

#69

Post by tptacek »

tialaramex wrote: post #66
tptacek wrote: post #13

Earlier quoted context omitted.

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,…

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.

Re: Encrypted SNI Comes to Firefox Nightly

#70

Post by zamadatix »

vetinari wrote: post #67
zamadatix wrote: post #65

Earlier quoted context omitted.

> 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…

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.
Post reply on HN