Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Handshake – Decentralized naming and certificate authority

handshake.org

Post reply on HN
Print view View original

81–90 of 104 posts

Re: Handshake – Decentralized naming and certificate authority

#81

Post by mattwilsonn888 »

The over specification of use case should be a big red flag. Any self-sustaining open and decentralized network capable of hosting a name service will be capable of pushing and storing arbitrary data around - the fact that data can have an owner is core to blockchain, so it's extremely dubious even without digging very deep that Handshake offers something you can't find in a more general platform.

It is also worth noting that the coins behind this project have been mined since February 2020. https://e.hnsfans.com/blocks?page=6517

Particularly for any use case where it is important that any user in all circumstances has access to data, it is really important to avoid centralizing forces present in Bitcoin and Ethereum - they were designed to secure blocks, not to secure open access, as plainly evident by their consensus mechanisms which do nothing explicit to reward the routing of data into the network.

This results in sub-optimal outcomes for data routing, but optimal outcomes for producing hash power or collecting large staking pools. If you are seriously interested in a platform which incentivizes and is based around open access and leverages that to gain better security guarantees (time-stamping, public key cryptography, exchange of value) at scale than Bitcoin or Ethereum, read about Saito and its economic foundations.

Re: Handshake – Decentralized naming and certificate authority

#82

Post by rpadovani »

judge2020 wrote: post #75
BenjiWiebe wrote: post #71

Earlier quoted context omitted.

Do browsers not check CAA? They could .

The protection for this is in certificate transparency, as Chrome will throw up a warning if a certificate is valid other than it never showing up in the CT logs. See: https://no-sct.badssl.com/ CAA combined with this CT requirement means that businesses serious about issuance can set up a service to watch CT logs and get notified every time a certificate is issued, so any would-be CA attacker would have to be pretty…

Interesting enough, only Chrome has a warning for this, Chromium and Firefox don't

Re: Handshake – Decentralized naming and certificate authority

#83

Post by noname120 »

heywoodlh wrote: post #69
noname120 wrote: post #51

> Email became Gmail, usenet became reddit, blog replies became facebook and Medium, pingbacks became twitter, squid became Cloudflare, even gnutella became The Pirate Bay How is that even remotely related to creating a new domain name service? Does the author really believe in good faith that the centralization of platforms would somehow be reduced or disappear entirely by introducing a new domain name service? This…

I wouldn't expect someone named noname120 to understand the need for a new naming service. (Just kidding, I totally agree with your point)

Haha you made me laugh!

My nickname comes from a throwaway account that I created when I was 8 years old. By an unfortunate series of events it sticked in :)

Re: Handshake – Decentralized naming and certificate authority

#84

Post by _8j50 »

8organicbits wrote: post #80
_8j50 wrote: post #68

Earlier quoted context omitted.

From a technical perspective it can. But how would you take down domains, resolve disputes like when your domain is taken over by attackers or a lookalike domain is defrauding users that are trying to get to your site. It isn't commercially viable without an authority everyone accepts for name revocation.

Some DNS revolvers filter results to protect against malware, malicious sites, or NSFW content. You can always add another layer on top of the blockchain that filters/censors based on your/your company's/your government's wishes.

Yea but that is opt-in not opt-out. For example there are botnets that use specific domains, they get disrupted until they spread again when a domain or IP is taken down. The longer a credential phish stays up the more people are affected by it as well. If there is no way to ensure by default a domain is inaccessible when revoked it isn't a workable system for commerical applications.

Re: Handshake – Decentralized naming and certificate authority

#85

Post by ddrdrck_ »

rvz wrote: post #29
kouteiheika wrote: post #17

> Handshake uses proof-of-work mining Uh, no thanks. If you insist on using a blockchain at least don't make it proof-of-work. It's 2022, and there are plenty of production-ready non-PoW chains out there already. Please stop killing the planet.

> It's 2022, and there are plenty of production-ready non-PoW chains out there already. Yeah. Like Solana, Polygon, Helium, Celo, etc? Which they went down. Why would something that operates like a CA, DNS or TLDs be suitable on those 'production-ready' chains? PoW makes sense for this use case. > Please stop killing the planet. I agree. I'd rather have something useful burning the planet and is an improvement than s…

> Yeah. Like Solana, Polygon, Helium, Celo, etc? Which they went down

