6 ms·

Introducing the dotDNS metaTLD

76 points by Riseed 13y ago

nwh 13y ago
Namecoin unfortunately does not scale. You can't have lite clients, just an ever growing multi gigabyte database on every device you wish to use it on. Relying on a remote party to securely store and relay the blockchain to you is foolhardy, at best you're trusting a remote DNS server that can be MITM'd itself (the dotDNS system doesn't provide signing requests only encrypting). It's a nice idea but inherently unusable in almost any circumstance.
- itistoday2 13y ago
  This does scale, and lite clients are not being proposed here. To use this, your phone/computer doesn't need to run any type of node to communicate with the blockchain. Instead, all of that is done for you by your chosen DNSChain server.
  - nwh 13y ago
    > This does scale, and lite clients are not being proposed here. The first part of this document tells me that a local daemon communicated with Namecoin, ergo the system is dependent on having it running locally for anything approaching security. > Instead, all of that is done for you by your chosen DNSChain server. That's just it, why would I ever trust a remote resolver? There's two public resolvers listed on the homepage of the site, one is doing resolution in the clear and the "encrypted" one has no listed public key to verify that again there's no MITM. None of this is filling me with confidence and we haven't even asked who is running the things yet.
    - wyager 13y ago
      At least this system gives you the option of security. At worst, it's just as good as the current DNS system.
      - richardwhiuk 13y ago
        No, it gives you the option of a different server that the NSA has also compromised. There's is no way to square the circle here - Zooko's triangle [1] guarantees that you can't have a decentralized system with memorable secure names. See Dan Kaminsky's analysis of Aaron's system (which was implemented by NameCoin. [2] 1: https://en.wikipedia.org/wiki/Zooko%27s_triangle https://en.wikipedia.org/wiki/Zooko%27s_triangle 2: http://dankaminsky.com/2011/01/13/spelunk-tri/ http://dankaminsky.com/2011/01/13/spelunk-tri/
        hueving 13y ago
        Zooko's triangle doesn't guarantee anything. It was proven to be false. Read your own link.
        kalleboo 13y ago
        I just read that rebuttal link, and it predates Namecoin and it looks like things have changed quite a lot since the original proposal - including a 250 day expiration date and more importantly, Bitcoin-style block mining to do tiebreaking on registration races to decide what the truth is. Have there been any successful attacks of the type outlined in the rebuttal made on Bitcoin or Namecoin?
        wyager 13y ago
        If you have a full desktop PC, you can run a full namecoin client and get a DNS that it's non-trivial for the NSA to compromise.
    - itistoday2 13y ago
      > Correct me if I'm wrong, but this looks as if it's just a system to present blockchain data to normal clients using a pseudo-tld DNS proxy. That's about right, I think. > That's just it, why would I ever trust a remote resolver? You trust yourself right? The docs emphasize in multiple locations that you should be the one who is running the resolver. And if you don't know how, you can use a friend's while you're learning or others are making it easy for you to have your own. > the "encrypted" one has no listed public key to verify that again there's no MITM. It does, click on the IP and the public key is listed there in a gist, along with the command to use it with dnscrypt-proxy. > They promise resolution will be signed by the server some day, but it's not a feature enabled right now. It's not like it's difficult to implement this. I could do it in a couple of hours, but I came to a stopping point with the code and began focusing on community building for a bit. Don't worry, it's coming real soon, and you're welcome to implement it yourself and submit a pull request if you can't wait. :) The point is that this approach works.
      - nwh 13y ago
        > It does, click on the IP and the public key is listed there in a gist, along with the command to use it with dnscrypt-proxy. You're right, github must have hiccuped before. When I looked at that before it was a blank document. I assumed it was a placeholder because the client didn't support any sort of request signing yet. (Sorry for editing my post out from under you, it wasn't intentional)
    - mediocregopher 13y ago
      In my mind it could be something run on a local lan, or at the organization or neighborhood ISP level. In those cases there is still a question of how trustworthy those sources are. But there is also a reduction in the ability to compromise many connections. An attacker targeting a specific computer or person or organization still has an avenue, but there is much less room for compromising the entire scheme as a whole (of which there is plenty of room currently). The solution as presented doesn't solve ALL of our problems, but solutions rarely do, and it's not reasonable to expect them to. But it does solve SOME, and doesn't present any new ones (although I expect to eat my words as I type that). Progress is progress, even if it doesn't get us the full mile. As for trusting those writing this particular software, we don't really have to trust them, we simply have to trust the code.
- MWil 13y ago
  it does say any block chain can be used
  - nwh 13y ago
    To what end? You could abusively embed data in the Bitcoin blockchain (20GB), or use the Namecoin blockchain, or any multitude of altcoins with useless security that nobody has even heard of before. The end result is always the same; you can prove data exists but you can't trustlessly prove it hasn't changed without the entire blockchain.
    - itistoday2 13y ago
      > The end result is always the same; you can prove data exists but you can't trustlessly prove it hasn't changed without the entire blockchain. This project (DNSChain), uses the entire blockchain, so it's all good. And no, you don't need to store it on your phone as has been explained in other comments here, on the blog, and on the github page.
- bachback 13y ago
  there's plenty of solutions which apply to bitcoin as well.
- indolering 13y ago
  Namecoin DOES scale, you can have lite clients, and note that dotDNS and OkTurtles are not official Namecoin projects. The developer doesn't really understand what he is talking about when it comes to the blockchain and he misrepresents his work as being fundamentally different than what a CA offers. He honestly thinks everyone will setup their own DNSChain on top of a Namecoin install.
chimeracoder 13y ago
> dot-DNS makes secure JavaScript apps possible > today’s JavaScript apps are at the mercy of the security provided by web browsers, which are incapable of distinguishing a secure SSL/TLS connection from one that’s being man-in-the-middle‘d (MITM) by an actor “with a privileged network position.” This section title makes no sense. There are lot of reasons that Javascript is bad for cryptographic use (which have been enumerated at length by others with far more experience in the field, like tptacek). But this isn't really one of them - or at least, it's not specific to Javascript. Any application that makes an HTTP(s) connection is incapable of distinguishing between one that is secure with one that is being MITMed - that's the definition of an MITM attack. Certificate pinning (which is good) is simply a way of making it harder for a connection to be MITMed. If browser has pinned the certificate for a particular website, the only way to MITM it is to compromise the actual private key itself, and use that to fake a secure connection. (This is of course not what people usually mean when they talk about MITM attacks, but it fits the same basic structure as one).
- pera 13y ago
  > This section title makes no sense. I agree > There are lot of reasons that Javascript is bad for cryptographic use Wrong. Javascript is a language, the problem is the platform: client-side scripting is dangerous, but add-on or server-side through Node.js could be fine.
  - hdevalence 13y ago
    The aforementioned article discusses why there are problems with Javascript itself, e.g., the difficulty in protecting against timing attacks.
    - pera 13y ago
      Yet not every cryptosystem is affected by timing attacks.
- cbhl 13y ago
  While there are arguments to be made for and against having secure DNS infrastructure (just look up DNSSEC), I really don't think that having trusted DNS would remotely make a browser capable of 'distinguishing a secure SSL/TLS connection from one that’s being man-in-the-middle‘d (MITM) by an actor “with a privileged network position.”' Even if you did know a trusted IP address, how do you know the packets aren't being sent by pf, or iptables, or ARP spoofing to a logging squid proxy? This almost makes me cringe as much as draft-loreto-httpbis-trusted-proxy20-01.
rsync 13y ago
I'm very interested in this project. However, the first thing I think of when I see: "We’ve taken several important steps on the road to making “NSA-proof communication” on your favorite websites possible." is that a lot of use cases involve mobile phones (of course) which have two other computers[1] inside of them that you have no control over and are regularly used to manipulate[2] your android/ios environment out from under you. I love to see these pieces coming together to form a more secure ecosystem, but it's really one step forward and two steps back as long as we don't have an open baseband and sim card OS, etc. [1] the baseband processor and the SIM card [2] OTA updates
- higherpurpose 13y ago
  The OTA updates one is such a tricky issue. What's more important? Not being able to fix bugs in hundreds of millions of devices for a long time (or at all), which NSA is going to use and abuse anyway, or worrying that one vendor will try to push an NSA backdoor to hundreds of millions of devices? I think the best compromise for that is to have OTA updates but the source of the software being upgraded needs to be open source, so at least there's a disincentive to backdoor it and also the possibility of finding the backdoor inside the new update. As for the baseband processor, we need to keep poking at Qualcomm and others to open source their modem firmware, and then vote with your wallet. Getting a SIM card with an open source OS is probably going to take a while, although Google is in a very good position to push for that right now, since their OS is so dominant in the mobile market, so it's probably Google the one we need to nag to get it.
tptacek 13y ago
Certificate pinning cannot stop this type of mass-surveillance. It is a band-aid that some companies use to mitigate the problem for their specific applications. PKP is obviously a band-aid, and nobody involved with it says otherwise; it's a static list delivered with browsers. But the idea of pinning scales just fine and isn't simply a band-aid. The TACK proposal allows every site to assert their own pins, and does in fact largely mitigate the risks of compromised certificate authority. https://tools.ietf.org/html/draft-perrin-tls-tack-02 https://tools.ietf.org/html/draft-perrin-tls-tack-02 It's disingenuous to argue that Google and Mozilla implement PKP simply to protect their own properties. They protect many properties other than their own.
- itistoday2 13y ago
  > It's disingenuous to argue that Google and Mozilla implement PKP simply to protect their own properties. The post didn't name specific companies or products, but on that note, is there a list of sites that Chrome and/or Firefox have pinned somewhere? I don't think TACK has been implemented in them. The thing with TACK is that it doesn't actually solve the key distribution problem. The draft itself states: TACK pins are easily shared between clients. For example, a TACK client may scan the internet to discover TACK pins, then publish these pins through some 3rd-party trust infrastructure for other clients to rely upon. Keywords: "some 3rd-party trust infrastructure" That is what DNSChain and the blockchain provides. It provides more than that though, and thus providing everything that TACK proposes too.
  - tptacek 13y ago
    This is a misrepresentation of TACK. TACK will ordinarily be deployed similarly to HSTS: it's a key continuity scheme, like SSH. It doesn't require a "third party trust infrastructure". But unlike the CA system, TACK also supports the notion of a third-party root; the EFF could run a site that would provide trustworthy pinned keys for arbitrary sites on the Internet, and you could subscribe to that site. Contrast to DNSChain, which requires that ordinary users trust a third-party server. DNSChain isn't going to happen.
    - 13y ago
hangonhn 13y ago
I've tried reading the site and even the blockchain article but I can't put the two together. How is blockchains being used to secure communications?
- itistoday2 13y ago
  They allow secure, distributed and decentralized public key distribution.
  - hangonhn 13y ago
    How? I understand how blockchains can be used to trace the history of transactions back to the root but I don't see how that can be used to do secure key distribution. Assuming everyone trusts the root block, how does that trust get transmitted down to subsequent blocks?
    - itistoday2 13y ago
      Read the links in the post and the website. Here's one of them that directly answers your question: http://www.aaronsw.com/weblog/squarezooko http://www.aaronsw.com/weblog/squarezooko
      - hangonhn 13y ago
        Every time I read an article by Swartz I feel our community' lost all over again. :-(
- al2o3cr 13y ago
  Assuming there aren't any more "any user can steal from any other user" bugs in Namecoin, here's some info on how it's intended to work: http://en.wikipedia.org/wiki/Namecoin http://en.wikipedia.org/wiki/Namecoin
- indolering 13y ago
  It isn't. He is stuffing information in the blockchain into a standard public-key crypto scheme. DNSChain is more secure in that you run your own certificate authority that happens to have it's trust root in Namecoin.
nieve 13y ago
Does anyone who's got some background with DNSSEC (https://en.wikipedia.org/wiki/Dnssec https://en.wikipedia.org/wiki/Dnssec) feel like comparing DNSChain to the basic idea of embedding certificates or signatures in authenticated DNS records? We've had a lot of different proposals for the latter over the years and my impression is their lack of adoption hasn't been because DNSSEC is fundamentally broken (though it is flawed in several ways). AFAICT it breaks down like this: Against DNSSEC + certificate records: 1) There's a centralized PKI administration issue, but less so than the current CA morass 2) Administrative/rubber hose/legal/monetary compromise of the DNS root administrators (currently US NTIA) would allow substitution of the TLD keys, but this would be blatantly obvious to every organization or individual paying attention 3) DNSSEC has some annoying properties with regard to name enumeration and such 4) Need to either use a primary resolver that supports DNSSEC (Google Public DNS and Comcast, among others) or do a separate query to one who does For: 5) Minimal extra infrastructure, already supported in some libraries 6) Extremely cacheable with low resource requirements (root & TLD keys, MRU/MFU certs) 7) No need to add a new dependency on a previously untrusted source of code and crypto data 8) As long as the parent TLD has deployed DNSSEC the organization only needs to get their key set up, add a theoretical cert record, and sign records as needed. I think issues 1 & 2 are at least as big a problem with DNSChain because in practice the hand-waving of how you pick a trusted DNSChain chain is ignoring a huge class of vulnerabilities. Issue 4 is still a win over implementing a large chunk of infrastructure or trusting okTurtles'. The "just use Javascript" bit seems to apply equally to either, though I guess the _query_ portion of DNSChain is relatively simple.
icantthinkofone 13y ago
Claims "NSA-proof communication" but what about KGB, MI5, BND, whatever the Chinese call themselves, and everyone else? They're all doing it, too. (Assuming you think they care about you at all.)

