Re: Securing DNS Re: IAB statement on the RPKI.
The point is not to protect the DNS. The point is to protect the people. And that means that maybe you don't want your machine to resolve every domain name. The typical attack these days is to direct a user to a malware site. This is usually spam but can easily be a malicious redirect or inline on a hacked Web site. Once the user is on the malware site they are either asked to install the malware or the site does a driveby download on them. Other sites we would like to avoid visiting are identified phishing sites. Sending the malware through email pretty much fails these days as very few email services will deliver executable attachments. Thus the need for the malware site approach. On Thu, Feb 18, 2010 at 6:53 PM, Paul Wouters p...@xelerance.com wrote: On Wed, 17 Feb 2010, Phillip Hallam-Baker wrote: One of the big fallacies of DNSSEC is the idea that providing clients access to the unfiltered authoritative DNS source is the same as securing the DNS. That was the case when DNSSEC was designed, today most endpoints would prefer to opt to connect to some sort of filtered DNS with malware and crimeware sites removed. most? That's quite the claim. If so, then opendns and friends would be much busier rewriting our DNS packets. The biggest DNS security vulnerability is in the information that is input to the DNS publication service. Most hijacking schemes have been due to attacks on registrars. I thought the most used hijacking schemes used dancing hamsters or nude Britney Spears promises to install a new version of SYSTEM32\etc\hosts. In fact, it was so bad that Microsoft even hardcoded their own update servers IP's in their own DLL's. I have only heard of 2 or 3 attacks via registrar accounts. I've heard of many more compromised caches and hosts files. But I look forward to your substantiation that most of us prefer our DNS to be rewritten for security and saving us from typos by redirecting us to advertisement servers (malicious or not) Paul -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
more ad hominem and irrelevant comparisons. The key point is choice. Just as some people CHOOSE to install products such as Norton Anti-Virus that stop certain applications running on their machine, the typical Internet user should probably CHOOSE to use a DNS service that has the known crimeware sites eliminated. The point is that the particular obsession with 'end to end' solutions means that we loose the ability to deploy architectures that provide greater protection against the attacks that actually matter. DNS hijacking is a very rare type of attack. Securing the mapping of DNS names to IP addresses will not provide a major reduction in expected losses due to attacks. We already have domain validated SSL certificates that meet that need quite adequately. The value in DNSSEC lies in being able to establish a coherent network based system of security policy distribution. On Thu, Feb 18, 2010 at 7:41 PM, Paul Wouters p...@xelerance.com wrote: On Thu, 18 Feb 2010, Phillip Hallam-Baker wrote: The point is not to protect the DNS. The point is to protect the people. And that means that maybe you don't want your machine to resolve every domain name. That sounds very much like the tapping/crypto debate. You may not secure your communications because we're using its weaknesses for your protection. Not securing DNS because some people are using it for something completely different, namely a filtering service, is not an acceptable solution. But besides that, services like opendns can still fetch and validate DNS, and then continue strip it and rewrite it for those endusers that prefer such a service. DNSSEC does not change that at all. Paul -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
If people want to prevent their TCP/IP enabled lightswitches from viewing porn as well as stopping them from accessing malware sites, then I guess they could use this mechanism. I do not consider stopping my computer from accessing malware or crimeware sites to be 'censorship'. Censorship is what people do to other people. I have never heard of a anti-porn crusader who says that they need to be protected from porn, they always worry about what it would do to other people. The fact that the DNS can be used as a censorship point only reinforces the need for the endpoint to be more careful in their choice of resolution service. The current DNS model was conceived when a VAX 11/780 only just fit in a standard elevator and cell phones were considered futuristic spy gadgets. Had the need for endpoints to move about been considered I don't think the default of taking DNS resolution service from your local network provider would have been acceptable. For a whole host of reasons it is a really bad idea for ICANN or any other single point authority to be in the business of filtering domain name issue. Since it is also a bad idea to route packets to names controlled by the Russian Business Network it follows that most end points should not be using the authoritative DNS name space. Given that the vast majority of medium to large sized businesses seem to already have some form of restriction on Internet access, I don't see that trying to enforce this by making the DNSSEC protocol issue failure reports is going to change anything. If the technical measures were effective then the businesses would simply turn off DNSSEC. But it is rather more likely that they won't work at all because nobody has yet worked out what a Web browser should do if it is told that the site exists but the resolution of the DNS request is blocked. Perhaps they could send a request for the missing packets by carrier pigeon. On Thu, Feb 18, 2010 at 8:59 PM, Paul Wouters p...@xelerance.com wrote: On Thu, 18 Feb 2010, Phillip Hallam-Baker wrote: The key point is choice. Just as some people CHOOSE to install products such as Norton Anti-Virus that stop certain applications running on their machine, the typical Internet user should probably CHOOSE to use a DNS service that has the known crimeware sites eliminated. Should they also CHOOSE for a porn filter. And a filter on politically sensitive words? Where does our job end to let the user CHOOSE their censorship? And again, you make it sound like DNSSEC is taking away that choice, which is clearly not the case. The point is that the particular obsession with 'end to end' solutions means that we loose the ability to deploy architectures that provide greater protection against the attacks that actually matter. It prevents hacking the protocol (for good AND for evil). And that is a good thing. DNS hijacking is a very rare type of attack. No it is not. It depends on your environment. I'll grant you that its more likely you'll end up on a phising side then caught in a DNS spoof, but that does not validate your opinion of not rolling out stronger security just so people can play games with protocols. And as Mark showed, there are legitimate ways of piggypacking filtering services with DNS using EDNS options. Securing the mapping of DNS names to IP addresses will not provide a major reduction in expected losses due to attacks. It will greatly improve security by providing a hierarchical distributed signed database. You will see many new applications leveling this new option. We already have domain validated SSL certificates that meet that need quite adequately. You haven't been around in the last year? When we had SSL attack after SSL attack? A 2 second email verification for a valid for the entire world certificate is not what I would call quite adequately. The value in DNSSEC lies in being able to establish a coherent network based system of security policy distribution. Sorry, I am not sure what this means. But if it is another application of distributed signed data, then yes, it is another case for the adoption of DNSSEC, not for critisism that it would block some filtering technique, which it doesn't) Paul -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
Phillip Hallam-Baker wrote: The point is that the particular obsession with 'end to end' solutions means that we loose the ability to deploy architectures that provide greater protection against the attacks that actually matter. FYI, there is no point to insist on 'end to end' here, because DNS, including plain old one not necessarilly DNSSEC, is not end to end. DNS servers are intermediate intelligent entities betweeen peers, though the servers are operated zone administrators between peers, which are, in general, not ISPs between peers. The lack of end to end property makes DNS, including DNSSEC, vulnerable to MitM attacks at intermediate zones. Though DNS resolvers can be, to avoid cache poisoning, implemented end to end between client hosts and DNS servers without intermediate resolvers, it's end to end merely between the client hosts and the DNS servers and not between the clients and application servers of the clients. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
Recursive to stub is the piece where you need to have Apple and Microsoft provide platform integration. And they have the longest lead times. So that is the piece that you need to prioritize. If we move to a mode where most people have transitioned from ISP provided recursive DNS to some form of managed recursive DNS service, the managers of those services may employ other strategies to provide a significant improvement in DNS security even without DNSSEC adoption. One of the big fallacies of DNSSEC is the idea that providing clients access to the unfiltered authoritative DNS source is the same as securing the DNS. That was the case when DNSSEC was designed, today most endpoints would prefer to opt to connect to some sort of filtered DNS with malware and crimeware sites removed. The biggest DNS security vulnerability is in the information that is input to the DNS publication service. Most hijacking schemes have been due to attacks on registrars. On Wed, Feb 17, 2010 at 1:48 PM, Tony Finch d...@dotat.at wrote: On Wed, 17 Feb 2010, Phillip Hallam-Baker wrote: One mechanism that was unfortunately pushed asside as a result of the fixation on end to end DNSSEC would be to for the resolver to use DNSSEC (and other methods) to authenticate the data it receives and to use some modification of TSIG to authenticate the communication between client and resolver. I don't think that has been pushed aside. There's not much interest in it at the moment because the focus is on authoritative-to-recursive DNSSEC. Maybe attention will turn to recursive-to-stub security once there is more assurance that the recursive server's answers are authentic. It would not take a great deal of effort to graft a Kerberos like scheme on to effect key exchange. Or use SIG(0). Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
On Wed, 17 Feb 2010, Phillip Hallam-Baker wrote: One of the big fallacies of DNSSEC is the idea that providing clients access to the unfiltered authoritative DNS source is the same as securing the DNS. That was the case when DNSSEC was designed, today most endpoints would prefer to opt to connect to some sort of filtered DNS with malware and crimeware sites removed. most? That's quite the claim. If so, then opendns and friends would be much busier rewriting our DNS packets. The biggest DNS security vulnerability is in the information that is input to the DNS publication service. Most hijacking schemes have been due to attacks on registrars. I thought the most used hijacking schemes used dancing hamsters or nude Britney Spears promises to install a new version of SYSTEM32\etc\hosts. In fact, it was so bad that Microsoft even hardcoded their own update servers IP's in their own DLL's. I have only heard of 2 or 3 attacks via registrar accounts. I've heard of many more compromised caches and hosts files. But I look forward to your substantiation that most of us prefer our DNS to be rewritten for security and saving us from typos by redirecting us to advertisement servers (malicious or not) Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
On Thu, 18 Feb 2010, Phillip Hallam-Baker wrote: The point is not to protect the DNS. The point is to protect the people. And that means that maybe you don't want your machine to resolve every domain name. That sounds very much like the tapping/crypto debate. You may not secure your communications because we're using its weaknesses for your protection. Not securing DNS because some people are using it for something completely different, namely a filtering service, is not an acceptable solution. But besides that, services like opendns can still fetch and validate DNS, and then continue strip it and rewrite it for those endusers that prefer such a service. DNSSEC does not change that at all. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
In message alpine.lfd.1.10.1002181937210.25...@newtla.xelerance.com, Paul Wouters writes: On Thu, 18 Feb 2010, Phillip Hallam-Baker wrote: The point is not to protect the DNS. The point is to protect the people. And that means that maybe you don't want your machine to resolve every domain name. That sounds very much like the tapping/crypto debate. You may not secure your communications because we're using its weaknesses for your protection. Not securing DNS because some people are using it for something completely different, namely a filtering service, is not an acceptable solution. But besides that, services like opendns can still fetch and validate DNS, and then continue strip it and rewrite it for those endusers that prefer such a service. DNSSEC does not change that at all. DNSSEC can even be used to secure reputation data to allow different applications on the same box to make different decisions about whether or not to trust the data returned from the DNS even if it is signed using DNSSEC or not. One could also use EDNS options to tell the recursive resolver whether to filter or not a particular query or to pass back a recommendations to filter the response. The data itself would still be signed and verifiable. The recommendation itself can be secured with TSIG/SIG(0). Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
On Thu, 18 Feb 2010, Phillip Hallam-Baker wrote: The key point is choice. Just as some people CHOOSE to install products such as Norton Anti-Virus that stop certain applications running on their machine, the typical Internet user should probably CHOOSE to use a DNS service that has the known crimeware sites eliminated. Should they also CHOOSE for a porn filter. And a filter on politically sensitive words? Where does our job end to let the user CHOOSE their censorship? And again, you make it sound like DNSSEC is taking away that choice, which is clearly not the case. The point is that the particular obsession with 'end to end' solutions means that we loose the ability to deploy architectures that provide greater protection against the attacks that actually matter. It prevents hacking the protocol (for good AND for evil). And that is a good thing. DNS hijacking is a very rare type of attack. No it is not. It depends on your environment. I'll grant you that its more likely you'll end up on a phising side then caught in a DNS spoof, but that does not validate your opinion of not rolling out stronger security just so people can play games with protocols. And as Mark showed, there are legitimate ways of piggypacking filtering services with DNS using EDNS options. Securing the mapping of DNS names to IP addresses will not provide a major reduction in expected losses due to attacks. It will greatly improve security by providing a hierarchical distributed signed database. You will see many new applications leveling this new option. We already have domain validated SSL certificates that meet that need quite adequately. You haven't been around in the last year? When we had SSL attack after SSL attack? A 2 second email verification for a valid for the entire world certificate is not what I would call quite adequately. The value in DNSSEC lies in being able to establish a coherent network based system of security policy distribution. Sorry, I am not sure what this means. But if it is another application of distributed signed data, then yes, it is another case for the adoption of DNSSEC, not for critisism that it would block some filtering technique, which it doesn't) Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Securing DNS Re: IAB statement on the RPKI.
One mechanism that was unfortunately pushed asside as a result of the fixation on end to end DNSSEC would be to for the resolver to use DNSSEC (and other methods) to authenticate the data it receives and to use some modification of TSIG to authenticate the communication between client and resolver. This model does not make much sense if you stick to the model where hosts pick up their DNS service from the local host. But it makes a great deal of sense when you are using a service like Google's DNS. It would not take a great deal of effort to graft a Kerberos like scheme on to effect key exchange. The real problem with DNSSEC is that it has taken so long that the Internet has changed since. And rather than go back and redesign we are always told that so much time and effort has been spent already that we cannot possibly take any time to look at the issues that might prevent deployment or use. And so instead of the opt-in fix taking six months as it should have done it took six years and instead of the zone walking/privacy issue taking six months it took four years. I am thinking of retitling my RSA talk '2010 The Year of DNSSEC'. I am not trying to beat up people and say do it the way we did it. What I am trying to say here is DON'T REPEAT OUR MISTAKES. Look at the solution that we were forced to adopt when the single rooted hierarchy proved undeployable. On Wed, Feb 17, 2010 at 10:01 AM, Basil Dolmatov d...@cryptocom.ru wrote: Masataka Ohta пишет: But, the most serious defect of DNSSEC, or PKI in general, is that, despite a lot of hypes, it is not cryptographically secure. Social attacks on trusted third parties makes the parties untrustworthy, which means PKI is merely socially or weakly secure. There are a lot of deficiencies in PKI, but at present time I can see no alternative for establishing trust in loosely connected and large systems. If there is one, please advise. For security of interdomain routing, social security of trust relationship between ISPs is just enough to which additional social security by PKI is not helpful. There are no trust relationships between my ISP and your ISP. How my ISP can trust routing announce, which I have got over the network and which has your ISP mentioned as the origin? For security of DNS, social security of trust relationship between ISPs and between zones are just enough to which additional social security by PKI is not helpful. Same question applies to DNS. My resolver have no trust relationships with your server. How I can trust DNS-answer which I have got over the network? Unfortunately, Internet 20 years ago and Internet today are two significantly different networks. 20 years ago I trusted to nearly all network participants and undoubtedly trusted to all network administrators. Now, the necessity to build the chains of trust is obvious, otherwise you will lose a lot. The methods, which are being implemented are definitely not ideal (I knew a lot of flaws and weaknesses in systems, which are using PKI), but at the same time I do not know anything better. dol@ Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
On Wed, 17 Feb 2010, Phillip Hallam-Baker wrote: One mechanism that was unfortunately pushed asside as a result of the fixation on end to end DNSSEC would be to for the resolver to use DNSSEC (and other methods) to authenticate the data it receives and to use some modification of TSIG to authenticate the communication between client and resolver. I don't think that has been pushed aside. There's not much interest in it at the moment because the focus is on authoritative-to-recursive DNSSEC. Maybe attention will turn to recursive-to-stub security once there is more assurance that the recursive server's answers are authentic. It would not take a great deal of effort to graft a Kerberos like scheme on to effect key exchange. Or use SIG(0). Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
On Wed, Feb 17, 2010 at 06:48:37PM +, Tony Finch wrote: On Wed, 17 Feb 2010, Phillip Hallam-Baker wrote: One mechanism that was unfortunately pushed asside as a result of the fixation on end to end DNSSEC would be to for the resolver to use DNSSEC (and other methods) to authenticate the data it receives and to use some modification of TSIG to authenticate the communication between client and resolver. I don't think that has been pushed aside. There's not much interest in it at the moment because the focus is on authoritative-to-recursive DNSSEC. Maybe attention will turn to recursive-to-stub security once there is more assurance that the recursive server's answers are authentic. There is also the camp that thinks that stubs should do validation themselves. It would not take a great deal of effort to graft a Kerberos like scheme on to effect key exchange. Or use SIG(0). Tony. Yeah, I kinda like SIG(0) myself. If you want to use Kerberos for symmetric key management, there is GSS-TSIG. But there is a bootstrapping problem -- Kerberos clients commonly use DNS SRV records to locate Kerberos servers. Most stub resolvers can't do any of this today (HMAC-MD5/SHAxxx TSIG, GSS-TSIG, SIG(0), etc) as far as I can tell. --Shumon. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
On Wed, Feb 17, 2010 at 11:01:38AM -0500, Phillip Hallam-Baker wrote: One mechanism that was unfortunately pushed asside as a result of the fixation on end to end DNSSEC would be to for the resolver to use DNSSEC (and other methods) to authenticate the data it receives and to use some modification of TSIG to authenticate the communication between client and resolver. Whatever made you think that had been pushed aside? And it seems to me SIG(0) will work better. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
