Not going to speak for Dan, but the problems that were identified a decade ago still seem relevant since you bring them back up; e.g. the small/medium sized entity with smaller resource pools to support enhanced crypto capabilities. The answer then (and now) is -outsource-… but this path is fraught with peril if we truly want trusted systems. Or we can just use the Baidu/Tata/Microsoft key escrow facilities…. and we are back to square one!
Solving this problem requires folks to own/manage their personal digital identity. /bill Neca eos omnes. Deus suos agnoscet. On 29April2014Tuesday, at 15:54, Trevor Freeman <trev...@exchange.microsoft.com> wrote: > 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:y...@isoc.org] > Sent: Monday, April 28, 2014 2:47 PM > To: Trevor Freeman > Cc: perpass@ietf.org > Subject: Re: [perpass] Is DNSDEC a viable technology for perpass? > > Trevor, > > On Apr 28, 2014, at 2:38 PM, Trevor Freeman <trev...@exchange.microsoft.com> > 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 > y...@isoc.org +1-802-735-1624 > Jabber: y...@jabber.isoc.org > Skype: danyork http://twitter.com/danyork > > http://www.internetsociety.org/deploy360/ > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass
