Ah, I think there is misunderstanding here. It's normal to discuss an erratum in many WGs with no procedural aim. I certainly am not trying to get something pushed through in this case. I do think it is a bug, but very much agree that it will require a consensus process.
I also think this traffic probably already happens over HTTPS sometimes, so perhaps the ship has sailed. thanks, Rob On Mon, Jan 15, 2024 at 4:47 AM Deb Cooley <[email protected]> wrote: > Again 'hold for update' is the only logical choice. We aren't fixing > vague language with an errata. When this RFC comes up for update, I hope > you will participate. > > Deb > > On Mon, Jan 15, 2024 at 7:41 AM Rob Sayre <[email protected]> wrote: > >> On Mon, Jan 15, 2024 at 3:42 AM Deb Cooley <[email protected]> wrote: >> >>> Items being brought up for discussion need to have specific and >>> concrete examples within scope. >>> >> >> I think the issue is that the spec is not specific or concrete: >> >> "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." >> >> That sentence is very vague, and also seems to preclude HSTS as specified >> in RFC 6797.* >> >> I can understand that HTTP (rather than HTTPS) might need to be used >> sometimes, but requiring it seems to conflict with HSTS, and enable the >> exact attack HSTS aims to address. The erratum suggests a redirect, but >> HSTS also aims to avoid that. At first, I thought there might be a >> bootstrapping problem. But, if that were the case, the redirect in the >> erratum wouldn't work either. >> >> thanks, >> Rob >> >> * https://datatracker.ietf.org/doc/html/rfc6797 >> >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
