6 ms·

> DNSCurve doesn't authenticate the records themselves. A malicious DNS Server can provide simply wrong responses and you cannot notice. There is no way to tell

by zrm 8y ago

> DNSCurve doesn't authenticate the records themselves. A malicious DNS Server can provide simply wrong responses and you cannot notice. There is no way to tell if a provider gave you a bad response. Sure there is. You do the recursion yourself and compare the result. If you do this 100% of the time, i.e. run your own recursive resolver, there is no need to even have a third party recursive DNS server that could potentially send malicious responses. If you do it a lower percentage of the time at random, or for specific queries you're expecting interference with, you detect the interference and know not to trust that DNS server anymore. Comparing keys in DNSSEC is no better than this. If a MITM attacker has altered your root keys, the attacker can forge responses from any DNS server you use, unless you're using something that actually authenticates the recursive resolver (whether DoT/DoH or DNSCurve), at which point you can compare the query responses again and no longer need to compare the keys or use DNSSEC at all. > DNSSEC makes such manipulation obvious and also prevents in-transit tampering. Which is one of its flaws. Sometimes you want friendly in-transit tampering. With DNSSEC there is a fixed root of trust that everybody has to follow and nobody can choose for themselves or alter for a specific subset of the tree.

zaarn 8y ago
>You do the recursion yourself and compare the result. I was talking about during recursion. Plus this is what I mentioned in my previous comment. This is about someone injecting responses on the network level and blocking proper communication or even having taken over an IP via BGP hijack, in which case the NS record might point to the correct IP but a malicious DNS server would be responding. DNSSEC would detect this failure mode. >Sometimes you want friendly in-transit tampering In which case you likely have your own PKI to manage HTTPS MitM as well, so it shouldn't be an issue to run DNSSEC.
- zrm 8y ago
  > DNSSEC would detect this failure mode. So would DNSCurve. If the root servers were using DNSCurve then you would distribute their public keys in the same way that you distribute their IP addresses, over some secure side channel such as your operating system's software update mechanism. Once you have the public keys of the root servers, no one can impersonate the root servers to you without their private keys. The root servers can then securely give you the names of the gTLD nameservers. If they use DNSCurve, their public keys are encoded in the names of the nameservers and you can communicate securely with them as well, and so on down the chain. Hijacking BGP doesn't allow you to impersonate any of the authoritative servers that have a chain up to the root using DNSCurve without having their private keys. You can also pin the public keys of any nameservers that don't have a chain up to the root for the same benefit for that subtree, e.g. if some gTLDs used DNSCurve but the root didn't, or to use between your clients and your company's authoritative DNS servers for your own domain. > In which case you likely have your own PKI to manage HTTPS MitM as well, so it shouldn't be an issue to run DNSSEC. This is regularly not the case. For example, sysadmins regularly map the most common tracking domains to a black hole in the resolver on the local network or local machine without doing any kind of HTTPS MitM.
  - zaarn 8y ago
    >For example, people regularly map the most common tracking domains to a black hole in the hosts file for dnsmasq on their internet gateway without doing any kind of HTTPS MitM. This behaviour doesn't break under DNSSEC; the blackholed domain either blackholes or the resolver fails due to the bad signature and effectively blackholes as well. >If the root servers were using DNSCurve then you would distribute their public keys in the same way that you distribute their IP addresses, over some secure side channel such as your operating system's software update mechanism. [...] And what does that gain you over DNSSEC+DoT/H other than being non-standard?
    - zrm 8y ago
      > This behaviour doesn't break under DNSSEC; the blackholed domain either blackholes or the resolver fails due to the bad signature and effectively blackholes as well. If you give an address that always sends back ICMP unreachable messages, the client fails immediately and continues to load the rest of the page, but DNSSEC proscribes that. You could refuse to send a response for those names, but then the client has to wait for the timeout. You could send a response with an invalid signature, but then the client should discard it and continue to wait for a valid response, and you still have to wait for the timeout. There are also circumstances where you want to return a specific address, e.g. so that attempts to send traffic to that address can be monitored, and redirecting the address doesn't work because it could be a shared host using SNI and you don't want to affect every name pointing to that address. > And what does that gain you over DNSSEC+DoT/H other than being non-standard? It's simpler, more efficient, lower latency, has less attack surface and can't be used as a DDoS amplification vector. And if you want something standard, why not standardize on DNSCurve? Using DNSSEC over that is only the sunk cost fallacy.
      - zaarn 8y ago
        >DDoS amplification vector. How would a TLS-using protocol be used as a DDoS amplification vector? >If you give an address that always sends back ICMP unreachable messages, the client fails immediately and continues to load the rest of the page, but DNSSEC proscribes that. You can return resolver errors or no data, there is plenty of options for DNS blackholing. >There are also circumstances where you want to return a specific address, e.g. so that attempts to send traffic to that address can be monitored, and redirecting the address doesn't work because it could be a shared host using SNI and you don't want to affect every name pointing to that address. You'll need a PKI for that anyway so you can deploy DNSSEC root keys.

