I'm sorry, I can't understand what you're trying to argue at this point. My argument is simply that LetsEncrypt doesn't depend on DNSSEC, and, indeed, it does not.
Me describing how these conversations go:
> Thomas will just pretend not to understand
Thomas just now:
> I'm sorry, I can't understand what you're trying to argue
Let's Encrypt does today depend on DNSSEC because it uses a DNSSEC verifying validator. If you have chosen not to sign names of course your names aren't protected by this, names which are signed are protected.
In a similar way, Firefox does today depend on the Web PKI because it uses NSS, a TLS implementation with a certificate validator baked into it. If you have chosen not to use HTTPS of course your sites aren't protected by this, sites which use HTTPS are protected.
You're simply using a different definition of "depend" than I am.
When you say "it does depend", you mean that in the rare cases where a domain owner has chosen (weirdly) to sign with DNSSEC, LetsEncrypt will enforce DNSSEC validation on that domain.
When I say "it does not depend", I mean that the basic functioning of LetsEncrypt does not in any way rely on DNSSEC. As I've said in the last several comments, LetsEncrypt will continue to function just fine when DNSSEC goes away, and a security failure in DNSSEC (for instance: if the root keys were posted to Pastebin) would literally not impact LetsEncrypt --- today's LetsEncrypt! --- at all.
I'm fine with you using the word "depend" to mean "uses, in any situation, ever", but you're clear now on what we're trying to say, and the semantic part of the debate should be over.
