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

From: Watson Ladd <[email-masked]>
Date: Wed, 7 Aug 2019 16:33:31 -0700

Dear all,

I'm concerned about changing the format of the certificate frame payload
based on the unsolicited flag. Instead I would prefer that we reserve
request id 0 for unsolicited frames. This way there is only one possible
format, versus 2. It's a very minor quibble, but I strongly feel things
should be as simply parseable as possible.

Secondly the draft seems to hold open the possibility of having multiple
certificate fragments being assembled at once. This seems like a misfeature
to me.

Thirdly the CERTIFICATE frame context in the certificate frame starts with
the request-id but is otherwise unconstrained. I'm not entirely sure why
the older approach of having the request specify it was a bad idea, but
perhaps it was a bad idea for reasons I haven't learned yet.

Then it seems both '*' and '_' are treated as wildcards in the Required
Domains extension. It's not clear to me why one or both would be required.

I still am not clear on the joint versus separate authoritative issue (is
it a question of simultaneity)  and why that implies clients MUST NOT
assume colocation in the future. Even if joint authorization existed, it
might change for a future connection.

Section 6.4 seems a little strong to me: 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 etc.

Section 6.5 seems to imply that the set of certificates can shrink as a
request is being processed. It's a bit surprising to me: I thought there
would only be one transition as the USE_CERTIFICATE frame arrives and is
processed, for any potential CERTIFICATE_REQUIRED relevant to the stream.
The fact that these frames are no longer on the stream but on stream 0
might be fooling me as to the ordering.

The second half of section 6.5 says clients don't know if the ambient
authority of a freely useable certificate will be honored. True, but I
imagine a server would request a certificate explicitly if needed instead
of reject the request assuming it had seen all of them. I would suggest a
SHOULD for servers requesting certificates explicitly when accessing
protected resources. Do people have real usecases/ sufficiently complex
configurations where this won't work?

Sincerely,
Watson Ladd

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 8 Aug 2019 11:00:02 -0400

On Thu, Aug 8, 2019 at 8:27 AM Watson Ladd <[email-masked]> wrote:

> Section 6.4 seems a little strong to me: 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 etc..
>

>From a security considerations point of view, isn't it more useful to
describe how it potentially could be abused or misused, rather than assume
how it's likely to be used?

That is, is the argument that the Security Considerations should be
guidelines for servers deploying it, rather than clients implementing it?
The lack of in-step synchronization with DNS seems incredibly important to
implementor's security assumptions, and thus important to call out, so I'm
curious which bit is seen as a little strong?

---

From: Watson Ladd <[email-masked]>
Date: Thu, 8 Aug 2019 15:26:09 -0700

On Thu, Aug 8, 2019 at 8:00 AM Ryan Sleevi <[email-masked]> wrote:
>> Section 6.4 seems a little strong to me: 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 etc..
>
>
> From a security considerations point of view, isn't it more useful to describe how it potentially could be abused or misused, rather than assume how it's likely to be used?
>
> That is, is the argument that the Security Considerations should be guidelines for servers deploying it, rather than clients implementing it? The lack of in-step synchronization with DNS seems incredibly important to implementor's security assumptions, and thus important to call out, so I'm curious which bit is seen as a little strong?

For benefit of those who  haven't read the draft, permit me to quote
from the document:

> After the owner of the domain has redirected traffic elsewhere by
>  changing the CNAME, new connections will not arrive for that origin,
> but connections which are properly directed to this provider for
> other origins would continue to claim control of this origin (via
>  ORIGIN frame and Secondary Certificates).  This is proper behavior
>  based on the third-party provider's configuration, but would likely
 > not be what is intended by the owner of the origin.

This is not inevitable, as 'would' seems to indicate, but rather
possible, as 'could' would indicate, and depends on what the third
party prover (third party to whom?) has configured, which in some
cases will depend on the customer (entirely possible it is opt-in? Who
knows what will happen). This doesn't seem to be clearly relevant to
HTTP clients as written, vs. 6.1 which discusses the lack of DNS
hijacking need to exploit a stolen certificate.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 8 Aug 2019 18:53:53 -0400

> hijacking need to exploit a stolen certificate.

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 see the distinction with 6.1 as being the difference between malice and
ignorance, but both share security consequences that implementors - on both
sides - should be aware of. Simply highlighting the malicious case seems to
do a disservice for the far more likely case resulting in ignorance (of DNS
changes by the DNS holder) that would lead a CDN/Cloud Provider to
inappropriately advertise, on the basis that it has not yet revoked its
certificate.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 8 Aug 2019 15:57:06 -0700

On Thu, Aug 8, 2019 at 3:54 PM Ryan Sleevi <[email-masked]> 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. 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 see the distinction with 6.1 as being the difference between malice and ignorance, but both share security consequences that implementors - on both sides - should be aware of. Simply highlighting the malicious case seems to do a disservice for the far more likely case resulting in ignorance (of DNS changes by the DNS holder) that would lead a CDN/Cloud Provider to inappropriately advertise, on the basis that it has not yet revoked its certificate.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 8 Aug 2019 19:47:32 -0400

On Thu, Aug 8, 2019 at 6:57 PM Watson Ladd <[email-masked]> wrote:

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

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?

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 8 Aug 2019 20:30:39 -0400

On Thu, Aug 8, 2019 at 7:47 PM Ryan Sleevi <[email-masked]> wrote:
<Snip for everyone's benefit>

> advertising to serve news.example via CDN 1's connection.

I suppose it's worthwhile to highlight that the assumption about that 6.5 -
and explicitly stated in 6.1 - is the omission of a DNS check prior to
using the asserted identity. That's not something inherent to
secondary-certs, but something it inherits from Section 1.1 / RFC 8336. If
https://tools.ietf.org/html/draft-bishop-httpbis-origin-fed-up were to
progress - such that a DNS check existed - then arguably the security
concerns for 6.1 / 6.5 would disappear.

Put differently, the security risk is not in secondary-certs; it's in
secondary-certs + skipping DNS. The current draft indirectly depends on
skipping DNS, but that's something that can change, in which case, I think
some of the concerns highlighted would disappear. That's just not (yet?) in
the current draft.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 8 Aug 2019 17:34:09 -0700

On Thu, Aug 8, 2019 at 4:47 PM Ryan Sleevi <[email-masked]> wrote:
> 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.
>
>>
> 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.