76 points by Riseed 13y ago

nwh 13y ago

Namecoin unfortunately does not scale. You can't have lite clients, just an ever growing multi gigabyte database on every device you wish to use it on. Relying on a remote party to securely store and relay the blockchain to you is foolhardy, at best you're trusting a remote DNS server that can be MITM'd itself (the dotDNS system doesn't provide signing requests only encrypting). It's a nice idea but inherently unusable in almost any circumstance.

itistoday2 13y ago
This does scale, and lite clients are not being proposed here. To use this, your phone/computer doesn't need to run any type of node to communicate with the blockchain. Instead, all of that is done for you by your chosen DNSChain server.
- nwh 13y ago
  > This does scale, and lite clients are not being proposed here. The first part of this document tells me that a local daemon communicated with Namecoin, ergo the system is dependent on having it running locally for anything approaching security. > Instead, all of that is done for you by your chosen DNSChain server. That's just it, why would I ever trust a remote resolver? There's two public resolvers listed on the homepage of the site, one is doing resolution in the clear and the "encrypted" one has no listed public key to verify that again there's no MITM. None of this is filling me with confidence and we haven't even asked who is running the things yet.
  - wyager 13y ago
    At least this system gives you the option of security. At worst, it's just as good as the current DNS system.
    - richardwhiuk 13y ago
      No, it gives you the option of a different server that the NSA has also compromised. There's is no way to square the circle here - Zooko's triangle [1] guarantees that you can't have a decentralized system with memorable secure names. See Dan Kaminsky's analysis of Aaron's system (which was implemented by NameCoin. [2] 1: https://en.wikipedia.org/wiki/Zooko%27s_triangle https://en.wikipedia.org/wiki/Zooko%27s_triangle 2: http://dankaminsky.com/2011/01/13/spelunk-tri/ http://dankaminsky.com/2011/01/13/spelunk-tri/
      - hueving 13y ago
        Zooko's triangle doesn't guarantee anything. It was proven to be false. Read your own link.
      - kalleboo 13y ago
        I just read that rebuttal link, and it predates Namecoin and it looks like things have changed quite a lot since the original proposal - including a 250 day expiration date and more importantly, Bitcoin-style block mining to do tiebreaking on registration races to decide what the truth is. Have there been any successful attacks of the type outlined in the rebuttal made on Bitcoin or Namecoin?
      - wyager 13y ago
        If you have a full desktop PC, you can run a full namecoin client and get a DNS that it's non-trivial for the NSA to compromise.
  - itistoday2 13y ago
    > Correct me if I'm wrong, but this looks as if it's just a system to present blockchain data to normal clients using a pseudo-tld DNS proxy. That's about right, I think. > That's just it, why would I ever trust a remote resolver? You trust yourself right? The docs emphasize in multiple locations that you should be the one who is running the resolver. And if you don't know how, you can use a friend's while you're learning or others are making it easy for you to have your own. > the "encrypted" one has no listed public key to verify that again there's no MITM. It does, click on the IP and the public key is listed there in a gist, along with the command to use it with dnscrypt-proxy. > They promise resolution will be signed by the server some day, but it's not a feature enabled right now. It's not like it's difficult to implement this. I could do it in a couple of hours, but I came to a stopping point with the code and began focusing on community building for a bit. Don't worry, it's coming real soon, and you're welcome to implement it yourself and submit a pull request if you can't wait. :) The point is that this approach works.
    - nwh 13y ago
      > It does, click on the IP and the public key is listed there in a gist, along with the command to use it with dnscrypt-proxy. You're right, github must have hiccuped before. When I looked at that before it was a blank document. I assumed it was a placeholder because the client didn't support any sort of request signing yet. (Sorry for editing my post out from under you, it wasn't intentional)
  - mediocregopher 13y ago
    In my mind it could be something run on a local lan, or at the organization or neighborhood ISP level. In those cases there is still a question of how trustworthy those sources are. But there is also a reduction in the ability to compromise many connections. An attacker targeting a specific computer or person or organization still has an avenue, but there is much less room for compromising the entire scheme as a whole (of which there is plenty of room currently). The solution as presented doesn't solve ALL of our problems, but solutions rarely do, and it's not reasonable to expect them to. But it does solve SOME, and doesn't present any new ones (although I expect to eat my words as I type that). Progress is progress, even if it doesn't get us the full mile. As for trusting those writing this particular software, we don't really have to trust them, we simply have to trust the code.
MWil 13y ago
it does say any block chain can be used
- nwh 13y ago
  To what end? You could abusively embed data in the Bitcoin blockchain (20GB), or use the Namecoin blockchain, or any multitude of altcoins with useless security that nobody has even heard of before. The end result is always the same; you can prove data exists but you can't trustlessly prove it hasn't changed without the entire blockchain.
  - itistoday2 13y ago
    > The end result is always the same; you can prove data exists but you can't trustlessly prove it hasn't changed without the entire blockchain. This project (DNSChain), uses the entire blockchain, so it's all good. And no, you don't need to store it on your phone as has been explained in other comments here, on the blog, and on the github page.
bachback 13y ago
there's plenty of solutions which apply to bitcoin as well.
indolering 13y ago
Namecoin DOES scale, you can have lite clients, and note that dotDNS and OkTurtles are not official Namecoin projects. The developer doesn't really understand what he is talking about when it comes to the blockchain and he misrepresents his work as being fundamentally different than what a CA offers. He honestly thinks everyone will setup their own DNSChain on top of a Namecoin install.

chimeracoder 13y ago

> dot-DNS makes secure JavaScript apps possible > today’s JavaScript apps are at the mercy of the security provided by web browsers, which are incapable of distinguishing a secure SSL/TLS connection from one that’s being man-in-the-middle‘d (MITM) by an actor “with a privileged network position.” This section title makes no sense. There are lot of reasons that Javascript is bad for cryptographic use (which have been enumerated at length by others with far more experience in the field, like tptacek). But this isn't really one of them - or at least, it's not specific to Javascript. Any application that makes an HTTP(s) connection is incapable of distinguishing between one that is secure with one that is being MITMed - that's the definition of an MITM attack. Certificate pinning (which is good) is simply a way of making it harder for a connection to be MITMed. If browser has pinned the certificate for a particular website, the only way to MITM it is to compromise the actual private key itself, and use that to fake a secure connection. (This is of course not what people usually mean when they talk about MITM attacks, but it fits the same basic structure as one).

pera 13y ago
> This section title makes no sense. I agree > There are lot of reasons that Javascript is bad for cryptographic use Wrong. Javascript is a language, the problem is the platform: client-side scripting is dangerous, but add-on or server-side through Node.js could be fine.
- hdevalence 13y ago
  The aforementioned article discusses why there are problems with Javascript itself, e.g., the difficulty in protecting against timing attacks.
  - pera 13y ago
    Yet not every cryptosystem is affected by timing attacks.
cbhl 13y ago
While there are arguments to be made for and against having secure DNS infrastructure (just look up DNSSEC), I really don't think that having trusted DNS would remotely make a browser capable of 'distinguishing a secure SSL/TLS connection from one that’s being man-in-the-middle‘d (MITM) by an actor “with a privileged network position.”' Even if you did know a trusted IP address, how do you know the packets aren't being sent by pf, or iptables, or ARP spoofing to a logging squid proxy? This almost makes me cringe as much as draft-loreto-httpbis-trusted-proxy20-01.

rsync 13y ago

I'm very interested in this project. However, the first thing I think of when I see: "We’ve taken several important steps on the road to making “NSA-proof communication” on your favorite websites possible." is that a lot of use cases involve mobile phones (of course) which have two other computers[1] inside of them that you have no control over and are regularly used to manipulate[2] your android/ios environment out from under you. I love to see these pieces coming together to form a more secure ecosystem, but it's really one step forward and two steps back as long as we don't have an open baseband and sim card OS, etc. [1] the baseband processor and the SIM card [2] OTA updates

higherpurpose 13y ago
The OTA updates one is such a tricky issue. What's more important? Not being able to fix bugs in hundreds of millions of devices for a long time (or at all), which NSA is going to use and abuse anyway, or worrying that one vendor will try to push an NSA backdoor to hundreds of millions of devices? I think the best compromise for that is to have OTA updates but the source of the software being upgraded needs to be open source, so at least there's a disincentive to backdoor it and also the possibility of finding the backdoor inside the new update. As for the baseband processor, we need to keep poking at Qualcomm and others to open source their modem firmware, and then vote with your wallet. Getting a SIM card with an open source OS is probably going to take a while, although Google is in a very good position to push for that right now, since their OS is so dominant in the mobile market, so it's probably Google the one we need to nag to get it.

tptacek 13y ago

Certificate pinning cannot stop this type of mass-surveillance. It is a band-aid that some companies use to mitigate the problem for their specific applications. PKP is obviously a band-aid, and nobody involved with it says otherwise; it's a static list delivered with browsers. But the idea of pinning scales just fine and isn't simply a band-aid. The TACK proposal allows every site to assert their own pins, and does in fact largely mitigate the risks of compromised certificate authority. https://tools.ietf.org/html/draft-perrin-tls-tack-02 https://tools.ietf.org/html/draft-perrin-tls-tack-02 It's disingenuous to argue that Google and Mozilla implement PKP simply to protect their own properties. They protect many properties other than their own.

itistoday2 13y ago
> It's disingenuous to argue that Google and Mozilla implement PKP simply to protect their own properties. The post didn't name specific companies or products, but on that note, is there a list of sites that Chrome and/or Firefox have pinned somewhere? I don't think TACK has been implemented in them. The thing with TACK is that it doesn't actually solve the key distribution problem. The draft itself states: TACK pins are easily shared between clients. For example, a TACK client may scan the internet to discover TACK pins, then publish these pins through some 3rd-party trust infrastructure for other clients to rely upon. Keywords: "some 3rd-party trust infrastructure" That is what DNSChain and the blockchain provides. It provides more than that though, and thus providing everything that TACK proposes too.
- tptacek 13y ago
  This is a misrepresentation of TACK. TACK will ordinarily be deployed similarly to HSTS: it's a key continuity scheme, like SSH. It doesn't require a "third party trust infrastructure". But unlike the CA system, TACK also supports the notion of a third-party root; the EFF could run a site that would provide trustworthy pinned keys for arbitrary sites on the Internet, and you could subscribe to that site. Contrast to DNSChain, which requires that ordinary users trust a third-party server. DNSChain isn't going to happen.
  - 13y ago

hangonhn 13y ago

I've tried reading the site and even the blockchain article but I can't put the two together. How is blockchains being used to secure communications?

itistoday2 13y ago
They allow secure, distributed and decentralized public key distribution.
- hangonhn 13y ago
  How? I understand how blockchains can be used to trace the history of transactions back to the root but I don't see how that can be used to do secure key distribution. Assuming everyone trusts the root block, how does that trust get transmitted down to subsequent blocks?
  - itistoday2 13y ago
    Read the links in the post and the website. Here's one of them that directly answers your question: http://www.aaronsw.com/weblog/squarezooko http://www.aaronsw.com/weblog/squarezooko
    - hangonhn 13y ago
      Every time I read an article by Swartz I feel our community' lost all over again. :-(
al2o3cr 13y ago
Assuming there aren't any more "any user can steal from any other user" bugs in Namecoin, here's some info on how it's intended to work: http://en.wikipedia.org/wiki/Namecoin http://en.wikipedia.org/wiki/Namecoin
indolering 13y ago
It isn't. He is stuffing information in the blockchain into a standard public-key crypto scheme. DNSChain is more secure in that you run your own certificate authority that happens to have it's trust root in Namecoin.

nieve 13y ago

Does anyone who's got some background with DNSSEC (https://en.wikipedia.org/wiki/Dnssec https://en.wikipedia.org/wiki/Dnssec) feel like comparing DNSChain to the basic idea of embedding certificates or signatures in authenticated DNS records? We've had a lot of different proposals for the latter over the years and my impression is their lack of adoption hasn't been because DNSSEC is fundamentally broken (though it is flawed in several ways). AFAICT it breaks down like this: Against DNSSEC + certificate records: 1) There's a centralized PKI administration issue, but less so than the current CA morass 2) Administrative/rubber hose/legal/monetary compromise of the DNS root administrators (currently US NTIA) would allow substitution of the TLD keys, but this would be blatantly obvious to every organization or individual paying attention 3) DNSSEC has some annoying properties with regard to name enumeration and such 4) Need to either use a primary resolver that supports DNSSEC (Google Public DNS and Comcast, among others) or do a separate query to one who does For: 5) Minimal extra infrastructure, already supported in some libraries 6) Extremely cacheable with low resource requirements (root & TLD keys, MRU/MFU certs) 7) No need to add a new dependency on a previously untrusted source of code and crypto data 8) As long as the parent TLD has deployed DNSSEC the organization only needs to get their key set up, add a theoretical cert record, and sign records as needed. I think issues 1 & 2 are at least as big a problem with DNSChain because in practice the hand-waving of how you pick a trusted DNSChain chain is ignoring a huge class of vulnerabilities. Issue 4 is still a win over implementing a large chunk of infrastructure or trusting okTurtles'. The "just use Javascript" bit seems to apply equally to either, though I guess the _query_ portion of DNSChain is relatively simple.

icantthinkofone 13y ago

Claims "NSA-proof communication" but what about KGB, MI5, BND, whatever the Chinese call themselves, and everyone else? They're all doing it, too. (Assuming you think they care about you at all.)