On Tue, Jul 10, 2018 at 1:05 PM, Adam Roach <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> 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" 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}