7 ms·

The DNS-Based Authentication of Named Entities (DANE) TLS Protocol

47 points by garaetjjte 10y ago

eloy 10y ago
rant about DANE from tptacek incoming http://sockpuppet.org/blog/2015/01/15/against-dnssec/ http://sockpuppet.org/blog/2015/01/15/against-dnssec/ I don't have a strong opinion on DNSSEC myself, but I agree with him that DANE is a bad replacement for standard TLS connections. DNSSEC is by far not the best security protocol ever designed, but it can protect to some threats, like cache poisoning.
- tptacek 10y ago
  Honestly, while I do truly believe that DANE is an insane response to the Snowden disclosures that centralizes Internet trust and hands the keys over to the FVEY IC, that's not my biggest problem with DNSSEC. It's just the argument that I think has the strongest valence on HN. Most of that post isn't about NSA controlling the Internet. It's about what a mess DNSSEC is, and how little it does to protect anything on the Internet even in a universe where it's actually deployed.
  - 0x0 10y ago
    But in today's world where CAs issue certificates based on simple DNS A and MX record lookups for ownership verification, whoever controls the root zone or the relevant TLD zones can get "the keys" they want already.
    - deleted 10y ago
      [deleted]
    - deleted 10y ago
      [deleted]
    - tptacek 10y ago
      First, nobody believes any part of the FVEY IC can't already get TLS certificates. DNS spoofing? They've already got CA=YES certificates. Second, DNSSEC doesn't even prevent this attack! All it does is attempt to protect name lookups. SMTP itself doesn't magically become secure just because there was a signature on an A record. Finally, we're already doing something that meaningfully blunts this attack. No matter how the CA system is compromised, browsers still monitor certificate pins. When pins break, the CA associated with the malicious certificate gets reported. When that happens, as we've seen repeatedly, the CA gets penalized --- or put out of business entirely. Public key pinning, CT, and surveillance is actually making a dent in the Internet trust problem. DNSSEC is a charade --- or, I think, something worse than that: you can't simply "revoke" .COM.
      - 0x0 10y ago
        Maybe we could 1. take away all the existing CA=YES certificates 2. stop using SMTP for domain verification, and issue the certificate at the same place that a domain's NS records are set (i.e. in a domain registrar's control panel), preferably in way that clients won't accept certificates issued by unrelated (and there unauthorized) domain registrars. As I mentioned the other day, nobody is talking about revoking ".com". We'd have multiple registrars under ".com", and if one behaves badly, revoke that particular registrar. Also, if ".com" itself is out to spoof you, then you have already lost as a .com domain owner, so maybe we SHOULD revoke all of .com if proof of that surfaces, so that everyone will know that .com can't be trusted at all anymore.
        tptacek 10y ago
        Maybe we could actually fix the problem instead of just moving it around.
    - agwa 10y ago
      Verifying based on DNS records is only a baseline. CAs can and do require more. If you want higher security for your domain, you can: 1. Make business arrangements with a handful of CAs to require additional verification when issuing certificates for your domain. 2. Use public key pinning to restrict your domain to those CAs. 3. Monitor certificate transparency logs to ensure that your chosen CAs are only issuing authorized certificates, and that other CAs are not issuing certificates for your domain. (CT does not have full coverage yet, but it has already done more to improve PKI security than DNSSEC has.) If one of your chosen CAs violates your trust, you drop them like a hot potato. DNSSEC removes this agility, leaving you at the mercy of your registrar and every zone operator higher than you in the hierarchy.
      - Kadin 10y ago
        You're already at the mercy of every CA whose certificates are trusted by default by browsers. You can request additional verification, but that's not going to stop someone from turning the screws on a CA on the other side of the planet, whose certificates are nonetheless accepted-by-default by users' systems, and as long as they're not totally foolish in deploying that cert (i.e. it's used in targeted attacks only), you'd never see it via certificate transparency. (And yes, for the record, HPKP blunts the compromised-CA weapon somewhat, but adoption has been pretty crummy. IIRC the latest iOS Safari and IE don't support it at all.)
        tptacek 10y ago
        HPKP works no matter how many people adopt it. The most important sites on the Internet are all generally pinned (very few of them are DNSSEC-signed). Moreover, the surveillance aspect of HPKP doesn't require IE and Safari adoption. Chrome and Firefox are way more than substantial enough to make the risk of detection not worth the reward of trying to deploy a forged certificate. Note how many times in the past few years Google has slapped down CAs for "accidentally" issuing Google certificates.
        agwa 10y ago
        The end game for certificate transparency is that browsers will reject a certificate unless the server can prove that it has been submitted to at least two logs. In fact, as of the next version of Chrome, this will be required of all Symantec certificates due to their past misdeeds. The fact that HPKP and CT have not been fully adopted yet is not a good argument against them when the alternative under discussion is DNSSEC+DANE, which has seen even less adoption and doesn't even solve the problem.
  - garaetjjte 10y ago
    DNSSEC is Unnecessary All secure crypto on the Internet assumes that the DNS lookup from names to IP addresses are insecure. Yes, because without DNSSEC they ARE insecure. With DNSSEC, we can store data in DNS that requires security. (eg. certificates for https) DNSSEC is a Government-Controlled PKI [...] Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys. How is that diffirent from current CA system, where any CA can issue certificate for any domain? Not only Muammar Gaddafi controlled bit.ly TLS keys, but anyone who can force/exploit any CA to issue certificate for it. DNSSEC is Incomplete [...] In fact, it does nothing for any of the “last mile” of DNS lookups: the link between software and DNS servers. It’s a server-to-server protocol. If client software want to be sure that reply received from ISP provided server is legitimate, it must verify DNSSEC trust chain. Though, if single DNS server is fully trusted, there is RFC 7858: "Specification for DNS over Transport Layer Security (TLS)" DNSSEC is Unsafe Yes, I agree that these chained NSEC are stupid, but it is not critical problem. CloudFlare solved that by: "We return an answer that says, “sure, the name exists, but the type you asked for does not”. This allows us to return only one NSEC record in negative answers!" (https://blog.cloudflare.com/dnssec-done-right/ https://blog.cloudflare.com/dnssec-done-right/) DNSSEC is Cryptographically Weak That's only point with I agree.
    - tptacek 10y ago
      Yours is a rebuttal that literally leads off by suggesting we store certificates for HTTPS in a PKI that is --- not by innuendo, not by implication, not just as a consequence of how the real world works, but de jure, as labeled on the tin --- controlled at the top by world governments, most prominently those of the Five Eyes Intelligence Community. There's an FAQ, linked at the top of that post, which probably addresses any of the other arguments you'd try to raise here. DNSSEC is a failed project, and a dodged bullet.
    - icebraining 10y ago
      How is that diffirent from current CA system The current CA system is already in place; an alternative should be better in the goals we wish to achieve, otherwise why incur in the switching costs?
- amalcon 10y ago
  I'm of more or less the opposite opinion: DNSSEC overall is pretty terrible. DANE is possibly a slight improvement over the existing CA system for some threat models, though only very slight. That improvement is frequently zero depending on the chosen threat model, though I've yet to see a real-world scenario where it's worse. DNSSEC is a complicated proposal with basically no adoption that requires widespread adoption to accomplish anything. We've had much better (though still not perfect) ways to improve authority-resolver security for years (DJB's DNSCurve for example). Given this, its only purpose is to make DANE happen. That benefit is way below the cost (again, maybe actual zero benefit depending on your point of view). It may even have a negative benefit by delaying a switch to an actually-good solution once someone figures one out (which nobody has, quite yet).
nneonneo 10y ago
This RFC was proposed in 2012. It provides a simple way to place TLS server certs in DNS, in addition to or even in place of usual TLS certificate negotiation. In theory, it lets us even remove the TLS chain of trust in favor of the one provided by DNSSEC. However, it is obviously dependent on DNSSEC, and as the latter isn't quite ubiquitous yet, DANE cannot be widely deployed.
okket 10y ago
OpenSSL 1.1.0 gained support for DANE TLSA peer authentication. Obtaining and performing DNSSEC validation of TLSA records is the application's responsibility. The application provides the TLSA records of its choice to OpenSSL, and these are then used to authenticate the peer. The TLSA records need not even come from DNS. They can, for example, be used to implement local end-entity certificate or trust-anchor "pinning", where the "pin" data takes the form of TLSA records, which can augment or replace verification based on the usual WebPKI public certification authorities. [Viktor Dukhovni] Changelog: https://www.openssl.org/news/cl110.txt https://www.openssl.org/news/cl110.txt API: https://www.openssl.org/docs/manmaster/ssl/SSL_dane_enable.html https://www.openssl.org/docs/manmaster/ssl/SSL_dane_enable.h... The RFC for storing/lookup OpenPGP keys in DNS via DANE was published recently: "DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP" https://tools.ietf.org/html/rfc7929 https://tools.ietf.org/html/rfc7929 All documents from the DANE working group are here: https://datatracker.ietf.org/wg/dane/documents/ https://datatracker.ietf.org/wg/dane/documents/ Edit: Since there is lot of negativity towards DNSSEC here, please have a look at the following link, so you get both sides of the arguments http://blog.easydns.org/2015/08/06/for-dnssec/ http://blog.easydns.org/2015/08/06/for-dnssec/
tptacek 10y ago
For those unaware: DANE is a scheme whereby TLS certificates are stored in DNSSEC-signed DNS records. The conventional nerd wisdom is: this is fantastic, because it's a step towards replacing the totally broken CA system with something that technical people can take direct control over. I like that story too. Unfortunately, the conventional wisdom is totally wrong. DANE does not eliminate CAs. Even in a world where DANE is universally deployed in all browsers (no browser does it today --- and several tried, and then removed support), we will still have CAs. What DANE will give us is a bunch of new CAs: one for every TLD, and one at the root. Don't take my word for this: Adam Langley, TLS superhero of the Chromium team, wrote an excellent blog post explaining why. But it gets worse. Those new CAs DANE deployed? They are controlled overwhelmingly by world governments. The most popular DNS TLDs are all legally bound to the governments of the FVEY IC. Here again you don't have to take my word for it: all you have to do is look at what the DOJ did to file sharing sites by asserting its control of the DNS. Lots of things are happening behind the scenes to make the train wreck of Internet trust a little better: * CA certificates themselves are hurtling towards "free", especially now that we have Let's Encrypt * Major browsers are implementing HPKP and static key pinning, so that once you see a certificate for a pinned domain, your browser remembers and screams bloody murder if it changes unexpectedly. Someone who attempts to get a domain-validated certificate to hijack Google Mail will, in the best case, succeed only in getting the CA dumb enough to do that kicked out of the Chrome and Firefox root trust store. * Google and others are coordinating efforts to monitor certificate issuance, not just using certificate pins but also with initiatives like Certificate Transparency, which involves cooperation from CAs that Google has repeatedly shown willingness to require as a condition of being included in their trust store. DNSSEC is not one of those things. It's a broken protocol, an attempt to deploy decades-outmoded cryptography across the backbone of the Internet, and, in the very best case, a bit of security theater. This, to me, is one of the rare cases where I think random end users who aren't in the unofficial cabal of TLS library maintainers, ISP operators, or standards committee members can make a real difference in Internet security. Don't let people pretend that DNSSEC is a good thing just because the name ends in SEC. When you see people cheerleading DNSSEC deployments, challenge them. DNSSEC deployment is failing, and has been failing for something like 15 years now. Let's try to keep it that way!
- 10y ago
jakobdabo 10y ago
Is it an insane idea to incorporate the blockchain technology into the current PKI system so that every time a CA signs a key it must insert a new transaction into the blockchain which links it to the certificate? We could have a full, transparent and cryptographically secure certificate log.
- lziest 10y ago
  check out certificate transparency https://www.certificate-transparency.org/ https://www.certificate-transparency.org/
  - jakobdabo 10y ago
    That's not quite the same, but I just found this NeoDNS[0] proposal, and it seems to be just what I described. [0] https://rot256.io/post/neodns/ https://rot256.io/post/neodns/ edited: Apparently it was briefly discussed at HN only 2 days ago: https://news.ycombinator.com/item?id=12370146 https://news.ycombinator.com/item?id=12370146
- hannob 10y ago
  It's actually one of the few non-insane ideas about blockchains. But it has already been done as another commenter already posted.
- icebraining 10y ago
  That's called an hash chain[1], they've been around for a while. In my country, receipts systems are actually required to implement hash chaining to allow the authorities to detect "missing" receipts (for tax-avoidance control purposes). [1] https://en.wikipedia.org/wiki/Hash_chain https://en.wikipedia.org/wiki/Hash_chain
stephenr 10y ago
Whenever DANE comes up, DNSSEC in general comes up. Whenever DNSSEC comes up, a raft of people arrive to say "but this means the government will have complete control and can do what they want". The evidence of this actually being a reality is then given as the us government took down a known and acknowledged "piracy" site. A further example is given that e.g bit.ly would have been effectively controllable by Gadafi. First off: no one forced them to use the .ly domain. If you choose to use a country code domain you should be aware of the situation the controlling country is in. Second: if your only argument supporting the idea that democratic governments - even those as fucking ass backwards as the USA - will arbitrarily take control of your domain, is a file sharing site, I suggest you look for more evidence.

47 points by garaetjjte 10y ago

eloy 10y ago

rant about DANE from tptacek incoming http://sockpuppet.org/blog/2015/01/15/against-dnssec/ http://sockpuppet.org/blog/2015/01/15/against-dnssec/ I don't have a strong opinion on DNSSEC myself, but I agree with him that DANE is a bad replacement for standard TLS connections. DNSSEC is by far not the best security protocol ever designed, but it can protect to some threats, like cache poisoning.

tptacek 10y ago
Honestly, while I do truly believe that DANE is an insane response to the Snowden disclosures that centralizes Internet trust and hands the keys over to the FVEY IC, that's not my biggest problem with DNSSEC. It's just the argument that I think has the strongest valence on HN. Most of that post isn't about NSA controlling the Internet. It's about what a mess DNSSEC is, and how little it does to protect anything on the Internet even in a universe where it's actually deployed.
- 0x0 10y ago
  But in today's world where CAs issue certificates based on simple DNS A and MX record lookups for ownership verification, whoever controls the root zone or the relevant TLD zones can get "the keys" they want already.
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - tptacek 10y ago
    First, nobody believes any part of the FVEY IC can't already get TLS certificates. DNS spoofing? They've already got CA=YES certificates. Second, DNSSEC doesn't even prevent this attack! All it does is attempt to protect name lookups. SMTP itself doesn't magically become secure just because there was a signature on an A record. Finally, we're already doing something that meaningfully blunts this attack. No matter how the CA system is compromised, browsers still monitor certificate pins. When pins break, the CA associated with the malicious certificate gets reported. When that happens, as we've seen repeatedly, the CA gets penalized --- or put out of business entirely. Public key pinning, CT, and surveillance is actually making a dent in the Internet trust problem. DNSSEC is a charade --- or, I think, something worse than that: you can't simply "revoke" .COM.
    - 0x0 10y ago
      Maybe we could 1. take away all the existing CA=YES certificates 2. stop using SMTP for domain verification, and issue the certificate at the same place that a domain's NS records are set (i.e. in a domain registrar's control panel), preferably in way that clients won't accept certificates issued by unrelated (and there unauthorized) domain registrars. As I mentioned the other day, nobody is talking about revoking ".com". We'd have multiple registrars under ".com", and if one behaves badly, revoke that particular registrar. Also, if ".com" itself is out to spoof you, then you have already lost as a .com domain owner, so maybe we SHOULD revoke all of .com if proof of that surfaces, so that everyone will know that .com can't be trusted at all anymore.
      - tptacek 10y ago
        Maybe we could actually fix the problem instead of just moving it around.
  - agwa 10y ago
    Verifying based on DNS records is only a baseline. CAs can and do require more. If you want higher security for your domain, you can: 1. Make business arrangements with a handful of CAs to require additional verification when issuing certificates for your domain. 2. Use public key pinning to restrict your domain to those CAs. 3. Monitor certificate transparency logs to ensure that your chosen CAs are only issuing authorized certificates, and that other CAs are not issuing certificates for your domain. (CT does not have full coverage yet, but it has already done more to improve PKI security than DNSSEC has.) If one of your chosen CAs violates your trust, you drop them like a hot potato. DNSSEC removes this agility, leaving you at the mercy of your registrar and every zone operator higher than you in the hierarchy.
    - Kadin 10y ago
      You're already at the mercy of every CA whose certificates are trusted by default by browsers. You can request additional verification, but that's not going to stop someone from turning the screws on a CA on the other side of the planet, whose certificates are nonetheless accepted-by-default by users' systems, and as long as they're not totally foolish in deploying that cert (i.e. it's used in targeted attacks only), you'd never see it via certificate transparency. (And yes, for the record, HPKP blunts the compromised-CA weapon somewhat, but adoption has been pretty crummy. IIRC the latest iOS Safari and IE don't support it at all.)
      - tptacek 10y ago
        HPKP works no matter how many people adopt it. The most important sites on the Internet are all generally pinned (very few of them are DNSSEC-signed). Moreover, the surveillance aspect of HPKP doesn't require IE and Safari adoption. Chrome and Firefox are way more than substantial enough to make the risk of detection not worth the reward of trying to deploy a forged certificate. Note how many times in the past few years Google has slapped down CAs for "accidentally" issuing Google certificates.
      - agwa 10y ago
        The end game for certificate transparency is that browsers will reject a certificate unless the server can prove that it has been submitted to at least two logs. In fact, as of the next version of Chrome, this will be required of all Symantec certificates due to their past misdeeds. The fact that HPKP and CT have not been fully adopted yet is not a good argument against them when the alternative under discussion is DNSSEC+DANE, which has seen even less adoption and doesn't even solve the problem.
- garaetjjte 10y ago
  DNSSEC is Unnecessary All secure crypto on the Internet assumes that the DNS lookup from names to IP addresses are insecure. Yes, because without DNSSEC they ARE insecure. With DNSSEC, we can store data in DNS that requires security. (eg. certificates for https) DNSSEC is a Government-Controlled PKI [...] Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys. How is that diffirent from current CA system, where any CA can issue certificate for any domain? Not only Muammar Gaddafi controlled bit.ly TLS keys, but anyone who can force/exploit any CA to issue certificate for it. DNSSEC is Incomplete [...] In fact, it does nothing for any of the “last mile” of DNS lookups: the link between software and DNS servers. It’s a server-to-server protocol. If client software want to be sure that reply received from ISP provided server is legitimate, it must verify DNSSEC trust chain. Though, if single DNS server is fully trusted, there is RFC 7858: "Specification for DNS over Transport Layer Security (TLS)" DNSSEC is Unsafe Yes, I agree that these chained NSEC are stupid, but it is not critical problem. CloudFlare solved that by: "We return an answer that says, “sure, the name exists, but the type you asked for does not”. This allows us to return only one NSEC record in negative answers!" (https://blog.cloudflare.com/dnssec-done-right/ https://blog.cloudflare.com/dnssec-done-right/) DNSSEC is Cryptographically Weak That's only point with I agree.
  - tptacek 10y ago
    Yours is a rebuttal that literally leads off by suggesting we store certificates for HTTPS in a PKI that is --- not by innuendo, not by implication, not just as a consequence of how the real world works, but de jure, as labeled on the tin --- controlled at the top by world governments, most prominently those of the Five Eyes Intelligence Community. There's an FAQ, linked at the top of that post, which probably addresses any of the other arguments you'd try to raise here. DNSSEC is a failed project, and a dodged bullet.
  - icebraining 10y ago
    How is that diffirent from current CA system The current CA system is already in place; an alternative should be better in the goals we wish to achieve, otherwise why incur in the switching costs?
amalcon 10y ago
I'm of more or less the opposite opinion: DNSSEC overall is pretty terrible. DANE is possibly a slight improvement over the existing CA system for some threat models, though only very slight. That improvement is frequently zero depending on the chosen threat model, though I've yet to see a real-world scenario where it's worse. DNSSEC is a complicated proposal with basically no adoption that requires widespread adoption to accomplish anything. We've had much better (though still not perfect) ways to improve authority-resolver security for years (DJB's DNSCurve for example). Given this, its only purpose is to make DANE happen. That benefit is way below the cost (again, maybe actual zero benefit depending on your point of view). It may even have a negative benefit by delaying a switch to an actually-good solution once someone figures one out (which nobody has, quite yet).

nneonneo 10y ago

This RFC was proposed in 2012. It provides a simple way to place TLS server certs in DNS, in addition to or even in place of usual TLS certificate negotiation. In theory, it lets us even remove the TLS chain of trust in favor of the one provided by DNSSEC. However, it is obviously dependent on DNSSEC, and as the latter isn't quite ubiquitous yet, DANE cannot be widely deployed.

okket 10y ago

OpenSSL 1.1.0 gained support for DANE TLSA peer authentication. Obtaining and performing DNSSEC validation of TLSA records is the application's responsibility. The application provides the TLSA records of its choice to OpenSSL, and these are then used to authenticate the peer. The TLSA records need not even come from DNS. They can, for example, be used to implement local end-entity certificate or trust-anchor "pinning", where the "pin" data takes the form of TLSA records, which can augment or replace verification based on the usual WebPKI public certification authorities. [Viktor Dukhovni] Changelog: https://www.openssl.org/news/cl110.txt https://www.openssl.org/news/cl110.txt API: https://www.openssl.org/docs/manmaster/ssl/SSL_dane_enable.html https://www.openssl.org/docs/manmaster/ssl/SSL_dane_enable.h... The RFC for storing/lookup OpenPGP keys in DNS via DANE was published recently: "DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP" https://tools.ietf.org/html/rfc7929 https://tools.ietf.org/html/rfc7929 All documents from the DANE working group are here: https://datatracker.ietf.org/wg/dane/documents/ https://datatracker.ietf.org/wg/dane/documents/ Edit: Since there is lot of negativity towards DNSSEC here, please have a look at the following link, so you get both sides of the arguments http://blog.easydns.org/2015/08/06/for-dnssec/ http://blog.easydns.org/2015/08/06/for-dnssec/

tptacek 10y ago

For those unaware: DANE is a scheme whereby TLS certificates are stored in DNSSEC-signed DNS records. The conventional nerd wisdom is: this is fantastic, because it's a step towards replacing the totally broken CA system with something that technical people can take direct control over. I like that story too. Unfortunately, the conventional wisdom is totally wrong. DANE does not eliminate CAs. Even in a world where DANE is universally deployed in all browsers (no browser does it today --- and several tried, and then removed support), we will still have CAs. What DANE will give us is a bunch of new CAs: one for every TLD, and one at the root. Don't take my word for this: Adam Langley, TLS superhero of the Chromium team, wrote an excellent blog post explaining why. But it gets worse. Those new CAs DANE deployed? They are controlled overwhelmingly by world governments. The most popular DNS TLDs are all legally bound to the governments of the FVEY IC. Here again you don't have to take my word for it: all you have to do is look at what the DOJ did to file sharing sites by asserting its control of the DNS. Lots of things are happening behind the scenes to make the train wreck of Internet trust a little better: * CA certificates themselves are hurtling towards "free", especially now that we have Let's Encrypt * Major browsers are implementing HPKP and static key pinning, so that once you see a certificate for a pinned domain, your browser remembers and screams bloody murder if it changes unexpectedly. Someone who attempts to get a domain-validated certificate to hijack Google Mail will, in the best case, succeed only in getting the CA dumb enough to do that kicked out of the Chrome and Firefox root trust store. * Google and others are coordinating efforts to monitor certificate issuance, not just using certificate pins but also with initiatives like Certificate Transparency, which involves cooperation from CAs that Google has repeatedly shown willingness to require as a condition of being included in their trust store. DNSSEC is not one of those things. It's a broken protocol, an attempt to deploy decades-outmoded cryptography across the backbone of the Internet, and, in the very best case, a bit of security theater. This, to me, is one of the rare cases where I think random end users who aren't in the unofficial cabal of TLS library maintainers, ISP operators, or standards committee members can make a real difference in Internet security. Don't let people pretend that DNSSEC is a good thing just because the name ends in SEC. When you see people cheerleading DNSSEC deployments, challenge them. DNSSEC deployment is failing, and has been failing for something like 15 years now. Let's try to keep it that way!

10y ago

jakobdabo 10y ago

Is it an insane idea to incorporate the blockchain technology into the current PKI system so that every time a CA signs a key it must insert a new transaction into the blockchain which links it to the certificate? We could have a full, transparent and cryptographically secure certificate log.

lziest 10y ago
check out certificate transparency https://www.certificate-transparency.org/ https://www.certificate-transparency.org/
- jakobdabo 10y ago
  That's not quite the same, but I just found this NeoDNS[0] proposal, and it seems to be just what I described. [0] https://rot256.io/post/neodns/ https://rot256.io/post/neodns/ edited: Apparently it was briefly discussed at HN only 2 days ago: https://news.ycombinator.com/item?id=12370146 https://news.ycombinator.com/item?id=12370146
hannob 10y ago
It's actually one of the few non-insane ideas about blockchains. But it has already been done as another commenter already posted.
icebraining 10y ago
That's called an hash chain[1], they've been around for a while. In my country, receipts systems are actually required to implement hash chaining to allow the authorities to detect "missing" receipts (for tax-avoidance control purposes). [1] https://en.wikipedia.org/wiki/Hash_chain https://en.wikipedia.org/wiki/Hash_chain

stephenr 10y ago

Whenever DANE comes up, DNSSEC in general comes up. Whenever DNSSEC comes up, a raft of people arrive to say "but this means the government will have complete control and can do what they want". The evidence of this actually being a reality is then given as the us government took down a known and acknowledged "piracy" site. A further example is given that e.g bit.ly would have been effectively controllable by Gadafi. First off: no one forced them to use the .ly domain. If you choose to use a country code domain you should be aware of the situation the controlling country is in. Second: if your only argument supporting the idea that democratic governments - even those as fucking ass backwards as the USA - will arbitrarily take control of your domain, is a file sharing site, I suggest you look for more evidence.