Re: [ietf] DNS spoofing at captive portals
On Sat, Sep 25, 2010 at 10:34:15PM -0400, John R. Levine wrote: Hmm. Are you talking about SiteFinder-like services? Not really. There turn out to be a significant number of domains, in the hundreds of thousands at least, that are purely evil. IMHO, tens of millions is closer to reality. (This of course depends on what one's definition of purely evil is, but mine includes anything set up solely for spam, attacks, malware, or resource exploitation.) But your [larger] point remains: while you and I and others are skilled at spotting such domains and at handling them appropriately, we're a tiny fraction of all Internet users, so it's arguably a service to prevent all of those from blithely accessing the web sites/mail servers/DNS servers/etc. associated with those domains. ---rsk ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
On Tue, Sep 28, 2010 at 5:27 PM, Mark Andrews ma...@isc.org wrote: In message aanlktinbtpvjlqsl87v5xbd0kh_hn+t1wx2mhdfy2...@mail.gmail.comaanlktinbtpvjlqsl87v5xbd0kh_hn%2bt1wx2mhdfy2...@mail.gmail.com, Phil lip Hallam-Baker writes: The most frustrating part about DNSSEC is that trying to pin down what it is and what it is not, what it is trying to do and what it is not is like trying to nail jello to a wall. DNSSEC is a tool. It can be used in lots of ways. It can be configured in lots of ways. But which of those ways are people prepared to stand behind and for which ones am I going to be told 'we aren't trying to solve that problem'. Which is perfectly possible to do with DNSSEC + TSIG or DNSSEC + SIG(0) or DNSSEC + GSS-TSIG or DNSSEC + IPSEC or That is four different possible ways, none of which I would describe as perfect. In addition there is TKEY + TSIG (RFC2930). This is a standards organization, there is a difference between four possibilities based on existing standards and a 'standard' in my view. We certainly have the basis for developing that type of standard, but to claim that we have one when there a five options and no understanding of the tradeoffs is a little previous in my view. Having looked at deployment of these schemes on a resolver large enough to have a high probability of DNSSEC cache hits, I cannot see a way to make the existing schemes work without making the performance issues of DNSSEC worse, which is not very helpful when you are trying to work out how to minimize the impact of deploying DNSSEC. What I originally said was that I don't regard DNSSEC as appropriate for intra-domain trust. What I did not say is 'broken'. I think that a lot of the limitations people are finding in the DNSSEC model come from the fact that in order to make the best use of information from the DNSSEC it is necessary to have more information available to the client than is available in a single request and response. Once you have the ability to aggregate more information the value of DNSSEC becomes much greater and the probability of providing protection in a real world security context is much greater. As you say, DNSSEC is currently just a tool. Now we have to work out how to make best use of it. -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
On 28 Sep 2010, at 02:20, Phillip Hallam-Baker hal...@gmail.com wrote: On Mon, Sep 27, 2010 at 10:48 AM, Tony Finch d...@dotat.at wrote: On Fri, 24 Sep 2010, Phillip Hallam-Baker wrote: DNSSEC is a mechanism for establishing inter-domain trust. It is not an appropriate technology for intra-domain trust. Why not? Because the root of trust for any enterprise is the enterprise itself. Not ICANN. DNSSEC does not require you to use only ICANN's trust anchor. You can also use your enterprise trust anchor, so you can validate your enterprise DNS independently of any third party. (The keyassure work might make this approach to key distribution easier than running an enterprise X.509 CA. DNSSEC also has the advantage of a defined trust anchor rollover protocol.) You can also use third party trust anchors such as the ISC's DLV. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
Because the root of trust for any enterprise is the enterprise itself. Not ICANN. On Mon, Sep 27, 2010 at 10:48 AM, Tony Finch d...@dotat.at wrote: On Fri, 24 Sep 2010, Phillip Hallam-Baker wrote: DNSSEC is a mechanism for establishing inter-domain trust. It is not an appropriate technology for intra-domain trust. Why not? Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
The most frustrating part about DNSSEC is that trying to pin down what it is and what it is not, what it is trying to do and what it is not is like trying to nail jello to a wall. Whenever an issue is raised with the DNSSEC protocol, someone immediately shoots back the reply 'well we are not trying to solve that problem'. Which is of course really easy when there is no clear statement of what real world security issues that DNSSEC is trying to deal with. Blocking one attack does not come close to justifying the cost of DNSSEC deployment. Is DLV a part of DNSSEC or not? I am not sure. DLV is presented as being a stopgap, an interim measure to go away with full DNSSEC deployment. What I do know is that I want to use secure DNS in devices that are not capable of performing public key cryptography. And even if every end point device is capable of performing RSA2048 operations in acceptable time, I do not want to push my trust management criteria out to my network endpoints. On Tue, Sep 28, 2010 at 4:23 AM, Tony Finch d...@dotat.at wrote: On 28 Sep 2010, at 02:20, Phillip Hallam-Baker hal...@gmail.com wrote: On Mon, Sep 27, 2010 at 10:48 AM, Tony Finch d...@dotat.atd...@dotat.atwrote: On Fri, 24 Sep 2010, Phillip Hallam-Baker wrote: DNSSEC is a mechanism for establishing inter-domain trust. It is not an appropriate technology for intra-domain trust. Why not? Because the root of trust for any enterprise is the enterprise itself. Not ICANN. DNSSEC does not require you to use only ICANN's trust anchor. You can also use your enterprise trust anchor, so you can validate your enterprise DNS independently of any third party. (The keyassure work might make this approach to key distribution easier than running an enterprise X.509 CA. DNSSEC also has the advantage of a defined trust anchor rollover protocol.) You can also use third party trust anchors such as the ISC's DLV. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/http://dotat.at/ -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
In message aanlktinbtpvjlqsl87v5xbd0kh_hn+t1wx2mhdfy2...@mail.gmail.com, Phil lip Hallam-Baker writes: The most frustrating part about DNSSEC is that trying to pin down what it is and what it is not, what it is trying to do and what it is not is like trying to nail jello to a wall. DNSSEC is a tool. It can be used in lots of ways. It can be configured in lots of ways. Whenever an issue is raised with the DNSSEC protocol, someone immediately shoots back the reply 'well we are not trying to solve that problem'. Which is of course really easy when there is no clear statement of what real world security issues that DNSSEC is trying to deal with. Blocking one attack does not come close to justifying the cost of DNSSEC deployment. It's designed to block a whole series of attacks and to be an enabling tools to do other things which are not possible with a insecure DNS. Is DLV a part of DNSSEC or not? I am not sure. DLV fills one of the left to the user how to do this parts of DNSSEC. How to distribute/configure the trust anchors DNSSEC needs to do its job. It uses DNSSEC to secure that distribution and requires one configured trust anchor to boot strap the process. This is conceptually no different to what IANA did with its ITAR. This is how it was presented to the IESG when the DLV record was being allocated. DLV is presented as being a stopgap, an interim measure to go away with full DNSSEC deployment. Which deals with which trust anchors are added and removed from the collection and when that is done. What I do know is that I want to use secure DNS in devices that are not capable of performing public key cryptography. And even if every end point device is capable of performing RSA2048 operations in acceptable time, I do not want to push my trust management criteria out to my network endpoints. Which is perfectly possible to do with DNSSEC + TSIG or DNSSEC + SIG(0) or DNSSEC + GSS-TSIG or DNSSEC + IPSEC or On Tue, Sep 28, 2010 at 4:23 AM, Tony Finch d...@dotat.at wrote: On 28 Sep 2010, at 02:20, Phillip Hallam-Baker hal...@gmail.com wrote: On Mon, Sep 27, 2010 at 10:48 AM, Tony Finch d...@dotat.atd...@dotat.atw rote: On Fri, 24 Sep 2010, Phillip Hallam-Baker wrote: DNSSEC is a mechanism for establishing inter-domain trust. It is not an appropriate technology for intra-domain trust. Why not? Because the root of trust for any enterprise is the enterprise itself. Not ICANN. DNSSEC does not require you to use only ICANN's trust anchor. You can also use your enterprise trust anchor, so you can validate your enterprise DNS independently of any third party. (The keyassure work might make this approach to key distribution easier than running an enterprise X.509 CA. DNSSEC also has the advantage of a defined trust anchor rollover protocol.) You can also use third party trust anchors such as the ISC's DLV. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/http://dotat.at/ -- Website: http://hallambaker.com/ --001636e0a79c19803a04915324b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable divThe most frustrating part about DNSSEC is that trying to pin down what= it is and what it is not, what it is trying to do and what it is not is li= ke trying to nail jello to a wall./divdivbr/divdivWhenever an iss= ue is raised with the DNSSEC protocol, someone immediately shoots back the = reply #39;well we are not trying to solve that problem#39;. Which is of c= ourse really easy when there is no clear statement of what real world secur= ity issues that DNSSEC is trying to deal with./div divbr/divdivBlocking one attack does not come close to justifying t= he cost of DNSSEC deployment./divdivbr/divdivbr/divdivIs DL= V a part of DNSSEC or not? I am not sure.=A0/divdivbr/divdivDLV i= s presented as being a stopgap, an interim measure to go away with full DNS= SEC deployment.=A0/div divbr/divdivWhat I do know is that I want to use secure DNS in devi= ces that are not capable of performing public key cryptography. And even if= every end point device is capable of performing RSA2048 operations in acce= ptable time, I do not want to push my trust management criteria out to my n= etwork endpoints./div divbr/divdivbr/divdivbr/divOn Tue, Sep 28, 2010 at 4:23 A= M, Tony Finch span dir=3Dltrlt;a href=3Dmailto:d...@dotat.at;d...@dot= at.at/agt;/span wrote:brdiv class=3Dgmail_quoteblockquote class= =3Dgmail_quote style=3Dmargin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex; div bgcolor=3D#FFdiv class=3DimdivspanOn 28 Sep 2010, at 02= :20, Phillip Hallam-Baker lt;a href=3Dmailto:hal...@gmail.com; target=3D= _blankhal...@gmail.com/agt; wrote:/spanbr/divblockquote type= =3Dcite divdivdivdiv class=3Dgmail_quoteOn Mon, Sep 27, 2010 at 10:48 AM,= Tony Finch span dir=3Dltrlt;a href=3Dmailto:d...@dotat.at; target=3D= _blank/aa
Re: [ietf] DNS spoofing at captive portals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi John, On 09/26/2010 04:34 AM, John R. Levine wrote: But we have real situtations where the opposite is true, quite possibly more often than the other way around. Not really. There turn out to be a significant number of domains, in the hundreds of thousands at least, that are purely evil. Some host So, if DNSSEC is enabled with an end-host validator and the ISP cache returns a different record for such a domain, the DNSSEC validator will mark it as bogus and the user gets a serverfailure response. The domain cannot be accessed. This is exactly right. DNSSEC provides integrity checks, it does not synthesize the original data out of thin air. Thus, domains can be blocked. As I said in a previous message, I am not a big fan of rewriting NXDOMAIN, and I was on one of ICANN's advisory committees and helped Showing an advert then, does not work. Of course, showing an advert on someone elses domain name is not particularly nice. So, an ISP can provide a DNSSEC-enabled cache (that can validate as well), and can block malware, and end-users can use that cache, and run their own validator to secure the path to the ISP cache. So, an end-user can run a validator that is still a 'stub' that connects to the ISP cache. This is much more efficient too as the ISP cache has all the data (and DNSSEC signatures) in its cache. A remaining stumbling block (well, once the ISP runs a DNSSEC cache), is the cablemodem-thingy, but it turns out these can (very often) be circumvented by providing the validating-stub on the end-users machine with the direct IP-address(es) of the ISP cache. Best regards, Wouter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkygTQYACgkQkDLqNwOhpPgbdACfbCRxW3Rii+MlFOUVeCl+HVRM CJwAoLHbvFWyMSH+rf0wjuCcNR2jnz88 =JuT/ -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
The point raised by John Levine is amongst my concerns. And one of the reasons that I have been looking at a different approach to the use of DNSSEC information that does not change the DNS model as radically as the end to end DNSSEC model. The idea of using DNS resolver as a proxy is a good one in my view. The problem with that model comes from the broken idea that a mobile host should accept any DNS service offered via DHCP. A DNS resolver is a trusted service, a host should not take just any DNS resolver, it should choose a resolver and establish a secure connection to it that at a minimum provides authentication but should ideally provide confidentiality as well. This is the case irregardless of whether DNSSEC is deployed or not. A DNS resolver is a trusted intermediary even in the case that DNSSEC deployment at servers is ubiquitous and clients are capable of DNSSEC end-to-end. Once we have a model in which the DNS resolver relationship is trusted and the communication to that resolver is secured, it is possible to use the DNS resolver in much more interesting ways. An end host can no more make sense of DNSSEC information on its own than a single mail server can deal with spam effectively. A DNS resolver with substantial throughput can collect the state data necessary to apply DNS information intelligently. DNSSEC is a mechanism for establishing inter-domain trust. It is not an appropriate technology for intra-domain trust. I do not want to connect my machines to every domain in the ICANN DNS repository. And I certainly don't want ICANN to start restricting issue of domains to people I or anyone else approves. DNSSEC can tell my resolver what the authoritative DNS registry is. But that resolver will then edit that registry to remove the domains that do not meet my security criteria. On Fri, Sep 24, 2010 at 8:16 PM, John Levine jo...@iecc.com wrote: Plan A: few consumers will use DNSSEC between their PCs and the ISP's resolver, so they won't notice. Plan B: consumers will observe that malicious impersonation of far away DNS servers is rare and exotic, but malware spam arrives hourly, so they will make a rational tradeoff, take their ISP's advice, and turn off DNSSEC. Something else occurs to me: Plan C: Sophisticated ISPs might configure their own DNSSEC key into customer resolvers, and sign replacement records with that. The threat model for DNSSEC has always been, approximately, that the authoritative server at the far end is friendly, and the middleboxes are hostile. But we have real situtations where the opposite is true, quite possibly more often than the other way around. If we want people deploying DNSSEC widely, we need to make sure it handles the actual threats they face. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
That is not the right question. The question should be, who chooses for me? My answer to the question does not have to be the same as other people's. Some people will want the full ICANN registry with every scammy malware site and every DNS name registered five minutes ago. Others will prefer to have only the ones proven safe. If I was running a power station in the US, I would probably be quite happy with a very short list indeed. Gen Alexander is proposing a separate network for critical infrastructure. I think that an edited DNS could play a very important role. On Fri, Sep 24, 2010 at 9:10 PM, bill manning bmann...@isi.edu wrote: On 24September2010Friday, at 17:16, John Levine wrote: Plan A: few consumers will use DNSSEC between their PCs and the ISP's resolver, so they won't notice. Plan B: consumers will observe that malicious impersonation of far away DNS servers is rare and exotic, but malware spam arrives hourly, so they will make a rational tradeoff, take their ISP's advice, and turn off DNSSEC. Something else occurs to me: Plan C: Sophisticated ISPs might configure their own DNSSEC key into customer resolvers, and sign replacement records with that. The threat model for DNSSEC has always been, approximately, that the authoritative server at the far end is friendly, and the middleboxes are hostile. But we have real situtations where the opposite is true, quite possibly more often than the other way around. presuming your statement about an inversion of the stated trust model is correct, can we dereference friendly and hostile to whom? Who makes that assessment and who/what defines the tools to implement a trust policy? --bill If we want people deploying DNSSEC widely, we need to make sure it handles the actual threats they face. R's, John PS: If I plug my random Windows PC or Mac into a cable modem, and I tell it to use DNSSEC, where does it get the top level validation keys? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
actually, it was the right questions... and the answers all distill down to your reply. security and trust are in the eyes/validator of the beholder. Sam Weiler borrowed the term local policy - which trumps any middleman. Steve B. suggests VPNs (or their functioal eqivalant) between the authoritative or trusted source and the end-system validator - where in this context, the validator/resolver is w/in a couple usec of the application; e.g. in the same box. you can do it yourself or you can outsource it to someone else. end of the day, its the end-system operators choice. the tools for crisply defining the constrainsts of local policy are still very crude/fuzzy/undefined. --bill On Fri, Sep 24, 2010 at 10:16:05PM -0400, Phillip Hallam-Baker wrote: That is not the right question. The question should be, who chooses for me? My answer to the question does not have to be the same as other people's. Some people will want the full ICANN registry with every scammy malware site and every DNS name registered five minutes ago. Others will prefer to have only the ones proven safe. If I was running a power station in the US, I would probably be quite happy with a very short list indeed. Gen Alexander is proposing a separate network for critical infrastructure. I think that an edited DNS could play a very important role. On Fri, Sep 24, 2010 at 9:10 PM, bill manning bmann...@isi.edu wrote: On 24September2010Friday, at 17:16, John Levine wrote: Plan A: few consumers will use DNSSEC between their PCs and the ISP's resolver, so they won't notice. Plan B: consumers will observe that malicious impersonation of far away DNS servers is rare and exotic, but malware spam arrives hourly, so they will make a rational tradeoff, take their ISP's advice, and turn off DNSSEC. Something else occurs to me: Plan C: Sophisticated ISPs might configure their own DNSSEC key into customer resolvers, and sign replacement records with that. The threat model for DNSSEC has always been, approximately, that the authoritative server at the far end is friendly, and the middleboxes are hostile. But we have real situtations where the opposite is true, quite possibly more often than the other way around. presuming your statement about an inversion of the stated trust model is correct, can we dereference friendly and hostile to whom? Who makes that assessment and who/what defines the tools to implement a trust policy? --bill If we want people deploying DNSSEC widely, we need to make sure it handles the actual threats they face. R's, John PS: If I plug my random Windows PC or Mac into a cable modem, and I tell it to use DNSSEC, where does it get the top level validation keys? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
I don't see why DNSSEC makes dropping out zones impossible. All DNSSEC does is to enable the end point to know that there is data missing. It does not provide the end zone with any way to find the missing data, nor is there any user interaction that makes any real sense in that situation. But the real answer to the problem is that the root zone signature is not the root of trust for my DNS, it is the root of trust for the ICANN DNS. myDNS = icannDNS - maliciousDNS I plan to publish my root cert for my zone at the apex of my DNS zone and establish that out-of-band as the trust anchor for every device and application in my network. Hosts in my network will determine that a secure DNS resolver is available for the zone via the ESRV mechanism I recently proposed and establish a secure tunnel with my DNS resolver via a protocol TBS, but probably based on either the TLS handshake to establish a ticket containing all necessary server-side state or the existing (but rather old and needing much revision) TKEY mechanism and either TSIG or a cryptographic packaging mechanism TBS. It would also be possible to adapt either DTLS or IPSEC. But neither of those is well suited to use as a security wrapper for DNS for reasons I won't go into here. On Sun, Sep 26, 2010 at 12:26 PM, Tony Finch d...@dotat.at wrote: On 25 Sep 2010, at 01:16, John Levine jo...@iecc.com wrote Plan C: Sophisticated ISPs might configure their own DNSSEC key into customer resolvers, and sign replacement records with that. DNSSEC's validation model makes this basically impossible. The customer resolvers would have to know ahead of time which names will be overridden by their ISP and so may be validated by the extra trust anchor. Plan D: ISPs that want to block the DNS for evil domains just return a server failure response for the appropriate queries. See also Paul Vixie's RPZ proposal. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
On Fri, 24 Sep 2010, Phillip Hallam-Baker wrote: DNSSEC is a mechanism for establishing inter-domain trust. It is not an appropriate technology for intra-domain trust. Why not? Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
On 27September2010Monday, at 7:48, Tony Finch wrote: On Fri, 24 Sep 2010, Phillip Hallam-Baker wrote: DNSSEC is a mechanism for establishing inter-domain trust. It is not an appropriate technology for intra-domain trust. Why not? Because the atomic unit of DNSSEC is a domain/zone/delegation, not a specific RRset. Everything in a domain has the exact same threat model. --bill Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
On Sep 24, 2010, at 5:17 PM, John Levine wrote: IANAL but would think that such practice should expose the operator of the server or proxy to civil and/or criminal action, both from the operators of the zones whose RRs are being misrepresented, and from the users' whose applications are affected. I'm not a lawyer either, but I at least know that fraud requires intent. If a naive user clicks on a link in spam, and the DNS cache intercepts the request and returns a pointer to a warning page rather than a Ukranian malware site, that's not fraud, that's a service. No, it's still fraud. You might personally believe that it's okay for an ISP to do harm to a site that it believes is distributing malware, but a court of law might see it differently. Nobody has given the ISP the authority to misrepresent others' DNS zones. I want my ISP to deliver packets to their destination addresses, not to try to second-guess which destination addresses I actually want to talk to. That is completely outside of their area of competence. Nor is it within the ISP's competence to decide that HTTP needs to work well (according to its definition of well) at the expense of all other applications. Now if an ISP allows users to opt-in to such a service, telling its prospective customers what it's going to do to DNS responses and explaining to them all of the various ways that their service can harm applications, that's a different matter. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
[I suspect you may know much of this, but just in case...] On Sep 24, 2010, at 5:16 PM, John Levine wrote: Plan A: few consumers will use DNSSEC between their PCs and the ISP's resolver, so they won't notice. In general, consumers won't be using DNSSEC between their PCs and ISPs. PCs typically use stub resolvers and while there are ways to secure the communication between the stub resolver and the ISP's (perhaps validating) resolver, namely SIG(0) or TSIG, I don't know of any implementations that make this easy enough for your average end user to use and in the case of TSIG, (symmetric) key management will be a bear. Given existing prevalent technology, you either trust your ISP and the communication path between yourself and that ISP or you run your own validating resolver. Note that if you take the latter route, you'll often find yourself frustrated when you try to roam on services like T-Mobile Hotspot (you _must_ use their resolver for initial validation). Plan B: consumers will observe that malicious impersonation of far away DNS servers is rare and exotic, but malware spam arrives hourly, so they will make a rational tradeoff, take their ISP's advice, and turn off DNSSEC. Not sure I see the relationship between malware spam and DNSSEC. Given most validation occurs at the ISP, in the case of an actual DNSSEC-preventable attack the end user will most likely get a friendly message from their web browser saying can't find the server or perhaps bounced mail because the destination email address didn't resolve. The end user will then call the ISP and say Internet's broke. Fix it!. In the cases where an actual cache poisoning attack is taking place (which, I'm told, is actually occurring thanks to scripts that implement the Kaminsky Method), the ISP end user support staff can say Hah! We protected you from Evil!. In the (likely more frequent) cases where a signature has expired or there is some other misconfiguration, the ISP end user support staff can say try this IP address. If the domain is popular enough, the ISP could even pre-populate their cache with the correct IP address so they stop getting support calls. However, I suspect if enough of the misconfiguration-variety of validation failures oc cur, the ISP will get tired of the additional support cost and turn off DNSSEC. Something else occurs to me: Plan C: Sophisticated ISPs might configure their own DNSSEC key into customer resolvers, and sign replacement records with that. Given current technology, I suspect this would be rather unlikely since it implies the customer is bright enough to set up their own validating resolver. In such cases, I'd think the customer would question why their ISP is asking them to use an ISP-specific trust anchor. The threat model for DNSSEC has always been, approximately, that the authoritative server at the far end is friendly, and the middleboxes are hostile. It's more that the authoritative server is ... well, authoritative and that anything in between can't really be trusted. But we have real situtations where the opposite is true, quite possibly more often than the other way around. Hmm. Are you talking about SiteFinder-like services? If we want people deploying DNSSEC widely, we need to make sure it handles the actual threats they face. As I mentioned, I have been told by reputable sources that folks are actually experiencing the Kaminsky method cache poisoning attacks, so that threat is real. The problem is that some folks have been trumpeting DNSSEC as a solution to many problems when in fact, it solves a relatively rare (albeit real) attack. All DNSSEC really does is ensure a DNS response hasn't been mucked with in transit from the authoritative server to the validating resolver. DNSSEC can't help you between the validating resolver and the originating requester if you can't trust that path and it can't help you if you can't trust the authoritative server. DNSSEC may be used as a trustable infrastructure to allow folks to do other things (see the keyassure proto-wg), but that's in the future... PS: If I plug my random Windows PC or Mac into a cable modem, and I tell it to use DNSSEC, where does it get the top level validation keys? In order to use DNSSEC (at least today), you have to run a validating resolver on your PC or Mac and you have to specify the trust anchor(s) in the name server configuration file. The trust anchor you'd most likely want to configure is available from http://data.iana.org/root-anchors/. Presumably, if you're ambitious enough to figure out how to run your own validating resolver, you'll be able to figure out how to add the trust anchor to your config file. Or at least that's the theory... Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
Not sure I see the relationship between malware spam and DNSSEC. See below. But we have real situtations where the opposite is true, quite possibly more often than the other way around. Hmm. Are you talking about SiteFinder-like services? Not really. There turn out to be a significant number of domains, in the hundreds of thousands at least, that are purely evil. Some host websites with drive-by malware installs, with victims pointed there by links in spam or various malicious SEO tricks in search engines. Some are command and control (CC) hosts that existing bots use to update themselves and get new instructions. Last year the Conficker Working Group did a great deal of quiet work preemptively registering or reserving the domains that the conficker 'bot tried to use to contact CC. See this for more info http://www.confickerworkinggroup.org/wiki/pmwiki.php/TLD/TLDOperators They were reasonably successful until the bad guys switched to ccTLDs that were less cooperative about reserving domains. Unless you are a malware researcher, it is overwhelmingly likely that any request for one of those domains is from a 'bot, not from you, and if a large ISP like Comcast intercepts them, it makes a significant difference to the amount of active malware on their networks. I have even heard of ISPs redirecting CC requests to a local server that sends the bot instructions to turn itself off. (I don't know whether Comcast does that, and I doubt they'd tell me if I asked.) As I said in a previous message, I am not a big fan of rewriting NXDOMAIN, and I was on one of ICANN's advisory committees and helped them get rid of Sitefinder, but if an ISP does it on consumer networks where there aren't supposed to be servers, the damage from doing so is hard to show, so I'm not inclined to make a big deal about it. So anyway, there are some good reasons for ISPs to mess with the DNS results their caches provide their users. If we ask them to use tools that will keep them from doing so, it won't happen. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
At Fri, 24 Sep 2010 07:21:21 -0400, Michael Richardson wrote:
Has the IETF (or rather then IAB) written any simple documents that
explain to less informed (i.e. marketing/product) managers why it
is a bad thing for a captive portal to spoof DNS replies?
(not just in regard to DNSSEC, but also in regards to just caching)
a) Most of the arguments explained in the 2003 IAB Commentary:
Architectural Concerns on the use of DNS Wildcards,
http://www.IAB.ORG/documents/docs/2003-09-20-dns-wildcards.html,
apply in a similar fashion, but it indeed would be a good idea
to produce such document. I think much text from 2003 could
be leveraged.
b) It should be clearly spelled out that this practice falls among the
category of actions commonly known as man-in-the-middle attacks.
c) draft-livingood-dns-redirect and draft-livingood-dns-malwareprotect
descibe these services in a much too friendly tone;
terms like service and benefits for users are clearly
abuse of language -- the above IAB statement already indicates
that similar interference with the DNS causes severe damage
to user perception and performance.
These drafts should clearly spell out the downside of these
methods and their fundamental nature, being MitM attacks.
d) In my personal opinion, the original idea of having recursive
DNS resolvers located close to the hosts should be given more
traction again in the future. All kinds of SOHO access gateways
or home gateways should preferably offer (locally) full recursive
and validating DNS resolution service. The ISP-based DNS recursor
was (and perhaps still is) a good idea in low-bandwidth (dial-in)
access networks, where the (bandwidth and monetary) costs of full
DNS service actually matter and are detrimental for the users, but
it does not make sense any more for broadband access networks with
(almost) bandwidth-usage independent billing models (flat rates).
Thus the dependency on (both technically and policy-wise!) powerful
central caching resolvers could be reduced dramatically.
DNSSEC validation makes most sense for applications when performed
as close as possible to the stub resolver, if the latter cannot
perform this function itself; this way, the unprotected path
at least is constrained to within the users' sites and hence their
own administrative domain.
Experience has shown that huge central resolver systems are very
attractive targets for external attacks as well as for insider
attacks (like ${subject}).
Kind regards,
Alfred Hönes.
--
+++
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: a...@tr-sys.de |
+++
-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
This document is probably relevant, although it goes the route of
providing guidelines for minimum breakage rather than forbidding.
http://tools.ietf.org/html/draft-livingood-dns-redirect-02
On Sep 24, 2010, at 8:38 AM, Alfred HÎnes wrote:
At Fri, 24 Sep 2010 07:21:21 -0400, Michael Richardson wrote:
Has the IETF (or rather then IAB) written any simple documents that
explain to less informed (i.e. marketing/product) managers why it
is a bad thing for a captive portal to spoof DNS replies?
(not just in regard to DNSSEC, but also in regards to just caching)
a) Most of the arguments explained in the 2003 IAB Commentary:
Architectural Concerns on the use of DNS Wildcards,
http://www.IAB.ORG/documents/docs/2003-09-20-dns-wildcards.html,
apply in a similar fashion, but it indeed would be a good idea
to produce such document. I think much text from 2003 could
be leveraged.
b) It should be clearly spelled out that this practice falls among the
category of actions commonly known as man-in-the-middle attacks.
c) draft-livingood-dns-redirect and draft-livingood-dns-malwareprotect
descibe these services in a much too friendly tone;
terms like service and benefits for users are clearly
abuse of language -- the above IAB statement already indicates
that similar interference with the DNS causes severe damage
to user perception and performance.
These drafts should clearly spell out the downside of these
methods and their fundamental nature, being MitM attacks.
d) In my personal opinion, the original idea of having recursive
DNS resolvers located close to the hosts should be given more
traction again in the future. All kinds of SOHO access gateways
or home gateways should preferably offer (locally) full recursive
and validating DNS resolution service. The ISP-based DNS recursor
was (and perhaps still is) a good idea in low-bandwidth (dial-in)
access networks, where the (bandwidth and monetary) costs of full
DNS service actually matter and are detrimental for the users, but
it does not make sense any more for broadband access networks with
(almost) bandwidth-usage independent billing models (flat rates).
Thus the dependency on (both technically and policy-wise!) powerful
central caching resolvers could be reduced dramatically.
DNSSEC validation makes most sense for applications when performed
as close as possible to the stub resolver, if the latter cannot
perform this function itself; this way, the unprotected path
at least is constrained to within the users' sites and hence their
own administrative domain.
Experience has shown that huge central resolver systems are very
attractive targets for external attacks as well as for insider
attacks (like ${subject}).
Kind regards,
Alfred HÎnes.
--
+
++
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-
Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax:
-18 |
| D-71254 Ditzingen | E-Mail: a...@tr-
Sys.de |
+
++
-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
c) draft-livingood-dns-redirect and draft-livingood-dns-malwareprotect draft-livingood-dns-malwareprotect concerns what is primarily an opt-in service to block known malware sites for end users. Hopefully that is less controversial than the redirect one, but who knows. draft-livingood-dns-redirect was written to do two things. First was to document a relatively long-standing process in a reference-able IETF document where no documentation previously existed. Second was to document the best or least worst way to approach it, if a party was planning to do so. Since that time, I've added a bunch of stuff related to DNSSEC to make clear an incompatibility there. I'm a bit conflicted though about whether to keep it as informational or consider historic. In any case, as noted below, I'm more than happy to consider any text that might improve these document by providing more information on opposing viewpoints, etc. descibe these services in a much too friendly tone; terms like service and benefits for users are clearly abuse of language -- the above IAB statement already indicates Sorry you feel that way. Operators view these as services and describe them as such, so I am simply using that language. As I do my next pass through the documents I will review it for any non-neutral descriptors. Of course, also feel free to email me a list of the ones you think I should consider revising in some manner. that similar interference with the DNS causes severe damage to user perception and performance. The 2nd draft concerns protection from malware, which is generally assumed to be a service that users opt-into (a la OpenDNS, etc.). Those users who have decided to use such services very likely are much more concerned with malware than the fact that FQDNs associated with malware would be blocked. Again, I'm quite willing to include text you wish to propose to capture alternative viewpoints and criticisms, as that's an important part of such a document IMHO. These drafts should clearly spell out the downside of these methods and their fundamental nature, being MitM attacks. I'm happy to consider any text you would like to propose, and am quite willing to include specific notes that some in the community consider the techniques MitM attacks, in order to try to capture all viewpoints on the subject. Feel free to send any proposed text to me via email. Regards, Jason ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
At 6:18 PM + 9/24/10, Livingood, Jason wrote: I'm a bit conflicted though about whether to keep it as informational or consider historic. If it describes something that you believe is currently deployed, even if you think that deployment is non-optimal, it should be marked as Informational. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
On Sep 24, 2010, at 8:38 AM, Alfred HÎnes wrote: At Fri, 24 Sep 2010 07:21:21 -0400, Michael Richardson wrote: Has the IETF (or rather then IAB) written any simple documents that explain to less informed (i.e. marketing/product) managers why it is a bad thing for a captive portal to spoof DNS replies? (not just in regard to DNSSEC, but also in regards to just caching) a) Most of the arguments explained in the 2003 IAB Commentary: Architectural Concerns on the use of DNS Wildcards, http://www.IAB.ORG/documents/docs/2003-09-20-dns-wildcards.html, apply in a similar fashion, but it indeed would be a good idea to produce such document. I think much text from 2003 could be leveraged. One important thing to realize is that this kind of service isn't always implemented using wildcards. Sometimes the service is implemented using interception proxies. b) It should be clearly spelled out that this practice falls among the category of actions commonly known as man-in-the-middle attacks. Agreed. Actually, when a server or interception proxy deliberately misrepresents the contents of others' DNS zones, the appropriate term (IMO) is fraud. IANAL but would think that such practice should expose the operator of the server or proxy to civil and/or criminal action, both from the operators of the zones whose RRs are being misrepresented, and from the users' whose applications are affected. c) draft-livingood-dns-redirect and draft-livingood-dns-malwareprotect descibe these services in a much too friendly tone; Strongly agree, at least for the -redirect draft. At the very least, a distinction needs to be made between services which the individual user deliberately chooses, and services which are imposed without the users' knowledge or consent. The draft also glosses over the problems created by this practice for all applications other than web browsing by human beings. Not only does this provide misleading error indications for all other applications, it even breaks applications that are layered on top of HTTP. d) In my personal opinion, the original idea of having recursive DNS resolvers located close to the hosts should be given more traction again in the future. All kinds of SOHO access gateways or home gateways should preferably offer (locally) full recursive and validating DNS resolution service. Agree with this also. In many cases the ideal model seems to be one in which the host serves as its own primary DNS server, or at least as the master DNS zone. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
IANAL but would think that such practice should expose the operator of the server or proxy to civil and/or criminal action, both from the operators of the zones whose RRs are being misrepresented, and from the users' whose applications are affected. I'm not a lawyer either, but I at least know that fraud requires intent. If a naive user clicks on a link in spam, and the DNS cache intercepts the request and returns a pointer to a warning page rather than a Ukranian malware site, that's not fraud, that's a service. If you claim otherwise, people will look at you quizzically, like you're spouting nonsense, which under the circumstances would be understandable. It also reinforces the perception that the IETF is out of touch and hasn't noticed that it's no longer 1990. Any analysis of DNS spoofing needs to take into account intentions and tradeoffs. On networks of consumer PCs, intercepting requests for malware sites is a 100% win. I'm not thrilled about the practice of replacing NXDOMAIN with the A record of a page of links to lexically similar web sites, but the actual harm of doing that on consumer networks (not networks with servers) is pretty hard to show. Replacing a valid record that isn't a pointer to malware with another is indeed bad, but I don't know anyone who does that. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
On Sep 24, 2010, at 5:17 19PM, John Levine wrote: IANAL but would think that such practice should expose the operator of the server or proxy to civil and/or criminal action, both from the operators of the zones whose RRs are being misrepresented, and from the users' whose applications are affected. I'm not a lawyer either, but I at least know that fraud requires intent. If a naive user clicks on a link in spam, and the DNS cache intercepts the request and returns a pointer to a warning page rather than a Ukranian malware site, that's not fraud, that's a service. If you claim otherwise, people will look at you quizzically, like you're spouting nonsense, which under the circumstances would be understandable. It also reinforces the perception that the IETF is out of touch and hasn't noticed that it's no longer 1990. Any analysis of DNS spoofing needs to take into account intentions and tradeoffs. On networks of consumer PCs, intercepting requests for malware sites is a 100% win. I'm not thrilled about the practice of replacing NXDOMAIN with the A record of a page of links to lexically similar web sites, but the actual harm of doing that on consumer networks (not networks with servers) is pretty hard to show. Replacing a valid record that isn't a pointer to malware with another is indeed bad, but I don't know anyone who does that. It will be interesting to see what will happen to these services when DNSSEC is used more widely. Me -- VPNs are your friend; I use them to deflect all sorts of damage. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
It will be interesting to see what will happen to these services when DNSSEC is used more widely. Plan A: few consumers will use DNSSEC between their PCs and the ISP's resolver, so they won't notice. Plan B: consumers will observe that malicious impersonation of far away DNS servers is rare and exotic, but malware spam arrives hourly, so they will make a rational tradeoff, take their ISP's advice, and turn off DNSSEC. Malware that infects browsers and rewrites bank transactions on the fly is a huge problem, particularly in Europe, and requires no DNS funny business at all. We can certainly imagine attacks that depend on DNS poisoning, but any tradeoff that makes it easier to get infected by malware is, for typical PC users, a foolish one. Be careful what you ask for, and all that. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
Plan A: few consumers will use DNSSEC between their PCs and the ISP's resolver, so they won't notice. Plan B: consumers will observe that malicious impersonation of far away DNS servers is rare and exotic, but malware spam arrives hourly, so they will make a rational tradeoff, take their ISP's advice, and turn off DNSSEC. Something else occurs to me: Plan C: Sophisticated ISPs might configure their own DNSSEC key into customer resolvers, and sign replacement records with that. The threat model for DNSSEC has always been, approximately, that the authoritative server at the far end is friendly, and the middleboxes are hostile. But we have real situtations where the opposite is true, quite possibly more often than the other way around. If we want people deploying DNSSEC widely, we need to make sure it handles the actual threats they face. R's, John PS: If I plug my random Windows PC or Mac into a cable modem, and I tell it to use DNSSEC, where does it get the top level validation keys? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [ietf] DNS spoofing at captive portals
On 24September2010Friday, at 17:16, John Levine wrote: Plan A: few consumers will use DNSSEC between their PCs and the ISP's resolver, so they won't notice. Plan B: consumers will observe that malicious impersonation of far away DNS servers is rare and exotic, but malware spam arrives hourly, so they will make a rational tradeoff, take their ISP's advice, and turn off DNSSEC. Something else occurs to me: Plan C: Sophisticated ISPs might configure their own DNSSEC key into customer resolvers, and sign replacement records with that. The threat model for DNSSEC has always been, approximately, that the authoritative server at the far end is friendly, and the middleboxes are hostile. But we have real situtations where the opposite is true, quite possibly more often than the other way around. presuming your statement about an inversion of the stated trust model is correct, can we dereference friendly and hostile to whom? Who makes that assessment and who/what defines the tools to implement a trust policy? --bill If we want people deploying DNSSEC widely, we need to make sure it handles the actual threats they face. R's, John PS: If I plug my random Windows PC or Mac into a cable modem, and I tell it to use DNSSEC, where does it get the top level validation keys? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
