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.
Erik
> >
> >>
> >> Erik Nygren <erik+i...@nygren.org> wrote:
> >> > 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.
> >>
> >> That seems like a bad thing for an ACME server to do.
> >> It's an http-01 challenge, not an https-01 challenge.
> >> It shouldn't be updating. ACME servers doing dns-01 challenges already
> >> take
> >> special care to avoid caching, so they should also pay attention to
> ignore
> >> HTTPS RRs
> >>
> >> > 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
> >>
> >> I don't think it's too big for an errata.
> >> "When doing http-01 challenges, ignore HTTPS RRs"
> >>
> >> --
> >> Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT
> consulting )
> >> Sandelman Software Works Inc, Ottawa and Worldwide
> >>
> >>
> >>
> >>
> >>
> >
> >
> > _______________________________________________
> > Acme mailing list -- acme@ietf.org
> > To unsubscribe send an email to acme-le...@ietf.org
>
>
_______________________________________________
Acme mailing list -- acme@ietf.org
To unsubscribe send an email to acme-le...@ietf.org
