It does protect against MITM. A man in the middle can pass the content along or they can refuse to do so but they can't forge a signature.

If confidentiality is required, well you already have a public key that you're using to verify content, then the content can say: "reach us at 196.7.3.45" and then you encrypt communications to that address with the same public key you use for validating content.

Or maybe they'll specify, in the content, that you should use a different key for that, but either way the chain of trust is preserved.

This would of course all be protocol level stuff, handled by the browser, not a human. They just have to maintain a list of keys they trust.

Yes to smaller scopes, with keys passed of during interactions that organically arise, preferably face to face, but maybe not always. No to making domain names be the thing that's being trusted.

We should push this into the application layer, so rather than scoping the keys to domain names let's scope them to something relevant to whatever the user authentically trusts. Something to do with their intentions for using this app. Because most users don't even know what a CA is, but they understand that most of the time they'll need to trust somebody. So let the app decide what that's going to mean because those dynamics are always going to depend on the situation.

So the user (or OS) would pass an object at runtime to indicate which keys they want the process to trust for this session. Typically it'll be another human or a company, not a server name, but I suppose it could also be a device. Something that can guard a key pair and be identified by its ability to produce valid signatures. That way you're just not relying on globally unique human friendly names at all. Doing so puts you in a cursed corner of zooko's triangle.

Users can assign a pet name for whoever they're trusting at the time they're configuring that trust since that's the moment they're best able to scrutinize the trustworthiness of this individual or company or device. Not later on when they're installing software updates and have no context for the decisions they're making.

This way your application can work over alternative transport layers: carrier pigeons, lobbing an SD card over the border wall, whatever, and doesn't break just because the other party has a different name on the new transport. Relevant for when the internet goes down and you still want it to work with other hosts on the LAN or the local mesh or whatever.

He's right. DNSSEC is a mess, and we should fix that. We should fix that whether or not we delete CAs because CAs rely on DNS to verify that you own your domain. If DNS isn't secure, neither are CAs.

In the long run, fixing bugs is almost always better than working around them. DNSSEC is a bug. So are CAs. We can and should fix both.

ECDSA was added to DNSSEC 3 years before that blog post in april 2012 (rfc6605).

I have seen their comments across this site for a very long time. Unfortunately I do not respect or put any stock in what they say, because of how unbelievably rude and dogmatic they are, and always have been.

"As a rule, strong feelings about issues do not emerge from deep understanding."

A secure DNS is valuable whether or not we get rid of CAs, since CAs rely on DNS queries to verify domain ownership.

And if we have a secure DNS, then CAs are completely redundant. I'd much rather trust a handful of domain registrars than a handful of domain registrars, plus 100 random questionably competent organisations all over the world. Especially when any one of them can generate keys for every domain on the planet.

Isn't this what DNSSEC solves?

> That still requires trust stores to be distributed to the clients

There's no such thing as a "trust store" in practice. To be "trusted" you just need to demonstrate you have control over a DNS TXT record, and we don't need a special "store" or intermediary for that.

Certificate authorities are an artifact of a bygone time and an entirely different model of internet infrastructure.

You just have one big one on the root.

(Half joking).

> If we want to improve on this, it has to come with the current level of ease of use at a minimum.

OR it has to be a situation catastrophic enough. I don't think this one is, but it's hard to be optimistic for the future

Presumably you had some reason to trust the bank in the first place. Maybe a recommendation from somebody you know? Get the key from them.

The current level of ease is not being achieved securely. If it's not possible to do so, we should walk it back.

> If we want to improve on this, it has to come with the current level of ease of use at a minimum.

We need to recognise that is impossible. Making getting into a bank account easier for the owner does so for everyone else too. And also makes it easier for the bank to ditch the secure fallback - a building.

And ask why vendor-indepedent trust shops aren't sprouting in every locale. Answer: same security problems.

We are well and truly doomed to living in a scammers' paradise.

You said "yes" but then answered "no"?

Like it seems your disagreement is that you're pointing out there are systems today that trust WebPKI CAs but don't validate CT/SCTs. I'd agree that that's an issue and I want those systems to join the world where CT exists.

As I said, in a world with CAA records and CT logs, this isn't an issue. If your CA wants to be in root trust stores, you have to put your certs in CT logs. CAA records are "advisory" in the sense that we mandate that root-trusted CAs obey CAA records and that they write cert issuance to CT logs, so a trusted CA that violates CAA records has to tell on itself in a very detectable way.