On Fri, Feb 27, 2015 at 5:17 PM, Daniel Kahn Gillmor <[email protected]> wrote:
> On Thu 2015-02-26 08:57:19 -0500, Phillip Hallam-Baker wrote: > > On Thu, Feb 26, 2015 at 6:35 AM, Neil Cook <[email protected]> > wrote: > >> Whilst I don’t deny that ISPs are using middelboxes for things like > >> advertising etc, it should also be pointed out that many ISPs are > concerned > >> about security, and may be using middleboxes to protect users from > things > >> like hijacking, detecting C&C in the DNS stream, detecting lookups to > known > >> phishing/malware sites etc. > > > > Comodo provides that type of service. > > Is this a reference to PrivDog? With all respect to Phillip, i hope the > recent vulnerabilities announced in some versions of PrivDog will make > users think twice about subscribing to service: > That isn't actually ours. And one of the problems with AV software is that it tends to share a lot of coding practices with the malware it is intended to suppress. We distributed a different version that passed our QA before the bug was inserted. Perhaps Clayton Christiansen's proposal to separate out disruptive technologies from the core company is not the best advice in a security product context. All security problems are easy if you only look at one problem. Lets stop Saddam from getting nukes... yep did that... but it wasn't the only security issue that should have been a concern now was it? https://blog.hboeck.de/archives/865-Software-Privdog-worse-than-Superfish.html > > Adopting a "security services provider" like this invariably means > opening yourself to whatever vulnerabilities lurk in that provider's > technological (and organizational, and legal) stack. > Which is why I distinguish between rewriting TLSA records and rewriting A/AAAA records. Very different trust concerns. If we do the usual route of deciding how we think things should work and supporting only those then people will come along and bust holes in our system. And like the trust root stores that will allow roots to be added but provide no way to limit their scope, the holes will be big and ugly ones. There is a justification for an enterprise root, but why not limit the roots by default to just the enterprise domain? Why does it take our techies half an hour to find out what roots have been installed and what the consequences are? > There is room for such a service in the world, but we need to find ways > to hold services like that to a *much* higher standard if we hope to > rely on them safely. > That is an accountability model and it is a necessary component. But we should also make as much use as possible from access control and least privilege as well. > A confidential resolving DNS cache sounds much easier and safer to use > by comparison, and DNSSEC could *still* be verified on the client side > (with some kind of extension to indicate that a domain is blacklisted) > to avoid exposure to the kind of untrustworthy behavior we saw in > PrivDog. > > --dkg >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
