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

[Watson Ladd <[e-mail]>]

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.