6 ms·

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 do

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.

markovbot 8y ago
Not if you use DNS-over-HTTPS, as is required to turn this on in Firefox
- rickbutton 8y ago
  right, DNS-over-HTTPS solves this particular problem.
erinnh 8y ago
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_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
- tptacek 8y ago
  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 https://www.imperialviolet.org/2015/01/17/notdane.html
  - tialaramex 8y ago
    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.
    - tptacek 8y ago
      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.
      - dagenix 8y ago
        And definitely read the post by Thomas Ptacek linked to from that article: https://sockpuppet.org/blog/2015/01/15/against-dnssec/ 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.
        tialaramex 8y ago
        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.
gpm 8y ago
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.
zzzcpan 8y ago
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.
- codetrotter 8y ago
  > 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.
  - zzzcpan 8y ago
    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.
    - zamadatix 8y ago
      >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.

markovbot 8y ago

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

rickbutton 8y ago
right, DNS-over-HTTPS solves this particular problem.

erinnh 8y ago

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_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

tptacek 8y ago
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 https://www.imperialviolet.org/2015/01/17/notdane.html
- tialaramex 8y ago
  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.
  - tptacek 8y ago
    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.
    - dagenix 8y ago
      And definitely read the post by Thomas Ptacek linked to from that article: https://sockpuppet.org/blog/2015/01/15/against-dnssec/ 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.
      - tialaramex 8y ago
        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.

gpm 8y ago

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.

zzzcpan 8y ago

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.

codetrotter 8y ago
> 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.
- zzzcpan 8y ago
  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.
  - zamadatix 8y ago
    >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.