by zrm 8y ago

zaarn 8y ago

>You do the recursion yourself and compare the result. I was talking about during recursion. Plus this is what I mentioned in my previous comment. This is about someone injecting responses on the network level and blocking proper communication or even having taken over an IP via BGP hijack, in which case the NS record might point to the correct IP but a malicious DNS server would be responding. DNSSEC would detect this failure mode. >Sometimes you want friendly in-transit tampering In which case you likely have your own PKI to manage HTTPS MitM as well, so it shouldn't be an issue to run DNSSEC.

zrm 8y ago
> DNSSEC would detect this failure mode. So would DNSCurve. If the root servers were using DNSCurve then you would distribute their public keys in the same way that you distribute their IP addresses, over some secure side channel such as your operating system's software update mechanism. Once you have the public keys of the root servers, no one can impersonate the root servers to you without their private keys. The root servers can then securely give you the names of the gTLD nameservers. If they use DNSCurve, their public keys are encoded in the names of the nameservers and you can communicate securely with them as well, and so on down the chain. Hijacking BGP doesn't allow you to impersonate any of the authoritative servers that have a chain up to the root using DNSCurve without having their private keys. You can also pin the public keys of any nameservers that don't have a chain up to the root for the same benefit for that subtree, e.g. if some gTLDs used DNSCurve but the root didn't, or to use between your clients and your company's authoritative DNS servers for your own domain. > In which case you likely have your own PKI to manage HTTPS MitM as well, so it shouldn't be an issue to run DNSSEC. This is regularly not the case. For example, sysadmins regularly map the most common tracking domains to a black hole in the resolver on the local network or local machine without doing any kind of HTTPS MitM.
- zaarn 8y ago
  >For example, people regularly map the most common tracking domains to a black hole in the hosts file for dnsmasq on their internet gateway without doing any kind of HTTPS MitM. This behaviour doesn't break under DNSSEC; the blackholed domain either blackholes or the resolver fails due to the bad signature and effectively blackholes as well. >If the root servers were using DNSCurve then you would distribute their public keys in the same way that you distribute their IP addresses, over some secure side channel such as your operating system's software update mechanism. [...] And what does that gain you over DNSSEC+DoT/H other than being non-standard?
  - zrm 8y ago
    > This behaviour doesn't break under DNSSEC; the blackholed domain either blackholes or the resolver fails due to the bad signature and effectively blackholes as well. If you give an address that always sends back ICMP unreachable messages, the client fails immediately and continues to load the rest of the page, but DNSSEC proscribes that. You could refuse to send a response for those names, but then the client has to wait for the timeout. You could send a response with an invalid signature, but then the client should discard it and continue to wait for a valid response, and you still have to wait for the timeout. There are also circumstances where you want to return a specific address, e.g. so that attempts to send traffic to that address can be monitored, and redirecting the address doesn't work because it could be a shared host using SNI and you don't want to affect every name pointing to that address. > And what does that gain you over DNSSEC+DoT/H other than being non-standard? It's simpler, more efficient, lower latency, has less attack surface and can't be used as a DDoS amplification vector. And if you want something standard, why not standardize on DNSCurve? Using DNSSEC over that is only the sunk cost fallacy.
    - zaarn 8y ago
      >DDoS amplification vector. How would a TLS-using protocol be used as a DDoS amplification vector? >If you give an address that always sends back ICMP unreachable messages, the client fails immediately and continues to load the rest of the page, but DNSSEC proscribes that. You can return resolver errors or no data, there is plenty of options for DNS blackholing. >There are also circumstances where you want to return a specific address, e.g. so that attempts to send traffic to that address can be monitored, and redirecting the address doesn't work because it could be a shared host using SNI and you don't want to affect every name pointing to that address. You'll need a PKI for that anyway so you can deploy DNSSEC root keys.