I'm not suggesting that the attack surfaces couldn't be closed, and that does seem like it would be sufficient to close them. However, we've been burned by implementations not getting details like this right in the past, so that's why I brought it up.
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 >
_______________________________________________ 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}