[Acme] Well Known CA->client poll on port 80/443 in http-acme

[Dirk-Willem van Gulik <[e-mail]>]

W.r.t. http-acme — as far as I understand; the current 0.4 draft (https://tools.ietf.org/html/draft-ietf-acme-acme-04) has the Well known fetch going to port 80:

	Section	7.2, page 47

	   3.  Dereference the URI using an HTTP GET request.  

		This request MUST be sent to TCP port 80 on the server.

The new draft: (https://letsencrypt.github.io/acme-spec/ also numbered ‘’04”) in section 7.1 ‘Simple HTTP’, does a 180 degree change on this ‘default’: to an httpS default with an option to explicitly move it to HTTP with:

	  "tls": false / false

With the explanation that:

	If this attribute is present and set to “false”, the server will perform its validation check over unencrypted HTTP (on port 80) rather than over HTTPS. Otherwise the check will be done over HTTPS, on port 443.

without the clarity of a MUST. And it then continues 3 paragraphs down with solving* the bootstrap issue by

	If using HTTPS, the ACME server MUST ignore the certificate provided by the HTTPS server.

I am currently puzzling over an implementation that makes it as easy as possible to bring up an HTTPS webserver if you do ‘nothing’ but flag the VirtualHost config with something like 'letsencrypt on’ - and then defers to sane ‘SSLLabs A+’ level SSl defaults.

What I’d like to understand is

-	What is the value of doing the exchange over HTTPS (as this is made the default as opposed to the current 80) when one does not check the certificate nor retains the ACME Servers its view of that cert in the further exchange (or uses the RSA key of the challenge to self sign) ?

-	Would there be any good reason to not allow the specification of a port number ?

The reason for the first question is that keeping the process simple is desirable from an implementers point of view - as you want it relatively robust because some of the backend server config processes need to hark back to pre-chroot and pre-fork/pre-setuid() as to get secure persistence of state and (private) keys (which you want be a social-internet citizen that does not willy nilly overload the lets encrypt infra every startup).

The reason for the latter question is that it 1) allows for non-root > 1024 settings and 2)  may be more ‘robust’ to allow the server to open a relatively random high ephemeral port for a short time during startup that does not give a false sense of having the actual virtual host yet up; or a HTTPS only virtualhost shortly seeming to be misconfigured and appearing on port 80.

Thanks,

Dw.

* Well not ‘solving’ it - as the cert seen by the ACME server or the session key negotiated are not mixed into the response as to allow the Client to verify that there was no MITM during this exchange — as this is sort of deferred to later - when you find out that the cert signed is not one you have a private key for. Or by for exampling insisting that this certificate that is ‘ignored’ is in fact one self-signed by the same RSA key used in the token dance (which would be probably easiest for implementors if HTTPS was a strong default/guidance/best-practice).