I guess we could organize regional parties where site operators and users meet up and exchange key material. I'm sure that will scale and won't have any problems of its own.

The same way you know if you should trust the WebPKI Rube-Goldberg-contraption: you don't.

It's a counterexample, not a recommendation.

If you need this guarantee, use self-certifying hostnames like Tor *.onion sites do, where the URL carries the public key. More examples of this: https://codeberg.org/amjoseph/not-your-keys-not-your-name

I trust the WebPKI infra quite a bit. Cert validation is publicly logged, CAs that do nefarious things get booted from browser trust stores.

I can set which CAs can sign certs for my domains, and monitor if any are issued that I didn't expect.

The same way I know which real person is serving me the website. I don't I merely know that the owner doesn't change randomly.

> The same way I know which real person is serving me the website. I don't I merely know that the owner doesn't change randomly.

Still doesn't explain how I'll confirm that if the website has not been intercepted by a middle man the first time I visit it.

In this case it isn't a middle man, but becomes the real website.

The very problem here is that I am not ok with middle man becoming the real website. If you are ok with that, you don't have a problem. You can use TOFU. Good for you. But I have a problem with that. So I can't use TOFU.

I'm saying that this is not your real problem. Your real problem is that you expect the "real website" to correspond to real world entities. And this can be solved better than the current state.

You mean it can't be solved with Let's Encrypt? Yes, I agree.

What about TLS certificates attested by CAs who validate the real world legal entity? Would you agree that this is a solved problem there?

Yes this solves it partially. The thing is that people assume that the green lock correspond to the domain name. It would be completely solved, if the browser would still show the validated company name, like it used to be, and then people would only validate that and the CA also validating that there are no similar names. The latter would essentially mean that there is a global coordination of CAs and that there only one entity on the whole world could have the same name, i.e. we only have one jurisdiction.

TOFU does not help if the ISP is consistently malicious, and serves me the MITM certificate on first use.

In that case the ISP becomes the real website. If this is always consistent, then you are always talking with the same entity.

This only matters, when your view of the entity isn't solely determined by the domain name. For example you care when someone impersonates google.com, because you expect it to belong to Alphabet Inc., you perceive impersonating when the entity you are talking to changes. When some domain is always constantly resolved to your ISP, then that domain is owned by the ISP in your network.

> When some domain is always constantly resolved to your ISP, then that domain is owned by the ISP in your network.

I think you've fundamentally misunderstood the problem. Nobody here is talking about the domain resolving to ISP.

We're talking about an MITM attack where a middle-man (doesn't even need to be the ISP, it could be a router in the middle acting like middle-man) intercepts our request and serving its own public key instead of the actual server's public key so that it can carry out an MITM attack.

With TOFU, there is no way to detect this attack the first time I am connecting to the website. Once you have foolishly trusted the middle-man's public key, you may not notice any problem for months or years. Then one day, the middle-man may decide to misuse your credentials that it has collected during MITM attack.

When someone MITMs the DNS request, the domain IS resolving to him. What determines who is the MITM and who is not? When I create an account with the "MITM", and then later the "MITM" goes away, THEN I'm sending my account data to some third-party, because at the time of me deciding who is that website it was the "MITM" who was the second party.

> In that case the ISP becomes the real website.

But that's exactly what we're trying to avoid. When I want to visit my bank website, I don't want the ISP to become the real website.

I don't understand your comments. Your solution to how I trust the website on first use (TOFU) is to trust whatever public key the middle man (the ISP) serves? If you're okay with that, I guess you don't have a problem. But I'm not okay with that, so TOFU doesn't solve my problem.

No, in this case this is not the real website, but it's not because of the ISP, it is because you consider that website "my bank website". That's the real issue here. It's not different than someone registering a (similar) domain name and you thinking that this is owned by the bank.

If you were to redesign name and address resolution, to enforce connecting to the real physical world entity, this should happen out-of-band. Well, know that I think of it, I think that's what the GNU Name System is trying to address: https://www.gnunet.org/en/gns.html .

-----

The question seams to be, what do you consider to be the real website? The one that answers to your request? Then the ISP is the real website. In your example you seem to have preconceptions of who might own the website, but these are outside of the network. TLS from Let's Encrypt only enforces that the entity never changes. There are validation schemes where the physical/legal entity is validated, but this is not the case here.