yes.

/bill
Neca eos omnes.  Deus suos agnoscet.

On 29April2014Tuesday, at 16:14, Trevor Freeman 
<trev...@exchange.microsoft.com> wrote:

> Are you referring to the assumption in the model that a domain in in control 
> of its DNS keys and where we are dealing with small and medium sized org, 
> that may be a stretch.
> 
> -----Original Message-----
> From: manning bill [mailto:bmann...@isi.edu] 
> Sent: Tuesday, April 29, 2014 4:03 PM
> To: Trevor Freeman
> Cc: Dan York; perpass@ietf.org
> Subject: Re: [perpass] Is DNSDEC a viable technology for perpass?
> 
> 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

Reply via email to