Subject: BCP56bis - remaining work

From: Mark Nottingham <[email-masked]>
Date: Wed, 21 Apr 2021 12:03:01 +1000

<editor hat on>

I think we're done processing BCP56bis WGLC feedback, except for two interrelated suggestion/issues and a heads-up about editorial work.

## Requirements for Security

In <https://www.w3.org/mid/[email-masked]>, Martin asks whether we can make HTTPS a MUST, rather than RECOMMENDED. 

Then, in <https://www.w3.org/mid/[email-masked]>, Martin suggests we disallow use of *all* HTTP authentication unless the connection is secured.

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.

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.

## Editorial improvements

I did an editorial pass in:
  https://github.com/httpwg/http-extensions/commit/46636829
I believe that this doesn't make any normative changes; if anyone sees an issue, please point it out to me.

Cheers,

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

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 21 Apr 2021 05:10:16 +0200

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 21 Apr 2021 05:30:04 +0200

Am 21.04.2021 um 04:03 schrieb Mark Nottingham:
> ...

Martin talked about the Basic and Digest schemes, not HTTP
authentication in general...

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 21 Apr 2021 08:20:40 +0000

--------
Mark Nottingham writes:

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

In the last para before 1.1 that is said quite clearly, but the
abstract feels a bit wishy-washy.

Proposed abstract:

   HTTP is often used as a substrate for other application protocols to
   create HTTP-based APIs.  This document specifies best practices for
   writing specifications that use HTTP to define new application
   protocols for deployment on the Internet, (e.g., in standards efforts).

We should not need to spell out that "other situations" (as the
para before 1.1 calls them) would be smart to use them as well.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 22 Apr 2021 16:35:48 +1000

Thanks for the suggestion; I agree the abstract needs work. However, I did something slightly different; I stole the last sentence of 1.1, since you liked it :)

Now:

> Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet, but might be applicable in other situations.

Cheers,

> On 21 Apr 2021, at 6:20 pm, Poul-Henning Kamp <[email-masked]> wrote:
> 
> --------
> Mark Nottingham writes:
> 
>> [However,]

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 22 Apr 2021 06:40:57 +0000

--------
Mark Nottingham writes:

> Thanks for the suggestion; I agree the abstract needs work. However, I =
> did something slightly different; I stole the last sentence of 1.1, =
> since you liked it :)

Works for me.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 26 Apr 2021 17:46:12 +1000

Hi Willy,

> On 21 Apr 2021, at 1:10 pm, Willy Tarreau <[email-masked]> wrote:
> 
> Hi Mark,
> 

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

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 26 Apr 2021 10:51:09 +0200

Hi Mark,

> are for deployment on the open internet.

OK but it till leaves a chicken-and-egg problem by which you could have
to use https to validate https. And quite frankly I continue to think it's
not a necessity for everything, it's very possible that some information
are more valuable if widely delivered than if secured as the transport
level. Look at OCSP for example, it's used in clear and is opened on the
net because the payload is secured by definition. Why should we prevent
some other services from doing the same if there's no risk and the
availability of the information is more valuable than its supposed
confidentiality or integrity ?

Imagine a service used to retrieve signatures of package updates, it's
possible that such signatures are implicitly controllable (e.g. PGP),
and that it's considered better to ease access to the widest possible
amount of requesters than see some of them ignore signatures just because
they can't use HTTPS due to an outdated local cert list, or not having
their clock right.

I really think that a strong recommendation is better, or even a SHOULD
(i.e. it's the expected way of doing it, unless there is a good reason
not to). MUST forces violations when there is a good reason that a spec
authors couldn't imagine, and I don't like encouraging violations.

Regards,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 26 Apr 2021 08:59:00 +0000

--------

> possible that such signatures are implicitly controllable (e.g. PGP),

This is actually a very on-point use-case:  Most FOSS projects cannot
afford CDN's and release-day traffic can be brutal.

Using HTTP and allowing sensible client-side caching is a good solution
since it allows end-user sites to loft a Squid for just that.

However, I'm not sure to what extent this really comes under BCP56bis,
since it is usually just "dumb file download".

> authors couldn't imagine, and I don't like encouraging violations.

Agreed.

Mandating HTTPS where it does not belong is not good policy.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 26 Apr 2021 19:01:13 +1000

This isn't a set of recommendations for FOSS project package updates, PHK. 

Perhaps we should take this question to the security directorate; ultimately they're going to weigh in during IETF LC anyway, and this type of policy is more in their bailiwick. 

Cheers,

> On 26 Apr 2021, at 6:59 pm, Poul-Henning Kamp <[email-masked]> wrote:
> 
> --------
> Willy Tarreau writes:
>