Re: Re-WGLC for BCP65bis

On Tue, Apr 06, 2021 at 02:13:55PM +1000, Mark Nottingham wrote:
> On 6 Apr 2021, at 12:47 pm, Martin Thomson <mt@lowentropy.net> wrote:
> > 
> > Section 4.4.2 says " "https" is RECOMMENDED".  I think that we can make
> > this mandatory.  I am not aware of any case today where unsecured HTTP
> > would be appropriate.  If non-compliance is necessary, I'm sure that a
> > specification can make that case and directly address this point.
> 
> I'm open to that. What do others think?

It depends as there are two readings to this. The text reads:

   "https" is RECOMMENDED to provide authentication, integrity
   and confidentiality, as well as mitigate pervasive monitoring
   attacks [RFC7258].

If this means "when it comes to authent/integrity/confidentiality"
only https should be used, I think I'm fine with this, even if I
know this is still not true as I don't recall seeing a browser
able to use https to talk to a proxy.

But if the sentence means "in order to provide auth/integrity/...
https must be used", it's different because while these properties
are often desired, we must not decide at the protocol level what
property the end user values above other ones. In some environments,
availability and accessibility could be way more important than all
other ones above. Using http to retrieve the current date at boot
can make sense for example, when you think that you'll need the date
to know if a certificate you're presented is still valid. And it's
important to keep in mind that https servers are the only devices
that periodically stop working when left unattended, which is an
issue in some cases.

> P.S. Can we talk about deprecating 'http' in Core, or do we have to wait for
> the next round?

I personally see this more as a dogma than anything realistic, because
the only way it would happen is by having plenty of deployments cheating.
I'd rather connect using HTTP on a service on my loopback than see services
create certificates that are valid for 100 years for example.

Just my two cents,
Willy

Received on Tuesday, 6 April 2021 04:37:22 UTC