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

On Thu, Aug 8, 2019 at 4:47 PM Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
>
>
>
> 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.

Agreed that it's a change from the current properties.

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

My only objection to the description is to a single word, would,
implying an inevitability, vs. could, a possibility. The rest of the
security considerations in this very document are worded with could,
and given that we both agree it is an issue, it should be solved not
by education but by some mechanism to deal with the problem, the same
way CDNs provide a purge mechanism to handle issues with HTTP caching.

Received on Friday, 9 August 2019 00:34:43 UTC