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

[Richard Barnes <[e-mail]>]

On Tue, Apr 15, 2025 at 7:22 PM Erik Nygren <[e-mail]> wrote:

> On Tue, Apr 15, 2025 at 7:08 PM Stephen Farrell <[e-mail]>
> wrote:
>
>>
>> Hiya,
>>
>> On 15/04/2025 23:50, Erik Nygren wrote:
>> > Thanks.  I went ahead and filed an errata for this.
>>
>> That adds: "(The HTTP client must not resolve and/or must ignore
>> any HTTPS DNS RRs [RFC 9460].)"
>>
>> Is that correct? What about aliasMode or different ports? Are we
>> insisting that ACME servers ignore all HTTPS RR content or just
>> some? (Note: I don't claim to know the right answer just now.)
>
>
> Thanks for pasting here.  I should have done that but the text disappeared
> after I clicked submit.
> Ignoring all HTTPS RR content seems much safer without thinking through
> the ramifications and interactions.
> It should be ignoring the port change there as well (especially as that
> would take you to a secure port
> and rfc8555 section 8.3 is quite clear on the use of Port 80.
> Since HTTPS RRs are all about how to connect to a secure transport
> endpoint and
> the HTTP-01 is all about starting with insecure HTTP on port 80 (at least
> unless redirected via a 301 redirect)
> it's unclear how to make them play well together without carefully
> thinking through how that should work.
> This could be a problem for anything that wanted to only use HTTPS RRs
> (eg, with AliasMode with no A/AAAA records)
> but that's not practical today.  There's nothing preventing those from
> using DNS-01 however.
>

I agree with this assessment.  If you need to do something fancier than
answering on port 80 on the host indicated in the A/AAAA record, use a
different validation method.

On the erratum itself:
1. I would change "must not" to "MUST NOT" since this is important for
interoperability.
2. It does seem like it would be useful to also address the HSTS risk that
Erik's initial email points out.

--Richard