Re: Comments on draft-ietf-httpbis-http2-secondary-certs-04

On Thu, Aug 8, 2019 at 6:57 PM Watson Ladd <watson@cloudflare.com> wrote:

> > Do you know of many cloud providers/CDNs that start rejecting
> configurations the moment their customers point their DNS records elsewhere?
> >
> > I’m unaware of a single one; certainly, unless they did so, this
> situation does seem an inevitability. For example, I’m similarly unaware of
> cloud providers today that both provision certificates for their customers
> and actively revoke certificates when their customers point their DNS
> elsewhere, which is currently required of all Subscriber Agreements with
> any publicly trusted CA. Last year, research was shared to that effect,
> under the name BygoneSSL, showing that it is rarely practiced.
>
> I don't see how revocation is necessary.


It was meant to draw attention to an existing requirement of Cloud
Providers / CDNs which is not currently being practiced, despite it being
contractually required of them.


> If the certificate frame is
> never sent by the server, or even if it is sent, once the TCP
> connection is restarted and the frame is not sent again, the
> connection is not reused. Why would the mere existence of a valid
> certificate lead to it getting used in a certificate frame?
>

I think you may have inadvertently shifted the requirements. Originally,
you stated
> it's unlikely that $CDN will claim control of all origins it could claim
authority over on a connection, but more likely that it does so for ones in
subrequests, link headers

I think that relies on certain assumptions about how it may be deployed; it
doesn't seem like we should be making assumptions of use when talking about
security considerations. However, even if we assume those assumptions hold,
then we can assume that a user who transitions from one cloud provider to
another may find their original cloud provider still claiming authority
over the connection - for those subresources, link headers, etc. That still
represents a real and meaningful security risk.

Let's imagine I am news.example. I use and configure CDN 1, to which I push
my latest news stories and content. Later, I decide I'm going to switch to
CDN 2. I initially start by pushing my content to both CDNs - ensuring it's
fresh regardless. I then transition my DNS to point to CDN 2 - still
populating fresh content, so long as my original DNS TTL was set.
Eventually, I stop updating CDN 1 with content, and my latest news and
corrections are only found and distributed by CDN 2.

Now, imagine I go to social-media.example, which happens to use CDN 1.
Someone links to a story - or subresource - from news.example. CDN 1 is
ever so clever, and says "Hey, I'm a valid authority for news.example, let
me use secondary certs so we can reuse this connection [along with the
ORIGIN] frame". The client - which we'll presume is a browser - says great,
and now uses the connection to social-media.example via CDN1 for
news.example

The user then attempts to visit https://news.example - but lo and behold,
the browser, thinking it already has a connection, ends up reusing the CDN
1 content - and now we're seeing an old page of not-updated content! Had
the user not relied on secondary certs and ORIGIN, they would have reached
the actual, fresh breaking news.

It might seem like this is conflatable with 6.1 - except 6.1 is relevant in
the context of maliciously issued/unauthorized certificates. In the
scenario I just described, news.example had authorized both CDN 1 and CDN 2
with such certificates, and the mitigations described in Section 6.1 are
not applicable.

You might say this is news.example's fault, for not rejecting CDN 1's
certificate when it transitioned authority. This is BygoneSSL - and why I
mentioned revocation. I don't think we'd suggest that CDN 1 is necessarily
behaving adversarial - after all, news.example previously authorized them.
However, CDN 1 doesn't know that news.example now has a relationship with
CDN 2 (again, c.f. BygoneSSL), and thus doesn't know it should stop
advertising to serve news.example via CDN 1's connection.

Does that resonate more?