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 <r...@ipv.sx> wrote: > On Tue, Apr 15, 2025 at 7:22 PM Erik Nygren <erik+i...@nygren.org> wrote: > >> On Tue, Apr 15, 2025 at 7:08 PM Stephen Farrell < >> stephen.farr...@cs.tcd.ie> 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 > >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
