Re: [Acme] [Errata Held for Document Update] RFC8555 (6843)

[Rob Sayre <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> wrote:
>
>> On Mon, Jan 15, 2024 at 3:42 AM Deb Cooley <[e-mail]> 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
>>
>