Re: BCP56bis - remaining work

Hi Mark,

On Wed, Apr 21, 2021 at 12:03:01PM +1000, Mark Nottingham wrote:
> There hasn't been much feedback on the second suggestion, but the first
> resulted in a few people objecting that it was too general. However, this BCP
> is for IETF standards-based HTTP APIs, not all HTTP APIs or all uses of HTTP.
> Given that the IETF is focused on internetworking, the examples of localhost
> APIs don't seem very applicable here.

But even with local networks or remote networks, I'm afraid that enforcing
a MUST where we *know* that plenty of accesses will remain forever in HTTP
for various reasons will simply result in interoperability issues again due
to anyone doing what they *think* is right given that what they deal with
already does not match the rules anymore.

> Therefore, I think the best path forward is to change the RECOMMENDED to a
> MUST, rewording the language about client authentication to account for that.
> If you don't agree, please respond and state why, taking the above into
> account.

Deciding for users is *always* worse than guiding them. For example if you
keep a RECOMMENDED for https and a MUST for the authentication stuff, this
maintains a certain consistency which is easy to enforce. If you turn https
to a must, all those who have good reasons for continuing to use HTTP will
not even make a special case of the auth part.

I think a much better approach would be to make the intent clear:

  HTTP implementations must take extreme care of the confidentiality and
  integrity of transported information, especially when it may be used to
  affect a user's privacy. As such, any information about the users'
  identification or browsing habits MUST be encrypted either by the
  application or at the transport level, and any information returned to
  the user MUST be authenticated, either by the application or at the
  transport layer. Therefore, the "https" scheme is RECOMMENDED for all
  uses involving a user.

As such this doesn't prevent applications from continuing to communicate
over HTTP, or even OCSP from being used, and may even allow users to use
HTTP for some services like time retrieval at boot or package updates on
their operating systems when these packages are already signed.

Any opinion ?

Willy

Received on Wednesday, 21 April 2021 03:10:44 UTC