Subject: Re-WGLC for BCP65bis

From: Tommy Pauly <[email-masked]>
Date: Thu, 01 Apr 2021 10:31:59 -0700

Hello all,

Now that the core documents have been completed, it’s time for us to un-park draft-ietf-httpbis-bcp56bis and progress it along towards publication.

However, you may note that it’s been a couple years since our last working group last call on this document, so I’d like to have the WG take another quick review of the document before moving it along. It has a few updates, which largely get it inline with the core documents.

The current version is here:
https://www.ietf.org/archive/id/draft-ietf-httpbis-bcp56bis-11.html <https://www.ietf.org/archive/id/draft-ietf-httpbis-bcp56bis-11.html>

You can see a diff between the older version here:
https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-httpbis-bcp56bis-11.txt <https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-httpbis-bcp56bis-11.txt>

Please reply to this email to indicate if you think this document is ready to progress, or if you have any review comments. We’d like feedback by April 12, 2021.

Best,
Tommy

---

From: Julian Reschke <[email-masked]>
Date: Fri, 2 Apr 2021 16:57:58 +0200

Am 01.04.2021 um 19:31 schrieb Tommy Pauly:
> Hello all,
>
> Now that the core documents have been completed, it’s time for us to
> un-park draft-ietf-httpbis-bcp56bis and progress it along towards
> publication.
>
> However, you may note that it’s been a couple years since our last
> working group last call on this document, so I’d like to have the WG
> take another quick review of the document before moving it along. It has
> a few updates, which largely get it inline with the core documents.
>
> https://www.ietf.org/archive/id/draft-ietf-httpbis-bcp56bis-11.html
> <https://www.ietf.org/archive/id/draft-ietf-httpbis-bcp56bis-11.html>
>
> https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-httpbis-bcp56bis-11.txt
> <https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-httpbis-bcp56bis-11.txt>
> ...

The last WGLC version was -08, so maybe the diff with that version is
more interesting...:

<https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-httpbis-bcp56bis-08.txt&url2=https://tools.ietf.org/id/draft-ietf-httpbis-bcp56bis-11.txt>

Best regards, Julian

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 02 Apr 2021 08:26:29 -0700

> On Apr 2, 2021, at 7:57 AM, Julian Reschke <[email-masked]> wrote:
> 

Thanks Julian! That was my mistake in the diff URL; I had intended to diff to that older version.

Best,
Tommy

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 06 Apr 2021 12:47:53 +1000

Looks good to me.

A request:

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.

A minor note:

Section 4.3 talks about certificates as being something special that APIs need to address.  I would instead invert this and suggest that an advantage of using HTTP is the ability to rely on the WebPKI (Section 3.3 could say "Integration with TLS and the Web PKI" and be more accurate).

For this context, I think that what you want to establish here is the divergence from normal.  It's entirely appropriate to establish your own trust anchors here.  That would NOT make your protocol a different protocol in quite the same way as other divergences do.  However, it does diminish that benefit and requires careful specification.  Yes, redirection is just something you need to accept and you probably want to default to not using cookies.  However, as it relates to Web PKI, we're now assuming it rather than actively deciding to use it.

I think that's consistent with the rest of the advice, which is mostly "use the same HTTP as everyone else unless you are sure that you need something different".

On Fri, Apr 2, 2021, at 04:31, Tommy Pauly wrote:
> take another quick review of the document before moving it along. It 
> has a few updates, which largely get it inline with the core documents.
> 
> Please reply to this email to indicate if you think this document is 
> ready to progress, or if you have any review comments. We’d like 
> feedback by *April 12, 2021*.
> 
> Best,
> Tommy

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 5 Apr 2021 23:48:59 -0400

On Mon, Apr 5, 2021 at 10:51 PM Martin Thomson <[email-masked]> wrote:

> A minor note:
>
> Section 4.3 talks about certificates as being something special that APIs
> need to address.  I would instead invert this and suggest that an advantage
> of using HTTP is the ability to rely on the WebPKI (Section 3.3 could say
> "Integration with TLS and the Web PKI" and be more accurate).
>
> For this context, I think that what you want to establish here is the
> divergence from normal.  It's entirely appropriate to establish your own
> trust anchors here.  That would NOT make your protocol a different protocol
> in quite the same way as other divergences do.  However, it does diminish
> that benefit and requires careful specification.  Yes, redirection is just
> something you need to accept and you probably want to default to not using
> cookies.  However, as it relates to Web PKI, we're now assuming it rather
> than actively deciding to use it.
>
> I think that's consistent with the rest of the advice, which is mostly
> "use the same HTTP as everyone else unless you are sure that you need
> something different".

I think that change ends up being pretty major in practice, because of how
we’ve seen the past decade play out when APIs make those assumptions.

In the context of APIs, it would be particularly bad to presume any sort of
Web PKI. Examples such as the removal of trust in Symantec and StartCom
within browsers, or the deprecations of SHA-1 and RSA-1024, have amply
shown why thinking about your PKI, and using a custom one, is entirely
appropriate and warranted: because failing to do so can easily break your
users or cause interoperability issues. If the choice of a browser, or even
all browsers, to remove support for a CA for web browsing contexts breaks
your credit card payment terminal or your pre-paid postage meter, both very
real things that happened, then you have a problematic design. So these are
things worth calling out, and perhaps as an area where divergence is
expected, but further documentation needed.

