Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
So we have totally abandoned the idea of doing DNSSEC in the end point client? Trust roots have to be valid for at least a decade to be acceptable to the application vendor community. And even though the current model of network administration is to constantly fiddle with everything, I think that is going to have to stop. On Thu, Jun 11, 2009 at 8:48 PM, Mark Andrewsma...@isc.org wrote: In message a123a5d60906110800i58353c99wc6b16a50395dc...@mail.gmail.com, Phill ip Hallam-Baker writes: OK, how do you do that if the ICANN root is baked into your broadband router? How about a light switch? Given that the ICANN root servers have a history of changing address I would not expect any vendor to not provide a mechanism for changing them. We build in the ICANN root servers in our products but we also provide mechanisms to change them. % grep ROOT-SE CHANGES 2328. [maint] Add addresses for A.ROOT-SERVERS.NET, F.ROOT-SERVERS.NET, H.ROOT-SERVERS.NET, J.ROOT-SERVERS.NET, K.ROOT-SERVERS.NET and M.ROOT-SERVERS.NET. 2255. [maint] L.ROOT-SERVERS.NET is now 199.7.83.42. 1567. [maint] B.ROOT-SERVERS.NET is now 192.228.79.201. 1397. [maint] J.ROOT-SERVERS.NET is now 192.58.128.30. % The same thing will have to be provided for and DNSKEY's embedded in software as the expectation is that these will change relatively often, much more often than CA certs. Yes in theory I can reverse engineer the code. In practice this is not practical. In theory the music industry could set up their own alternative to iTunes, in practice they have no choice but to deal with Apple. Governments are not private companies. Governments often do things no sane company would do. Most cell phones ship with only a small number of SSL roots and the end user has no ability to change them. You can change the signing key, but distributing and embedding the verification key is a whole different issue. The reason that VeriSign can charge a premium for certs is because its verification roots are the most widely embedded. You may disagree with my arguments here, but you do not have the standing to call them 'specious'. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- -- 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: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
I agree the resources are non-trivial But it creates a put-up or shut-up point for the non-US objectors to the sole US controlled root. What it does not do is to address the state dept concerns that the root is a liability. And the cost of setting up an apex authority are much less than the cost of fracturing the root. Given the complete lack of interest that the DNSSEC community has had in consultation with deployment stakeholders, the quorate approach might well be important as a way to co-opt the existing Domain Validated SSL cert providers to seed a DNSSEC deployment in a DLV structure. One of the administrative parts of the puzzle that nobody seems to have thought out is why the registrars are going to play ball. Or for that matter what the charge for a DNSSEC zone entry is going to be. On Thu, Jun 11, 2009 at 8:35 PM, Stephen Kentk...@bbn.com wrote: Phil, The examples you give about backed-in trust anchors are valid, but they point to decisions by vendors to simplify their designs at the cost of secruity and functionality. I've been told that it is very hard, if not impossible, to permanently remove some vendor-supplied TAs in a popular browser. These are not fundamental results of architectural decisions of the sort the IETF makes, but vendor choices that lead to possible problems for user. I think I understand the multi-party, RP-centric threshold approach to managing the DNSSEC root that you outlined. But, in a DNSSEC environment, IANA performs two roles: - it coordinates the info from the gTLDs and ccTLDs and constructs the authoritative root zone file - it signs the records of that file Any scheme that allows multiple entities to confirm the content of the root zone file also has to include a means for these entities to independently acquire and verify the master file data and to create a separate, distinct master file if they disagree. This is a lot more complex that what you outlined in your message (from an from an administrative vs. crypto perspective). It also raises questions about how complex RP software has to be in dealing with multiple sets of quasi-authoritative root authorities. All experience to date suggests that RPs fare poorly when trying to deal with much less complex trust anchor situations in other PKI environments today. It is conceivable (under the new administration) that ICANN will stop being under the control of the U.S DoC, but it also is not clear that such a change would ameliorate the concerns of all governments with regard to this issue. I think the set of folks who feel a need to use other than the current, proposed model (IANA as the DNSSEC root) are a very small minority of the set of public Internet users and thus they should bear the burden of dealing with the resulting costs and complexity for managing alternative root schemes. I don't think that such costs and complexity should be borne by the vast majority of Internet users. Its also not clear how long one might spend debating the question of whether any single scheme would satisfy all of the players who are not comfortable with the current model. Steve -- -- 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: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
On Thu, Jun 11, 2009 at 10:34 PM, Mark Andrewsma...@isc.org wrote: In message a123a5d60906111838t460ca168l9cf797a486ec1...@mail.gmail.com, Phill ip Hallam-Baker writes: So we have totally abandoned the idea of doing DNSSEC in the end point clie= nt? Trust roots have to be valid for at least a decade to be acceptable to the application vendor community. That's a unproved assumption. It is an observation backed by fifteen years of experience and direct conversations with the principals for cryptographic security at the major platform vendors. Moreover, I note that far from soliciting opinion from these groups, the DNSEXT working group has done everything it can to drive such folk away. Every single time a real world deployment constraint has been raised, the response of the group has been fingers in ears 'LA-LA-LA NOT LISTENING'. It took two years of argument before the zone walking issue was accepted as a legal requirement, it took five to get support for opt-in. At each stage in the proceedings, the length of time that the process has taken is used to avoid considering real world deployment constraints. You think that you are finished. All you have done so far is to build PEM. PEM got to the exact stage that DNSSEC has got to thus far in a quarter the time. They had a complete set of RFCs specified that described a scheme that nobody could deploy. Their excuse was that nobody understood the deployment constraints. And even though the current model of network administration is to constantly fiddle with everything, I think that is going to have to stop. Lots companies already use private roots. Equipment manufactures are not going to build equipment that can't be used by those markets. Manufacturers are quite capable of producing only checklist compliance for features that have no customer demand. I talked to analysts from Gartner, Burton and others at RSA this year, none considered DNSSEC to be a major security issue. They write the RFPs that drive feature support. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
These are assertions, not facts. PKI is demonstrated to be effective in the reduction and management of risk, that is what it is designed to do and that is how I define the term 'security'. On Fri, Jun 12, 2009 at 8:19 AM, Masataka Ohtamo...@necom830.hpcl.titech.ac.jp wrote: Phillip Hallam-Baker wrote: Trust roots have to be valid for at least a decade to be acceptable to the application vendor community. ? ? ? ?That's a unproved assumption. It is an observation backed by fifteen years of experience and direct conversations with the principals for cryptographic security at the major platform vendors. PKI, including DNSSEC, is NOT secure cryptographically, but secure socially or, in other word, weakly secure, subject to social and other forms of attacks. PKI, however, is not so insecure, in a sense that plain old DNS (specified in 1987) is not so insecure and has been valid for more than a decade to be acceptable to the application vendor community. That is the observed fact. If the broken security model of bailiwick is thrown away, plain old DNS is made secure enough. Moreover, plain old DNS is a lot easier to manage than PKI. Masataka Ohta -- -- 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: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
Past history is no guarantee of future performance. A pattern we see repeated over and over again is that a new control on some form of Internet crime leads to a dramatic short term reduction even though the control merely increases the cost of crime, not eliminates the capability. This is the displacement effect. The criminals attack weaker targets instead. Once the criminals have exhausted the supply of easy targets the original targets see a sudden increase in the crime rate, often orders of magnitude in a few days. On Fri, Jun 12, 2009 at 9:16 AM, Masataka Ohtamo...@necom830.hpcl.titech.ac.jp wrote: Phillip Hallam-Baker wrote: These are assertions, not facts. The fact is that since 1987, DNS has been mostly secure. that is what it is designed to do and that is how I define the term 'security'. You did not simply say security but said cryptographic security. Masataka Ohta -- -- 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: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
Past history is a good indicator of problems that may arise. Past history is a very bad guarantee that problems will not arise in the future. On Fri, Jun 12, 2009 at 7:54 PM, Masataka Ohtamo...@necom830.hpcl.titech.ac.jp wrote: Phillip Hallam-Baker wrote: Past history is no guarantee of future performance. Is your argument applicable to the following statement you just made yesterday? : Trust roots have to be valid for at least a decade to be acceptable to : the application vendor community. A pattern we see repeated over and over again is that a new control on some form of Internet crime leads to a dramatic short term reduction even though the control merely increases the cost of crime, not eliminates the capability. This is the displacement effect. The criminals attack weaker targets instead. Once the criminals have exhausted the supply of easy targets the original targets see a sudden increase in the crime rate, often orders of magnitude in a few days. Note that, given dynamically generated zones, signature generation mechanisms of DNSSEC is rather weaker targets. Masataka Ohta -- -- 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: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
Or alternatively, Be liberal in anticipating repeat of past problems, be conservative in your expectation that new problems will not arise. On Fri, Jun 12, 2009 at 8:21 PM, Phillip Hallam-Bakerhal...@gmail.com wrote: Past history is a good indicator of problems that may arise. Past history is a very bad guarantee that problems will not arise in the future. On Fri, Jun 12, 2009 at 7:54 PM, Masataka Ohtamo...@necom830.hpcl.titech.ac.jp wrote: Phillip Hallam-Baker wrote: Past history is no guarantee of future performance. Is your argument applicable to the following statement you just made yesterday? : Trust roots have to be valid for at least a decade to be acceptable to : the application vendor community. A pattern we see repeated over and over again is that a new control on some form of Internet crime leads to a dramatic short term reduction even though the control merely increases the cost of crime, not eliminates the capability. This is the displacement effect. The criminals attack weaker targets instead. Once the criminals have exhausted the supply of easy targets the original targets see a sudden increase in the crime rate, often orders of magnitude in a few days. Note that, given dynamically generated zones, signature generation mechanisms of DNSSEC is rather weaker targets. Masataka Ohta -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ -- -- 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: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
It is very clear that at least part of this discussion is due to your unfamiliarity with English. Looking at past failures is a very good way to predict the possibility of similar failures in the future. History is a very good guide to setting a lower bound on risk. History is a very poor guide to setting a lower bound on risk, not least because people have a habit of only looking at the past events that give them good news. Most of us know that the typical business cycle lasts 7-10 years. However the geniuses behind 'Long Term Capital Management' only reviewed six years of the business cycle ending entirely. When one of the principals behind LTM is interviewed on TVfor his opinions on the bailout he is invariably tagged as 'Nobel Laureate', and never 'The fool who caused the last major fiscal crisis'. I have fifteen years experience in this business area. I am the only participant in this debate so far who can claim any direct knowledge of the business of embedding roots. It is on that basis and on the basis of direct conversations with my peers in the industry that I believe that the current DNSSEC specs do not meet the needs of deployment. Given that DNSSEC has not achieved deployment in fifteen years and given that the only deployment momentum that can be seen at the moment is in the form of 'top-down' edicts from ICANN, Vint Cerf and co, I think that the onus of proof falls on those who assure us that DNSSEC does in fact meet deployment requirements. On Sat, Jun 13, 2009 at 5:25 AM, Masataka Ohtamo...@necom830.hpcl.titech.ac.jp wrote: Phillip Hallam-Baker wrote: Past history is a very bad guarantee that problems will not arise in the future. So, you mean your statement: : Trust roots have to be valid for at least a decade to be acceptable to : the application vendor community. hardly guarantee anything. Be liberal in anticipating repeat of past problems, Indeed. Unnoticeable cache poisoning by glues is repeated even with bailiwick and once again with DNSSEC. be conservative in your expectation that new problems will not arise. The protection is to make protocols as simple as possible. The following paper discusses about it to some extent. http://ftp.csci.csusb.edu/ykarant/courses/f2007/csci530/papers/counterpane-ipsec.pdf Masataka Ohta -- -- 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: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
* Phillip Hallam-Baker: OK, how do you do that if the ICANN root is baked into your broadband router? How about a light switch? Nowadays, there are software update protocols for broadband routers, too. You can change the signing key, but distributing and embedding the verification key is a whole different issue. The reason that VeriSign can charge a premium for certs is because its verification roots are the most widely embedded. No, Verisign's pricing is based on branding. Verisign is just the most valuable brand, so certificates associated with it cost the most. Verisign also issues certificates under a root called Equifax, which are far cheaper but functionally equivalent. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
Phillip Hallam-Baker wrote: Past history is a very bad guarantee that problems will not arise in the future. So, you mean your statement: : Trust roots have to be valid for at least a decade to be acceptable to : the application vendor community. hardly guarantee anything. Be liberal in anticipating repeat of past problems, Indeed. Unnoticeable cache poisoning by glues is repeated even with bailiwick and once again with DNSSEC. be conservative in your expectation that new problems will not arise. The protection is to make protocols as simple as possible. The following paper discusses about it to some extent. http://ftp.csci.csusb.edu/ykarant/courses/f2007/csci530/papers/counterpane-ipsec.pdf Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
* Joe Baptista: DNSCurve encrypts all DNS packets. Ahem, this part of the protocol has not been specified so far. Encryption is not mentioned on the dnscurve.org pages, only key exchange, and even that is not fully disclosed. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
Phillip Hallam-Baker wrote: It is very clear that at least part of this discussion is due to your unfamiliarity with English. As you said : Please learn to express your opinions in a manner that is appropriate : to a professional forum rather than a bar room brawl. : You are entitled to your opinion but not to converse in the abusive : and insulting manner you have chosen to use if you wish to receive a : reply. Thank you again for demonstrating a perfect manner for a professional forum. However, you should consider a possibility that your poetry skill in English, if any, can not, in this professional forum not on poetry but on engineering, make up for your lack of expertise in protocol design. Most of us know that the typical business cycle lasts 7-10 years. However the geniuses behind 'Long Term Capital Management' only reviewed six years of the business cycle ending entirely. When one of the principals behind LTM is interviewed on TVfor his opinions on the bailout he is invariably tagged as 'Nobel Laureate', and never 'The fool who caused the last major fiscal crisis'. Though you obviously don't know much about LTCM, it is merely that business model of LTCM has been broken from the beginning, just as authority model of DNSSEC has been broken from the beginning. Initial success of LTCM is due to not technical but poetry skill of people involved, because economy is not very technical. As for DNSSEC in highly technical world, after years of unsuccessful experimental deployment, most of the problems of authority model, all of which was pointed out by me from the beginning, was fixed. The only remaining problem of DNSSEC is that it is not very secure. It is not cryptographically but weakly secure, which is the security of plain old DNS. I have fifteen years experience in this business area. I thought you shun businesses. : The link you gave was to a paywalled version of the paper. I did not : bother to read the authors once I discovered it was paywalled. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
At 10:32 PM -0400 6/11/09, David Conrad wrote: Hi, On Jun 11, 2009, at 8:35 PM, Stephen Kent wrote: But, in a DNSSEC environment, IANA performs two roles: - it coordinates the info from the gTLDs and ccTLDs and constructs the authoritative root zone file - it signs the records of that file Nope. Just to clarify things: IANA (well, ICANN as the IANA functions operator) receives and validates root zone changes. VeriSign constructs and publishes the root zone to the root server operators. In the context of DNSSEC, as documented at http://www.icann.org/en/announcements/announcement-2-03jun09-en.htm, VeriSign will have operational responsibility for the zone signing key and ICANN will manage the key signing process. David, Thanks for the clarification. I just wanted to emphasize the two distinct functions that IANA performs in the DNSSEC context, without getting into the ZSK/KSK details and the current proposed split of responsibility between IANA and VeriSign (which is outside the IETF DNSSEC architecture, right?). Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
Phillip Hallam-Baker wrote: Trust roots have to be valid for at least a decade to be acceptable to the application vendor community. ? ? ? ?That's a unproved assumption. It is an observation backed by fifteen years of experience and direct conversations with the principals for cryptographic security at the major platform vendors. PKI, including DNSSEC, is NOT secure cryptographically, but secure socially or, in other word, weakly secure, subject to social and other forms of attacks. PKI, however, is not so insecure, in a sense that plain old DNS (specified in 1987) is not so insecure and has been valid for more than a decade to be acceptable to the application vendor community. That is the observed fact. If the broken security model of bailiwick is thrown away, plain old DNS is made secure enough. Moreover, plain old DNS is a lot easier to manage than PKI. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
Phillip Hallam-Baker wrote: These are assertions, not facts. The fact is that since 1987, DNS has been mostly secure. that is what it is designed to do and that is how I define the term 'security'. You did not simply say security but said cryptographic security. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
Phillip Hallam-Baker wrote: Past history is no guarantee of future performance. Is your argument applicable to the following statement you just made yesterday? : Trust roots have to be valid for at least a decade to be acceptable to : the application vendor community. A pattern we see repeated over and over again is that a new control on some form of Internet crime leads to a dramatic short term reduction even though the control merely increases the cost of crime, not eliminates the capability. This is the displacement effect. The criminals attack weaker targets instead. Once the criminals have exhausted the supply of easy targets the original targets see a sudden increase in the crime rate, often orders of magnitude in a few days. Note that, given dynamically generated zones, signature generation mechanisms of DNSSEC is rather weaker targets. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
At 10:41 AM +1000 6/11/09, Mark Andrews wrote: In message p06240803c65430cf6...@[10.10.10.117], Stephen Kent writes: Joe, You have argued that DNSSEC is not viable because it requires that everyone adopt IANA as the common root. Which isn't even a requirement. Alternate root providers just need to get copy of the root zone with DS records and sign it with their own DNSKEY records for the root. ISP's that choose to use alternate roots might get complaints however from their customers if they are validating the answers using the trust-anchors provided by IANA. This however should be seen as a good thing as the ISP can no longer tamper with the DNS without being detected. If a ISP can convince all their customers that the alternate roots are a good thing then this won't become a issue. Fair point, although I think we all want to avoid the sort of Balkionization that this suggests. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
Phil, That's a specious argument. As several others have noted on this list, it's perfectly feasible for any relying parties (sovereign nations or otherwise) to not use the IANA root, simply by creating their own root. This is a little more complicated than just redirecting IP traffic, but not by much. To quote from Mark's earlier message: Mark Andrews wrote: Stephen Kent writes: You have argued that DNSSEC is not viable because it requires that everyone adopt IANA as the common root. Which isn't even a requirement. Alternate root providers just need to get copy of the root zone with DS records and sign it with their own DNSKEY records for the root. --Richard Phillip Hallam-Baker wrote: Steve, The sovereign nations that object to US control of the root are willing to accept the current status quo preciely because they have an exit option. Should the US defect on its obligations and order ICANN to drop Cuba or Palestine out of the root or to take any other action that was considered to be abusive, the countries that objected could simply direct their local ISPs to redirect all IP traffic to the A thru M root servers to another set of servers of their choice. At the moment the ICANN has the theoretical ability to defect, but can only do so at the cost of becomming irrelevant. The global DNS outside the US would swiftly pass to the ITU. With the proposed root arrangement for DNSSEC, this changes. Not only does the US have effective control, it has perpetual control of any apparatus that chains to the ICANN root of trust. This is bad for the US, bad for ICANN and bad for other sovereign states. First, consider the likely source of a defection, some idiot member of Congress from Florida grandstanding for votes. Such a move is going to give the career civil service a fit, particularly the diplomats who prefer to end rather than begin international crises. I have spoken to very enior members of this administration on this topic, they had come to the exact same conclusion themselves. Now consider ICANN. Let us imagine that they do hold the master root key. What is then to stop some armed terrorist nut cases laying siege to the key repository? Their objective might not be to drop a country out, they might want to insert some irredentist domain of their own. Ordinary PKIs are not subject to this type of pressure, because they are not the lynchpin of the global communication system. While the various splinter-roots may appear to be complete jokes, they have had one significant result, they have drawn attention to the issue. In particular very much doubt that the Turkish secret service are too amused at the whole process given some of their experiences. On Wed, Jun 10, 2009 at 1:11 PM, Stephen Kentk...@bbn.com wrote: Joe, You have argued that DNSSEC is not viable because it requires that everyone adopt IANA as the common root. I agree that under the current IANA management situation many folks may be uncomfortable with IANA as the root. However, in practice, the world has lived with IANA as the root for the non-secure version of DNS for a long time, so it's not clear that a singly-rooted DNSSEC is not viable based on this one concern. Moreover, DNSSEC is a form of PKI, an din ANY PKI, it is up to the relying parties to select the trust anchors they recognize. In a hierarchic system like DNS, the easiest approach is to adopt a single TA, the DNS root. But, it is still possible for a relying party to do more work and select multiple points as TAs. I would expect military organizations in various parts of the world to adopt a locally-managed TA store model for DNSSEC, to address this concern. However the vast majority of Internet users probably are best served by the single TA model. As for DNSCurve, I agree with the comments that several others have made, i.e., it doe snot provide the fundamental security one wants in DNS, i.e., an ability to verify the integrity and authenticity of records as attested to by authoritative domains, din the face of caching. Steve ___ 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: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
It is possible for people set their own roots, but it is not very practical to maintain them. And this is going to be particularly difficult if we ever get DNSSEC deployed in platform distributions and end-entities are configured to check their own DNS chains up to a baked-in ICANN root. It is not a sustainable model. Here is what I propose instead, it is a variation of ideas Carl Ellison and Phil Zimmerman have proposed in the past, it is thus entirely unencumbered: 1) There are multiple public signers for the apex zone signing key. These are moderately serious entities employing trustworthy hardware, secure facilities etc. They publish a CPS describing their practices. 2) Each relying party selects the subset of apex signers they are willing to trust and the conditions for accepting a signature. This may be 3 out of 5 or 4 out of 7 or anything the relying party decides. 3) Applications, Servers, etc. ship with default quorum conditions configured but these can be over-ridden. This has a number of interesting effects: 1) We have eliminated the incentive to default, not just placed controls that make it difficult to default. While an apex signatory can defect, they cannot profit unless they can persuade others to collude with them. Relying parties can make this rather unlikely by choosing apex signers that are entirely unlikely to collude (Cuba, France and the US). 2) Parties that feel that the US has too much influence in the DNS have something that they can do to counter that influence. Instead of sitting on the sidelines and throwing spanners into the works, the countries concerned about their sovereignty being infringed can start their own apex signatory authority. 3) The system can be stable over very long periods of years, centuries even, even if the apex signer authorities are not stable. This makes it viable for a corporation to be a signer. While it is most unlikely that Google will disappear in the next 5 years, any company can go bust over a course of decades, as GM and Chrysler are demonstrating. The same approach can be extended to support long term repositories of digital data. So imagine that we wanted to set up a long term repository of academic journal articles in electronic form. Most people who propose these things understand the necessity of physical duplication of the data storage, but not the need for failsafe design of the management institutions. On Wed, Jun 10, 2009 at 8:41 PM, Mark Andrewsma...@isc.org wrote: In message p06240803c65430cf6...@[10.10.10.117], Stephen Kent writes: Joe, You have argued that DNSSEC is not viable because it requires that everyone adopt IANA as the common root. Which isn't even a requirement. Alternate root providers just need to get copy of the root zone with DS records and sign it with their own DNSKEY records for the root. ISP's that choose to use alternate roots might get complaints however from their customers if they are validating the answers using the trust-anchors provided by IANA. This however should be seen as a good thing as the ISP can no longer tamper with the DNS without being detected. If a ISP can convince all their customers that the alternate roots are a good thing then this won't become a issue. I agree that under the current IANA management situation many folks may be uncomfortable with IANA as the root. However, in practice, the world has lived with IANA as the root for the non-secure version of DNS for a long time, so it's not clear that a singly-rooted DNSSEC is not viable based on this one concern. Moreover, DNSSEC is a form of PKI, an din ANY PKI, it is up to the relying parties to select the trust anchors they recognize. In a hierarchic system like DNS, the easiest approach is to adopt a single TA, the DNS root. But, it is still possible for a relying party to do more work and select multiple points as TAs. I would expect military organizations in various parts of the world to adopt a locally-managed TA store model for DNSSEC, to address this concern. However the vast majority of Internet users probably are best served by the single TA model. As for DNSCurve, I agree with the comments that several others have made, i.e., it doe snot provide the fundamental security one wants in DNS, i.e., an ability to verify the integrity and authenticity of records as attested to by authoritative domains, din the face of caching. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- 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 -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
OK, how do you do that if the ICANN root is baked into your broadband router? How about a light switch? Yes in theory I can reverse engineer the code. In practice this is not practical. In theory the music industry could set up their own alternative to iTunes, in practice they have no choice but to deal with Apple. Most cell phones ship with only a small number of SSL roots and the end user has no ability to change them. You can change the signing key, but distributing and embedding the verification key is a whole different issue. The reason that VeriSign can charge a premium for certs is because its verification roots are the most widely embedded. You may disagree with my arguments here, but you do not have the standing to call them 'specious'. On Thu, Jun 11, 2009 at 10:28 AM, Richard Barnesrbar...@bbn.com wrote: Phil, That's a specious argument. As several others have noted on this list, it's perfectly feasible for any relying parties (sovereign nations or otherwise) to not use the IANA root, simply by creating their own root. This is a little more complicated than just redirecting IP traffic, but not by much. To quote from Mark's earlier message: Mark Andrews wrote: Stephen Kent writes: You have argued that DNSSEC is not viable because it requires that everyone adopt IANA as the common root. Which isn't even a requirement. Alternate root providers just need to get copy of the root zone with DS records and sign it with their own DNSKEY records for the root. --Richard Phillip Hallam-Baker wrote: Steve, The sovereign nations that object to US control of the root are willing to accept the current status quo preciely because they have an exit option. Should the US defect on its obligations and order ICANN to drop Cuba or Palestine out of the root or to take any other action that was considered to be abusive, the countries that objected could simply direct their local ISPs to redirect all IP traffic to the A thru M root servers to another set of servers of their choice. At the moment the ICANN has the theoretical ability to defect, but can only do so at the cost of becomming irrelevant. The global DNS outside the US would swiftly pass to the ITU. With the proposed root arrangement for DNSSEC, this changes. Not only does the US have effective control, it has perpetual control of any apparatus that chains to the ICANN root of trust. This is bad for the US, bad for ICANN and bad for other sovereign states. First, consider the likely source of a defection, some idiot member of Congress from Florida grandstanding for votes. Such a move is going to give the career civil service a fit, particularly the diplomats who prefer to end rather than begin international crises. I have spoken to very enior members of this administration on this topic, they had come to the exact same conclusion themselves. Now consider ICANN. Let us imagine that they do hold the master root key. What is then to stop some armed terrorist nut cases laying siege to the key repository? Their objective might not be to drop a country out, they might want to insert some irredentist domain of their own. Ordinary PKIs are not subject to this type of pressure, because they are not the lynchpin of the global communication system. While the various splinter-roots may appear to be complete jokes, they have had one significant result, they have drawn attention to the issue. In particular very much doubt that the Turkish secret service are too amused at the whole process given some of their experiences. On Wed, Jun 10, 2009 at 1:11 PM, Stephen Kentk...@bbn.com wrote: Joe, You have argued that DNSSEC is not viable because it requires that everyone adopt IANA as the common root. I agree that under the current IANA management situation many folks may be uncomfortable with IANA as the root. However, in practice, the world has lived with IANA as the root for the non-secure version of DNS for a long time, so it's not clear that a singly-rooted DNSSEC is not viable based on this one concern. Moreover, DNSSEC is a form of PKI, an din ANY PKI, it is up to the relying parties to select the trust anchors they recognize. In a hierarchic system like DNS, the easiest approach is to adopt a single TA, the DNS root. But, it is still possible for a relying party to do more work and select multiple points as TAs. I would expect military organizations in various parts of the world to adopt a locally-managed TA store model for DNSSEC, to address this concern. However the vast majority of Internet users probably are best served by the single TA model. As for DNSCurve, I agree with the comments that several others have made, i.e., it doe snot provide the fundamental security one wants in DNS, i.e., an ability to verify the integrity and authenticity of records as attested to by authoritative domains, din the face of caching. Steve
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
In message a123a5d60906110800i58353c99wc6b16a50395dc...@mail.gmail.com, Phill ip Hallam-Baker writes: OK, how do you do that if the ICANN root is baked into your broadband router? How about a light switch? Given that the ICANN root servers have a history of changing address I would not expect any vendor to not provide a mechanism for changing them. We build in the ICANN root servers in our products but we also provide mechanisms to change them. % grep ROOT-SE CHANGES 2328. [maint] Add addresses for A.ROOT-SERVERS.NET, F.ROOT-SERVERS.NET, H.ROOT-SERVERS.NET, J.ROOT-SERVERS.NET, K.ROOT-SERVERS.NET and M.ROOT-SERVERS.NET. 2255. [maint] L.ROOT-SERVERS.NET is now 199.7.83.42. 1567. [maint] B.ROOT-SERVERS.NET is now 192.228.79.201. 1397. [maint] J.ROOT-SERVERS.NET is now 192.58.128.30. % The same thing will have to be provided for and DNSKEY's embedded in software as the expectation is that these will change relatively often, much more often than CA certs. Yes in theory I can reverse engineer the code. In practice this is not practical. In theory the music industry could set up their own alternative to iTunes, in practice they have no choice but to deal with Apple. Governments are not private companies. Governments often do things no sane company would do. Most cell phones ship with only a small number of SSL roots and the end user has no ability to change them. You can change the signing key, but distributing and embedding the verification key is a whole different issue. The reason that VeriSign can charge a premium for certs is because its verification roots are the most widely embedded. You may disagree with my arguments here, but you do not have the standing to call them 'specious'. -- 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: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
Phil, The examples you give about backed-in trust anchors are valid, but they point to decisions by vendors to simplify their designs at the cost of secruity and functionality. I've been told that it is very hard, if not impossible, to permanently remove some vendor-supplied TAs in a popular browser. These are not fundamental results of architectural decisions of the sort the IETF makes, but vendor choices that lead to possible problems for user. I think I understand the multi-party, RP-centric threshold approach to managing the DNSSEC root that you outlined. But, in a DNSSEC environment, IANA performs two roles: - it coordinates the info from the gTLDs and ccTLDs and constructs the authoritative root zone file - it signs the records of that file Any scheme that allows multiple entities to confirm the content of the root zone file also has to include a means for these entities to independently acquire and verify the master file data and to create a separate, distinct master file if they disagree. This is a lot more complex that what you outlined in your message (from an from an administrative vs. crypto perspective). It also raises questions about how complex RP software has to be in dealing with multiple sets of quasi-authoritative root authorities. All experience to date suggests that RPs fare poorly when trying to deal with much less complex trust anchor situations in other PKI environments today. It is conceivable (under the new administration) that ICANN will stop being under the control of the U.S DoC, but it also is not clear that such a change would ameliorate the concerns of all governments with regard to this issue. I think the set of folks who feel a need to use other than the current, proposed model (IANA as the DNSSEC root) are a very small minority of the set of public Internet users and thus they should bear the burden of dealing with the resulting costs and complexity for managing alternative root schemes. I don't think that such costs and complexity should be borne by the vast majority of Internet users. Its also not clear how long one might spend debating the question of whether any single scheme would satisfy all of the players who are not comfortable with the current model. Steve___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
Hi, On Jun 11, 2009, at 8:35 PM, Stephen Kent wrote: But, in a DNSSEC environment, IANA performs two roles: - it coordinates the info from the gTLDs and ccTLDs and constructs the authoritative root zone file - it signs the records of that file Nope. Just to clarify things: IANA (well, ICANN as the IANA functions operator) receives and validates root zone changes. VeriSign constructs and publishes the root zone to the root server operators. In the context of DNSSEC, as documented at http://www.icann.org/en/announcements/announcement-2-03jun09-en.htm , VeriSign will have operational responsibility for the zone signing key and ICANN will manage the key signing process. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
In message a123a5d60906111838t460ca168l9cf797a486ec1...@mail.gmail.com, Phill ip Hallam-Baker writes: So we have totally abandoned the idea of doing DNSSEC in the end point clie= nt? No. Recursive nameserver need to validate the answers returned from the DNS for their own uses. This doesn't preclude other applications also validating answers. Having recursive nameserver validate answers is not the end point in DNSSEC deployment. It's just a good first step which is good enough is some operational envionments. There are however lots of operational envioronments where this would not be good enough and the validation really needs to be performed in the application. For your light switch example a validating recursive resolver is probably all you need. For laptops you most probably want to move the validation onto the laptop either in the application or by a running a validation recursive nameserver on the laptop which may or may not use the nameservers in the DHCP response as forwarders. I do this today. Trust roots have to be valid for at least a decade to be acceptable to the application vendor community. That's a unproved assumption. And even though the current model of network administration is to constantly fiddle with everything, I think that is going to have to stop. Lots companies already use private roots. Equipment manufactures are not going to build equipment that can't be used by those markets. 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: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
Joe, You have argued that DNSSEC is not viable because it requires that everyone adopt IANA as the common root. I agree that under the current IANA management situation many folks may be uncomfortable with IANA as the root. However, in practice, the world has lived with IANA as the root for the non-secure version of DNS for a long time, so it's not clear that a singly-rooted DNSSEC is not viable based on this one concern. Moreover, DNSSEC is a form of PKI, an din ANY PKI, it is up to the relying parties to select the trust anchors they recognize. In a hierarchic system like DNS, the easiest approach is to adopt a single TA, the DNS root. But, it is still possible for a relying party to do more work and select multiple points as TAs. I would expect military organizations in various parts of the world to adopt a locally-managed TA store model for DNSSEC, to address this concern. However the vast majority of Internet users probably are best served by the single TA model. As for DNSCurve, I agree with the comments that several others have made, i.e., it doe snot provide the fundamental security one wants in DNS, i.e., an ability to verify the integrity and authenticity of records as attested to by authoritative domains, din the face of caching. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
Steve, The sovereign nations that object to US control of the root are willing to accept the current status quo preciely because they have an exit option. Should the US defect on its obligations and order ICANN to drop Cuba or Palestine out of the root or to take any other action that was considered to be abusive, the countries that objected could simply direct their local ISPs to redirect all IP traffic to the A thru M root servers to another set of servers of their choice. At the moment the ICANN has the theoretical ability to defect, but can only do so at the cost of becomming irrelevant. The global DNS outside the US would swiftly pass to the ITU. With the proposed root arrangement for DNSSEC, this changes. Not only does the US have effective control, it has perpetual control of any apparatus that chains to the ICANN root of trust. This is bad for the US, bad for ICANN and bad for other sovereign states. First, consider the likely source of a defection, some idiot member of Congress from Florida grandstanding for votes. Such a move is going to give the career civil service a fit, particularly the diplomats who prefer to end rather than begin international crises. I have spoken to very enior members of this administration on this topic, they had come to the exact same conclusion themselves. Now consider ICANN. Let us imagine that they do hold the master root key. What is then to stop some armed terrorist nut cases laying siege to the key repository? Their objective might not be to drop a country out, they might want to insert some irredentist domain of their own. Ordinary PKIs are not subject to this type of pressure, because they are not the lynchpin of the global communication system. While the various splinter-roots may appear to be complete jokes, they have had one significant result, they have drawn attention to the issue. In particular very much doubt that the Turkish secret service are too amused at the whole process given some of their experiences. On Wed, Jun 10, 2009 at 1:11 PM, Stephen Kentk...@bbn.com wrote: Joe, You have argued that DNSSEC is not viable because it requires that everyone adopt IANA as the common root. I agree that under the current IANA management situation many folks may be uncomfortable with IANA as the root. However, in practice, the world has lived with IANA as the root for the non-secure version of DNS for a long time, so it's not clear that a singly-rooted DNSSEC is not viable based on this one concern. Moreover, DNSSEC is a form of PKI, an din ANY PKI, it is up to the relying parties to select the trust anchors they recognize. In a hierarchic system like DNS, the easiest approach is to adopt a single TA, the DNS root. But, it is still possible for a relying party to do more work and select multiple points as TAs. I would expect military organizations in various parts of the world to adopt a locally-managed TA store model for DNSSEC, to address this concern. However the vast majority of Internet users probably are best served by the single TA model. As for DNSCurve, I agree with the comments that several others have made, i.e., it doe snot provide the fundamental security one wants in DNS, i.e., an ability to verify the integrity and authenticity of records as attested to by authoritative domains, din the face of caching. Steve ___ 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: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
In message p06240803c65430cf6...@[10.10.10.117], Stephen Kent writes: Joe, You have argued that DNSSEC is not viable because it requires that everyone adopt IANA as the common root. Which isn't even a requirement. Alternate root providers just need to get copy of the root zone with DS records and sign it with their own DNSKEY records for the root. ISP's that choose to use alternate roots might get complaints however from their customers if they are validating the answers using the trust-anchors provided by IANA. This however should be seen as a good thing as the ISP can no longer tamper with the DNS without being detected. If a ISP can convince all their customers that the alternate roots are a good thing then this won't become a issue. I agree that under the current IANA management situation many folks may be uncomfortable with IANA as the root. However, in practice, the world has lived with IANA as the root for the non-secure version of DNS for a long time, so it's not clear that a singly-rooted DNSSEC is not viable based on this one concern. Moreover, DNSSEC is a form of PKI, an din ANY PKI, it is up to the relying parties to select the trust anchors they recognize. In a hierarchic system like DNS, the easiest approach is to adopt a single TA, the DNS root. But, it is still possible for a relying party to do more work and select multiple points as TAs. I would expect military organizations in various parts of the world to adopt a locally-managed TA store model for DNSSEC, to address this concern. However the vast majority of Internet users probably are best served by the single TA model. As for DNSCurve, I agree with the comments that several others have made, i.e., it doe snot provide the fundamental security one wants in DNS, i.e., an ability to verify the integrity and authenticity of records as attested to by authoritative domains, din the face of caching. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- 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: DNSSEC is NOT secure end to end
Masataka-san Please learn to express your opinions in a manner that is appropriate to a professional forum rather than a bar room brawl. You are entitled to your opinion but not to converse in the abusive and insulting manner you have chosen to use if you wish to receive a reply. The link you gave was to a paywalled version of the paper. I did not bother to read the authors once I discovered it was paywalled. On Mon, Jun 8, 2009 at 1:22 AM, Masataka Ohtamo...@necom830.hpcl.titech.ac.jp wrote: Phillip Hallam-Baker wrote: I was at a dinner with Dave Clarke last week. Those who invoke his name in these arguments rarely seem to have read his paper on the end to end principle IN NETWORKING. Which paper is, are you saying, his paper? The original one or latter one (published in 2001) which includes discussion on PKI, which I referred in previous mails. As you say IN NETWORKING, I'm afraid you haven't read his original paper END-TO-END ARGUMENTS IN SYSTEM DESIGN, which is on system design in general and not necessarily in networking. For example, in the original paper, RISC (Reduced Instruction Set Computer) is given as an example of end to end design. Depending on your level of abstraction you choose to work at you can argue that anything is an end. Apparently, he taught you basic points in his original paper but not beyond. It is discussed in the original paper that: Identifying the ends Using the end-to-end argument sometimes requires subtlety of analysis of application requirements. one must use some care to identify the end points to which the argument should be applied. Beyond the original paper, the application of the end to end argument to PKI including DNSSEC is discussed in his latter paper in 2001 with PROPERLY IDENTIFIED end points. In the paper, certificate authorities are identified to be third parties. With the discussion, there is no point denying DNSSEC is NOT secure end to end. It would be nice if the paper was available in unencumbered form. Both of the papers are freely downloadable. The original paper: http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf The paper in 2001: http://www.csd.uoc.gr/~hy558/papers/Rethinking_2001.pdf You should have read both of them to make the dinner more valuable. Publication in ACM does not help anything but the author's academic career. I gave a link to the paper in 2001 through ACM because it has DOI, assuming that anyone can use search engines and that all the people who talks about the end to end principle should have read the original paper in advance. Masataka Ohta -- -- 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: DNSSEC is NOT secure end to end
Andrew Sullivan a...@shinkuro.com writes: On Fri, Jun 05, 2009 at 08:10:55AM +0900, Masataka Ohta wrote: In general, registries welcome DNSSEC, no matter how secure it is, as long as its complicated operation works as an excuse to increase (or not to reduce) registration charge and registries' revenue. That is a serious charge. I've seen no evidence that DNSSEC represents a revenue opportunity for registries. On the contrary, so far as I've seen, most registries are introducing it without any fee, even though it represents a substantial additional operational cost. The organization operating .SE charges for DNSSEC. According to [1] it costs 250 SEK annually (~22 EUR or ~30 USD) extra per year to protect a domain name with DNSSEC. /Simon [1] http://www.iis.se/docs/se-dnssec_-_broschyr_eng_ny_.pdf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Shane Kerr wrote: If you mean COM zone, it is not necessary to inject any data into the zone. You, instead, can inject a forged certificate into some cache used by your victim. You said transport security can help. How can it in this case? With plain old DNS, zone administrators have to make master zone files secure not to include forged data. Other administrators take care of transport security, for example, to make port numbers randomized, which makes plain old DNS reasonably secure. With DNSSEC, however, a new administration mechanism to generate signatures is mandated, which is NOT automagically secure and introduces new administrative security holes. Thus, even if master zone files are administrated as secure as plain old DNS administration, the signature generation mechanisms may be hacked. Unlike forgery on master zone files, which is published and detected by periodic checking by thid parties, attack by unpublished forged signature will not be noticed until a victim is attacked, the victim noticed the (resulting loss by successful) attack and the victim has sufficient knowledge on DNSSEC. Still, the victim may be protected, if the victim can not be injected forged signature through transport. Also, how can you create a forged certificate? By attacking signature generation mechanisms, which is a security hole specific to DNSSEC not shared by plain old DNS. Note that DNSSEC does not give any cryptographical protection against attacks on the signature generation mechanisms. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Subject: Re: DNSSEC is NOT secure end to end Date: Mon, Jun 08, 2009 at 11:25:36AM +0200 Quoting Simon Josefsson (si...@josefsson.org): The organization operating .SE charges for DNSSEC. According to [1] it costs 250 SEK annually (~22 EUR or ~30 USD) extra per year to protect a domain name with DNSSEC. Not anymore; it is included with the registration since .SE went to a registry-registrar model a year ago. However, the registrar may choose to charge for the work associated with doing DNSSEC. -- Måns Nilsson ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Simon Josefsson wrote: Andrew Sullivan a...@shinkuro.com writes: In general, registries welcome DNSSEC, no matter how secure it is, as long as its complicated operation works as an excuse to increase (or not to reduce) registration charge and registries' revenue. That is a serious charge. The organization operating .SE charges for DNSSEC. According to [1] it costs 250 SEK annually (~22 EUR or ~30 USD) extra per year to protect a domain name with DNSSEC. That is the serious charge. Thank you for the information. Are there anyone who is not working for registries and is still interested in deploying DNSSEC for the extra charge despite the lack of cryptographic security? If not, let's conclude the thread with a consensus to abandon DNSSEC. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Mans Nilsson mansa...@besserwisser.org writes: Subject: Re: DNSSEC is NOT secure end to end Date: Mon, Jun 08, 2009 at 11:25:36AM +0200 Quoting Simon Josefsson (si...@josefsson.org): The organization operating .SE charges for DNSSEC. According to [1] it costs 250 SEK annually (~22 EUR or ~30 USD) extra per year to protect a domain name with DNSSEC. Not anymore; it is included with the registration since .SE went to a registry-registrar model a year ago. However, the registrar may choose to charge for the work associated with doing DNSSEC. That is good to hear. It would be better if the web pages would reflect the new order. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
I was at a dinner with Dave Clarke last week. Those who invoke his name in these arguments rarely seem to have read his paper on the end to end principle IN NETWORKING. The end to end security argument came earlier, it is referenced as an antecedent to lend support to the then novel idea of applying it to a network. And it is an argument about the best place to manage complexity. No internet security is end to end, no internet security protocol can be end to end as the ends of the security relationship are PEOPLE and ORGANIZATIONS. Depending on your level of abstraction you choose to work at you can argue that anything is an end. It would be nice if the paper was available in unencumbered form. Publication in ACM does not help anything but the author's academic career. There are real problems with DNSSEC but not those that tend to gain advancement there, On Sat, May 30, 2009 at 7:27 PM, Masataka Ohtamo...@necom830.hpcl.titech.ac.jp wrote: Francis Dupont wrote: = not only this is very arguable (for instance about the resource exhaustion) but no hop-by-hop/channel security, even something as strong as TSIG, can provide what we need, i.e., end-to-end/object security (*). Unless your meaning of end-to-end differs from that of David Clark, the following argument of his paper is applicable to DNSSEC. http://portal.acm.org/citation.cfm?doid=383034.383037 Rethinking the design of the Internet: The end to end arguments vs. the brave new world The certificate is an assertion by that (presumably trustworthy) third party that the indicated public key actually goes with the particular user. These certificates are principal components of essentially all public key schemes, That is, security of DNSSEC involves third parties and is not end to end. PS (*): I use the common meaning of end-to-end, not Masataka Ohta's one. I'm afraid you don't know who David Clark is and how he is related to the end to end argument. However, all the people who are qualified to discuss end to end do know him and his argument. 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: DNSSEC is NOT secure end to end
Ohta-san, On Sat, 2009-06-06 at 12:04 +0900, Masataka Ohta wrote: Shane Kerr wrote: I think we all understand that it is possible to inject bad data into the DNS at the parent. I the parent in the same sense as in RFC 1034 - the delegating level. So, for EXAMPLE.COM this would be COM. If you mean COM zone, it is not necessary to inject any data into the zone. You, instead, can inject a forged certificate into some cache used by your victim. You said transport security can help. How can it in this case? Also, how can you create a forged certificate? -- Shane ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Phillip Hallam-Baker wrote: Please learn to express your opinions in a manner that is appropriate to a professional forum rather than a bar room brawl. The link you gave was to a paywalled version of the paper. I did not bother to read the authors once I discovered it was paywalled. Thank you for demonstrating a perfect manner for a professional forum to deny a reference to an ACM article because it is paywalled. So, we, professionals, should, of course, not discuss about DNS, because domain registration is not free but badly monopolized. Before closing the discussion, cloud you teach me the name and location of the restaurant you have had dinner with David Clark obviously free of charge? Free dinner is better than free lunch. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Phillip Hallam-Baker wrote: I was at a dinner with Dave Clarke last week. Those who invoke his name in these arguments rarely seem to have read his paper on the end to end principle IN NETWORKING. Which paper is, are you saying, his paper? The original one or latter one (published in 2001) which includes discussion on PKI, which I referred in previous mails. As you say IN NETWORKING, I'm afraid you haven't read his original paper END-TO-END ARGUMENTS IN SYSTEM DESIGN, which is on system design in general and not necessarily in networking. For example, in the original paper, RISC (Reduced Instruction Set Computer) is given as an example of end to end design. Depending on your level of abstraction you choose to work at you can argue that anything is an end. Apparently, he taught you basic points in his original paper but not beyond. It is discussed in the original paper that: Identifying the ends Using the end-to-end argument sometimes requires subtlety of analysis of application requirements. one must use some care to identify the end points to which the argument should be applied. Beyond the original paper, the application of the end to end argument to PKI including DNSSEC is discussed in his latter paper in 2001 with PROPERLY IDENTIFIED end points. In the paper, certificate authorities are identified to be third parties. With the discussion, there is no point denying DNSSEC is NOT secure end to end. It would be nice if the paper was available in unencumbered form. Both of the papers are freely downloadable. The original paper: http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf The paper in 2001: http://www.csd.uoc.gr/~hy558/papers/Rethinking_2001.pdf You should have read both of them to make the dinner more valuable. Publication in ACM does not help anything but the author's academic career. I gave a link to the paper in 2001 through ACM because it has DOI, assuming that anyone can use search engines and that all the people who talks about the end to end principle should have read the original paper in advance. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
Mark Andrews wrote: Thus, we must, anyway, protect cache. Then, where is the point to introduce DNSSEC only to have another possibility of security holes? We still lock doors and windows despite the possiblity of people breaking in by lifting tiles. I'm afraid DNSSEC people have been arguing against SCTP saying DNSSEC is good enough. Worse, though I have been warning for these 15 years that cached glue may be used only for glue with same refferal, a broken concept of bailiwick was introduced only to enable so called Kaminsky attack. Attacks at the registry level are the equivalient of lifting tiles. It happens sometimes. Protection of DNSSEC at the registy level is equivalent to protection against lifting tiles. Not practical at all. Locking the doors and windows stops most attacks however. Then, let's lock the doors and windows first, before working on DNSSEC. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
On Fri, Jun 05, 2009 at 08:10:55AM +0900, Masataka Ohta wrote: In general, registries welcome DNSSEC, no matter how secure it is, as long as its complicated operation works as an excuse to increase (or not to reduce) registration charge and registries' revenue. That is a serious charge. I've seen no evidence that DNSSEC represents a revenue opportunity for registries. On the contrary, so far as I've seen, most registries are introducing it without any fee, even though it represents a substantial additional operational cost. (Indeed, some of us were at times under the impression that the practical inability to charge anything in order to offset this additional cost was one of the biggest barriers to DNSSEC deployment.) What registries are you thinking of that are charging extra for DNSSEC delegations (i.e. for accepting a DS record)? A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Shane Kerr wrote: I think we all understand that it is possible to inject bad data into the DNS at the parent. What do you mean the parent? Do you mean master zone file of the parent or some caching server expected by a client to have parent data? What I do not understand about this comment is how transport security can help in that case. Can you please explain? Explanation depends on your definition of the parent. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
On Fri, Jun 5, 2009 at 8:32 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: So, let's throw away DNSSEC and the broken-from-the-beginning idea of bailiwick. Let's move on to lock the doors and windows. Words of wisdom. I however propose we do not throw it away. I propose it be allowed to wither on the vine until DNSSEC life signs show it as being dead. Then the IETF can then do it's job and give it the proper burial it deserves. I propose all developers simply secure the DNS. A transparent solution tha is available NOW - is DNSCurve. Will ensure the end to end transport of DNS UDP packets is secure. And that basically fixes once and for all the insecurity we have in the UDP transport. DNSCurve encrypts all DNS packets. DNSSEC does not. DNSCurve cryptographically authenticates all DNS responses, eliminating forged DNS packets. DNSSEC does not. DNSCurve very quickly recognizes and discards forged packets, so attackers have much more trouble preventing DNS data from getting through. DNSSEC does not. so I ask you - who wins the cookie in this race? regards joe baptista -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 Personal: www.joebaptista.wordpress.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: DNSSEC is NOT secure end to end
Yes, security of DNSSEC is totally hop by hop. Thus, you imply a definition of hop by hop along digital signature relationships. Indeed, DNSSEC security is limited to the weakest link along the chain from the bottom to the top of the DNS hierarchy. Nothing new there. I don't think any DNSSEC expert ever claimed differently. Even in the presence of the attack by a trusted party, there are still huge differences between DNSSEC and transport-hop-by-transport-hop security. Transport based solution, SCTP or TCP, are open to attacks by any party in the path between two hops -- NAT routers come to mind. DNSSEC is immune to such attacks, a big advantage in practice. Also, it is actually possible to improve on DNSSEC by introducing additional knowledge. If two domains have an establish relation, their servers can memorize the relevant public keys. If a host has a relation with a domain, it can memorize that domain's public key. This kind of peer-to-peer improvement makes the domain-to-domain or host-to-domain DNSSEC service immune to attacks by nodes higher in the hierarchy. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Ohta-san, On Fri, 2009-06-05 at 21:32 +0900, Masataka Ohta wrote: I mention transport security merely because it is still required with DNSSEC, because administrative security of DNSSEC is cryptographically weak. I think we all understand that it is possible to inject bad data into the DNS at the parent. What I do not understand about this comment is how transport security can help in that case. Can you please explain? Thanks, -- Shane ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Ohta-san, On Fri, 2009-06-05 at 22:15 +0900, Masataka Ohta wrote: I think we all understand that it is possible to inject bad data into the DNS at the parent. What do you mean the parent? Do you mean master zone file of the parent or some caching server expected by a client to have parent data? I the parent in the same sense as in RFC 1034 - the delegating level. So, for EXAMPLE.COM this would be COM. What I do not understand about this comment is how transport security can help in that case. Can you please explain? Explanation depends on your definition of the parent. -- Shane ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: DNSSEC is NOT secure end to end
On Wed, 3 Jun 2009, Christian Huitema wrote: Also, it is actually possible to improve on DNSSEC by introducing additional knowledge. If two domains have an establish relation, their servers can memorize the relevant public keys. If a host has a relation with a domain, it can memorize that domain's public key. This kind of peer-to-peer improvement makes the domain-to-domain or host-to-domain DNSSEC service immune to attacks by nodes higher in the hierarchy. How do you handle key changes? How do you determine if the key change is performed by the domain holder or an attacker? There is no reason for such a leap of faith caching. In fact, with SSHFP records, we can also nail down that leap of faith for ssh finally :) Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
On Jun 3, 2009, at 12:23 AM, Christian Huitema wrote: Yes, security of DNSSEC is totally hop by hop. Thus, you imply a definition of hop by hop along digital signature relationships. Indeed, DNSSEC security is limited to the weakest link along the chain from the bottom to the top of the DNS hierarchy. Nothing new there. I don't think any DNSSEC expert ever claimed differently. Even in the presence of the attack by a trusted party, there are still huge differences between DNSSEC and transport-hop-by- transport-hop security. Transport based solution, SCTP or TCP, are open to attacks by any party in the path between two hops -- NAT routers come to mind. DNSSEC is immune to such attacks, a big advantage in practice. Also, it is actually possible to improve on DNSSEC by introducing additional knowledge. If two domains have an establish relation, their servers can memorize the relevant public keys. If a host has a relation with a domain, it can memorize that domain's public key. This kind of peer-to-peer improvement makes the domain-to-domain or host-to-domain DNSSEC service immune to attacks by nodes higher in the hierarchy. Private ad-hoc caching of keys would make DNS fairly fragile. While the trust anchor issue for DNSSEC looms, DNS will remain prone to inadvertently cached unsigned content. Benefits obtained by using DNS over SCTP would be significant protection from out-of-path poisoning, whether information is signed or not. Once DNSSEC is fully implemented and trust anchor issues are resolved, information contained within DNS would not depend upon transport protections. When that might happen remains unknown. However, once DNSSEC becomes widely adopted, the Internet may need protection from UDP/EDNS0 source spoofing. For this, SCTP would offer protection from source spoofing that DNSSEC does not prevent. EDNS0 should also have min/max limits imposed, where packets of a greater size should be handled by SCTP. The brute force strategy that allows DNS over UDP to cope with source spoofing and misuse, also makes DNSSEC over UDP a greater risk. UDP does not lend itself to being moderated or flow controlled, as some suggest. Although TCP permits flow control, TCP is much more vulnerable to resource exhaustion, creating significant costs when defending TCP services compared to those using UDP or SCTP. Reliability, performance and DDoS immunity makes SCTP an attractive solution over TCP. SCTP should perform well as a transport for either DNS or DNSSEC. SCTP would also provide improved security and performance for HTTP as well. :^) -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Shane Kerr wrote: I think we all understand that it is possible to inject bad data into the DNS at the parent. I the parent in the same sense as in RFC 1034 - the delegating level. So, for EXAMPLE.COM this would be COM. If you mean COM zone, it is not necessary to inject any data into the zone. You, instead, can inject a forged certificate into some cache used by your victim. It will be extremely easy if people are deceived that DNSSEC were so secure that no proteciton on cache were necessary. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
On Wed, Jun 03, 2009 at 03:27:42PM +0900, Masataka Ohta wrote: Though we have to trust the zone administration put correct referral and glue data in a master zone file, unless we use DNSSEC, we don't have to trust the zone administration never issue certificates over forged keys of child zones. You know, the former operation is much simpler, thus more secure, than the latter. If an attacker can get its bogus data into the referring zone, who cares whether it's NS data or DS data? One of the important things we are trying to add with DNSSEC is some means of assuring ourselves that the referral we got was the one that comes from the actual authority for that referall, rather than some other agent spoofing the response. DNSSEC appears to provide that assurance, and so far you have provded not one jot of evidence that it does not. I fail completely to see how it is easier to put the wrong DS record in the parent than it is to inject bad NS data in there. If you can put illegitimate data in, there are two possibilities: 1. You put it in via some legitimized mechanism (e.g. via SQL injection, you manage to get data that wasn't intended to be in the zone into the zone). This causes that illegitimate data to be treated as legitimate, and probably signed and such. This is a bad attack, of course, but it is available today. This is no different than being able to plant some evil file on the corporate file server inside the VPN: the security is breached not by failure of its mechanisms, but by failure of authentication. DNSSEC doesn't solve this, I agree; that's because the _provisioning_ of data is beyond the scope of the DNS protocol itself. In any case, surely a more effective attack in this case is to get phony NS or A data (or whatever) into the zone than to put phony DS data. The latter will get you at best a DoS, whereas the former allows you to take control of the target zone. 2. You put it in via some illegitimate mechanism (e.g. by intercepting the wire transmission and adding the data to the stream). Unless the keys are somehow compromised, this vulnerability is exactly what DNSSEC aims to stop. I don't see any argument from you that this DNSSEC capability is not effective. If you have such an argument, it'd be nice to hear it before we continue with the efforts at deployment. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
So, there is no point to deploy DNSSEC. no ? http://jprs.co.jp/en/topics/081125.html regards Marc -- Les enfants teribbles - research / deployment Marc Manthey Vogelsangerstrasse 97 D - 50823 Köln - Germany Vogelsangerstrasse 97 Geo: 50.945554, 6.920293 PGP/GnuPG: 0x1ac02f3296b12b4d Tel.:0049-221-29891489 Mobil:0049-1577-3329231 web : http://www.let.de Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. PGP.sig Description: Signierter Teil der Nachricht ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Marc Manthey wrote: So, there is no point to deploy DNSSEC. no ? No, no point. http://jprs.co.jp/en/topics/081125.html FYI, JPRS, which is a commercial entity to administrate JP domain, is commercially motivated not to admit it merely an untrustworthy third party. In general, registries welcome DNSSEC, no matter how secure it is, as long as its complicated operation works as an excuse to increase (or not to reduce) registration charge and registries' revenue. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
Andrew Sullivan wrote: Though we have to trust the zone administration put correct referral and glue data in a master zone file, unless we use DNSSEC, we don't have to trust the zone administration never issue certificates over forged keys of child zones. If an attacker can get its bogus data into the referring zone, I never said such a thing. I said issue certificates over forged keys of child zones. The attack is possible by those who have access to signature generation mechanisms and the attack is not visible until the false certificates are used later. People introduced DNSSEC believing DNSSEC makes cache poisoning not a problem, are ready to accept false certificates through unprotected cache. Thus, we must, anyway, protect cache. Then, where is the point to introduce DNSSEC only to have another possibility of security holes? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
On Jun 3, 2009, at 8:35 PM, Masataka Ohta wrote: The problem is that the accuracy and integrity of DNSSEC is not cryptographically, but socially secure. DNS over UDP is prone to port/transaction-id guessing, where cryptography could play a protective role. The risk of these values being guessed increases whenever NATs reduce port diversity, or operate in a predictable manner. Protocols such as SPF that embed macros into DNS, allow hundreds of transactions to be chained. The entire chain might result from the local-parts of a single email. These transactions can target otherwise uninvolved victims or evil domains. When an evil domain is the target of SPF transactions, attackers can discover the nature of the resolver. Afterwords, with only one transaction targeting the evil domain, and others targeting their victim, the guesswork for injecting poison is reduced, where even ACLs offer no protection. The growing speed of today's Internet makes this an ever growing concern. While DNSSEC might prevent caches from being poisoned, EDNS0 creates new concerns also aggravated by SPF. Since the 512 byte DNS message size did not accommodate RSA signatures, EDNS0 is required to adjust message limits. EDNS0 allows bad actors to further leverage DNS transactions, such as those that might emanate from cached SPF records to initiate more than 20 TXT record transactions when a recipient evaluates a single email. The TXT records might be policy documents not intended for machine consumption or wildcard SPF records enumerating address authorizations for outbound MTAs. The flexibility sought by SPF has created a sizable list of concerns, where caution was often countered with distain for DNS. It might have been better to have specified limits for EDNS0, such as a minimum message size of 1280 and a maximum at 1424, where transactions that don't comply are refused. UDP allows source spoofing, which could allow bad actors a means to create packet fragmentation by incorrectly setting message. If addition, when fragmentation does occur, DNS transactional-ids offer little protection for packet fragments that may contained unsigned information. DNS will need to be become pedantic about confirming information, perhaps also enforcing the use of checksums and message size. While DNSSEC may not require channel security at some point when a trust anchor can be safely found, DNS over UDP remains a brute. When an SPF process sequence prematurely times out, rather than waiting for exponential back-off, SPF simply begins another sequence, ignoring congestion avoidance. SCTP carrying either DNS or DNSEC packets would ensure DNS remains tame despite much of the abuse. Unlike TCP, SCTP does not commit resources without return of a cookie, but can start data exchanges sooner. SCTP can carry simultaneous DNS messages and can can keep a large number of sparse connections per port active. Perhaps recursive resolvers might be more responsive with SCTP than with UDP. Importantly, the source of abusive DNS behavior can be identified and thereby avoided. This is not true for either TCP or UDP. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
In message 4a285750.9010...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes: Andrew Sullivan wrote: Though we have to trust the zone administration put correct referral and glue data in a master zone file, unless we use DNSSEC, we don't have to trust the zone administration never issue certificates over forged keys of child zones. If an attacker can get its bogus data into the referring zone, I never said such a thing. I said issue certificates over forged keys of child zones. The attack is possible by those who have access to signature generation mechanisms and the attack is not visible until the false certificates are used later. People introduced DNSSEC believing DNSSEC makes cache poisoning not a problem, are ready to accept false certificates through unprotected cache. Thus, we must, anyway, protect cache. Then, where is the point to introduce DNSSEC only to have another possibility of security holes? We still lock doors and windows despite the possiblity of people breaking in by lifting tiles. Attacks at the registry level are the equivalient of lifting tiles. It happens sometimes. Locking the doors and windows stops most attacks however. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- 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: DNSSEC is NOT secure end to end (more tutorial than debating)
Mark Andrews wrote: A problem of blindly believing a zone administration is that it is only as secure as blindly believing an ISP administration. Attacking a router of a large ISPs is as easy/difficult as attacking a signature generation mechanism of a large zone. The difference is we *have* to trust the zone administration. Zone administration involves multiple operations. Though we have to trust the zone administration put correct referral and glue data in a master zone file, unless we use DNSSEC, we don't have to trust the zone administration never issue certificates over forged keys of child zones. You know, the former operation is much simpler, thus more secure, than the latter. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Christian Huitema wrote: NAT routers come to mind. DNSSEC is immune to such attacks, a big advantage in practice. I'm afraid DNSSEC and some NAT interact terribly. Also, it is actually possible to improve on DNSSEC by introducing additional knowledge. If two domains have an establish relation, their servers can memorize the relevant public keys. If a host has a relation with a domain, it can memorize that domain's public key. This kind of peer-to-peer improvement makes the domain-to-domain or host-to-domain DNSSEC service immune to attacks by nodes higher in the hierarchy. Do you know that the paper particularly discusses on revocation? It is written in the paper that: It can happen that a user loses his private key (the value that goes with the given public key) through inadvertence or theft; alternatively, a user may become unworthy in some way relevant to the purpose for which the certificate has been issued. Under such circumstances, the certificate authority (third party) would want to revoke the certificate. How can this be known? Your improvement makes the entire system more complex only to introduce new difficulties for revocation. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
On Tue, Jun 02, 2009 at 10:38:28PM +0900, Masataka Ohta wrote: Christian Huitema wrote: That is, security of DNSSEC involves third parties and is not end to end. That is indeed correct. An attacker can build a fake hierarchy of secure DNS assertions and try to get it accepted. The attack can succeed with the complicity of one of the authorities in the hierarchy. It is a classic attack by a trusted party. Yes, the hierarchy has hops. For my domain: necom830.hpcl.titech.ac.jp, hierarechy of zones have hops of ., jp, ac.jp, titech.ac.jp and hpcl.titech.ac.jp. The authority hops are IANA, JPNIC, my university, and my lab. Though you may have direct relationship with IANA, JPNIC is the third party for both you and me. If an intermediate authority has been compromised, it can just as well insert a fake NS record -- that's not harder than a fake record signature. So, with a compromised hop of an intermediate authority, record signature on the faked next hop key can be generated. Then, with a private key corresponding to the faked next hop key, record signature on the faked second next hop key can be generated. Then, with a private key corresponding to the faked second next hop key, record signature on the faked third next hop key can be generated. Yes, security of DNSSEC is totally hop by hop. Masataka Ohta i think the distinction here might be characterised by the use of terms: -channel security -data integrity DNSSEC - the signing of the data, provides a means to ensure the accuracy and integrity of the data, the payload. Given the design of the DNS, that data can come from an authoritative source or a cache. there is no expectation that the data will emerge from or through any given path/source. Once the data is received, it is possible to determine if the data is a) intact, and b) untampered with. There is no hop/hop at the transport level cause DNS really doesn't work that way today. Channel Security - hop/hop can be done a couple of different ways. IPsec, TSIG, SIG(0), DNSCurve et.al. From a resolver point of view, this type of security is usually done only one hop away, to the prefered cache or (small) set of authoritative servers. It could be possible, but unweildy to do complete channel security. But to what end? --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Bill Manning wrote: i think the distinction here might be characterised by the use of terms: -channel security Don't try to confuse the terminology. With the terminology of channel, the paper addresses the issue that security by channels between zones or zone administrators depends on security of intermediate zones and is not end to end. -data integrity Date integrity is maintained through the channels between zones hop by hop. DNSSEC - the signing of the data, provides a means to ensure the accuracy and integrity of the data, the payload. The problem is that the accuracy and integrity of DNSSEC is not cryptographically but socially secure. So is plain old DNS. So, there is no point to deploy DNSSEC. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Christian Huitema wrote: That is, security of DNSSEC involves third parties and is not end to end. That is indeed correct. An attacker can build a fake hierarchy of secure DNS assertions and try to get it accepted. The attack can succeed with the complicity of one of the authorities in the hierarchy. It is a classic attack by a trusted party. Yes, the hierarchy has hops. For my domain: necom830.hpcl.titech.ac.jp, hierarechy of zones have hops of ., jp, ac.jp, titech.ac.jp and hpcl.titech.ac.jp. The authority hops are IANA, JPNIC, my university, and my lab. Though you may have direct relationship with IANA, JPNIC is the third party for both you and me. If an intermediate authority has been compromised, it can just as well insert a fake NS record -- that's not harder than a fake record signature. So, with a compromised hop of an intermediate authority, record signature on the faked next hop key can be generated. Then, with a private key corresponding to the faked next hop key, record signature on the faked second next hop key can be generated. Then, with a private key corresponding to the faked second next hop key, record signature on the faked third next hop key can be generated. Yes, security of DNSSEC is totally hop by hop. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Masataka Ohta wrote: Christian Huitema wrote: That is, security of DNSSEC involves third parties and is not end to end. That is indeed correct. An attacker can build a fake hierarchy of secure DNS assertions and try to get it accepted. The attack can succeed with the complicity of one of the authorities in the hierarchy. It is a classic attack by a trusted party. Yes, the hierarchy has hops. For my domain: necom830.hpcl.titech.ac.jp, hierarechy of zones have hops of ., jp, ac.jp, titech.ac.jp and hpcl.titech.ac.jp. The authority hops are IANA, JPNIC, my university, and my lab. Though you may have direct relationship with IANA, JPNIC is the third party for both you and me. This is exactly like a chain of PKI CA's (replacing the path from bottom to top of zone hierarchy): For my [end-user administrative units], [chain of CA's] have hops of [CA run by IANA], [CA run by JPNIC], [CA run by my university], and [CA run by my lab]. I don't know what is meant by a direct relationship with IANA. If an intermediate authority has been compromised, it can just as well insert a fake NS record -- that's not harder than a fake record signature. So, with a compromised hop of an intermediate authority, record signature on the faked next hop key can be generated. Exactly the same with a compromised intermediate CA. Then, with a private key corresponding to the faked next hop key, record signature on the faked second next hop key can be generated. Exactly the same with a private key corresponding to the next intermediate CA along the chain (i.e. the one certified by the compromised CA). Then, with a private key corresponding to the faked second next hop key, record signature on the faked third next hop key can be generated. Same thing. Yes, security of DNSSEC is totally hop by hop. Thus, you imply a definition of hop by hop along digital signature relationships. Indeed, DNSSEC security is limited to the weakest link along the chain from the bottom to the top of the DNS hierarchy. Nothing new there. I don't think any DNSSEC expert ever claimed differently. Regards, - Thierry Moreau Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
This debate has nothing to do with the security properties of DNSSEC. A basic assumption of the DNS is that what the authoritative server for zone says is, well, authoritative. The structure of DNS itself entitles JPNIC to point ac.jp wherever they want; by using a name within the .jp domain, you are agreeing to act within JPNIC's domain of control. JPNIC could set up an authoritative server for hpcl.titech.ac.jp completely independently of you, regardless of DNSSEC, and from the perspective of the DNS, that would be the right answer. All DNSSEC does is make the assertions made in the DNS reliable -- it does nothing to change the locus of control. On the other hand, you can certainly use the DNSSEC protocol elements to do peer-to-peer security, just like you can use private DNS servers, and just like you can use TLS without trust anchors (i.e., with self-signed certs). Just hand out the public half of your ZSK to people you want to be able to verify names within your zone. --Richard Masataka Ohta wrote: Christian Huitema wrote: That is, security of DNSSEC involves third parties and is not end to end. That is indeed correct. An attacker can build a fake hierarchy of secure DNS assertions and try to get it accepted. The attack can succeed with the complicity of one of the authorities in the hierarchy. It is a classic attack by a trusted party. Yes, the hierarchy has hops. For my domain: necom830.hpcl.titech.ac.jp, hierarechy of zones have hops of ., jp, ac.jp, titech.ac.jp and hpcl.titech.ac.jp. The authority hops are IANA, JPNIC, my university, and my lab. Though you may have direct relationship with IANA, JPNIC is the third party for both you and me. If an intermediate authority has been compromised, it can just as well insert a fake NS record -- that's not harder than a fake record signature. So, with a compromised hop of an intermediate authority, record signature on the faked next hop key can be generated. Then, with a private key corresponding to the faked next hop key, record signature on the faked second next hop key can be generated. Then, with a private key corresponding to the faked second next hop key, record signature on the faked third next hop key can be generated. Yes, security of DNSSEC is totally hop by hop. Masataka Ohta ___ 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: DNSSEC is NOT secure end to end (more tutorial than debating)
Richard Barnes wrote: This debate has nothing to do with the security properties of DNSSEC. A basic assumption of the DNS is that what the authoritative server for zone says is, well, authoritative. The structure of DNS itself entitles JPNIC to point ac.jp wherever they want; by using a name within the .jp domain, you are agreeing to act within JPNIC's domain of control. JPNIC could set up an authoritative server for hpcl.titech.ac.jp completely independently of you, regardless of DNSSEC, and from the perspective of the DNS, that would be the right answer. I guess what Masataka was referring to is a different source of variance, i.e. an impersonation of JPNIC's authority over its domain of control (using a compromised JPNIC's private key). All DNSSEC does is make the assertions made in the DNS reliable -- it does nothing to change the locus of control. Reliable through a chain fo digital signatures. Reliable to the extent an impersonation attack (on the locus of control) does not occur based on a compromised private signature key. On the other hand, you can certainly use the DNSSEC protocol elements to do peer-to-peer security, just like you can use private DNS servers, and just like you can use TLS without trust anchors (i.e., with self-signed certs). Just hand out the public half of your ZSK to people you want to be able to verify names within your zone. Then you reduce the chain of digital signatures to a single one, raising confidence level at the cost of more key management hindrance. Indeed, this thread seems to be another attempt to understand the basic DNSSEC properties. - Thierry --Richard ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
Richard Barnes wrote: (That is: You already trust the zones above you to maintain the integrity of the zone on the *server*; This assumption does not stand universally. For some DNS users/usage, DNSSEC signature verification will be a must. The discussion implicitly referred to such uses. Then, it is legitimate to appraise the overall confidence in the DNSSEC chain of signatures, and to pinpoint the weakest link (e.g. the zone manager having the greatest likelihood of lousy private key protection in place). Indeed, DNS+DNSSEC is no different from plain DNS for those who are satisfied with the plain DNS. For those awaiting DNS+DNSSEC for some uses, it is useful to understand DNSSEC chains of digital signatures. Accesssorily, the zones above you means nothing to a relying party that is not validating its own domain. Regards, -- - Thierry Moreau ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
On Tue, 2 Jun 2009, Masataka Ohta wrote: For my domain: necom830.hpcl.titech.ac.jp, hierarechy of zones have hops of ., jp, ac.jp, titech.ac.jp and hpcl.titech.ac.jp. The authority hops are IANA, JPNIC, my university, and my lab. Though you may have direct relationship with IANA, JPNIC is the third party for both you and me. Yes, security of DNSSEC is totally hop by hop. Just as DNS was designed to work. hierarchical. If you want to add additional protection because you don't trust your parents, no one stops you from using a DNSSEC capable resolver that has DNSSEC zones configured directly, without relying on the parent. I can't preload 50 million keys. I cannot build trust relations with 50 millions domains. Just like we could not preload 50 million nameserver pointers. Hierarchy is the strength of DNS, not its weakness. DNSSEC allows you to specifically bypass the hierarchy for whatever zone you want. The only real question is, how does Masataka Ohta scale? My suspicion is that you don't scale to 50M domains, and that you will be forced to outsource some of that trust. DNSSEC does the outsourcing of trust distributed to the same people who are already responsible for the data you're about to trust. And note that even if you scale to 50M domains, I don't, so don't expect me to setup a trust relationship with you specifically. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Thierry Moreau wrote: That is, security of DNSSEC involves third parties and is not end to end. This is exactly like a chain of PKI CA's (replacing the path from bottom to top of zone hierarchy): Exactly the same with a compromised intermediate CA. Exactly the same with a private key corresponding to the next intermediate CA along the chain (i.e. the one certified by the The paper of David Clark says PKI is not secure end to end. Some tried to argue against by saying DNSSEC is so special that it is secure end to end. But, as you can observe, DNSSEC is no special and not secure end to end. I don't think any DNSSEC expert ever claimed differently. I am the DNSSEC expert and see some people having a lot less expertise than me says DNSSEC secure end to end. They are incorrect or using different terminology on end to end not acceptable to the Internet community. Masataka Ohtqa ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
Thierry Moreau wrote: (That is: You already trust the zones above you to maintain the integrity of the zone on the *server*; This assumption does not stand universally. For some DNS users/usage, DNSSEC signature verification will be a must. The discussion implicitly referred to such uses. A problem of blindly believing a zone administration is that it is only as secure as blindly believing an ISP administration. Attacking a router of a large ISPs is as easy/difficult as attacking a signature generation mechanism of a large zone. Moreover, administration of LAN of a local organization (my universty, for example) is as secure as administration of a zone local to the organization. You can, for example, bribe a personnel or two, against which there is no cryptographical protection, which means PKI is weakly secure. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Paul Wouters wrote: I can't preload 50 million keys. I cannot build trust relations with 50 millions domains. Just like we could not preload 50 million nameserver pointers. That is the essential point of the paper of David Clark: These certificates are principal components of essentially all public key schemes, except those that are so small in scale that the users can communicate their public keys to each other one to one, in an ad hoc way that is mutually trustworthy. A credit card brand (VISA, for example) may manage more than 50 million PIN numbers. But, it uses agents to do so. The security of the system depends on not only (cryptographical) security between the brand holder and agents but also social security of the agents. Though 4 digit PIN or 16 bit message ID of DNS is cryptographically not very secure, it is a cryptographical issue of each hop, having nothing to do with social security between hops, introduction of which is inevitable for large infrastructures. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
On Wed, 3 Jun 2009, Masataka Ohta wrote: You can, for example, bribe a personnel or two, against which there is no cryptographical protection, which means PKI is weakly secure. You have never heard of a Hardware Security Module? Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
In message 4a25b8ef.70...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes: Thierry Moreau wrote: (That is: You already trust the zones above you to maintain the integrity of the zone on the *server*; This assumption does not stand universally. For some DNS users/usage, DNSSEC signature verification will be a must. The discussion implicitly referred to such uses. A problem of blindly believing a zone administration is that it is only as secure as blindly believing an ISP administration. Attacking a router of a large ISPs is as easy/difficult as attacking a signature generation mechanism of a large zone. The difference is we *have* to trust the zone administration. There is no scalable way to avoid that trust issue. We don't have to trust the router adminstration or caching server administration or authoritative server adminstration. Moreover, administration of LAN of a local organization (my universty, for example) is as secure as administration of a zone local to the organizati on. I've been on plenty of LAN's which I would treat as hostile. You can, for example, bribe a personnel or two, against which there is no cryptographical protection, which means PKI is weakly secure. Which is not a arguement for not doing DNSSEC. Knowing where the risks are is how you do risk management. If you arn't willing to accept some risks then don't connect to the net. Masataka Ohta -- 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: DNSSEC is NOT secure end to end (more tutorial than debating)
In message alpine.lfd.1.10.0906022034140.22...@newtla.xelerance.com, Paul Wou ters writes: On Wed, 3 Jun 2009, Masataka Ohta wrote: You can, for example, bribe a personnel or two, against which there is no cryptographical protection, which means PKI is weakly secure. You have never heard of a Hardware Security Module? HSM doesn't stop the wrong data being signed. It just stops it being signed on machines other that the designated servers. Mark Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- 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: DNSSEC is NOT secure end to end (more tutorial than debating)
On Wed, 3 Jun 2009, Mark Andrews wrote: You can, for example, bribe a personnel or two, against which there is no cryptographical protection, which means PKI is weakly secure. You have never heard of a Hardware Security Module? HSM doesn't stop the wrong data being signed. It just stops it being signed on machines other that the designated servers. The context was the false security of DNSSEC and the third party trust. Obviously changing the raw dns data is possible both with and without DNSSEC. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
In message alpine.lfd.1.10.0906022057560.22...@newtla.xelerance.com, Paul Wou ters writes: On Wed, 3 Jun 2009, Mark Andrews wrote: You can, for example, bribe a personnel or two, against which there is no cryptographical protection, which means PKI is weakly secure. You have never heard of a Hardware Security Module? HSM doesn't stop the wrong data being signed. It just stops it being signed on machines other that the designated servers. The context was the false security of DNSSEC and the third party trust. Obviously changing the raw dns data is possible both with and without DNSSEC. Paul If you are bribing personel you need to assume they can do anything the orginisation they work for can do. HSM's don't help in this case. HSM's have their place but you need to understand the limitations of the devices. HSM's are better than just having the private component of a public key sitting on a disk somewhere but in most operational enviornments they don't add that much more security to the process. 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: DNSSEC is NOT secure end to end (more tutorial than debating)
At 09:09 PM 6/2/2009, Mark Andrews wrote: HSM's are better than just having the private component of a public key sitting on a disk somewhere but in most operational enviornments they don't add that much more security to the process. It depends on the HSM. For example, there are HSMs that allow you to program just about any policy you want - including the requirement to have at least N people agree that something needs to be signed. The size of N is chosen to balance need for accountability with that of usefulness. I.e. requiring 20 people to turn the keys to get something signed is probably not useful. Permitting 1 person to sign without further oversight is probably not enough accountability. So saying they don't add much more security is really a statement that might be correct under really bad management practices, but mostly isn't. For example, even a simple version of keeping the set of HSM PIN holders distinct from set of people allowed to physically access the HSM for signing provides a substantial amount of operational security. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
On Mon, Jun 1, 2009 at 12:30 AM, Mark Andrews ma...@isc.org wrote: If you believe that I have a bridge to sell you. Keep the bridge - it's all yours. Remember - in order to sell the bridge you first have to own it. Your convenced you have something to sell. I am not. Totally different from DNSSEC. You can disagree all you want but it doesn't change the fact that DNSSEC and DNSCurve both have chains of trusts. The proponents of DNSCurve even say this. Note the chain of trust as described on http://www.dnscurve.org/tld.html/. The correct URL is http://www.dnscurve.org/tld.html not http://www.dnscurve.org/tld.html/ And yet again - it has nothing to do with chains of trust. It does learn how to trust and whom to trust. Thats part of the job. What DNSCurve does do is it adds link-level public-key protection to DNS packets therefore guaranteeing the integrity of the packets end to end. Totally different from DNSSEC which indeed uses chains of trust - i.e. root to tld to sld etc.etc. I am totally amazed at the propaganda that comes out of ISC these days. When you guys start comparing DNSSEC to DNSCurve - we'll - all I can say is this - I have this really nice bridge on the Hudson I'd like to sell you that will compliment the bridge you've already have. cheers joe baptista -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 Personal: www.joebaptista.wordpress.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
In message 874c02a20906010608p3e7fbdd3wa31c9ea5452a7...@mail.gmail.com, Joe Baptista writes: On Mon, Jun 1, 2009 at 12:30 AM, Mark Andrews ma...@isc.org wrote: If you believe that I have a bridge to sell you. Keep the bridge - it's all yours. Remember - in order to sell the bridge you first have to own it. Your convenced you have something to sell. I am not. Totally different from DNSSEC. You can disagree all you want but it doesn't change the fact that DNSSEC and DNSCurve both have chains of trusts. The proponents of DNSCurve even say this. Note the chain of trust as described on http://www.dnscurve.org/tld.html/. The correct URL is http://www.dnscurve.org/tld.html not http://www.dnscurve.org/tld.html/ And yet again - it has nothing to do with chains of trust. It does learn how to trust and whom to trust. Thats part of the job. What DNSCurve does do is it adds link-level public-key protection to DNS packets therefore guaranteeing the integrity of the packets end to end. DNSCurve protects authoritative server to iterative resolver if and only if you can authenticate the names of the nameservers and that they are supposed to be serving the zone you are querying against. If you can't do that then you are just talking to some random server using a cryptographic channel and you shouldn't be trusting the results. Totally different from DNSSEC which indeed uses chains of trust - i.e. root to tld to sld etc.etc. And DNSCurve uses chains of trust from root servers to tld servers to sld servers etc. etc. I am totally amazed at the propaganda that comes out of ISC these days. When you guys start comparing DNSSEC to DNSCurve - we'll - all I can say is this - I have this really nice bridge on the Hudson I'd like to sell you that will compliment the bridge you've already have. cheers joe baptista -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 Personal: www.joebaptista.wordpress.com -- 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: DNSSEC is NOT secure end to end
As a disinterested third party... On Mon Jun 1 16:09:39 2009, Mark Andrews wrote: Totally different from DNSSEC which indeed uses chains of trust - i.e. root to tld to sld etc.etc. And DNSCurve uses chains of trust from root servers to tld servers to sld servers etc. etc. After skimming DNSCurve to get the general idea, I agree with Mark here. I don't see any particular way in which the NS records (which specify the keys) from the parent are themselves validated, other than by trusting the parent domain's nameservers, which essentially means they give equivalent protection to DNSSEC from that standpoint. I did wonder whether there was additional scope for leap of faith, but I'm not sure even that exists. Moreover, since DNSCurve only operates hop-by-hop, rather than end-to-end (in the sense of the DNS resolution process as a whole) it relies on a hop-by-hop trust arrangement. In particular, my servers here would have to use either a trusted resolver, or no resolver at all. I do note that DNSCurve looks like a neat hack, just one that, on closer inspection, turns out to have no obvious benefits in this particular respect. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
In your previous mail you wrote: = not only this is very arguable (for instance about the resource exhaustion) but no hop-by-hop/channel security, even something as strong as TSIG, can provide what we need, i.e., end-to-end/object security (*). PS (*): I use the common meaning of end-to-end, not Masataka Ohta's one. = I added it because hop-by-hop and end-to-end can be ambiguous when hops and ends are not defined. In the context of DNS intermediate entities are the caching servers so even I agree your argument is valid it doesn't apply to *this* interpretation of the term end-to-end. Regards francis.dup...@fdupont.fr PS: if you'd like to discuss about end-to-end arguments there is a dedicated mailing list at IRTF. If you'd like to continue about the trusted third parties as intermediate entities I believe the thread you initiated is the best place. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
In message 874c02a20905311802r2b9b4544j374bb374eb7a7...@mail.gmail.com, Joe Baptista writes: DNSSEC indeed violates the end to end principle. It's simply that simple. And it asks us to put our trust in the root a.k.a. ICANN. I don't think governments world wide are going to put their trust and faith in ICANN. The U.S. Government is the only government that has been bamboozled into adopting DNSSEC into .gov infrastructure. I wonder how President Obama would feel about handing over the keys to U.S. Government infrastructure to a U.S. contractor. I'd have trouble sleeping at night if that was the case. I've addressed this at length in my comments to the NTIA. http://www.ntia.doc.gov/DNS/comments/comment034.pdf If the U.S. government wants DNSSEC today then it must nationalize the roots. I don't even trust Vixie with the root. I remember when he hijacked the root with Postel. Or as they put it we were only running an experiment. In any case the new infrastructure campaign demands U.S. government roots be set up to exclusively serve U.S. network infrastructure. regards joe baptista p.s. If you want to secure the DNS end to end - think DNSCurve - not DNSSEC. http://dnscurve.org/ DNSCurve has exactly the same trust issues as DNSSEC does. You are trusting the parent to give you a secure introduction to the child. The introduction is just encoded differently. 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: DNSSEC is NOT secure end to end
I disagree. DNSCurve has nothing to do with trust. It simply ensure the system you are connected to is in fact the system that gives you the answer. DNSCurve addresses the UDP issues without the need for a root or any other third party enjoying any degree of trust. Totally different from DNSSEC. regards joe baptista On Sun, May 31, 2009 at 9:38 PM, Mark Andrews ma...@isc.org wrote: In message 874c02a20905311802r2b9b4544j374bb374eb7a7...@mail.gmail.com, Joe Baptista writes: DNSSEC indeed violates the end to end principle. It's simply that simple. And it asks us to put our trust in the root a.k.a. ICANN. I don't think governments world wide are going to put their trust and faith in ICANN. The U.S. Government is the only government that has been bamboozled into adopting DNSSEC into .gov infrastructure. I wonder how President Obama would feel about handing over the keys to U.S. Government infrastructure to a U.S. contractor. I'd have trouble sleeping at night if that was the case. I've addressed this at length in my comments to the NTIA. http://www.ntia.doc.gov/DNS/comments/comment034.pdf If the U.S. government wants DNSSEC today then it must nationalize the roots. I don't even trust Vixie with the root. I remember when he hijacked the root with Postel. Or as they put it we were only running an experiment. In any case the new infrastructure campaign demands U.S. government roots be set up to exclusively serve U.S. network infrastructure. regards joe baptista p.s. If you want to secure the DNS end to end - think DNSCurve - not DNSSEC. http://dnscurve.org/ DNSCurve has exactly the same trust issues as DNSSEC does. You are trusting the parent to give you a secure introduction to the child. The introduction is just encoded differently. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 Personal: www.joebaptista.wordpress.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
In message 874c02a20905312100g120b83c7ufbfc13b2849a4...@mail.gmail.com, Joe Baptista writes: I disagree. DNSCurve has nothing to do with trust. It simply ensure the system you are connected to is in fact the system that gives you the answer. DNSCurve addresses the UDP issues without the need for a root or any other third party enjoying any degree of trust. If you believe that I have a bridge to sell you. Totally different from DNSSEC. regards joe baptista You can disagree all you want but it doesn't change the fact that DNSSEC and DNSCurve both have chains of trusts. The proponents of DNSCurve even say this. Note the chain of trust as described on http://www.dnscurve.org/tld.html/. The root DNS servers can also be protected with DNSCurve. Once a cache knows DNSCurve server names for the root servers, its packets to and from those servers are protected, so it securely learns the DNSCurve server names for .com and other top-level domains, so its packets to and from the .com servers are protected, so it securely learns the DNSCurve server names for nytimes.com, etc. 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: DNSSEC is NOT secure end to end
Francis Dupont wrote: = not only this is very arguable (for instance about the resource exhaustion) but no hop-by-hop/channel security, even something as strong as TSIG, can provide what we need, i.e., end-to-end/object security (*). Unless your meaning of end-to-end differs from that of David Clark, the following argument of his paper is applicable to DNSSEC. http://portal.acm.org/citation.cfm?doid=383034.383037 Rethinking the design of the Internet: The end to end arguments vs. the brave new world The certificate is an assertion by that (presumably trustworthy) third party that the indicated public key actually goes with the particular user. These certificates are principal components of essentially all public key schemes, That is, security of DNSSEC involves third parties and is not end to end. PS (*): I use the common meaning of end-to-end, not Masataka Ohta's one. I'm afraid you don't know who David Clark is and how he is related to the end to end argument. However, all the people who are qualified to discuss end to end do know him and his argument. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
