By creating the DNS record you have already done that.
Obviously anything behind the address pointed by the DNS record can do that, that's the whole point.
The network/domain owner responsibility for sure. You need to internally coordinate in your organization which sub domain is going to be used by which user so they don't step on each other toes.
But in the case you mention you would probably have a centralized LE from where you can distribute the certs to the users.
And to repeat again, the possibility of using any port to obtain the certificate is there which doen not mean you have to use it. If you have any kind of issues with this you can keep the LE challenges on port 80 and 443 and block all the rest. The whole point is the choice is there you don't have to use it!
As certificates are "per domain", not "per domain and port combination", I wouldn't be happy with this - not by default. Opt in? Yeah, sure, but how? (If I want to allow user of my server to run their SSH on port 22 of my IP address, it's easy and obvious.)
As an aside, I believe that omission of port binding in certificates is a thing we will never be able to fix...
The problem is that Let's Encrypt is not the only certification authority in the world. Even with LE only, you cannot reliably prevent validation on non-standard ports from succeeding, as Validation Authority servers addresses are not publicly disclosed and they are subject to change. You can try to MitM incoming traffic to your users, but what if there is a new certification authority, which uses Yet-Another-Challenge-Format? To prevent misisuance, you would have to block all incoming traffic to your users...
There was no choice for many years, so I believe that "permissive by default" approach is a no-go now (you can't teach an old dog new tricks, people won't change their habits instantly). Possibility of using any port for validation should rather be an explicit opt-in from domain owner.
Maybe in future CAA DNS record type would allow to specify which ports you want to use for validation - I believe there is proposal for CAA ACME-oriented extension, which would allow to specify which challenge methods (dns-01, tls-sni-01, http-01...) you want to permit for domain name. If that approach would work, then maybe CA/Browser Forum will consider amendment to Baseline Requirements to allow issuance on "non-blessed" ports if permitted by another extension for CAA record.
You open a port range that your organization will use for LE specifically.
Correct.
I already mentioned in one of my previous comments the possibility of using DNS DANE for this purpose. This enables organizations running their own PKI infrastructure and put their own self signed CA in the DNS records including CAA if you like.
Another option that was mentioned (not sure if you had a chance to read the previous thread in whole) is using SRV records too where you include the port you expect that specific sub domain to listen on for challenges.
Well LE is the only one that does this in this specific way. For the future I assume in case of new providers like this the whole thing would be regulated (i.e. standard challenges etc.) for the sake of the consumers and the mental health of the admins. Otherwise we will have another chaos on the loose like it happened with many things internet till now.
Definitely seems like a discussion-worthy idea -- I wonder if has been previously discussed by CABF?
It is really opportune that CAA is now widely implemented and mandatory, because it provides the ability to introduce additional controls/tags (such as nominating additional validation ports) that won't unnecessarily cause harm to existing domains and infrastructure.
e: For example, we see the latest CAA draft introduced a validation-methods parameter, which seems like we are on the road to defining granular validation policies at a domain level already. However, as noted, it seems like any expansion of validation capabilities (such as extra ports) would require the zone to be signed by DNSSEC, so you would probably still have the "sysadmin headache" of signing your zones
If you insist upon this proposal I have some first steps you should take. Please don’t bother keep trying to drum up support for it until you’ve taken these steps since they are necessary for it to have any hope of working.
Eliminate the bulk hosting industry. Buy them all out, get an international treaty signed banning them, or convert everybody to a religion that thinks they’re sinful. It doesn’t matter how you do it, but so long as bulk hosting is widespread this is utterly impossible.
Teach the world your “sockets are for name owners” philosophy. It needs to be everywhere so that nobody is in any doubt as to the fact that if someone can make a socket on their server, that person will immediately be entitled to certificates for all their names. Most of us don’t agree with this philosophy, so you probably won’t succeed, but too bad.
I understand these might feel like impossible hurdles, but here’s the problem: Your plan can’t work without jumping these hurdles. Updating the BRs is trivial by comparison, so don’t start there. If you want to wallpaper the Eiffel tower, don’t start by choosing a wallpaper pattern, that isn’t the important bit.
