5 ms·

There are a bunch of reasons why this doesn't work, but first among them is this: This would require browsers to make DNSSEC queries, and if those queries were

There are a bunch of reasons why this doesn't work, but first among them is this: This would require browsers to make DNSSEC queries, and if those queries were blocked or otherwise failed, the browser would have to fail closed and present a certificate error. (The alternative, failing open and allowing users to visit a site if the browser doesn't get a response to the DNSSEC query, would be completely insecure, because the whole point of HTTPS is to defend against MITM attacks, and an MITM could simply block all DNSSEC traffic.) This is impractical because there are a bunch of existing firewalls and middleboxes that don't understand DNSSEC and that (contra Postel's Law) block DNS traffic that they don't understand; implementing this change would be cutting off everyone behind those firewalls and middleboxes from the Web. There are also a lot of other objections to it, including that it's too centralized (see https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=author%3Atptacek%20DNSSEC&sort=byPopularity&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...), but that's the basic reason why it can't be deployed.

josteink 6y ago
> This is impractical because there are a bunch of existing firewalls and middleboxes that don't understand DNSSEC and that (contra Postel's Law) block DNS traffic that they don't understand; implementing this change would be cutting off everyone behind those firewalls and middleboxes from the Web. Funny how this was never an argument when HTTPS was forced on everyone (to solve the problem with JavaScript being insecure), despite almost the exact same reasons holding up with middle-boxes, proxies and the like. Now that there is an alternate, much simpler HTTPS-solution everyone is "oh noes that would break corporate environments". What's different this time around? Why is breaking things bad this time? If we could just sit down, and all agree that the only reason we "need" HTTPS everywhere is because running JavaScript in a browser represents a security-issue, the quicker we can start solving the real problem: JavaScript as a default-permission. The quicker we can phase that out from web-pages (which honestly more often than not, simply represents documents), the better.
- acdha 6y ago
  > Funny how this was never an argument when HTTPS was forced on everyone (to solve the problem with JavaScript being insecure), This misunderstanding is where your argument went off the rails: people wanted HTTPS because they are sending data over networks which aren’t perfectly trustworthy. Starting in the late 1990s there was string consumer demand to feel safe entering credit cards and other personal information even if the site used no JavaScript - our household-name clients expected it even if they only used JS for mouseover effects. That was before WiFi became common, too, and people realized the risks of letting everyone at Starbucks see their information. DNSSEC has no equivalent because it took so long to be adopted that it offers no meaningful user benefit over HTTPS, and it’d need to be a substantial win to balance out the poor user experience and implementation challenges.
  - josteink 6y ago
    But most of the websites today are not sending sensitive data back and forth, they are simply sending public data from public websites. And here the HTTPS crowd‘S argument is that an evil attacker can inject malicious JS if MITMed, and this according to them is why everyone must have HTTPS for everything. No middle ground. But if JS was not a default permission, that wouldn’t be a problem and plain HTTP would go a long way for most people, without risking stuff like heart bleed and insecure servers, due to an overly complicated and often vulnerable crypto stack. Edit: I don’t see why people think this is a crazy suggestion. We used to treat MSWord-documents the same way we treat web-documents now. That is, once op deed, the document had the permission and capability to run any embedded script it wanted. In the end everyone realized this was a bad idea, and now Word-documents have to request the script-permission from the user before scripts are allowed to run. The result? MSWord-based worms and malware almost eliminated over night. And I’d like to see anyone argue that we should give HTML-email script-permissions by default. You know why that is a bad idea. So why wouldn’t want the same for the web? Why should not the web be safe by default? Why should we have to accept scripts we haven’t authorised?
    - UncleMeat 6y ago
      Making 99.9% of websites ask for js permissions, and often break if the user clicks no, is just adding unneeded friction for the huge majority of cases. “Do you want to accept X” is also a terrible security boundary since most users won’t be able to tell when it is reasonable vs an attack scenario. The HN community loves static sites and the old web. But this is a tiny tiny tiny minority.
