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.
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? 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. From: Ryan Sleevi [mailto:ryan-i...@sleevi.com] Sent: Tuesday, July 10, 2018 10:52 AM To: Adam Roach <a...@nostrum.com> Cc: Ted Lemon <mel...@fugue.com>; Joe Abley <jab...@hopcount.ca>; DoH WG <d...@ietf.org>; d...@ietf.org; dnsop WG <dnsop@ietf.org>; Paul Wouters <p...@nohats.ca>; Patrick McManus <pmcma...@mozilla.com>; Philip Homburg <pch-dnso...@u-1.phicoh.com>; HTTP Working Group <ietf-http...@w3.org> Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal On Tue, Jul 10, 2018 at 1:05 PM, Adam Roach <a...@nostrum.com<mailto:a...@nostrum.com>> wrote: On 7/10/18 11:41 AM, Ted Lemon wrote: On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley <jab...@hopcount.ca<mailto:jab...@hopcount.ca>> wrote: > But this is really equivalent in just about every important way to sending > the normal <img src="https://example.com/img/f.jpg";> along with a pushed DNS > record that indicates that "example.com<http://example.com>" resolves to > "192.0.2.1" -- and this latter thing is (to my understanding, at least) in > scope of the conversation that Patrick is proposing to have. My question is why you would involve the DNS at all if all the performance-based resolution decisions can be made without it. You're just adding cost and complexity without benefit The ip= modifier would be a great way to arrange for something to look like it came from a different source than its actual source. I'm sure there's an attack surface in there somewhere. Keeping in mind that the certificate provided by whatever machine you reached would necessarily have to match the URL's origin, this is very much one of the questions that is being asked: is there? /a Yes. Consider Site A (foo.example) and Site B (bar.example). Both point themselves to CDN 1, which then obtains a certificate for both their names in subjectAltNames. Site B then decides that CDN 1 is an unreliable partner, and goes CDN 2, updating DNS appropriately. This is the same problem in considering the HTTP/2 coalescing without doing DNS resolution (either because of poor security posture or by combining ORIGIN + Secondary Certificates). RFC 8336 briefly touches on this ( https://tools.ietf.org/html/rfc8336#section-4 ) but doesn't really explore the policy implications of the proposed or recommended mitigations. If you start with no mitigations, the net effect of both an ip= or a DNS-ignoring ORIGIN frame is to effectively treat the certificate as a 825-day DNS TTL. By framing the problem as "What's the worst that could happen if DNS entries had their TTLs ignored and were cached for 825 days", that might help explore things further. The suggestion of OCSP reduces that TTL to 7 days (effectively; due to Microsoft's contractual requirements on publicly trusted CAs), but that's still substantially longer. That's why involving DNS is at least relevant to that discussion, especially given that publicly trusted certificates are themselves predicated on DNS. Further, considering that the CA only has to validate a DNS once per 825-day period, and can issue unlimited 825-day certificates during that period, then the effective extension of relying solely on certificates 1650 days minus a second.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
![https://example.com/img/f.jpg"](https://example.com/img/f.jpg"){kind=link}