7 ms·

Isn't dnscurve a better alternative? Dnscrypt? Etc

by mtgx 8y ago

bluejekyll 8y ago
dnscurve and dnscrypt handle a different use case than DNSSEC. DNSSEC allows for the records in a DNS zone to be verified via signatures, also stored in the zone, RRSIGs, against keys also registered in the zone, DNSKEYs, which are pinned to the zone along with the NS records in the parent zone via a record called a DS record. dnscurve and dnscrypt are in the same space as DNS-over-HTTPS, DoH, and DNS-over-TLS, DoT. What they do is authenticate the dns server (resolver) and also encrypt the channel giving you privacy. DNSSEC == authenticated records. dnscurve, dnscrypt, DoH, and DoT == authenticated and encrypted resolutions.
- tptacek 8y ago
  And, of course, one of these is a real problem and is seeing widespread deployment and has a bright future, and the other isn't and has been failing since approximately 1994.
- zrm 8y ago
  > DNSSEC == authenticated records. dnscurve, dnscrypt, DoH, and DoT == authenticated and encrypted resolutions. But notice that authenticated resolutions get you authenticated records provided you do them all the way to the root. The root servers on down could support DNSCurve or similar and you could operate recursively using it, or have your trusted recursive resolver do so as you in turn reach it using the same mechanism. Meanwhile that wouldn't break the cases where you want your DNS server to modify records, e.g. for blocking tracking domains.
  - zaarn 8y ago
    Authenticated resolution does not give you authenticated records. You cannot verify that the response between root and your resolver wasn't manipulated or that some DNS Server in the chain is sending malicious responses, even if they had DNSCurve.
    - zrm 8y ago
      If the root was using DNSCurve, a request to the root would be authenticated, and so on all the way down for each domain that uses it. The recursive resolver would have authenticated responses from each authoritative nameserver from the root on down. The recursive resolver could then provide a different response to the client, but the client could use DNSCurve to authenticate its DNS server as well, so the client only gets malicious responses if it configures a malicious DNS server. And that would compromise anything. What happens to DNSSEC if the attacker replaces the client's DNSSEC root keys with the attacker's?
      - zaarn 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. With DNSSEC the DNS Server also has to advertise different keys, which is something you can notice in your resolver and alert too, for example if you already know the key is different via a side channel or you communicate with another resolver and they got a different key. DNSSEC makes such manipulation obvious and also prevents in-transit tampering. Coupled with DoH/T you get all the benefits of both.
        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.
- calgoo 8y ago
  So basically, DNSSEC is like signing an email with a PGP key, and the others are like encrypting an email with PGP ?
  - bluejekyll 8y ago
    Similar, yes, but it's not a perfect analogy. In the DNSSEC case, yes, that's akin to the same thing. In the other, PGP is both encrypting and authenticating the data, then sending that over untrusted email servers. DoH, DoT, et al, are encrypting the channel, and authenticating the endpoints, but not authenticating the data.

Isn't dnscurve a better alternative? Dnscrypt? Etc

by mtgx 8y ago

Isn't dnscurve a better alternative? Dnscrypt? Etc

dnscurve and dnscrypt handle a different use case than DNSSEC. DNSSEC allows for the records in a DNS zone to be verified via signatures, also stored in the zone, RRSIGs, against keys also registered in the zone, DNSKEYs, which are pinned to the zone along with the NS records in the parent zone via a record called a DS record. dnscurve and dnscrypt are in the same space as DNS-over-HTTPS, DoH, and DNS-over-TLS, DoT. What they do is authenticate the dns server (resolver) and also encrypt the channel giving you privacy. DNSSEC == authenticated records. dnscurve, dnscrypt, DoH, and DoT == authenticated and encrypted resolutions.

tptacek 8y ago
And, of course, one of these is a real problem and is seeing widespread deployment and has a bright future, and the other isn't and has been failing since approximately 1994.
zrm 8y ago
> DNSSEC == authenticated records. dnscurve, dnscrypt, DoH, and DoT == authenticated and encrypted resolutions. But notice that authenticated resolutions get you authenticated records provided you do them all the way to the root. The root servers on down could support DNSCurve or similar and you could operate recursively using it, or have your trusted recursive resolver do so as you in turn reach it using the same mechanism. Meanwhile that wouldn't break the cases where you want your DNS server to modify records, e.g. for blocking tracking domains.
- zaarn 8y ago
  Authenticated resolution does not give you authenticated records. You cannot verify that the response between root and your resolver wasn't manipulated or that some DNS Server in the chain is sending malicious responses, even if they had DNSCurve.
  - zrm 8y ago
    If the root was using DNSCurve, a request to the root would be authenticated, and so on all the way down for each domain that uses it. The recursive resolver would have authenticated responses from each authoritative nameserver from the root on down. The recursive resolver could then provide a different response to the client, but the client could use DNSCurve to authenticate its DNS server as well, so the client only gets malicious responses if it configures a malicious DNS server. And that would compromise anything. What happens to DNSSEC if the attacker replaces the client's DNSSEC root keys with the attacker's?
    - zaarn 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. With DNSSEC the DNS Server also has to advertise different keys, which is something you can notice in your resolver and alert too, for example if you already know the key is different via a side channel or you communicate with another resolver and they got a different key. DNSSEC makes such manipulation obvious and also prevents in-transit tampering. Coupled with DoH/T you get all the benefits of both.
      - 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.
calgoo 8y ago
So basically, DNSSEC is like signing an email with a PGP key, and the others are like encrypting an email with PGP ?
- bluejekyll 8y ago
  Similar, yes, but it's not a perfect analogy. In the DNSSEC case, yes, that's akin to the same thing. In the other, PGP is both encrypting and authenticating the data, then sending that over untrusted email servers. DoH, DoT, et al, are encrypting the channel, and authenticating the endpoints, but not authenticating the data.