I think the blog post on LE’s role in fighting Phishing and Malware is missing a point. Whereas TLS-CAs do not need to guarantee content (they could with some kind of “Trusted … Seal”), they need to guarantee server identity. It’s the identity users connecting via TLS care about. When I am going to do business with my bank I need to be sure I am talking to the server of my bank. Which leads us to DNS spoofing and I think that LE’s policy and protocol is vulnerable to that. I read the blog post hoping to find answers to this concern but found none. So what is LE’s position on this?
Let’s Encrypt is about as vulnerable to spoofing attacks as any other CA that issues domain-validated certificates. Essentially all CAs rely on DNS to a certain degree, whether it is via DNS validation (i.e. “create this TXT record to confirm your domain ownership”), email validation (“click on a link we sent to the email address in your whois record”) or HTTP validation (http-01). Let’s Encrypt does authoritative DNS lookups, which mitigates this risk to a certain degree.
Your bank shouldn’t be using DV certs in the first place.
There is nothing you can do with DV to make this safe, maybe require DNSSEC but meh. The problem exists with any other DV CA.
Don’t use the wrong tool if you need strong trust.
is the whois also part of the DNS? if yes, many tlds are DNSSec’ed so LE could verify the whois data and instead of sending to an “amin mail” (like postmaster@domain) just to the whois contact because that one can be verified using the TLD.
No, it is an old clear text protocol: client connect on tcp port 43, ask a question, for instance example.com and get an answer without any predefine syntax. The answer can be go ask to this server (with no standardized syntax, it's up to the whois client to understand this whois server) so you can be redirected from the whois.iana.org whois database to a tld database.
Edit: I misread the post I was replying to and gave a correction that was irrelevant to the actual post. This post is correct. 