On Tue, Jul 10, 2018 at 2:09 PM, Mike Bishop <mbishop@evequefou.be> wrote:
> Yes, the multi-CDN case is the scariest aspect of coalescing and the
> various DNS tricks we’ve been doing in recent years. The server may not be
> malicious, may not even be misconfigured – site X uses DNS to dynamically
> share load between CDNs A and F. If X decides to start moving more load to
> A, F could in all good faith continue to route clients to itself by
> providing cached, signed DNS records.
>
Yup. And, at least for browsers that follow a Priority of Constituency
model, it seems more important to ensure that site operators wishes are
respected over that of the CDNs they've used, or for their being a more
explicit signal from the user that it truly intends to ignore the site
operator.
>
>
> The industry norm is that changing the DNS record’s CNAME to a different
> CDN is the cut-over, regardless of whether the other CDN remains
> configured. It’s effectively acting as a “hot standby.” If it had to
> provided better proof of freshness, that might be sufficient, but how fresh
> is sufficiently fresh? And does DNSSEC provide that freshness guarantee?
>
Right, these are questions that need to be answered, and not just with
abstract theoretical mitigations that don't or can't be deployed.
> However, F could do this today with Alt-Svc and have the same impact.
> Secondary Certificates provides another way this might happen. So this
> ship might have already sailed.
>
The ship has only sailed for those foolish enough to ship those features :)
That is, these are real security concerns, they have not been
satisfactorily addressed, and security conscious implementations have held
off implementing these features for precisely this reason. If there are
implementations that have shipped, without understanding or considering the
security harm they're doing, that doesn't seem like a good argument to keep
building more features on the buggy premise.
If they believe they have sufficiently mitigated those very real and
practical security concerns, they would hopefully be sharing those concrete
strategies and tradeoffs, rather than a Security Considerations that
acknowledges the dragons without adequately describing how to avoid them
(or how not to).