4 ms·

The argument for it (not saying I accept it) is that the definition of the "authentic site" largely resides in the database of the DNS registrars anyway. Curre

The argument for it (not saying I accept it) is that the definition of the "authentic site" largely resides in the database of the DNS registrars anyway. Currently, many CAs authenticate new applicants primarily on the basis of this "domain control", i.e., can they receive an email at this domain. So DNSSEC wouldn't be changing anything there. IMHO, the idea of providing cryptographic authentication for DNS records isn't inherently a bad one and it's only natural that it would follow the same hierarchy as the name delegation itself. In one sense it delegates more freedom than the CA system does (assuming you don't purchase yourself a sub-CA). However, in other fundamental ways it represents a highly centralized system of control.

tptacek 15y ago
DNSSEC advocates (not saying you're one) tend to talk about the idea of cryptographic authentication of DNS records as if it were free. But it's not free. It will cost many tens of millions of dollars. It will contribute to the instability of the Internet as a whole as well-meaning but necessarily inexpert administrators misconfigure their zones. And because DNS is at a lower layer of the stack than TLS, those failures will be more severe. For instance, read any tutorial on socket programming, or browse socket code on Github or Google Code Search. Look how a DNS name is normally resolved in code: by calling gethostbyname(name). Look how the return value of that call is handled: either the struct hostent it returns is NULL, in which case "host not found", or it's non-NULL, in which case the domain name is good. Where's the error channel? There are DNSSEC advocates --- presumably none of whom have shipped a product in C before --- who talk as if this is a minor detail. But look at Daniel J. Bernstein's "ipv6mess" article: http://cr.yp.to/djbdns/ipv6mess.html http://cr.yp.to/djbdns/ipv6mess.html How do we reach the magic moment? How do we teach every server on the Internet to talk to clients on public IPv6 addresses? How do we teach every client on the Internet to talk to servers on public IPv6 addresses? Answer: We go through every place that 4-byte IPv4 addresses appear, and allow 16-byte IPv6 addresses in the same place. Isn't it the same deal for DNS? Aren't we talking about either forklifting out or breaking huge amounts of deployed code? And to what end? DNSSEC doesn't solve the PKI problem we have on the Internet. When people in the Czech Republic go to Google, aren't they often going to GOOGLE.CZ? When people in Italy go to Amazon, don't they go to AMAZON.IT? Who controls .CZ? .IT? .COM? Certainly not Amazon and Google. What we have on the Internet is a failure of security policy. It's a human factors problem and a UX problem, not a failure of the core Internet protocols. By acting like a band-aid on those core protocols is going to fix the problem, we: * defer the real solution to the problem for another 10 years while we wait-and-see whether DNSSEC helps (hint: it won't really) * make it even harder to apply UX solutions to the problem by pushing the decisions that need to be made further down the stack * incur costs and instability and yes probably a good deal of security flaws to no good end.
- marshray 15y ago
  Look how a DNS name is normally resolved in code: by calling gethostbyname(name). Look how the return value of that call is handled: either the struct hostent it returns is NULL, in which case "host not found", or it's non-NULL, in which case the domain name is good. Where's the error channel? Don't forget the influence of Mozilla, Google, Microsoft, and Apple. While they may not own even the majority of the lines of code, the code they do own is disproportionately visible. Some of their stuff actually does its own name resolution, or even provides the implementation for a whole operating system. I believe some of them are shipping some actual DNSSEC client code today. Combine that with the work done by ISC and this thing isn't exactly alone whistling in the wind. There are DNSSEC advocates --- presumably none of whom have shipped a product in C before --- who talk as if this is a minor detail. Hmm, well Paul Vixie counts at least double in my book. Isn't it the same deal for DNS? Aren't we talking about either forklifting out or breaking huge amounts of deployed code? Sure, it will probably take 10 years before the absence of DNSSEC data can be interpreted as a name resolution failure. But technology can move a lot faster now that MS IE and Windows doesn't have 90% market share on the client side anymore.
  - tptacek 15y ago
    I'm not talking about Paul Vixie.
    - marshray 15y ago
      But there's only so much hand-picking of your examples that you can get away with. Your argument would be stronger if it accounted for more data points.
      - tptacek 15y ago
        I'm sorry, I didn't mean to be so terse. I just wanted to make it clear that I was not in that instance sniping at Paul Vixie.
- marshray 15y ago

tptacek 15y ago

DNSSEC advocates (not saying you're one) tend to talk about the idea of cryptographic authentication of DNS records as if it were free. But it's not free. It will cost many tens of millions of dollars. It will contribute to the instability of the Internet as a whole as well-meaning but necessarily inexpert administrators misconfigure their zones. And because DNS is at a lower layer of the stack than TLS, those failures will be more severe. For instance, read any tutorial on socket programming, or browse socket code on Github or Google Code Search. Look how a DNS name is normally resolved in code: by calling gethostbyname(name). Look how the return value of that call is handled: either the struct hostent it returns is NULL, in which case "host not found", or it's non-NULL, in which case the domain name is good. Where's the error channel? There are DNSSEC advocates --- presumably none of whom have shipped a product in C before --- who talk as if this is a minor detail. But look at Daniel J. Bernstein's "ipv6mess" article: http://cr.yp.to/djbdns/ipv6mess.html http://cr.yp.to/djbdns/ipv6mess.html How do we reach the magic moment? How do we teach every server on the Internet to talk to clients on public IPv6 addresses? How do we teach every client on the Internet to talk to servers on public IPv6 addresses? Answer: We go through every place that 4-byte IPv4 addresses appear, and allow 16-byte IPv6 addresses in the same place. Isn't it the same deal for DNS? Aren't we talking about either forklifting out or breaking huge amounts of deployed code? And to what end? DNSSEC doesn't solve the PKI problem we have on the Internet. When people in the Czech Republic go to Google, aren't they often going to GOOGLE.CZ? When people in Italy go to Amazon, don't they go to AMAZON.IT? Who controls .CZ? .IT? .COM? Certainly not Amazon and Google. What we have on the Internet is a failure of security policy. It's a human factors problem and a UX problem, not a failure of the core Internet protocols. By acting like a band-aid on those core protocols is going to fix the problem, we: * defer the real solution to the problem for another 10 years while we wait-and-see whether DNSSEC helps (hint: it won't really) * make it even harder to apply UX solutions to the problem by pushing the decisions that need to be made further down the stack * incur costs and instability and yes probably a good deal of security flaws to no good end.

marshray 15y ago
Look how a DNS name is normally resolved in code: by calling gethostbyname(name). Look how the return value of that call is handled: either the struct hostent it returns is NULL, in which case "host not found", or it's non-NULL, in which case the domain name is good. Where's the error channel? Don't forget the influence of Mozilla, Google, Microsoft, and Apple. While they may not own even the majority of the lines of code, the code they do own is disproportionately visible. Some of their stuff actually does its own name resolution, or even provides the implementation for a whole operating system. I believe some of them are shipping some actual DNSSEC client code today. Combine that with the work done by ISC and this thing isn't exactly alone whistling in the wind. There are DNSSEC advocates --- presumably none of whom have shipped a product in C before --- who talk as if this is a minor detail. Hmm, well Paul Vixie counts at least double in my book. Isn't it the same deal for DNS? Aren't we talking about either forklifting out or breaking huge amounts of deployed code? Sure, it will probably take 10 years before the absence of DNSSEC data can be interpreted as a name resolution failure. But technology can move a lot faster now that MS IE and Windows doesn't have 90% market share on the client side anymore.
- tptacek 15y ago
  I'm not talking about Paul Vixie.
  - marshray 15y ago
    But there's only so much hand-picking of your examples that you can get away with. Your argument would be stronger if it accounted for more data points.
    - tptacek 15y ago
      I'm sorry, I didn't mean to be so terse. I just wanted to make it clear that I was not in that instance sniping at Paul Vixie.
marshray 15y ago