6 ms·

The blockchain, on the other hand, would: https://github.com/okTurtles/dnschain/blob/master/README.md#DNSChain https://github.com/okTurtles/dnschain/blob/maste

The blockchain, on the other hand, would: https://github.com/okTurtles/dnschain/blob/master/README.md#DNSChain https://github.com/okTurtles/dnschain/blob/master/README.md#...

itistoday2 12y ago
> DNSSEC does one task extremely well – but it does only this one task: DNSSEC ensures that the information the operator of a domain[..] put into DNS is the exact same information that a user gets out of DNS when they request info for a domain. Even this is not true. DNSSEC is an abysmal protocol. To quote from [1]: DNSSEC suggests a complicated mechanism to essentially re-create many of the same problems with X509 and CAs in DNS itself, by providing a chain of trust to untrustworthy entities. Its intended goal is to secure DNS and thereby assure clients that when they ask for apple.com, they are actually visiting apple.com. This proposal does not protect against MITM attacks [2]. It suffers from extreme and unnecessary complexity, a systemic fault that's antithetical to secure systems. See also this list of resources on why DNSSEC is considered harmful [3]. [1] http://okturtles.com/#oktvs http://okturtles.com/#oktvs [2] http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/ http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authe... [3] http://ianix.com/pub/dnssec-outages.html http://ianix.com/pub/dnssec-outages.html
- danyork 12y ago
  I'm a bit confused by the text you quote. DNSSEC does protect against MITM attacks. That is specifically what it is designed to do. Unless I am missing something (which could be), the article you reference as "[2]" does not seem to support the idea that DNSSEC doesn't protect against MITM attacks. The mentions specifically how DNSSEC and DANE can protect against those attacks, although the article then discusses the author's issues with trusting the parties involved in the chain of trust. For my part, I like the mechanism provided by DANE/DNSSEC because it puts me, as the DNS operator, in control of what TLS cert I want to publish. I can publish my own self-signed cert. I can publish a CA-signed cert (or a fingerprint). I can say that I only support TLS certs from a specific CA. I can designate my own trust anchor for the TLS certs coming from my site. I can publish those certs (or fingerprints) in TLSA records and have them then validated up the global chain of trust. I like how the system is put together. I also like that there are other systems out there like okTurtles and Convergence looking at other alternative mechanisms for securing naming. It's good to have many different systems that in the end can lead to a more secure Internet.
  - tptacek 12y ago
    DNSSEC merely attempts to protect against one MITM attack out of many many possible MITM attacks. In particular: DNSSEC doesn't even protect against DNS-based MITM attacks between browsers and DNS servers. DANE does not put you as the DNS operator in control of what TLS cert you want to publish (TACK would do that, without requiring any change to the DNS hierarchy whatsoever.) Rather, DNSSEC adds you to a larger set of people who would have the ability to govern what TLS cert applies to your domain; everyone on the DNS hierarchy back up to the root would effectively have the same ability. In a DNSSEC/DANE world, if you have a .LY name, the government of Libya would have a say in what your TLS certs were. How could that possibly be a win?
    - xorcist 12y ago
      If you have a Libyan domain name, the entity responsible for Libyan domain names can also transfer or shut down your domain. What does that have to do with DNSSEC? Nothing. With DANE you trade a model where 300 CAs around the world each acting alone have the ability to falsify your certificate, to one where you and your top domain do. That's a big win in every which way you look at it. (It is also worth nothing that control over the domain name implies the power to generate valid certificates not only in DANE but also in today's CA model and most of the competing systems.) TACK and other systems may or may not help. We don't know until it has been throughly peer reviewed. Most models like it turned out to be vulnerable to a Sybil attack, or be based on plain TOFU. DNS-based MITM attacks between clients and validators is a red herring. The standard has assumed local validation for many years now.
    - danyork 12y ago
      > In a DNSSEC/DANE world, if you have a .LY name, the government of Libya would have a say in what your TLS certs were. Please explain to me how this would be possible? - I sign my .LY domain with DNSSEC and create the appropriate DNSKEY and RRSIG records. - I create a DS record with a fingerprint of my DNSKEY and via my registrar (typically) upload this DS record to the TLD registry (.LY in this case). - Additionally, I create a TLSA record in my zone that holds my TLS cert and sign that with my key (creating the associated RRSIG record). When someone is querying DNS using a DNSSEC-validating DNS resolver, the resolver: ---- 1. Gets my DNS records (A, AAAA, MX, TLSA, whatever) from the authoritative name server for my domain (let's assume I operate it), along with the associated RRSIG and DNSKEY records. 2. Gets my DS record from the .LY registry, along with the RRSIG and the DNSKEY for the .LY registry. 3. Gets the DS record for .LY from the root zone, along with the RRSIG and the DNSKEY for the root zone. 4. Presumably has the root's trust anchor already stored. 5. Validates that my DNSKEY has the same fingerprint as that in the DS record received from the .LY registry - and walks back up the chain of trust to ensure that all DS records and DNSKEYs match. ---- Where in there can the government of Libya have a say in what TLS certs I offer? The best I could see is that the operator of the .LY registry could choose to modify or remove my DS record, which would then mean that my domain would fail DNSSEC validation. But the TLSA record is still coming from my site. All the .LY registry can do is potentially remove the link to the chain of trust. I really would like to know if I am missing something here.
dsl 12y ago
If we used a blockchain based DNS system, we would never have this problem in the first place because we would be unable to take down malicious domains.
- itistoday2 12y ago
  That is a good thing. No need to take down a malicious domain name, just like malware, add it to a blacklist (Google's Chrome already does this).
  - sp332 12y ago
    The whole point of DNS is that we don't have to pass lists of domain names around, like we did before DNS.
    - itistoday2 12y ago
      Erm, one is a lookup table for arbitrary (and unknown) names, the other is a blacklist. These are two very different things (the latter is perfectly practical and manageable).
      - sp332 12y ago
        But why wouldn't a blacklist of people trying to game the system be unmanageably huge?
        itistoday2 12y ago
        It could be "unmanageably huge" for clients, just like the blockchain itself is unmanageably huge for clients. This is the reason DNSChain is designed the way it is (having a personal, dedicated server to store the blockchain for "groups of friends"), thus allowing many client devices to send it arbitrary queries.
        AnthonyMouse 12y ago
        > But why wouldn't a blacklist of people trying to game the system be unmanageably huge? First, you don't have to leave every entry on the list until the end of time. At some point (possibly as a result of the domain being on the blacklist) the attacker is going to discontinue using it and it could then be removed. Second, you don't have to store the blacklist on every client device. You could even just integrate it with the DNS. If you want to know if foo.com is on the blacklist, you do a lookup for foo.com.blacklist.google.com and if that resolves then it's blacklisted. If you don't trust Google to maintain the blacklist then you change a setting and your computer looks up foo.com.blacklist.microsoft.com or foo.com.blacklist.spamhaus.org or whatever else instead. The point is to decentralize the decision of who maintains the blacklist, so that users can stop using a blacklist if its maintainer makes unpopular decisions.

The blockchain, on the other hand, would: https://github.com/okTurtles/dnschain/blob/master/README.md#DNSChain https://github.com/okTurtles/dnschain/blob/master/README.md#...

itistoday2 12y ago

> DNSSEC does one task extremely well – but it does only this one task: DNSSEC ensures that the information the operator of a domain[..] put into DNS is the exact same information that a user gets out of DNS when they request info for a domain. Even this is not true. DNSSEC is an abysmal protocol. To quote from [1]: DNSSEC suggests a complicated mechanism to essentially re-create many of the same problems with X509 and CAs in DNS itself, by providing a chain of trust to untrustworthy entities. Its intended goal is to secure DNS and thereby assure clients that when they ask for apple.com, they are actually visiting apple.com. This proposal does not protect against MITM attacks [2]. It suffers from extreme and unnecessary complexity, a systemic fault that's antithetical to secure systems. See also this list of resources on why DNSSEC is considered harmful [3]. [1] http://okturtles.com/#oktvs http://okturtles.com/#oktvs [2] http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/ http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authe... [3] http://ianix.com/pub/dnssec-outages.html http://ianix.com/pub/dnssec-outages.html

danyork 12y ago
I'm a bit confused by the text you quote. DNSSEC does protect against MITM attacks. That is specifically what it is designed to do. Unless I am missing something (which could be), the article you reference as "[2]" does not seem to support the idea that DNSSEC doesn't protect against MITM attacks. The mentions specifically how DNSSEC and DANE can protect against those attacks, although the article then discusses the author's issues with trusting the parties involved in the chain of trust. For my part, I like the mechanism provided by DANE/DNSSEC because it puts me, as the DNS operator, in control of what TLS cert I want to publish. I can publish my own self-signed cert. I can publish a CA-signed cert (or a fingerprint). I can say that I only support TLS certs from a specific CA. I can designate my own trust anchor for the TLS certs coming from my site. I can publish those certs (or fingerprints) in TLSA records and have them then validated up the global chain of trust. I like how the system is put together. I also like that there are other systems out there like okTurtles and Convergence looking at other alternative mechanisms for securing naming. It's good to have many different systems that in the end can lead to a more secure Internet.
- tptacek 12y ago
  DNSSEC merely attempts to protect against one MITM attack out of many many possible MITM attacks. In particular: DNSSEC doesn't even protect against DNS-based MITM attacks between browsers and DNS servers. DANE does not put you as the DNS operator in control of what TLS cert you want to publish (TACK would do that, without requiring any change to the DNS hierarchy whatsoever.) Rather, DNSSEC adds you to a larger set of people who would have the ability to govern what TLS cert applies to your domain; everyone on the DNS hierarchy back up to the root would effectively have the same ability. In a DNSSEC/DANE world, if you have a .LY name, the government of Libya would have a say in what your TLS certs were. How could that possibly be a win?
  - xorcist 12y ago
    If you have a Libyan domain name, the entity responsible for Libyan domain names can also transfer or shut down your domain. What does that have to do with DNSSEC? Nothing. With DANE you trade a model where 300 CAs around the world each acting alone have the ability to falsify your certificate, to one where you and your top domain do. That's a big win in every which way you look at it. (It is also worth nothing that control over the domain name implies the power to generate valid certificates not only in DANE but also in today's CA model and most of the competing systems.) TACK and other systems may or may not help. We don't know until it has been throughly peer reviewed. Most models like it turned out to be vulnerable to a Sybil attack, or be based on plain TOFU. DNS-based MITM attacks between clients and validators is a red herring. The standard has assumed local validation for many years now.
  - danyork 12y ago
    > In a DNSSEC/DANE world, if you have a .LY name, the government of Libya would have a say in what your TLS certs were. Please explain to me how this would be possible? - I sign my .LY domain with DNSSEC and create the appropriate DNSKEY and RRSIG records. - I create a DS record with a fingerprint of my DNSKEY and via my registrar (typically) upload this DS record to the TLD registry (.LY in this case). - Additionally, I create a TLSA record in my zone that holds my TLS cert and sign that with my key (creating the associated RRSIG record). When someone is querying DNS using a DNSSEC-validating DNS resolver, the resolver: ---- 1. Gets my DNS records (A, AAAA, MX, TLSA, whatever) from the authoritative name server for my domain (let's assume I operate it), along with the associated RRSIG and DNSKEY records. 2. Gets my DS record from the .LY registry, along with the RRSIG and the DNSKEY for the .LY registry. 3. Gets the DS record for .LY from the root zone, along with the RRSIG and the DNSKEY for the root zone. 4. Presumably has the root's trust anchor already stored. 5. Validates that my DNSKEY has the same fingerprint as that in the DS record received from the .LY registry - and walks back up the chain of trust to ensure that all DS records and DNSKEYs match. ---- Where in there can the government of Libya have a say in what TLS certs I offer? The best I could see is that the operator of the .LY registry could choose to modify or remove my DS record, which would then mean that my domain would fail DNSSEC validation. But the TLSA record is still coming from my site. All the .LY registry can do is potentially remove the link to the chain of trust. I really would like to know if I am missing something here.

dsl 12y ago

If we used a blockchain based DNS system, we would never have this problem in the first place because we would be unable to take down malicious domains.

itistoday2 12y ago
That is a good thing. No need to take down a malicious domain name, just like malware, add it to a blacklist (Google's Chrome already does this).
- sp332 12y ago
  The whole point of DNS is that we don't have to pass lists of domain names around, like we did before DNS.
  - itistoday2 12y ago
    Erm, one is a lookup table for arbitrary (and unknown) names, the other is a blacklist. These are two very different things (the latter is perfectly practical and manageable).
    - sp332 12y ago
      But why wouldn't a blacklist of people trying to game the system be unmanageably huge?
      - itistoday2 12y ago
        It could be "unmanageably huge" for clients, just like the blockchain itself is unmanageably huge for clients. This is the reason DNSChain is designed the way it is (having a personal, dedicated server to store the blockchain for "groups of friends"), thus allowing many client devices to send it arbitrary queries.
      - AnthonyMouse 12y ago
        > But why wouldn't a blacklist of people trying to game the system be unmanageably huge? First, you don't have to leave every entry on the list until the end of time. At some point (possibly as a result of the domain being on the blacklist) the attacker is going to discontinue using it and it could then be removed. Second, you don't have to store the blacklist on every client device. You could even just integrate it with the DNS. If you want to know if foo.com is on the blacklist, you do a lookup for foo.com.blacklist.google.com and if that resolves then it's blacklisted. If you don't trust Google to maintain the blacklist then you change a setting and your computer looks up foo.com.blacklist.microsoft.com or foo.com.blacklist.spamhaus.org or whatever else instead. The point is to decentralize the decision of who maintains the blacklist, so that users can stop using a blacklist if its maintainer makes unpopular decisions.