On 10.7.2018 20:57, Ryan Sleevi wrote: > > > On Tue, Jul 10, 2018 at 2:09 PM, Mike Bishop <mbis...@evequefou.be > <mailto:mbis...@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.
Signatures in DNSSEC (i.e. RRSIG records) have validity period with 1-second granularity so in theory it allows fine-tunning. Of course shorter validity means more cryptographic operations to update signatures etc. Taking into account that Cloudflare signs all recorsd on the fly, it is clearly feasible for CDN to generate fresh signatures on every DNS request. Petr Špaček @ CZ.NIC > 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). _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
