[baby]

Domain name/identity and key pinning has always been the only useful use of NFTs that I can think of.

Today, to encrypt your communications with people, you use something like PGP or Signal which rely on "trust on first use (TOFU) but verify", in practice people don't really verify so it's more like TOFU. This means that if someone compromised the session at the moment where it was created (or re-created), then your communication are being snooped on.

Today, to encrypt your communication to websites, you use HTTPS which rely on a vast network of certificate authorities. Any of these actors misbehaving leads to potential attacks. Because of that, the Certificate Transparency project was created to _potentially_ catch bad actors, that is if you check for your own domains regularly.

Using a consensus-based registry, you can prevent (better than detect) attacks in both of these scenarios. Let people register their identity or domain name, and associate a public key to it that can be used to encrypt communications with the identity/domain, as long as the number of dishonest actors remain under a threshold no attacks are possible.

The only (albeit not small) downside is that by taking middle men out of the picture, the naive approach prevents account recovery from happening. So to be practical, you need to find the right middle ground.

[cracker_jacks]

> no attacks are possible

I think this just shifts the responsibility and point of attack onto the owner (which is true for all decentralized crypto). An attack is still possible and worse yet, it is completely irreversible.

That said, the option of taking personal custody and responsibility is important and I think it should always be an option.

[mrnobody_67]

Honeypot is much smaller.

Any centralized source of data is very attractive and worth spending a lot of time & effort on and inevitable gets hacked: https://en.wikipedia.org/wiki/List_of_data_breaches

[baby]

> I think this just shifts the responsibility and point of attack onto the owner

The owner is always a target, it doesn't change that, it just removes a bunch of single points of failure and middle men.

> An attack is still possible and worse yet, it is completely irreversible

Attacks are always possible, but depending on your threat model you do end up eliminating a number of them. As I said, with a naive implementation you make an attack irreversible, but it's not impossible to imagine an optional, committee base KYC-based account recovery mechanism.

[hadcomplained]

> Today, to encrypt your communication to websites, you use HTTPS which rely on a vast network of certificate authorities.

This fact has been irritating me for a long time. Because no one should believe that every single certificate authority is tolerant to any attempts to steal the private keys. But that is exactly the underlying assumption behind HTTPS being the only way to use HTTP in a more secure manner than exchanging in plaintext.

Let's think about this scenario: Suppose that I built a web service for my personal use and hosted it in public cloud. I don't trust any certificate authorities, so I created my own TLS certificate without using them. I installed my own certificates on the machine from which to connect to my web service. Now the server for my web service is serving in HTTPS using my own certificate. Am I safe? No. Because any entity with access to the private key of any of the certificate authorities trusted by my machine, is capable of intercepting the communication between my machine and my server, simply by MITM.

The problem of being forced to trust certificate authorities can be solved by adding the feature to embed a public key in a url. For example, it would be wonderful to have a url like httpsecure://rsa:PUBLICKEY/example.com/ to make sure example.com always responds using the key PUBLICKEY. IIRC, the Tor onion services is an instance of this -- the .onion domains include public keys.

[judge2020]

> Am I safe? No. Because any entity with access to the private key of any of the certificate authorities trusted by my machine, is capable of intercepting the communication between my machine and my server, simply by MITM.

You're probably more safe than you'd think. Certificate Transparency is now required for Chrome, Firefox, or Safari or you'll get an error message during the TLS connection, before any private data is sent to the (potentially MITM'd) site.

Given that all certificates are logged, site operators can use some of the many CT alert websites to let them know if and when a new certificate is issued for their domain, so if some random authority they haven't heard of before issues a cert or it's done at a time they know they didn't need to renew their certs, it'd be time to raise major alarms about the occurrence and thus would mean instant loss of all business for that authority; plus, shockwaves would be sent across the internet as this would be a huge event, especially if it's against a company worth burning a CT for (eg. Google which houses so many fortune 500 companies' secrets).

> the .onion domains include public keys.

The .onion domain is, in itself, a public key. The side effects of your proposed solution are:

A) it would mean you HAVE to trust whoever sent you a link

A) 1) for web-based referrals, this would mean you trust your (possibly state-sponsored) search engine to never MITM you (this is currently mitigated by CT which would expose Google's GTS issuing a random domain's cert)

A) 2) for IRL events, this would mean you have to trust that the business themselves put up a certain QR code with the public key and not some malicious actor

B) This would mean site.com could never rotate their private key without changing all of their backlinks to one with the correct public key.

These are all problems Tor already faces - you have no idea if the onion site you're linked to is actually the site it says it is if it perfectly mimics it and/or reverse proxies the real site. You're currently always advised to get URLs from a trusted source once then only use bookmarks to access them to prevent reverse engineering. And you can't rotate your private key without doing this domain change.

[kenniskrag]

Can't you pin the cert (http pinning)? Can we pin a CA cert of one CA? Can we add to dns which CA is allowed to issue certs for this domain like which ip is allowed to send emails?

[tialaramex]

Web browsers no longer offer key pinning because it's both a foot gun and subject to ransom attacks.

So what that means if, maybe the person in charge of the web site "cleverly" enables key pinning, then loses the keys, you fire them for incompetence but too bad your site is now unreachable for a long period, hope it wasn't important. But worse, maybe everybody you employ is smart or careful or both, but unfortunately bad guys break in, and they set up key pinning, then deliberately remove the keys. Now your site is unreachable... unless you pay them a ransom for the keys.

For non-browsers (e.g. a phone app) pinning is still very much possible, and I would say judging from what we see on community.letsencrypt.org that it does indeed function as a footgun - e.g. we had an outfit that does industrial IoT stuff and their things all believed they needed to see certificates from Let's Encrypt X3, which is a shame because X3 was retired in favour of R3 and so those things just broke until a human could reach them to perform a manual firmware update.

A DNS record to indicate which CAs may issue for a DNS name exists today, it's called CAA, and you are welcome to go set it up. However, CAA is about preventing a different issue than the one your parent was ranting about. CAA tells a trustworthy CA that you don't want them issuing, for example because their processes aren't suitable. But it does not prevent them from doing so, it would be a misissuance (policy forbids, they did anyway, that's a policy violation), but it wouldn't be impossible and is deliberately not detected by software like web browsers.

Let me give two examples, one where CAA fixes it and one where it's not applicable at all

1. [Yes this really happened] Facebook has a deal with a CA where Facebook pays them money and they have a bespoke process to issue certificates which includes ensuring the Facebook security team is happy. However, Facebook did not set CAA, and so when a contractor who didn't know any better just created a new web server something.something.fb.com and asked Let's Encrypt for a certificate, they got one. Facebook freaked out. Setting CAA would have prevented this, Let's Encrypt would say "Cannot issue, prohibited by CAA for fb.com" and the contractor asks his contact at FB, who then checks with security first and they either say "No" or get a certificate from their preferred CA. Today Facebook sets CAA.

2. Someone buys a domain example.com, and they're annoyed that the previous owner has a valid certificate for example.com which is still valid, from Entrust. So, they blacklist Entrust in CAA. This has no effect on that existing certificate, it only means the new owner can't get new certificates for that name from Entrust. The correct fix they should have done was to show Entrust that they, as the new owner, want this certificate revoked, in most cases that's just a matter of sending an email and doing what the reply says although the details vary by CA.