Funny how you forgot to mention Cosmos [0] which is one of the most prominent PoS blockchain, in production since march 2019, and never went down ...

[0] https://cosmos.network/

Re: Handshake – Decentralized naming and certificate authority

#86

Post by mhluongo »

_8j50 wrote: post #84
8organicbits wrote: post #80

Earlier quoted context omitted.

Some DNS revolvers filter results to protect against malware, malicious sites, or NSFW content. You can always add another layer on top of the blockchain that filters/censors based on your/your company's/your government's wishes.

Yea but that is opt-in not opt-out. For example there are botnets that use specific domains, they get disrupted until they spread again when a domain or IP is taken down. The longer a credential phish stays up the more people are affected by it as well. If there is no way to ensure by default a domain is inaccessible when revoked it isn't a workable system for commerical applications.

You can build decentralized domain name systems with revocation. Many of the people building such things wouldn't be big into adding deplatforming into the base layer, though.

These projects are about a more free internet, not about a more easily controlled internet.

Re: Handshake – Decentralized naming and certificate authority

#87

Post by kenniskrag »

josu wrote: post #58
kenniskrag wrote: post #56

Earlier quoted context omitted.

small PoW networks are prone to takeovers. E.g. one actor decidea to use his asics to take over the network for a few blocks.

This is a solved issue with Merge mining. Here a primer: https://blog.bitmex.com/the-growth-of-bitcoin-merge-mining/

then someone has to mine two blocks?

How are they linked together. E.g. I haven't much luck to mine a bitcoin block and will others put data inside the bitcoin blockchain for me? If it is the other way around there should be some kind of auth?

Re: Handshake – Decentralized naming and certificate authority

#88

Post by blamestross »

noname120 wrote: post #51

> Email became Gmail, usenet became reddit, blog replies became facebook and Medium, pingbacks became twitter, squid became Cloudflare, even gnutella became The Pirate Bay How is that even remotely related to creating a new domain name service? Does the author really believe in good faith that the centralization of platforms would somehow be reduced or disappear entirely by introducing a new domain name service? This…

It is worth pointing out the distributed systems tend towards centralization over time.

Keeping things decentralized is always going to be an active effort. Fundamentally decentralized vs centralized is also robustness vs efficiency. Anybody with a short returns horizon that hasn't been burned yet prefers efficiency.

Re: Handshake – Decentralized naming and certificate authority

#89

Post by 0xbadcafebee »

rhyselsmore wrote: post #27
lizardactivist wrote: post #21

A very big security problem with current domain certificates is that browsers accept any certificate for any domain, as long as they trust the issuer. There is no concept or notion of who is supposed to have issued the certificate.

Certificate Transparency Logging allows you to view the issuances of certificates. CAA records provide some extra defence ( https://en.m.wikipedia.org/wiki/DNS_Certification_Authority_... ). It’s not perfect, but it’s getting better.

I think those two are examples of why it's not getting better. People point at these lame kludges and think "well maybe it's secure". But CT doesn't stop attacks and literally nobody looks at it anyway. And nobody uses CAA, and even if they did, it depends on the security of their name servers, the DNS protocol, BGP, and other things, all of which are insecure.

There is simply no way to secure a domain name without having asserted it cryptographically from the people who actually control the domain: the registrar. Only the registrar knows who owns the domain, and what that owner will allow to happen with the domain. A CSR must go through the registrar, and the registrar must pass the request to the human who owns the domain for validation. (This can be automated by the owner for automatic cert renewal.) This puts the power in the hands of the people who really control the domain, rather than a bunch of wonky insecure kludges to kinda-sorta-validate who might control a DNS record or some temporary IP space or an email address or some other nonsense.

It's friggin' 2022. If we land on Mars before we figure out how to control domain names securely, we are truly an incompetent industry.

Re: Handshake – Decentralized naming and certificate authority

#90

Post by easrng »

whatisweb3 wrote: post #46

Application-level protocols should not be attempting to secure their own consensus mechanisms - it ties the security of the application to the base token. If you are seeking decentralized naming and certificate authorities you can look at Ethereum and ENS. Besides the eventual transition to Proof-of-Stake, building an application on top of an existing consensus mechanism means that your application will inherit the s…

It's not possible to make a lightweight ENS resolver that doesn't fully trust the Ethereum node it's using.
Post reply on HN