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 Ohta 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
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-Baker 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 > Ohta 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
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 Ohta 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
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 Ohta 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
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 Ohta 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
On Thu, Jun 11, 2009 at 10:34 PM, Mark Andrews wrote: > > In message , > 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
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 Kent 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
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 Andrews wrote: > > In message , > 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
* 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: > 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
* 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: > 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
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
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: >>>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
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
In message , Phill ip Hallam-Baker writes: > So we have totally abandoned the idea of doing DNSSEC in the end point clie= > nt? No. Recursive nameserver need to validate the answers returned from the DNS for their own uses. This doesn't preclude other applications also validating answers. Having recursive nameserver validate answers is not the end point in DNSSEC deployment. It's just a good first step which is good enough is some operational envionments. There are however lots of operational envioronments where this would not be good enough and the validation really needs to be performed in the application. For your light switch example a validating recursive resolver is probably all you need. For laptops you most probably want to move the validation onto the laptop either in the application or by a running a validation recursive nameserver on the laptop which may or may not use the nameservers in the DHCP response as forwarders. I do this today. > Trust roots have to be valid for at least a decade to be acceptable to > the application vendor community. That's a unproved assumption. > And even though the current model of network administration is to > constantly fiddle with everything, I think that is going to have to > stop. Lots companies already use private roots. Equipment manufactures are not going to build equipment that can't be used by those markets. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
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
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
In message , 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
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 Barnes 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 Kent 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 wan
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 Andrews wrote: > > In message , 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://quantum
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 Kent 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
At 10:41 AM +1000 6/11/09, Mark Andrews wrote: In message , 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
In message , 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: 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 Kent wrote: > Joe, > > You have argued that DNSSEC is not viable because it requires that everyone > adopt IANA as the common root. I agree that under the current IANA > management situation many folks may be uncomfortable with IANA as the root. > However, in practice, the world has lived with IANA as the root for the > non-secure version of DNS for a long time, so it's not clear that a > singly-rooted DNSSEC is not viable based on this one concern. Moreover, > DNSSEC is a form of PKI, an din ANY PKI, it is up to the relying parties to > select the trust anchors they recognize. In a hierarchic system like DNS, > the easiest approach is to adopt a single TA, the DNS root. But, it is still > possible for a relying party to do more work and select multiple points as > TAs. I would expect military organizations in various parts of the world to > adopt a locally-managed TA store model for DNSSEC, to address this concern. > However the vast majority of Internet users probably are best served by the > single TA model. > > As for DNSCurve, I agree with the comments that several others have made, > i.e., it doe snot provide the fundamental security one wants in DNS, i.e., > an ability to verify the integrity and authenticity of records as attested > to by authoritative domains, din the face of caching. > > > Steve > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
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
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
