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. > 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 <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
