CA/Browser Forum Ballot 169 (Domain Validation methods)

[schoen]

@tialaramex

The chances of getting non-default ports permitted for the actual remote validation step is almost nil. Google's fairly influential rep to the CA/B forum thinks that's an awful idea

There's also a ballot being voted on right (169) now in CA/B Forum to limit DV validation methods to those explicitly previously approved by the Forum (right now, methods that are as secure as another existing method are also allowed, even without explicit approval). I think that ballot may already have received enough votes to pass; with this change, something like a new port would have to be explicitly considered and approved for us in testing.

Ballot 169 also lists three non-HTTP-related ports as initially authorized for DV:

Authorized Port: One of the following ports: 80 (http), 443 (http), 115 (sftp), 25 (smtp), 22 (ssh).

[lssl]

I suspect the concern is that for every ...

I hear you. Just personally not a fan of designing software/services to self-inflicted-wound-proof the least-common-denominator.

There's also a ballot being voted on

Alternate ports are one option (115 is interesting)

Not knowing any of the politics of it all, and little of the tech on the backend, I've wondered naively whether a 'protected word' prefix might work.

By that I mean simply that for ANY domain (sub.example.com) that I want a cert for, instead of monkeying with getting past in-use ports, etc, a standalone server listening at PROTECTEDWORD.sub.example.com could easily be configured.

When submitted, LE would simply strip off the PROTECTEDWORD. and return the certs.

No monkeying with DNS auth, no more worries about port conflicts, etc.

I could host my cert auth anywhere I please.

And since I own the domain, etc. auth for PROTECTEDWORD.sub.example.com should be just as 'validating' as auth for sub.example.com.

I'm sure I've missed some terrible 'gotcha', but this all is still a PITA ...

[tialaramex]

I have been (in between doing my day job) following ballot 169 and it looks like it’ll pass. I’d forgotten 115 and 22 got into the DV reform though.

I get that 22 is in practice going to be controlled by someone who is a Big Deal™ because on all Unix-ish systems it’ll be the SSH login system for remote access, and maybe even on future Windows systems (where Microsoft keeps hinting they’ll do remote Powershell over SSH) but port 115 is a really weird choice, I’m temped to say “mistake”.

SFTP the widely used admin / Unix feature isn’t port 115 at all, it’s just port 22 and then a protocol negotiation (“Oh hey, I logged in but I need to talk to something called an sftp server? Do you have one of those?” “Yeah I do. I will connect you to that instead of running a shell”). The “sftp” associated with port 115 is RFC 913 “Simple File Transfer Protocol”, which is a classic 1980s RFC that’s clearly the work of a handful of people brain-storming, not the modern IETF.

So, on the one hand, port 22 makes a good validation choice because it’s controlled by the people you’d expect to be allowed to obtain certificates in 99.9% of cases, yet it’s a bad choice because almost nobody is going to be willing to run some validation script behind what is an absolutely essential piece of security infrastructure like SSH.

On the other hand, port 115 is this weird old protocol nobody cares about, if you use it to validate I’m very doubtful as to whether you can be sure that’s really the legitimate owner of the name you’re talking to and it has no built-in security features you can leverage, yet it’s a good choice in another way because nobody will care if you run some certificate validator on port 115 which they weren’t using for anything else…

[lssl]

I'm very doubtful as to whether you can be sure that's really the legitimate owner of the name you're talking to and it has no built-in security features you can leverage

I don't see that concern at all.

A port has no "built in security features". The security wrapped around that port -- firewall, listeners, IDS, etc -- is what makes the port secure, or not.

If I'm an admin that can open or close port 22, I can do the same at any other port.

Port 115 is "interesting" to me for exactly the reason that it is NOT used for anything of interest here.

I could easily set up a listener on port 115, and isolate it to single use -- LE auth.

[tialaramex]

It’s a political rather than technical concern, because the certificates serve a political rather than purely technical purpose.

The web PKI ended up not associating certificates with specific services. It could have been different, it’s not impossible that some day it will be. But today a certificate is for any TLS for the host example.com, not for the example.com HTTPS server, or the example.com SMTP server, or whatever.

The rationale for port restrictions is that the ports end up associated with particular roles at a company. Running the SSH server (inevitably on port 22) or the Web server, for a business, is a big deal, even if you literally run a company that sells FTP software, you undoubtedly get all your enquiries over HTTP anyway. Whereas port 115? Well it’s nothing, so let whoever needs to run something have it. Who would suspect they can thereby get a certificate issued for your precious name ?

We used to have this before with the email addresses. Before the BRs, you’d get a company offering to give a certificate for example.com to anyone who controlled certificatebuyer@example.com - an address that you’d have no reason to imagine was given this power, yet there it was. So the BRs banned that, narrowing the list of addresses down to a much shorter list, all associated with existing roles at companies that people actually knew about like “admin” and “postmaster” and all listed in one place so you could make sure to ban all of them if running a public mail service or allowing employees to assign their own addresses.

We are in danger of deviating very far off this post’s intended topic. I recommend we split here if there’s any discussion to continue.

[lssl]

We are in danger of deviating very far off this post's intended topic. I recommend we split here if there's any discussion to continue.

Thanks for the split.

I honestly dunno re: the value of continuing the discussion. From the outside, and as new around here and LE, the way things are done doesn't make a lot of sense to me all the time, and given all the discussion about lots of things that seem to have little effect on direction, I can't say ...

The rationale for port restrictions is that the ports end up associated with particular roles at a company.
We used to have this before with the email addresses

I'm sticking with my view that designing a product/process to accommodate poor poiicy/poltical decisions is simply bad design. It may be the reality in the middle of the end-user bell-curve; just doesn't change my view.

I sure agree with necessary management of port controls, or mail address, etc. I also maintain it's the responsiblity of the port-and-server owner to make sure their house is in order. Tired of catering to the sloppy. (For example, companies that STILL can't configure their mailservers correctly. Frankly, screw em. They can call me.)

Validation is validation. If 'valid because of access over port 80, or port 443', then simply picking ONE other port that the entire flippin web doesn't already have stuff running on is not that big of a deal.

I just don't buy the idea that one additional far-less-used port is going to screw up vaildation security or efficacy.

OTOH, making it less of a PITA to deploy LE without having to jump through 27 hoops at a time, will have a dramatic effect. It will improve both.

And, as I mused above (the PROTECTEDWORD shtick ...), making it easier to get a cert for a machine that's behind a firewall and will NEVER have a webserver exposed on any port is a good thing.