Re: Re-WGLC for BCP65bis

On Mon, Apr 5, 2021 at 10:51 PM Martin Thomson <mt@lowentropy.net> 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.