Hi Dan, Yes I want to consider the DNS authentication of encryption keys as one scenario which has a dependency on DNSSEC so we quickly get full circle.
There have been a number of people who have offered opinions in this area, and none so far have pointed to a technology issue as holding up deployment. Far from it, there seems to be advances in many area. This all seems goodness. It seems a little disturbing that it took a stick to get some level of DNSSEC deployment in the .gov domain. That model is hard to replicate elsewhere so I don't see it as a general solution to deployment. I much prefer carrots to drive dependents. You are correct in that the Dutch government was one of the two governments I could find who's public web site was actually DNSSEC secured, despite many of the parent domain being signed. The only other was Estonia. As you pointed out, there are a large number of content distribution networks hosting sites on behalf of organizations with signed domains, who have not signed their own domain thereby breaking the chain of trust to the web site dns record. We seem to be missing the carrot to get them to sign. What is the value proposition that would convince them to sign their domain? I note that there is a session at the forthcoming ICANN DNSSEC workshop on DNSSEC and the enterprise. What about small and mediums sized organizations who have typical lower security skill and smaller budgets? They are mostly migrating to cloud services of some form. Aside from inviting speakers, has the been any research done with organizations on why they are not adopting DNSSEC? It may also be fruitful to think about what are the next set of deployment goals in terms of what scenarios do we want to work. I would submit its time to move on from how many of the TLDS are signed onto tangible goals like what works. Do we want to look at a percentage of the email sent over the internet being DANE protected for example. Trevor From: Dan York [mailto:[email protected]] Sent: Monday, April 28, 2014 2:47 PM To: Trevor Freeman Cc: [email protected] Subject: Re: [perpass] Is DNSDEC a viable technology for perpass? Trevor, On Apr 28, 2014, at 2:38 PM, Trevor Freeman <[email protected]<mailto:[email protected]>> wrote: We have a range of technologies in the toolkit to address issues identified by perpass. One of the candidate technologies is DNSSEC. At a technology level it has much to commend it. Which of the perpass issues do you see DNSSEC helping with? If I look at http://tools.ietf.org/html/draft-trammell-perpass-ppa-01 or http://tools.ietf.org/html/draft-tschofenig-perpass-surveillance-01 or other documents that have been circulated, they are almost all related to concerns around privacy and more specifically confidentiality... which is not a focus of DNSSEC. DNSSEC is focused on ensuring the *integrity* of the information carried in DNS queries, although when coupled with DANE for TLS certificates it can help with confidentiality, too. The trend seems about 2 orders of magnitude below where we need to be for DNSSEC to be viable in a realistic timescale. Am I misinterpreting the data? No, you're not misinterpreting the data for .COM. Only a very small % of .com domains are signed. The story is better in other TLDs such as .GOV, for instance, where 87% of all domains are DNSSEC-signed ( http://fedv6-deployment.antd.nist.gov/snap-all.html ). Attaining this high level, of course, took a mandate from the US government to all agencies. Over in .NL, there are 1.7 million domains signed representing about 31% of all .NL domains (see right sidebar of https://www.sidn.nl/ ). We are tracking a number of other statistics sites that monitor the DNSSEC status of various TLDs at: http://www.internetsociety.org/deploy360/dnssec/statistics/ You are correct, though, that overall the % of domains signed with DNSSEC is low. If not, then do we have consensus on what is blocking deployment? I don't know that there is a "consensus"... and I could have a long conversation on this topic... but I know from conversations with a good number of people within what I'll call the "DNSSEC community" over the past couple of years that we have the fundamental bootstrapping issue with DNSSEC where we need both more signing of domains and more deployment of DNSSEC-validating DNS resolvers. The challenge has been that people say "why should I bother signing my domain when 'no one' is validating" and on the opposite side ISPs and other network operators say "why should I enable DNSSEC validation in my DNS resolvers where there aren't a lot of domains signed". About 2 years ago a colleague and I wrote a paper for the SATIN conference in the UK and while the situation *has* improved, many of the points are still valid: http://www.internetsociety.org/deploy360/resources/whitepaper-challenges-and-opportunities-in-deploying-dnssec/ The good news is that we've seen some good growth on the validation side, helped largely by Google turning on full DNSSEC validation in their Public DNS servers and Comcast enabling DNSSEC validation in their large network in North America. Additionally, many ISPs in countries such as Sweden, the Netherlands, the Czech Republic and Brazil have turned on DNSSEC validation. Geoff Huston, George Michaelson and the rest of the team at APNIC Labs have done a number of DNSSEC validation measurement projects and presented those at various conferences. At RIPE67 last October, his set of slides ( https://ripe67.ripe.net/presentations/111-2013-10-15-dnssec.pdf ) was showing the May 2013 data where about 8.3% of all queries were being validated. That's certainly a good start... and the validation % is much higher in some countries. We also now have DNSSEC validation easily configurable in most all the major DNS resolvers, including BIND, Unbound and Microsoft Windows Server 2012. It was also recently added to dnsmasq, a DNS server widely used in many smaller environments. So the conditions are now right to get more DNSSEC validation occurring - this was one of the roadblocks for some time. We also have the new getdns API ( http://www.vpnc.org/getdns-api/ ) that provides an easier way for application developers to get to DNS info and to get DNSSEC records. There are still some operational issues to sort out regarding deploying DNSSEC validation that have been documented by Wes Hardaker, Olafur Gudmundsson and Suresh Krishnaswamy in a draft in the DNSOP working group: http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance On the signing side, we know many of the deployment challenges and people are working on them, although many of them are not anything that the IETF can do anything directly about. There are a few standardization issues that are being worked through within the DNSOP working group, such as how a parent zone is alerted when a key changes in a child zone. There's a secure key transfer mechanism working through EPPEXT. As an example of one area outside of the IETF, one challenge historically has been that many registrars have not provided any way to let you add DS or DNSKEY records to your domain info, which would then be passed up to your TLD. That is now changing because ICANN's 2013 Registrar Accreditation Agreement (RAA) requires registrars to support the passing of DNSSEC records - and to sell the newgTLDs, registrars have to sign the 2013 RAA. So we're seeing more registrars offering at least some base level of DNSSEC support. Beyond that, it would certainly be helpful if there were more automation in the overall system to make it easier for people to just enable DNSSEC and have it "just work" - for example, it would be great to see more DNS hosting providers offer DNSSEC-signing. It would also be helpful to have more content distribution networks (CDNs) supporting DNSSEC, as this is a barrier for getting many websites signed. Perhaps a more fundamental factor "blocking" deployment is just that people don't understand the value of DNSSEC and haven't felt the urgent need to deploy it. It's on "their list" of things to implement... but hasn't bubbled up enough in the priorities. Many of us view DANE as a key driver here as it provides a real use case for how DNSSEC can help add a layer of trust to your web security infrastructure. I could go on... and probably what I should do is write an update to that SATIN paper that provides a more current look at the remaining challenges... but hopefully this provides a view into some of the state of deployment. I'm glad to expand on any points or be part of a larger discussion around these issues. I'm employed by the Internet Society on the Deploy360 program where a large part of my work is focused on how we accelerate DNSSEC deployment... so I'm here to help on these points. Regards, Dan P.S. And if anyone is interested in being involved specifically with efforts around advancing DNSSEC deployment (both inside the IETF but more so outside in the larger industry), we have a separate mailing list set up at https://elists.isoc.org/mailman/listinfo/dnssec-coord that is open to anyone to join. -- Dan York Senior Content Strategist, Internet Society [email protected]<mailto:[email protected]> +1-802-735-1624 Jabber: [email protected]<mailto:[email protected]> Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
