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

[Erik Nygren <[e-mail]>]

So perhaps:

"(The HTTP client MUST NOT resolve and/or MUST ignore any HTTPS DNS RRs
[RFC 9460].
 It also MUST NOT automatically apply an HSTS behavior to auto-upgrade to
the HTTPS scheme.)".  ?

Erik

On Wed, Apr 16, 2025 at 10:40 AM Richard Barnes <[e-mail]> wrote:

> 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
>
>