xoa 6y ago
Contra GP, could you clarify how DNSSEC itself even important in this though? As far as I can tell, nearly all of my typical stack ultimately comes down to my domain. If my registrar, account with them, or DNS is compromised that's it. Let's Encrypt will cheerfully issue all the certs hostile attackers want. They'd have the ability to get most new emails (except for PGP/custom S/MIME) and in turn most accounts as well except for those with out of band pre-shared keys required (SSH, webauthn sites, maybe SMS). "Required", because realistically with that level of access many services that claim to require 2FA could probably be socially engineered around. So I guess I'm confused how DNS records hold a public key rather than _acme-challenge would be any worse? Is it that while browsers may not be able to consistently get DNSSEC, Let's Encrypt consistently can for those that use it so it provides a weak bit of OOB workaround? I can see how that might be of some value, but not sure it's worth the trade off. I hope there's at least a concerted effort to someday secure DNS in general, thus making CAs (including LE) obsolete unless they do something beyond domain checks.
- tzs 6y ago
  You seem to be looking at it from the point of view of attacks against the domain owner. If someone gets control of your domain, then yes, there really isn't much difference between a system where a public key in your domain's DNS records is used by clients to tell they are talking to your sites and a system where a certificate issued by LE is used for that. As you note, once they have control of your domain they can get new certificates from LE for it. But attacks against the domain owner aren't the only kind of attacks. There are also attacks against the domain's visitors. Suppose Bob has an old router at home with out of date, buggy firmware that I know a remote exploit for that allows me to change his DNS settings. I change it so that instead of using the DNS servers it get from Bob's ISP via DHCP to resolve DNS requests from the LAN, it uses my DNS server. My DNS server points your domain to one of my sites instead of yours, where I run my nefarious fake version of your site. Under the public key on DNS server approach, it's my DNS server, so I can put a public key on it that corresponds to my keys on my fake version of your site, and everything will check out from Bob's point of view. Under the LE approach, this does not work. To get LE to issue to me a certificate for your site, I have to get LE to use a DNS server I control to resolve your domain. That's the difference. Under the current system to securely hijack your site I need to compromise your system, your DNS provider, your domain registrar, your ISP, or your hosting provider. Under the keys in DNS approach, I just need to compromise end users.
jart 6y ago
Are you saying, there exists some goofball who filters DNSSEC traffic, therefore DNSSEC isn't possible? If that's how you want to play it then Google now has a moral duty to implement NAPTR and SRV too. That way fallback and load balancing can happen in the Chrome client. Thus folks won't have to pay for BGP or VIP privilege anymore to be able to serve internationally.
- ameliaquining 6y ago
  IIUC the Chrome developers ran experiments to determine how many users would break if they rolled this out, and the number was above whatever they consider an acceptable threshold.
  - jart 6y ago
    Which L Team member came to that determination? Would he or she like us to help by setting up public RRDtool monitoring of the policy impact on Internet properties?

josteink 6y ago

> This is impractical because there are a bunch of existing firewalls and middleboxes that don't understand DNSSEC and that (contra Postel's Law) block DNS traffic that they don't understand; implementing this change would be cutting off everyone behind those firewalls and middleboxes from the Web. Funny how this was never an argument when HTTPS was forced on everyone (to solve the problem with JavaScript being insecure), despite almost the exact same reasons holding up with middle-boxes, proxies and the like. Now that there is an alternate, much simpler HTTPS-solution everyone is "oh noes that would break corporate environments". What's different this time around? Why is breaking things bad this time? If we could just sit down, and all agree that the only reason we "need" HTTPS everywhere is because running JavaScript in a browser represents a security-issue, the quicker we can start solving the real problem: JavaScript as a default-permission. The quicker we can phase that out from web-pages (which honestly more often than not, simply represents documents), the better.