The Web PKI is unique to web browsers, while the context of BCP56 is most
definitely not limited to that, even if 4.3 is trying to encourage
harmonization where appropriate. There aren’t really advantages to reusing
the browser Web PKI in non-browser cases, especially weighted against the
risk. In practice, if you need to support multiple classes of users or
devices, such as web browsers AND programmatic API endpoints, the lesson of
the past decade can be summed up as this: maintain separate endpoints
(URLs, by virtue of distinct hostnames). Having an API endpoint used both
by browsers and not-browsers, for example, is a recipe for disaster, which
is why so many major services have migrated off that.

The reason is simple: assuming, or explicitly aligning to, the browser Web
PKI couples your connection security (certificates and TLS versions) to the
update cycles and security needs of browsers. This means things like 5 days
max to replace your certificates, and, if necessary, your entire CA. It
means coupling certificate profiles to what is appropriate or necessary for
browsers. And it means large-scale global update cycles measured in weeks,
at most.

We know that doesn’t work for everyone, especially those whose use cases
involve things that are not designed with security in mind and cannot be or
are not regularly updated. And, for better or worse, that is still the norm
today, so using the Web PKI can and should be the exception, not the rule.
If you’re not using the Web PKI (and shouldn’t be), then it’s important to
document what the client PKI is or should be, and that’s true whether or
not you still use a TLS PKI (as you recommend as a MUST), or use an
application-layer PKI appropriate for the API.

Another, more recent, example of bad things happening is looking at all of
the effort into specifying OpenID Connect’s PKI, so that an RP can trust an
IDP’s security assertions (via RFC  7517/7519), only to have an API like
OpenID Connect Discovery erase all of those security properties, by making
the PKI something derived from Web PKI and DNS, with all of their attendant
risks. These are things we should encourage, rather than discourage, API
authors from thinking about and diverging from.

Fundamentally, these problems aren’t unique to HTTP APIs. They are
consequences of using TLS, and shared by all TLS protocols. I’m not trying
to suggest BCP56bis needs to touch all this. Instead, I’m supportive of the
current language, which encourages agnosticism about the PKI in use, and
keeps assumptions about the certificate profiles limited to
httpbis-semantics (and, through that, to 6125 and using well-defined SANs).
Explicitly presuming or encouraging either the Web PKI profile (which is
constantly evolving) or the set of Web PKI CAs/trust framework (which is
also constantly evolving), however, would be problematic.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 6 Apr 2021 14:13:55 +1000

> 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 open to that. What do others think?

Cheers,

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

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

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 6 Apr 2021 06:37:01 +0200

On Tue, Apr 06, 2021 at 02:13:55PM +1000, Mark Nottingham 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.
> 

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

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

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 06 Apr 2021 14:50:06 +1000

> P.S. Can we talk about deprecating 'http' in Core, or do we have to 

I don't think that it's quite time.  But this document explicitly has a narrower scope, which is documenting good practices for people who want to use HTTP.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 6 Apr 2021 16:14:38 -0700

> On Apr 5, 2021, at 7:47 PM, Martin Thomson <[email-masked]> wrote:
> 
> Looks good to me.
> 
> A request:
> 

I don't see any reason to do that, unless it has become IETF practice
to lie to people about how their systems work. HTTP over localhost
does not use TLS certificates, nor does HTTP over VPN, HTTP between
internal datacenter hosts (most of the time), HTTP over IPsec,
HTTP over third-party secured hardware, HTTP to your pre-configured
local router, HTTP to your local network printer, HTTP to your smart bulbs, etc.

How do you expect people to refer to their existing network equipment
that is deliberately blocking TLS? As a non-compliant option? The
Internet is a weird place, and part of keeping it weird is allowing
people to make their own decisions about when end-to-end security
is the function being requested by an application.

I don't have any use for BSP advice. We are better off with RFCs that
recommend on the basis of actual deployment.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Wed, 7 Apr 2021 09:35:29 +0200

The draft currently refers to draft-ietf-httpbis-rfc6265bis-07, for
which it's not really clear when we'll be done with it.

Are we ok with *this* document sitting in the RFC Publication Queue
until it is ready? Otherwise it might be wise to reference RFC 6265
instead...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Apr 2021 16:29:30 +0200

OK, I re-read the spec, and found some editorial nits (see mails,
issues, and PRs).

The main class of editorial issues I found is the way bcp56bis refers to
HTTP base (semantics) spec. One could see bcp56bis as a document *about*
http-semantics, so essentially *all* of it refers to it in some way.
That means that when it does want to refer to a *specific* part of HTTP,
it should do so by actually telling the reader where *exactly* to look
(that is, by Section number). I opened a few PRs for that, but I'M
pretty sure there are some cases of unspecific references left.

There's another procedural issue: this document has been waiting for the
http-core specs for ~ 1.5 years alreads. These are now in the hands of
the IESG. However, it also has a reference to rfc6265bis (cookies). I
believe it would be better to refer to RFC 6265 (as the update isn't
really relevant for BCP56bis), so that *this* document has a chance to
get published soon after the http core specs.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 19 Apr 2021 17:23:00 +1000

I tend to agree; updated in <https://github.com/httpwg/http-extensions/commit/223a67e086>.

(if the bis effort speeds up, we can always update in AUTH48).

> On 7 Apr 2021, at 5:35 pm, Julian Reschke <[email-masked]> wrote:
>