On 21 December 2016 at 12:47, Ted Lemon <mel...@fugue.com> wrote: > On Dec 21, 2016, at 12:39 PM, Matthew Pounsett <m...@conundrum.com> wrote: > > None of those things are required by RPZ, but I believe they are required > by the hypothetical better alternative that a few people have suggested we > should work on instead. > > > To be clear, there is no real alternative to RPZ in terms of providing > protection. We could provide annotation in RPZ, and that might be useful > in some cases. But ultimately if a domain is malicious, you _have_ to > block it by not providing an answer. If you do not, only those devices > that implement the new protocol will be protected, which is to say we will > be failing broken, not failing safe. >
You and I are in energetic agreement. > > If you want the browser to receive and understand a signal then that > signal needs to be invented, the DNS servers need to be modified to send > it, and the browsers (and all other applications you want to benefit) need > to be modified to receive and understand it. This is the point I was > making. > > > Yes, correct. I proposed a draft in tls to do this after the redirect > has happened, which I think is useful, but does not solve the problem of > signaling when DNSSEC is available: https://tools.ietf. > org/html/draft-lemon-tls-blocking-alert-00 > > If we wanted to account for DNSSEC and provide signaling, I think the > signaling would have to take the form of a signed EDNS0 option that > signaled similar information. > > In the draft I’m referencing, it was my intention to provide a set of > values that could be returned to indicate what has happened. I think it’s > a bad idea to provide anything more than that, because for example if you > return a text string, that becomes an attack surface. You can use it to > trick the user into bypassing their security settings. > > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
