I'm not sure if this is the right place for this request, as it's not just a feature request for LE but for the ACME protocol. It's based on a desire to overcome limitations of the existing challenge methods:
HTTP-01 requires some integration with the a web server, and is exposed to unwarranted trust in the network layer (subject to BGP hijacking, MITM on networks the traffic is legitimately crossing, etc.).
DNS-01 solves the trust problem if used with DNSSEC, but otherwise it interacts badly with DNSSEC, requiring a setup with dynamic signing using an online key and precluding a more secure setup where the keys are entirely offline and not accessible by automated processes.
I would like to propose a "challenge method" DANE-01 that would not involve any actual challenge, only validation that the CSR is signed by a key in the TLSA records for the subject name(s). Used with TLSA type "3 1" and persistent keys, this allows certificates to be issued and renewed with no dynamic interaction with other services/infrastructure, and to be based entirely on cryptographic proof of possession of the private key for the relevant service.
As a bonus, offering this would greatly boost the deployment of DNSSEC and DANE by making them a way to streamline ACME certificate issuance.
Sure, but they made changes to the CA/B Forum requirements to allow for ACME at all, so if this went through the (presumably lengthy) standardization process then I assume part of the process would be to update the appropriate requirements documents. It'd probably be good to go through that process at any rate, to ensure that people have a chance to dig through and find any security flaws in the formal proposal.
I think this is an interesting idea, but I don't know if it's got enough wide applicability for people to jump on trying to standardize it. Part of the problem is the chicken-and-egg that not much uses DANE, so there's not many people wanting to use it for anything. My first thought is that if you're going to have DANE being worthwhile, you might as well skip the CA entirely and have the browser check the public key in DNS directly. But there are probably other thoughts I'll end up having too.
The right place to develop a new ACME challenge is the relevant IETF Working Group, ACME. That group also has people who can help you ensure that your design is sound and delivers the intended security. If that work is done, even if no other steps are taken, at least there's agreement on how a private system can issue certificates this way.
Once that ACME WG development is well under way and seems likely to be fruitful, the CA/Browser forum would need to also authorise either the specific ACME method or some generalised method that the ACME method is an implementation of to add to the Ten Blessed Methods.
Once a ballot adding this method passes, Let's Encrypt (or any other CA) would be allowed to offer this feature to subscribers. Obviously they would then need to develop software (for Let's Encrypt that's the Boulder software) to implement this feature.
The historical "Any other method" exemption which allowed CAs to make up whatever rules they wanted no longer exists, there is intentionally no longer a way to sidestep this route.
That's where you get the chicken and egg problem. By making DANE deployment one option to streamline and secure the ACME workflow, we'd get it deployed and facilitate an eventual transition to having the client just skip the CAs and validate DANE.
I'm trying to remember what people most recently told me when I asked why browsers backed away from the latter approach (since it seemed natural to me). I think one answer was that some DNS resolvers block DANE queries and so it might lead to reduced reliability of TLS connections if sites relied only on DANE as a way to authenticate their keys.
While the point of your request is of course the above quoted piece of it, I think this goes against the whole random token idea which is mandatory for I think all automated challenges in the CA/B Forum baseline requirements. The possibilities for challenges is either a random value with a minimum of 112 bits of entropy (not the case for this proposal) or uses a token generated from a keypair (so far so good), which may only be used once (oh no..) or incorporate a timestamp (also not the case for this proposal).
I think the whole non-dynamic, non-randomized aspect of this proposed challenge is probably a dealbreaker.
@Osiris that's a great point, although I'd love to hear an updated view from the ACME WG and the CA/B Forum about what they would or wouldn't consider appropriate. (Partly because I kind of like this DANE idea, and partly because I'm wondering about a future RDAP challenge in which domain registrars could confirm more directly that a certificate applicant was the same entity as the domain registrant, without any DNS queries at all.) I wonder if the PKI world might someday say "the automated challenges normally all need to be single-use, but the security property we're trying to achieve with that is ..., so maybe for challenges that ..., they don't".
The chain of keys/signatures from the root to the TLSA record, along with their validity times, form a sort of timestamp. It's not one that's necessarily unique per renewal unless at least one level of the chain is doing updates that often, but I believe it meets the desirable properties of the existing requirement without having any of the undesirable ones.
An alternative I suggested elsewhere in the past, that does still have a unique per-renewal challenge, is what I called HTTPS-DANE-01. It would behave exactly like HTTP-01 except that HTTPS is mandatory and the certificate presented (which may not yet be valid according to CA roots) must match the TLSA records for the HTTPS service on the host (as opposed to HTTP-01 where certificate checking is just disabled).
I think this is a pure negative. It doesn't facilitate the delegation properties domains should have, and DNS registrars are notorious for botching this sort of thing in ways that would give unauthorized parties the ability to obtain certificates. DNSSEC can already do it right without the registrar's involvement.
Note that another advantage of this (my original) proposal is that it provides a point of entry for the signature chains in DNSSEC+DANE to make it into CT logs, so that there's permanent record of anything fishy by registrars/TLDs (signing keys not authorized by the legitimate owner of the domain).
I like the idea, and I like that you started with the limitation you would like to overcome, because there are other solutions that could help solve them, and it is important to consider all of them, like [cabf_validation] Validation methods used for Wildcards/ADNs
As others have said any solution should eventually be standardized in the IETF ACME WG and approved by the CABForum. But I don't think they will look at the problem before there is a rough proposal that is backed by a publicly trusted CA like Let's Encrypt.
The proposal does not include a random value, but one can easily be added while still solving the stated limitations. BR methods 3.2.2.4.{2,13-17} all use a random value that is not exchanged within DNS or the website hosted at the validated domain, so there is precedence.
On the discussion of support for DANE in browsers, I think there are three main challenges:
Certificate Transparency is essential now. As far as I know a widely deployed CT for DANE solution does not exist yet.
A robust mechanism for delivering the DNS records to clients needs to be developed, standardized and deployed. Many clients are only able to access A and AAAA records. Firefox once had an experimental implementation where the DANE DNS records were delivered by the server in a TLS extension. This is difficult to deploy in practice because adding support for a new TLS extension in servers is difficult, but has been done before (ALPN). Chrome once had an experimental implementation where the DANE DNS records were delivered within a self-signed certificate. This is difficult to deploy in practice because you still need to deliver a CA signed certificate to older clients that don't understand the new protocol yet.
Browsers don't want to give up control. With the CA system browsers define the policies CAs have to follow, and a browser can kick out a CA that don't follow the policies. With DANE the policy will be defined by the DNS root operator. Browsers argue that they actively compete on security and therefore have an incentive to enforce a good policy, because users could leave the browsers that don't deliver. The DNS root operator does not answer to anyone, and therefore does not have the same incentive. As an example, if I remember correctly, the DNSSEC root zone was still only signed with RSA 1024 many years after it was declared insecure and browsers had forced CAs to use stronger keys.
and so it might lead to reduced reliability of TLS connections if sites relied only on DANE as a way to authenticate their keys.