Allow DVSNI challenge of non-HTTP/TLS services

[chilinux]

On page 26 of the Sept 2014 draft, it is specified that a DVSNI challenge must go to port 443. However, the verification process given completes from just the TLS session without needing to issue any HTTP packets. So, the only thing keeping ACME from performing validation of other services such as SMTP/TLS, IMAP/TLS or POP3/TLS (commonly ports 465, 993 and 995) is that the client can't specify to go to a different port number. The only limitation on port should be that the service must be running on a port below 1024 at the time of validation to prove administrative control.

[jsha]

Keep in mind that the SMTP or IMAP server won't be speaking the ACME protocol: an ACME client will. In the case of a server that only serves SMTP, it's actually easier for the ACME client to satisfy the challenge on port 443, since it doesn't have to coordinate with the SMTP server. In the case where there's already a web server on port 443, the ACME client has to either bring it down temporarily or coordinate with it (this is why DVSNI is useful, since it can be executed on web server that is actively serving other names).

[chilinux]

I understand that an MTA won't directly be speaking the ACME protocol. It seems to me that Apache will never directly be speaking the ACME protocol either.

I am confused by the leap in logic that a hard specification of the challenge port makes things easier.

Please walk me through how it helps in each of the next three senarios:

(1) Someone is writing a RPM package with a script to automate configuring TLS of the Postfix SMTP server for Fedora GNU/Linux. By nature of the purpose of the script, it knows how to modify the configuration files for Postfix and along with being able to stop/start Postfix. It does not contain any code for modifying the configuration file format for the Apache web server, NGINX web server, mini_httpd, LiteSpeed web server (both Apache mode and LiteSpeed XML configuration mode), stunnel proxy from 443, [insert custom web server written in python here], etc. There is also no library that supports the configuration file format for every single web server which could be taking up port 443. It is possible for the script to locate what process is listening on port 443 and kill it so the script can supply it's own web server on the required port. However, there is nothing that guarantee that it can find the correct way to restart the previous web server when done. Also, supporting a clean way to stop and start the plethora of web servers (as stated before) would go beyond the reasonable scope of a script intended just to configure postfix to do tls. In the end, the requirement that ACME client be able to directly or indirectly control port 443 results in a script which must prompt the user to restart the web service web done when all it should be modifying should be Postfix.

(2) An ISP has a policy of only providing 1 IP per customer. Company policy requires the email services to be run on a different machine than web services. In this case, the server the ACME client is running on is has port 465 exposed via DNAT from the company router but has no method to automate binding to port 443 on the public IP address. Modifying this configuration requires the mail server administrator to go through red tape of coordinating with the network administrator and the web server administrator.

(3) A company has outsourced public facing web servers to a third party company. The firewall policy of the company prohibits internet accessible web server on the corporate network (network traffic to both 80 and 443 are blocked). However, the company policy does require a mail server to be on the DMZ.

In each of the senarios above, I see requiring the ACME client to be able to answer a challenge on port 443 does not seem to make it easier to write a script to make it easier to improve TLS adoption for email. While I can understand that some flexibility is not possible for security reasons, I am confused what additional security is provided from a challenge response from port 443 over a challenge response from any other port below 1024. Instead, it seems this just creates another hurtle to adoption of TLS for non-web protocols for no additional benefit.

[coolaj86]

I've got the process by which you can use an alternate port tested documented - even if the spec doesn't change.

See https://coolaj86.com/articles/lets-encrypt-with-haproxy/

[cpu]

This repository is deprecated & un-maintained. Closing this issue. If applicable, please move discussion to the replacement IETF owned repo and the mailing list.