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: [Asrg] DNSSEC is NOT secure end to end
On Wed, Jun 10, 2009 at 09:18:22AM +0900, Masataka Ohta wrote: With DNSSEC, a security aware resolver will want to check the signature. Except for glue A. That's not a vector for attack. Glue records from the parent side of the cut are not authoritative data in the parent zone, because the zone in question has been delegated away. They're only to be used to stick the two sides of the cut together. (Indeed, treating the parent-source glue data as authoritative and reusing it as answer data is in fact a source of poison attacks, as you have quite cogently pointed out more than once.) If you are validating data, why would you not follow the chain to the glue record (secured on each side of _that_ cut by the DS/DNSKEY pairs) and validate the signature on the authoritative data you get? You'll get a signature over the A record from the child server, and that signature will either pass or fail validation according to the same rules as before. (Glue records on the child side do, of course, come with RRSIGs which can be validated just like anything else.) I think people have already heard enough from me on this topic, so I won't post on it any more. But if you have a real attack that actually works against DNSSEC in the cases you keep insisting it does, please show it. Otherwise, please stop insisting DNSSEC is broken. You haven't shown that it is, and you seem to be making no effort to provide such a demonstration. There's no question that DNSSEC is complicated, and that it provides a whole new pile of ways for zone administrators to screw things up: new features provide a new opportunity for mistakes. But that's nowise a proof that DNSSEC itself does not do what it says it does. Best regards, Andrew -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ 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: [Asrg] DNSSEC is NOT secure end to end
Andrew Sullivan wrote: With DNSSEC, a security aware resolver will want to check the signature. Except for glue A. That's not a vector for attack. Glue is the vector for most, if not all, attacks including Kaminsky's and DNSSEC with forged certificates. If you are validating data, why would you not follow the chain to the glue record (secured on each side of _that_ cut by the DS/DNSKEY pairs) and validate the signature on the authoritative data you get? Following the chain over a forged certificate to confirm forged data have valid signatures? Or, what if the glue is inside a grand child zone on which no nameservers are responding? When DNSSEC was designed, I pointed out several detailed but fatal problems including that glue can not be secured. The WG had a different fantasy. The WG wasted about 10 years for experimental deployment only to confirm that I have been perfectly correct and the protocol was modified. So, you don't have to waste yet another 10 years only to reconfirm it. Just accept the current DNSSEC protocol: With DNSSEC, a security aware resolver will want to check the signature. Except for glue A. which makes DNSSEC as insecure as plain old DNS. 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
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: [Asrg] DNSSEC is NOT secure end to end
Hi, [ASRG removed, since I cannot see even a little bit how this is on-topic there. But if you think it is, feel free to republish this as you like.] On Tue, Jun 09, 2009 at 08:54:48AM +0900, Masataka Ohta wrote: As has been discussed in the thread, DNSSEC is NOT a protection against cache poisoning, because caches poisoned with forged certificate breaks the security. To beat the stain on the ground that betokens the long-since-passed equine presence, you haven't answered the question, posed to you several times, how this poison-with-forged-certificate is supposed to work. If I have a validating resolver, and I get data from a poisoned cache, then I attempt to validate the signature over that data, checking the chain of signatures from that data all the way back to some trust anchor I have configured. Therefore, in order to poison a cache with a forged certificate, one of two things has to have happened: 1. The forger managed to forge keys and inject them in the poisoned cache such that one of those keys will be valid according to the trust anchor I have installed. Is this the threat you claim? If so, and assuming you're not saying that the crypto is weak (in which case we have way bigger problems than forged DNS data), that just seems to be a claim that the signing procedures can be subverted. And yes, of course, a security system is possibly subverted by poor operation. I'm not sure what the surprise is supposed to be here. You can argue just as easily that the DNS is badly secured because it's possible to convince a registrar to publish the wrong data for a domain (a problem we've certainly seen in action more than once). It is indeed possible to get bad data into the system, and DNSSEC doesn't completely protect against such bad data coming in; but that is no criticism of DNSSEC. 2. The forger managed to forge data that is not validatable in a chain from any trust anchor I have, and managed to convince me to trust it anyway. If this is the threat you claim, I want to know how this works. If you're right, then DNSSEC is indeed completely broken. We need to know that now, before more deployment goes on. If neither of (1) or (2) happens, then my attempt to validate the data will fail, marking the data bogus. It is true that this is a vector for denial of service: I won't connect to a site with invalid DNS data. I'm having a hard time coming up with a reason why that is worse than I go to the site controlled by Dr Evil. Best regards, Andrew -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Asrg] DNSSEC is NOT secure end to end
On Tue, 2009-06-09 at 08:54 +0900, Masataka Ohta wrote: DNSSEC provides two things. Firstly, it provides the means to digitally sign RRsets. This provides data origin authentication and data integrity. The provision is through hops of certificate authorities, As I clearly stated, the actual signing is end to end, and if the receiver has chosen to trust the explicit key used to sign, there is no involvement of PKI. The presence of a valid digital signature is good evidence that the data originated in that form from the owner of the private key corresponding to the public key used for verification. which is what is discussed in latter paper of David Clark published in 2001. Read it. I have, and I cannot find any explicit sentence which uses the phrase hops of certificate authorities. Nor can I find any statement which states anything to the effect PKI is not end to end and is therefore bad. If these are present, please point them out. He does state Each interaction is nominally ... but its robustness depends on the larger context composed of the whole sequence. It does state, in effect, PKI is difficult (particularly because of the revocation problem) but that is well known. But it also gives me the impression that it says that this kind of thing is necessary, because of the trust issue on the modern Internet. I'm not sure of the reason for your insisting that DNSSEC is not end to end. I must apologise to the Asrg list for continuing this discussion, which seems to have just gone down a pointless semantic hole. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Asrg] DNSSEC is NOT secure end to end
On Tue, 2009-06-09 at 08:54 +0900, Masataka Ohta wrote: This origin authentication and integrity is precisely what is required to avoid the DNS cache poisoning which is the kind of vulnerability which prompted this discussion. As has been discussed in the thread, DNSSEC is NOT a protection against cache poisoning, because caches poisoned with forged certificate breaks the security. I think you need to explain how this happens in detail. For instance, an attacker wishes to poison the cache of some ISP's DNS server for 'example.com.. Currently, it gets the server to request information about example.com from its authoritative server, and sends information that purports to be from that server. It needs to guess some properties of the original request, but there have been and are various features of DNS servers which make this easier than you might think. Without DNSSEC, the attacked DNS resolver simply accepts the information. With DNSSEC, a security aware resolver will want to check the signature. The information is only accepted if the signature checks out, and the key is trusted. If the key is a trust anchor, then the check is complete. If not, then the resolver needs to get the DS RR for example.com from com's DNS server. This information is itself signed with com's signing key. So, it will not accept that unless it verifies. If com's signing key is not a trust anchor, then it will get com's DS RR from the root. Also signed by root, and the root key is probably a trust anchor. If any of this information is not available, or is not signed, then the trust chain is not present, and the original information is not accepted by the security aware resolver. So, perhaps you can explain how an attacker can get a security aware resolver to accept information which will subvert this? I think you have proposed that an attacker might explicitly subvert the chain. In this case it would involve getting the com DNS server to accept a DS RR for example.com. This is altogether harder problem for the attacker, and is of a significantly different character than cache poisoning, as it involves actual changes to the DNS servers, rather than just persuading resolvers to accept incorrect information. But, perhaps this mechanism would better be reported to people other than the asrg. ___ 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: [Asrg] DNSSEC is NOT secure end to end
David Wilson wrote: As has been discussed in the thread, DNSSEC is NOT a protection against cache poisoning, because caches poisoned with forged certificate breaks the security. I think you need to explain how this happens in detail. In detail??? See below. With DNSSEC, a security aware resolver will want to check the signature. Except for glue A. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Asrg] DNSSEC is NOT secure end to end
David Wilson wrote: The provision is through hops of certificate authorities, As I clearly stated, As we are discussing on concepts described in two papers, your own statement without proper quotation from the papers does not mean anything. the actual signing is end to end, The security hole is located not between certificate authorities but within certificate authorities. To quote from the 2001 paper, Transactions based on a wellknown public key can be rather simple two-party interactions that fit well within the end to end paradigm. However, there is a key role for a third party, which is to issue a Public Key Certificate and manage the stock of such certificates; such parties are called certificate authorities. the first sentence roughly corresponds to your statement the actual signing is end to end, however... And the third parties of certificate authorities constitute a chain, a channel, hops or whatever terminology you might use, which is not end to end. Masataka Ohta ___ 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: [Asrg] DNSSEC is NOT secure end to end
On Sat, 2009-06-06 at 13:09 +0900, Masataka Ohta wrote: David Wilson wrote: However, I think there is some difference in the way people are using some terms. According to the terminology of David Clark, PKI including DNSSEC is not secure end to end. DNSSEC provides two things. Firstly, it provides the means to digitally sign RRsets. This provides data origin authentication and data integrity. As this operates at the DNS application layer, this is clearly end to end within David Clark's terminology. It does not rely on any security services in the lower communication layers (in the way that, for instance, relying on TCP would). This origin authentication and integrity is precisely what is required to avoid the DNS cache poisoning which is the kind of vulnerability which prompted this discussion. This aspect of DNSSEC does not require the use of any PKI. A security aware resolver can obtain by some out-of-band means the public signing key for some island of security, and choose to trust that key. However, such bilateral arrangements do not scale to the Internet. So, DNSSEC provides a means for an Authentication Chain, to use the specific DNSSEC term. A signed zone can authenticate the key of a child zone. There is a chain here. However, it is of a significantly different character to a communication network. Whether it is end to end or not, is for a different discussion. End-to-end security means that the security of that data item does not depend on the trustworthiness of any intermediate node, or channel. According to the terminology of David Clark, certificate authorities are intermediate nodes. If you have different terminology, use it outside of the Internet community but not within. I get the impression from you that DNSSEC is to be disregarded because it is not end to end. However, the opinion of the Internet community as regards DNSSEC has been made clear in the last few days, given these announcements: http://www.nist.gov/public_affairs/releases/dnssec_060309.html http://pir.org/index.php?db=content/Websitetbl=ORG_Advantageid=2 http://www.networkworld.com/news/2009/022409-verisign-dns-security.html?hpg1=bn If the Internet community agrees with you that DNSSEC is not end to end, then this does not seem to divert them from implementing it. best regards David ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Asrg] DNSSEC is NOT secure end to end
On Mon, 2009-06-08 at 14:22 +0900, Masataka Ohta wrote: 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. Er, no. The article states: The arguments that are used in support of reduced instruction set computer (RISC) architecture are similar to end-to-end arguments. I.e. the arguments for end to end are similar to the arguments for RISC. This is not the same as saying that RISC is an example of end to end design. 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. [Interesting articles, which took me back to discussions 20 years ago as regards connectionless vs. connection oriented networks.] It is clear from both of these that the basic subject is data communication over a communication system. Thus the second article quotes from the first article thus: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communications system. Therefore, providing that questioned function as a feature of the communications systems itself is not possible. So the basic object under consideration here is a communication system. It is clear from the first article that what is envisaged is a layered model, (c.f. the conclusion). I would not be surprised if this kind of thinking was input to the development of the OSI model for data communications, which does set out to assign to each layer an appropriate function. The basic thesis of the article is that functions concerned with, for instance, security and reliability are best done in the upper layers, even the top (application) layer, as the application cannot rely entirely on the lower layers to do their stuff. Thus end to end is about communication from one application layer to the peer application layer down through the layers at one system, and then up through the layers at the other system. So, I would paraphrase the end to end design principle as the application to application design principle. I note that in models like the OSI model, only the lowest layer have intermediate systems. (That's why layer 3 is called the network layer). The article in no way implies that it is the existence of intermediate systems which is the deciding factor in the design. End to end is not in contrast to hop by hop. So, applying this to DNSSEC's PKI, this is clearly an application layer security system. The system does not depend upon the security or reliability of any lower layers (or, indeed, intermediate systems). So, it would seem to fit the end to end design of this article. The second article is a discussion about how the end-to-end design principle might need to be modified in the light of the realities of the modern Internet. In the present context of DNSSEC, the discussion of trust is important. best regards David ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Asrg] DNSSEC is NOT secure end to end
David Wilson wrote: According to the terminology of David Clark, PKI including DNSSEC is not secure end to end. DNSSEC provides two things. Firstly, it provides the means to digitally sign RRsets. This provides data origin authentication and data integrity. The provision is through hops of certificate authorities, which is what is discussed in latter paper of David Clark published in 2001. Read it. As this operates at the DNS application layer, this is clearly end to end within David Clark's terminology. It does not rely on any security services in the lower communication layers (in the way that, for instance, relying on TCP would). If you read the paper, you can find the lower layer of PKI consists of communication with or between certificate authorities. Compromising a certificate authority in the lower communication layer breaks the security of data origin authentication and data integrity. This origin authentication and integrity is precisely what is required to avoid the DNS cache poisoning which is the kind of vulnerability which prompted this discussion. As has been discussed in the thread, DNSSEC is NOT a protection against cache poisoning, because caches poisoned with forged certificate breaks the security. This aspect of DNSSEC does not require the use of any PKI. Read the 2001 paper on why PKI not end to end and why DNSSEC no exception. The paper explains why scale breaks the end to end property. I get the impression from you that DNSSEC is to be disregarded because it is not end to end. Being end to end has practical advantages. See above on how useless DNSSEC is to avoid cache poisoning, which was the motivation to deploy it. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RISC is end to end (was Re: [Asrg] DNSSEC is NOT secure end to end)
David Wilson wrote: 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. Er, no. The article states: The paper states: any attempt by the computer designer to anticipate the client's requirements for an esoteric feature will probably miss the target slightly and the client will end up reimplementing that feature anyway which is an end to end argument where communication is at high level between computer designers and their clients. It is clear from both of these that the basic subject is data communication over a communication system. That is true only with the widest meaning of communication. However, IN NETWORKING by Phillip has a lot narrow meaning and even the original paper says: A version of the end-to-end argument in a non-communication application was developed in the 1950's by system analysts whose responsibility included reading and writing files on large numbers of magnetic tape reels. So, applying this to DNSSEC's PKI, this is clearly an application layer If you want to draw some conclusion from the 2001 paper, quote text from the paper. There is no point to reiterate it with your subtly modified terminology only to give a subtly modified impression on the content of the paper. The second article is a discussion about how the end-to-end design principle might need to be modified in the light of the realities of the modern Internet. That is an explanation on the motivation to write the paper and the conclusion of the paper is: We argue that the open, general nature of the Net, which derived from the end to end arguments, is a valuable characteristic that encourages innovation, and this flexibility should be preserved. which means the end to end argument is not modified. Instead, the paper, for example, says for regulations to be realistic, they should follow the end to end principle. 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: 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
DNSSEC is NOT secure end to end
Bill Manning wrote: If you are so interested in transport layer security, then by all means, encourage, promote, and develop solutions. The discussion of the paper of David Clark about public key is not on a transport but on an administrative layer. The paper says: However, there is a key role for a third party, which is to issue a Public Key Certificate and manage the stock of such certificates; such parties are called certificate authorities. and the issuance and management of certificates, which is the key, involves no transportation of the certificates and is not transport but local (local to zone) administrative issues. Or, if you insist the paper discusses on transport layer security of public key cryptography, please feel free to quote the relevant part of the paper. I mention transport security merely because it is still required with DNSSEC, because administrative security of DNSSEC is cryptographically weak. 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. 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: [Asrg] DNSSEC is NOT secure end to end
On Tue, 2009-06-02 at 22:38 +0900, Masataka Ohta wrote: Yes, security of DNSSEC is totally hop by hop. I am nervous of adding to this debate (and should it really be on ASRG?) However, I think there is some difference in the way people are using some terms. My understanding of the terms hop-by-hop and end-to-end is this: A data item traverses a number of nodes within a network. (E.g. a UDP datagram moving through an inter-network, or a Email message from its submitting UA via a sequence of MTAs to the recipient's UA). End-to-end security means that the security of that data item does not depend on the trustworthiness of any intermediate node, or channel. Hop-by-hop security means that you do rely on the trustworthiness of the intermediate nodes and channels. (E.g. CRC provides no defence against deliberate tampering, TLS for email is only as trustworthy as the least trusted intermediate MTA). PKI establishes a chain of trust between the signing certificate (i.e. the certificate containing the public key corresponding to the private key used to generate the signature) and your trust anchors (which you choose). This is not really hop-by-hop as data is not hopping. Like a real chain, it is only as strong as its weakest link. However, the chain operates in a different 'space' from that used to transfer the data being protected. As far as I understand, the key thing which DNSSEC gives you is data origin authentication (although that by itself without data integrity would be useless). The DNS attacks which were the start of the discussion are all based on the attacker sending false data to the system under attack. Having an effective means for determining from whom data comes is necessary to overcome this kind of attack. best regards David Wilson ___ 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: [Asrg] DNSSEC is NOT secure end to end
David Wilson wrote: However, I think there is some difference in the way people are using some terms. According to the terminology of David Clark, PKI including DNSSEC is not secure end to end. End-to-end security means that the security of that data item does not depend on the trustworthiness of any intermediate node, or channel. According to the terminology of David Clark, certificate authorities are intermediate nodes. If you have different terminology, use it outside of the Internet community but not within. 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
Appropriate forum? (was: DNSSEC is NOT secure end to end)
To the IETF mailing list subscribers: The US government involvement in DNSSEC operations is almost certainly not in-scope for the ietf mailing list. Thus, it would be counterproductive to start a discussion based on Mr. Baptista comments on this topic (hence no in-line comments in the original message below). However, the question remains: which forum, if any, is appropriate for a discussion? I don't have the answer, so I merely share the following observations. A) ICANN was specifically requested to abstain from public consultations about its proposal to deploy DNSSEC at the root. This is in a letter from US Department of Commerce to ICANN, ref http://www.icann.org/correspondence/baker-to-twomey-09sep08.pdf (filed among other documents in http://www.icann.org/correspondence/ ). B) The US Department of Commerce issued a public comment notice (the deadline is now past), see http://www.ntia.doc.gov/DNS/DNSSEC.html . This forum has been used by Mr. Baptista. I was favourably impressed by the material written by NTIA staff (and published in the Federal Register), so I would recommend this reading (at http://www.ntia.doc.gov/frnotices/2008/FR_DNSSEC_081009.pdf ). However, this forum is not really interactive. C) Some other forums on which DNSSEC protocol and operational aspects are discussed frequently avoid and/or terminate discussions about US government involvement in DNSSEC operations for the DNS root. I do not blame their moderator or anybody else, I'm just reporting an observation. D) If any stakeholder group or representatives see some effectiveness in the WSIS, the discussions on DNSSEC deployment would fall under the heading critical Internet resources. I don't see much potential for active discussion on this front, but it's only my opinion. So, that's it. Anybody has other suggestions for an appropriate forum for DNSSEC deployment at the root *including* US government involvement? Regards, - Thierry Moreau Joe Baptista wrote: 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/ On Sat, May 30, 2009 at 7:27 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp mailto:mo...@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 mailto:Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Joe Baptista www.publicroot.org http://www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the
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
DNSSEC is NOT secure end to end
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/ On Sat, May 30, 2009 at 7:27 PM, Masataka Ohta mo...@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 -- 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 -- 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 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
DNSSEC is NOT secure end to end
Mark Andrews wrote: In a general PKI you need a third party to validated the name to certificate mapping because there is not natual method to do this. With DNSSEC the naming authority is the introducing authority. Read the paper. Your attempt to modify the meaning of the third party does not affect the following part of the paper and its consequences. http://portal.acm.org/citation.cfm?doid=383034.383037 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. This is where DNSSEC differs from a general PKI infrastucture. Regardless of whether DNSSEC differs from a general PKI or not, security of DNSSEC is not end to end. Masataka Ohta ___ 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