Replacing Ceritificate Authorities with Handshake
Replacing Ceritificate Authorities with Handshake
Hey Pale Moon community,
I'm visiting from the (HNS) Handshake community and wanted to see whether there's anyone who'd be open to finding time to chat about a potential integration?
For context, Handshake is a project focused on decentralizing the root zone (to decentralize control of domain names from ICANN) with the goal of replacing Certificate Authorities (to rehaul Internet security and privacy).
A Handshake name can have its TLS key pinned to its records on the Handshake blockchain so that anyone can verify the key’s legitimacy without the need to trust Certificate Authorities.
Only a name’s owner can modify their Handshake name’s records, which takes 6 hours of block confirmations to update. This means it would require at least 6 hours worth of hash power to undo any update, making Handshake name records extremely secure.
Normally it only takes a single sabotaged Certificate Authority to compromise Internet security, but to break the security of a Handshake name would require the entire Handshake blockchain to be compromised!
Does anyone have more interest in exploring this further?
P.S. In case you'd like to read more, here's the whitepaper for Handshake: https://hsd-dev.org/files/handshake.txt. For more digestible content, this may help: learn.namebase.io
I'm visiting from the (HNS) Handshake community and wanted to see whether there's anyone who'd be open to finding time to chat about a potential integration?
For context, Handshake is a project focused on decentralizing the root zone (to decentralize control of domain names from ICANN) with the goal of replacing Certificate Authorities (to rehaul Internet security and privacy).
A Handshake name can have its TLS key pinned to its records on the Handshake blockchain so that anyone can verify the key’s legitimacy without the need to trust Certificate Authorities.
Only a name’s owner can modify their Handshake name’s records, which takes 6 hours of block confirmations to update. This means it would require at least 6 hours worth of hash power to undo any update, making Handshake name records extremely secure.
Normally it only takes a single sabotaged Certificate Authority to compromise Internet security, but to break the security of a Handshake name would require the entire Handshake blockchain to be compromised!
Does anyone have more interest in exploring this further?
P.S. In case you'd like to read more, here's the whitepaper for Handshake: https://hsd-dev.org/files/handshake.txt. For more digestible content, this may help: learn.namebase.io
-
- Pale Moon guru
- Posts: 35648
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Re: Replacing Ceritificate Authorities with Handshake
Sorry but I have no interest whatsoever in a system that ties certificate ownership to anonymous cryptographic keys (that, when compromised, will not be recoverable by other real-world means), is based on a PoW blockchain that greatly favours energy-expensive coin generations, and on top does not, at all, seem to focus on the authentication part of certificate issuance, i.e. that the domain owner is, in fact, the person or legal entity they claim to be. I have at least not seen anything in the text blurb that ensures that this system is actually performing any sort of face-to-face or KYC that is essential for EV.
What's more, for a browser to integrate this it would require blockchain functionality inside the browser at the network level which means for performant lookups it would either have to store a full copy of the blockchain (which is infeasible for a browser) or rely on third parties providing proof of the TLS key (potentially fungible, and potentially a privacy concern a la the OCSP concern), and which ultimately only shifts the responsibility from parties that have significant financial stake in providing trust, to distributed nodes that do not.
What's more, for a browser to integrate this it would require blockchain functionality inside the browser at the network level which means for performant lookups it would either have to store a full copy of the blockchain (which is infeasible for a browser) or rely on third parties providing proof of the TLS key (potentially fungible, and potentially a privacy concern a la the OCSP concern), and which ultimately only shifts the responsibility from parties that have significant financial stake in providing trust, to distributed nodes that do not.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: Replacing Ceritificate Authorities with Handshake
Thanks so much for the reply !
I can't refute the PoW part since that's necessary in order to have the DNS record security I mentioned before (PoS just wouldn't cut it). What did you mean by the "that, when compromised, will not be recoverable by other real-world means" part?
For the authentication and the blockchain functionality inside the browser part, I think HNSD (https://github.com/handshake-org/hnsd) might change your view there — it can trustlessly resolve names using 12mb of RAM and virtually no CPU. It's actually the "killer app" of Handshake![Smile :)](./images/smilies/icon_e_smile.gif)
I can't refute the PoW part since that's necessary in order to have the DNS record security I mentioned before (PoS just wouldn't cut it). What did you mean by the "that, when compromised, will not be recoverable by other real-world means" part?
For the authentication and the blockchain functionality inside the browser part, I think HNSD (https://github.com/handshake-org/hnsd) might change your view there — it can trustlessly resolve names using 12mb of RAM and virtually no CPU. It's actually the "killer app" of Handshake
![Smile :)](./images/smilies/icon_e_smile.gif)
Re: Replacing Ceritificate Authorities with Handshake
That would be a negative for me as well so don't come knocking on my door either.
This all seems like a covert effort to just mine more crytocurrency leaving no actual responsibility being assigned to anyone and thus true trust can never be achieved.
While it is true that icann is a fucked company lording over us with the root domains and the CA industry has been hurt by efforts like Let's Encrypt and of course Google infiltration as both a private tld holder and CA and the whole https-everywhere agenda...
I just don't see anything good coming in the end for anything related to the blockchain cryptobullshit being presented. Not with mass criminality and increasing plans for forced govermental control.. or both.
So as far as my self and BinOC are conserned, if anyone cares, y'all can take a hike.
This all seems like a covert effort to just mine more crytocurrency leaving no actual responsibility being assigned to anyone and thus true trust can never be achieved.
While it is true that icann is a fucked company lording over us with the root domains and the CA industry has been hurt by efforts like Let's Encrypt and of course Google infiltration as both a private tld holder and CA and the whole https-everywhere agenda...
I just don't see anything good coming in the end for anything related to the blockchain cryptobullshit being presented. Not with mass criminality and increasing plans for forced govermental control.. or both.
So as far as my self and BinOC are conserned, if anyone cares, y'all can take a hike.
-
- Pale Moon guru
- Posts: 35648
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Re: Replacing Ceritificate Authorities with Handshake
No, it's not at all necessary. Dismissing PoS (or PoC for that matter) out of hand in favour of PoW which is known to be extremely top-heavy in terms of early investors and dedicated hardware/financial incentives (and mining farms for that matter) gives me a pretty strong signal that this clearly isn't the entirety of reasoning being exposed here. I happen to have plenty of experience with cryptocurrency so I've got a pretty good grasp of the dynamics of crypto coins as a whole and it doesn't really add up.
If a private key is compromised there is no way to establish a positive identity otherwise, meaning the entire domain and brand identity will be compromised when that happens with no way to recover by e.g. f2f or other real-world positive identification. You really expect domain holders to take that risk?
![Wtf? :wtf:](./images/smilies/icon_wtf.gif)
No it does not. In fact it severely reduces my trust in this system as you are requiring all DNS resolution to be handled through an inherently untrusted network that has at least 2 extra points of failure/compromise/manipulation before getting to the authentication against the blockchain, none of which is cryptographically secured. That makes the privacy concerns even worse than I already indicated. You are making a massive trade-off of security for performance because the system you propose is too inefficient to work otherwise.
On top of the fact that using a local recursive resolver isn't an option in many situations, bypasses any (potentially required) system resolver in favour of an unknown trusted resolver, etc... - it is simply not a proper way to establish authentication of a certificate.
I understand the way you're trying to do this, but the authoritative TLD resolver for the blockchain would take the exact same position as any of the TLD resolvers for the actual web with the same implied trust and the same control; only in this case the control isn't just for public address resolution delegation of a single TLD, but for actual establishing of cryptographic trust of all domains served by handshake.
Compare that with a short trust chain that is cryptographically verified locally against a built-in trust anchor. A short, verifiable certificate trust chain that has cryptographic affirmation that a certificate was indeed issued (and confirmed not revoked) through cryptographic signatures with secure hash algorithms.
Where is the trust anchor in your case if it's simplified through a DNS-style lookup that has no point of verification?
P.S.: regarding your remark "it only takes a single sabotaged Certificate Authority to compromise Internet security" That's simply not true. Might want to look into things like CAA that combat mis-issue by unauthorised CAs.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: Replacing Ceritificate Authorities with Handshake
I'm glad we're at least on common ground regarding our shared exasperation about ICANN and CAs.New Tobin Paradigm wrote: ↑2021-08-06, 20:58That would be a negative for me as well so don't come knocking on my door either.
This all seems like a covert effort to just mine more crytocurrency leaving no actual responsibility being assigned to anyone and thus true trust can never be achieved.
While it is true that icann is a fucked company lording over us with the root domains and the CA industry has been hurt by efforts like Let's Encrypt and of course Google infiltration as both a private tld holder and CA and the whole https-everywhere agenda...
I just don't see anything good coming in the end for anything related to the blockchain cryptobullshit being presented. Not with mass criminality and increasing plans for forced govermental control.. or both.
So as far as my self and BinOC are conserned, if anyone cares, y'all can take a hike.
Love your bio btw, very accurate and had a good chuckle
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
Re: Replacing Ceritificate Authorities with Handshake
Whoa whoa for starters, I really really appreciate how deep you're going into this with me! A lot of constructive criticism that's super helpful, unforunately I'm pretty non-technical so I'll need to lean on a developer to help clarify some stuff (like the PoW vs PoS security and the CA stuff).
Will need to defer to someone else on how HNSD and all that jazz works, thanks a million again just for having this conversation with me thus far though — it helps our entire community better understand the potential potholes on the road of adoption for Handshake. 🙏
I can say that I do absolutely think domain holders will take on the risk where a compromised private key means their entire domain and brand identity gets irrecoverably compromised because every cryptocurrency holder around the world is already taking on that same exact risk. And of course the trade off for taking on that risk is extreme security so long they maintain access of that key.Moonchild wrote: ↑2021-08-06, 21:28If a private key is compromised there is no way to establish a positive identity otherwise, meaning the entire domain and brand identity will be compromised when that happens with no way to recover by e.g. f2f or other real-world positive identification. You really expect domain holders to take that risk?![]()
Will need to defer to someone else on how HNSD and all that jazz works, thanks a million again just for having this conversation with me thus far though — it helps our entire community better understand the potential potholes on the road of adoption for Handshake. 🙏
Re: Replacing Ceritificate Authorities with Handshake
Ah okay so you might be missing the fact that HNSD verifies the PoW of the Handshake blockchain and receives proofs from full nodes answering root zone queries.
HNSD is a light client though, which might be the issue you have with it. That said, this was just released last week and does secure Handshake resolution while serving a Dane proxy as well: https://github.com/imperviousinc/fingertip
I totally understand your stance that there's no way in hell Handshake will ever be supported by Pale Moon browser but I'm curious whether that at least reduces the mistrust in the Handshake system a bit?
HNSD is a light client though, which might be the issue you have with it. That said, this was just released last week and does secure Handshake resolution while serving a Dane proxy as well: https://github.com/imperviousinc/fingertip
I totally understand your stance that there's no way in hell Handshake will ever be supported by Pale Moon browser but I'm curious whether that at least reduces the mistrust in the Handshake system a bit?
Re: Replacing Ceritificate Authorities with Handshake
Pro-tip: Don't try and shill for revolutionary technology on a tech-centric forum where the core community are technical people with strongly held ideals and convictions without extensive technical knowledge.
Basically, we will eat you alive and ship off whatever is left to Ascrod, where ever he may be.
Basically, we will eat you alive and ship off whatever is left to Ascrod, where ever he may be.
-
- Contributing developer
- Posts: 1537
- Joined: 2018-10-28, 19:56
- Location: Georgia
Re: Replacing Ceritificate Authorities with Handshake
I'm not an expert on cybersecurity, but this entire Handshake idea really seems like a solution in search of a problem. Here's what jumps out at me:
1. It's already possible to create an alternative chain of trust with existing technology that isn't based on the root servers, there are more established projects than yours attempting to do just that, and maintaining a full-on blockchain would probably require more resources than maintaining an alternate chain of trust. The only advantage blockchain has is being somewhat decentralized in terms of processing, and that doesn't seem like a huge advantage here because ultimately the whole network has to agree on a single decision regarding a registration for it to be useful. Otherwise you'll just have the network splitting over disagreements about who rightfully owns a particular domain.
2. As far as I can tell, you haven't gotten any notable entities on board. You haven't gotten any standards organizations like the IETF or W3C to take a look this, you haven't gotten any major corporation or non-profit organization to push it as a way to save money on certificate renewal costs, etc. In other words, basically no one is using this, and by the time it got approved as a standard, your draft proposal would likely be obsolete. I just can't envision a scenario in which implementing something that isn't widely used and probably won't be adopted in this form if it ever is adopted, would actually benefit us.
3. If this really is such a great idea, why hasn't anyone with an established blockchain already tried to help in implementing it in order to get it started up faster? Your project seems like it would more than likely wind up providing infrastructure that would be useful to, say, something along the lines of Namecoin. That is to say, why does a new blockchain with more people mining have to be established for just this project, and why can't you work with an existing blockchain run by people who share some of your goals and ideals? Why are you trying to go totally independent here? It seems like relying on the resources of an established blockchain and encouraging people to mine on that would make more sense than creating yet another blockchain and trying to convince people to mine on that one instead of the hundreds of others out there.
In summary... as far as I can tell, this isn't needed, it's not standardized, it's not being used by anyone, and it's running on a completely new blockchain that is likely going to struggle to establish itself. Namecoin wasn't exactly a smashing success, and I see no reason to think this will take the Internet by storm and change everything either. Namecoin in the end just turned out to be an inconvenient and clunky way of providing an alternative TLD that requires the users to setup their computers in an unusual way, just like every other alternative to the existing root servers.
I know your aims aren't the same as Namecoin, and you're hoping that by using DNS rather than throwing it away you'll be more successful. It seems like you're looking for a third way that's somewhere between Namecoin and what established alternative root servers do, and I'm just not seeing anything revolutionary here. You're moving things one level of abstraction up from Namecoin and seeing if you can make their basic idea work better there. I personally doubt it will, but I wish you good luck.
All that being said, if you are successful in getting a standards organization or another major browser to take a serious look at implementing this, then I would be very impressed and could be persuaded to change my mind. Until then though, I just don't see what Handshake has to offer us.
1. It's already possible to create an alternative chain of trust with existing technology that isn't based on the root servers, there are more established projects than yours attempting to do just that, and maintaining a full-on blockchain would probably require more resources than maintaining an alternate chain of trust. The only advantage blockchain has is being somewhat decentralized in terms of processing, and that doesn't seem like a huge advantage here because ultimately the whole network has to agree on a single decision regarding a registration for it to be useful. Otherwise you'll just have the network splitting over disagreements about who rightfully owns a particular domain.
2. As far as I can tell, you haven't gotten any notable entities on board. You haven't gotten any standards organizations like the IETF or W3C to take a look this, you haven't gotten any major corporation or non-profit organization to push it as a way to save money on certificate renewal costs, etc. In other words, basically no one is using this, and by the time it got approved as a standard, your draft proposal would likely be obsolete. I just can't envision a scenario in which implementing something that isn't widely used and probably won't be adopted in this form if it ever is adopted, would actually benefit us.
3. If this really is such a great idea, why hasn't anyone with an established blockchain already tried to help in implementing it in order to get it started up faster? Your project seems like it would more than likely wind up providing infrastructure that would be useful to, say, something along the lines of Namecoin. That is to say, why does a new blockchain with more people mining have to be established for just this project, and why can't you work with an existing blockchain run by people who share some of your goals and ideals? Why are you trying to go totally independent here? It seems like relying on the resources of an established blockchain and encouraging people to mine on that would make more sense than creating yet another blockchain and trying to convince people to mine on that one instead of the hundreds of others out there.
In summary... as far as I can tell, this isn't needed, it's not standardized, it's not being used by anyone, and it's running on a completely new blockchain that is likely going to struggle to establish itself. Namecoin wasn't exactly a smashing success, and I see no reason to think this will take the Internet by storm and change everything either. Namecoin in the end just turned out to be an inconvenient and clunky way of providing an alternative TLD that requires the users to setup their computers in an unusual way, just like every other alternative to the existing root servers.
I know your aims aren't the same as Namecoin, and you're hoping that by using DNS rather than throwing it away you'll be more successful. It seems like you're looking for a third way that's somewhere between Namecoin and what established alternative root servers do, and I'm just not seeing anything revolutionary here. You're moving things one level of abstraction up from Namecoin and seeing if you can make their basic idea work better there. I personally doubt it will, but I wish you good luck.
All that being said, if you are successful in getting a standards organization or another major browser to take a serious look at implementing this, then I would be very impressed and could be persuaded to change my mind. Until then though, I just don't see what Handshake has to offer us.
"The Athenians, however, represent the unity of these opposites; in them, mind or spirit has emerged from the Theban subjectivity without losing itself in the Spartan objectivity of ethical life. With the Athenians, the rights of the State and of the individual found as perfect a union as was possible at all at the level of the Greek spirit." -- Hegel's philosophy of Mind
-
- Pale Moon guru
- Posts: 35648
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Re: Replacing Ceritificate Authorities with Handshake
Please don't twist my words. That's not at all what I said!
As it is presented now I'm not considering it. That doesn't mean "no way supported ever".
And you're still missing the point I was trying to make that an unverifiable DNS lookup doesn't provide a cryptographically secure way of delivering a result (unlike signed certificates in a chain delivered by a server), on top of there not being a trust anchor without having direct access to the blockchain. *)
It's not a problem that light clients for the blockchain are used, but it is a problem that the delivery method of the result can't be verified as authentic, and DNS answers simply don't provide that level of verification.
So, technically, it's not sound in its current state as far as I can tell. This is why it's important to get standards and peer organisations involved like Athenian200 explained, to get these kinds of issues worked out (if possible). You may have to go back to the drawing board and redesign some things before it'd be a possibly acceptable alternative.
*) Maybe you don't understand this premise but the terminology is there for a reason. To moor a ship (= have a positive confirmation that an entity is who they say they are) you need both an anchor and a chain. The same is valid here with the metaphorical use of the terms. If there is no anchor or if there is even one compromised link in the chain, you can't moor.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: Replacing Ceritificate Authorities with Handshake
Duly noted!New Tobin Paradigm wrote: ↑2021-08-08, 05:15Pro-tip: Don't try and shill for revolutionary technology on a tech-centric forum where the core community are technical people with strongly held ideals and convictions without extensive technical knowledge.
Basically, we will eat you alive and ship off whatever is left to Ascrod, where ever he may be.
Re: Replacing Ceritificate Authorities with Handshake
Ah we've actually already chatted with W3C and one of our community members is taking that on. Brave (debatable on whether it's considered a "major browser") has already agreed to integrate Handshake as long as we submit a pull request. They've also claimed their name on Handshake last June. If it means anything, Namecheap also purchased p/ on Handshake a couple months back for abotu $200k — curious to see what they're going to do with it.athenian200 wrote: ↑2021-08-08, 06:45All that being said, if you are successful in getting a standards organization or another major browser to take a serious look at implementing this, then I would be very impressed and could be persuaded to change my mind. Until then though, I just don't see what Handshake has to offer us.
Does that make you a little more interested in digging further?
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
On the offchance you have the time to go through it, I think the Handshake whitepaper is actually the best resource to look through since it directly addresses a lot of the aforementioned objections: https://hsd-dev.org/files/handshake.txt
Re: Replacing Ceritificate Authorities with Handshake
Oops sorry about inserting my own assumption, thanks for the clarification!
Ah I see, it sounds like you're talking about how the DNS itself is not authenticated and therefore isn't a good way to deliver a server certificate. For Handshake we're actually talking about using the existing DNSSEC + DANE standards to address that.Moonchild wrote: ↑2021-08-08, 11:08And you're still missing the point I was trying to make that an unverifiable DNS lookup doesn't provide a cryptographically secure way of delivering a result (unlike signed certificates in a chain delivered by a server), on top of there not being a trust anchor without having direct access to the blockchain. *)
It's not a problem that light clients for the blockchain are used, but it is a problem that the delivery method of the result can't be verified as authentic, and DNS answers simply don't provide that level of verification.
So, technically, it's not sound in its current state as far as I can tell. This is why it's important to get standards and peer organisations involved like Athenian200 explained, to get these kinds of issues worked out (if possible). You may have to go back to the drawing board and redesign some things before it'd be a possibly acceptable alternative.
I'm pretty outta my depth here now but on the off chance you're interested in exploring a little further into this Handshake thing, I think the whitepaper (https://hsd-dev.org/files/handshake.txt) does a really good job addressing many of the concerns that have already been raised. If you have time to give it a read, I'd love to hear any thoughts that arise afterwards and I can pull a core developer in to answer any additional questions you might have. Otherwise, again, really really appreciate the time and thoughts you've already shared
-
- Moon Magic practitioner
- Posts: 2194
- Joined: 2018-05-05, 13:29
Re: Replacing Ceritificate Authorities with Handshake
I've skimmed the whitepaper (I mostly skipped the sections talking about blockchain usage and resource allocations to stakeholders) and to be honest it specified some rather dubious practices which don't really make the system that much resilient.
On the other hand, since the whitepaper is relatively old they might have been fixed (though it mentions that those choises were taken to provide acceptable performance, so maybe not...)
I'm talking about how information storage is (or was) handled. Despite the claims in the whitepaper, the chosen solutions are a pond of data corruption and partly-written data, which is bad regardless of the system. Even if the network component was sound (which is not due to the blockchain), the data storage part ruins everything.
Just my opinion on the matter.
On the other hand, since the whitepaper is relatively old they might have been fixed (though it mentions that those choises were taken to provide acceptable performance, so maybe not...)
I'm talking about how information storage is (or was) handled. Despite the claims in the whitepaper, the chosen solutions are a pond of data corruption and partly-written data, which is bad regardless of the system. Even if the network component was sound (which is not due to the blockchain), the data storage part ruins everything.
Just my opinion on the matter.
-
- Pale Moon guru
- Posts: 35648
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Re: Replacing Ceritificate Authorities with Handshake
That's only part of the problem. Please re-read what I wrote. DNSSEC also only protects against other-than-authoritative servers providing answers but that's not the danger here, at all. The danger re: DNS lies in the trusted resolver itself, not the transport.
You haven't really addressed any of the major concerns I raised and I don't have the gumption to deal with this on a trickle basis when there are some massive core issues with the way the whole system is set up that really don't make it secure, robust or trust-instilling. At all.
I understand you're out of your depth here. I'm not sure why you came here to advocate for it in that case because you're talking to people who are entrenched in knowledge about network topologies, network and internet security, name resolution and data transport... because we have to be if we want to be able to develop a secure web browser.
My opinion and conclusion won't change unless the major issues raised by myself and others in this thread will be addressed and until that happens your chances for adoption are effectively nil. I won't compromise our security.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite