[Acme] Interactions between HTTPS RRs (rfc9460) and HTTP-01 DV

[Erik Nygren <[e-mail]>]

One of my colleagues recently pointed out a potential interaction between
HTTPS RRs (RFC 9460) as it relates to ACME and HTTP-01 DV.  If a hostname
get an HTTPS RR into DNS prior to getting a cert validated, then there
would be a problem if the ACME client resolved the HTTPS RR and
auto-upgraded the http:// URI to https as part of HTTP-01 DV.  Since a cert
won't exist yet this would fail.

How would we want to clarify this?  It's probably too big for an errata for
RFC 8555 but annoying to have to have a draft just to clarify all on its
own.  If there are plans to do an rfc8555bis (or anything else Updating
rfc8555 for HTTP-01) this could be good to include in there.

The reading of RFC 8555 section 8.3 is fairly clear that:

Dereference the URL using an HTTP GET request. This request MUST be sent to
TCP port 80 on the HTTP server

[...]
>
Because many web servers allocate a default HTTPS virtual host to a
> particular low-privilege
> tenant user in a subtle and non-intuitive manner, the challenge must be
> completed over HTTP, not HTTPS
>

but there's a potential that implementors of HTTP client libraries
implementing RFC 9460 might follow section 9.5 (
https://www.rfc-editor.org/rfc/rfc9460.html#name-http-strict-transport-secur)
and get into trouble. That section specifies:

An HTTPS RR directs the client to communicate with this host only over a
secure transport, similar to HSTS [HSTS]. Prior to making an "http" scheme
request, the client SHOULD perform a lookup to determine if any HTTPS RRs
exist for that origin. To do so, the client SHOULD construct a
corresponding "https" URL as follows:
1. Replace the "http" scheme with "https".
2. If the "http" URL explicitly specifies port 80, specify port 443.
3. Do not alter any other aspect of the URL.


I think one potential clarification to RFC 8555 Section 8.3 would be that
validating clients SHOULD NOT do a resolution of HTTPS RRs.

Best,
       Erik