[tzs]

Those two other problems that it does solve could be done in a less centralized way, couldn't they? E.g., add a record to DNS that contains a public key for the domain. Clients can grab that when they are grabbing the server IP address.

[devrand]

That's not really any better than what we have now. In your model you need to have full trust in the DNS operator and that your DNS responses weren't MITM'd (which are still generally unencrypted!!).

In other words, you're just trading trusted CAs for trusted DNS operators.

[lolinder]

We already have to place full trust in DNS operators—a rogue DNS operator could trivially get a LetsEncrypt cert for your domain and redirect your traffic to a different server that they control.

[devrand]

Sort of. Let’s Encrypt checks multiple DNS operators, so you’d need to compromise multiple from LE’s perspective.

Whereas putting the public key in DNS only requires compromising a user’s nearest DNS server. For example, in my home network I would be able to MITM any site that anyone using my DNS server, which DHCP will gladly hand out, attempts to connect to.

Edit: actually, I would be to MITM any unencrypted DNS lookup. So even if they didn’t use my DNS server, I could still alter the responses.

[tzs]

I didn't state it, but I was assuming that browsers would only use keys from DNS servers if they had used DNS over HTTPS to make sure they are talking to a DNS server that the user trusts.

[devrand]

And what if the request isn’t made via DoH (very few today are)? Do we just fallback to the existing Web PKI? If so we’d now have two systems to support until everything is migrated to DoH, which can very well be never.

Also, how do we know which certificate to use for DoH?

[lolinder]

Ah, that makes sense! I thought you were talking about the root nameservers, I wasn't considering all the other DNS servers.

[duhast2020]

DNS is unexpected and easily modified.