Re: BCP56bis - remaining work

Hi Willy,

> On 21 Apr 2021, at 1:10 pm, Willy Tarreau <w@1wt.eu> wrote:
> 
> 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.

Again, this is *just* about IETF specifications that define HTTP APIs that are for deployment on the open internet.


>> 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
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Monday, 26 April 2021 07:46:36 UTC