acdha 6y ago
> Funny how this was never an argument when HTTPS was forced on everyone (to solve the problem with JavaScript being insecure), This misunderstanding is where your argument went off the rails: people wanted HTTPS because they are sending data over networks which aren’t perfectly trustworthy. Starting in the late 1990s there was string consumer demand to feel safe entering credit cards and other personal information even if the site used no JavaScript - our household-name clients expected it even if they only used JS for mouseover effects. That was before WiFi became common, too, and people realized the risks of letting everyone at Starbucks see their information. DNSSEC has no equivalent because it took so long to be adopted that it offers no meaningful user benefit over HTTPS, and it’d need to be a substantial win to balance out the poor user experience and implementation challenges.
- josteink 6y ago
  But most of the websites today are not sending sensitive data back and forth, they are simply sending public data from public websites. And here the HTTPS crowd‘S argument is that an evil attacker can inject malicious JS if MITMed, and this according to them is why everyone must have HTTPS for everything. No middle ground. But if JS was not a default permission, that wouldn’t be a problem and plain HTTP would go a long way for most people, without risking stuff like heart bleed and insecure servers, due to an overly complicated and often vulnerable crypto stack. Edit: I don’t see why people think this is a crazy suggestion. We used to treat MSWord-documents the same way we treat web-documents now. That is, once op deed, the document had the permission and capability to run any embedded script it wanted. In the end everyone realized this was a bad idea, and now Word-documents have to request the script-permission from the user before scripts are allowed to run. The result? MSWord-based worms and malware almost eliminated over night. And I’d like to see anyone argue that we should give HTML-email script-permissions by default. You know why that is a bad idea. So why wouldn’t want the same for the web? Why should not the web be safe by default? Why should we have to accept scripts we haven’t authorised?
  - UncleMeat 6y ago
    Making 99.9% of websites ask for js permissions, and often break if the user clicks no, is just adding unneeded friction for the huge majority of cases. “Do you want to accept X” is also a terrible security boundary since most users won’t be able to tell when it is reasonable vs an attack scenario. The HN community loves static sites and the old web. But this is a tiny tiny tiny minority.

xoa 6y ago

Contra GP, could you clarify how DNSSEC itself even important in this though? As far as I can tell, nearly all of my typical stack ultimately comes down to my domain. If my registrar, account with them, or DNS is compromised that's it. Let's Encrypt will cheerfully issue all the certs hostile attackers want. They'd have the ability to get most new emails (except for PGP/custom S/MIME) and in turn most accounts as well except for those with out of band pre-shared keys required (SSH, webauthn sites, maybe SMS). "Required", because realistically with that level of access many services that claim to require 2FA could probably be socially engineered around. So I guess I'm confused how DNS records hold a public key rather than _acme-challenge would be any worse? Is it that while browsers may not be able to consistently get DNSSEC, Let's Encrypt consistently can for those that use it so it provides a weak bit of OOB workaround? I can see how that might be of some value, but not sure it's worth the trade off. I hope there's at least a concerted effort to someday secure DNS in general, thus making CAs (including LE) obsolete unless they do something beyond domain checks.

tzs 6y ago
You seem to be looking at it from the point of view of attacks against the domain owner. If someone gets control of your domain, then yes, there really isn't much difference between a system where a public key in your domain's DNS records is used by clients to tell they are talking to your sites and a system where a certificate issued by LE is used for that. As you note, once they have control of your domain they can get new certificates from LE for it. But attacks against the domain owner aren't the only kind of attacks. There are also attacks against the domain's visitors. Suppose Bob has an old router at home with out of date, buggy firmware that I know a remote exploit for that allows me to change his DNS settings. I change it so that instead of using the DNS servers it get from Bob's ISP via DHCP to resolve DNS requests from the LAN, it uses my DNS server. My DNS server points your domain to one of my sites instead of yours, where I run my nefarious fake version of your site. Under the public key on DNS server approach, it's my DNS server, so I can put a public key on it that corresponds to my keys on my fake version of your site, and everything will check out from Bob's point of view. Under the LE approach, this does not work. To get LE to issue to me a certificate for your site, I have to get LE to use a DNS server I control to resolve your domain. That's the difference. Under the current system to securely hijack your site I need to compromise your system, your DNS provider, your domain registrar, your ISP, or your hosting provider. Under the keys in DNS approach, I just need to compromise end users.

jart 6y ago

Are you saying, there exists some goofball who filters DNSSEC traffic, therefore DNSSEC isn't possible? If that's how you want to play it then Google now has a moral duty to implement NAPTR and SRV too. That way fallback and load balancing can happen in the Chrome client. Thus folks won't have to pay for BGP or VIP privilege anymore to be able to serve internationally.

ameliaquining 6y ago
IIUC the Chrome developers ran experiments to determine how many users would break if they rolled this out, and the number was above whatever they consider an acceptable threshold.
- jart 6y ago
  Which L Team member came to that determination? Would he or she like us to help by setting up public RRDtool monitoring of the policy impact on Internet properties?