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

[Ryan Sleevi <[e-mail]>]

On Thu, Aug 8, 2019 at 6:26 PM Watson Ladd <[e-mail]> wrote:

> On Thu, Aug 8, 2019 at 8:00 AM Ryan Sleevi <[e-mail]> wrote:
> >
> >
> >
> > On Thu, Aug 8, 2019 at 8:27 AM Watson Ladd <[e-mail]>
> 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.


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.