On Apr 28, 2014, at 2:38 PM, Trevor Freeman <trevorf@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 m= uch 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&nbs= p;http://tools.ietf.org/html/draft-tschofenig-perpass-surveillance-01<= /a> or other documents that have been circulated, they are almost all related to = concerns around privacy and more specifically confidentiality... which is n= ot a focus of DNSSEC. DNSSEC is focused on ensuring the *integrity* o= f the information carried in DNS queries, although when coupled with DANE for TLS certificates it can help with conf= identiality, too.

The trend seems about 2 orders of magnitu= de below where we need to be for DNSSEC to be viable in a realistic timesca= le.

Am I misinterpreting the data?

No, you're not misinterpreting the data for .COM. Only a very sm= all % of .com domains are signed. The story is better in other TLDs s= uch as .GOV, for instance, where 87% of all domains are DNSSEC-signed (&nbs= p;http://fe= dv6-deployment.antd.nist.gov/snap-all.html ). Attaining this high level, of course, took a mandate from the US gov= ernment to all agencies.

Over in .NL, there are 1.7 million domains signed representing about 3= 1% of all .NL domains (see right sidebar of https://www.sidn.nl/ ). We are tracking a number of o= ther 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 DNS= SEC 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 w= ith a good number of people within what I'll call the "DNSSEC communit= y" 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 challeng= e 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&= quot;. About 2 years ago a colleague and I wrote a paper for the SATI= N conference in the UK and while the situation *has* improved, many of the points are still valid:

http://www.internetso= ciety.org/deploy360/resources/whitepaper-challenges-and-opportunities-in-de= ploying-dnssec/

The good news is that we've seen some good growth on the validation si= de, helped largely by Google turning on full DNSSEC validation in their Pub= lic DNS servers and Comcast enabling DNSSEC validation in their large netwo= rk 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 M= ichaelson and the rest of the team at APNIC Labs have done a number of DNSS= EC 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 certain= ly 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 wa= s one of the roadblocks for some time. We also have the new getdns A= PI ( http://www.vpnc.org/g= etdns-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 deployin= g DNSSEC validation that have been documented by Wes Hardaker, Olafur Gudmu= ndsson and Suresh Krishnaswamy in a draft in the DNSOP working group:

http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-a= voidance

On the signing side, we know many of the deployment challenges and peo= ple are working on them, although many of them are not anything that the IE= TF can do anything directly about. There are a few standardization issues t= hat are being worked through within the DNSOP working group, such as how a parent zone is alerted when a key c= hanges in a child zone. There's a secure key transfer mechanism worki= ng through EPPEXT.

As an example of one area outside of the IETF, one challenge historica= lly 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 regi= strars to support the passing of DNSSEC records - and to sell the newgTLDs,= registrars have to sign the 2013 RAA. So we're seeing more registrar= s offering at least some base level of DNSSEC support.

Beyond that, it would certainly be helpful if there were more automati= on 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 si= gned.

Perhaps a more fundamental factor "blocking" deployment is j= ust that people don't understand the value of DNSSEC and haven't felt the u= rgent 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 infr= astructure.

I could go on... and probably what I should do is write an update to t= hat SATIN paper that provides a more current look at the remaining challeng= es... but hopefully this provides a view into some of the state of deployme= nt. I'm glad to expand on any points or be part of a larger discussion around these issues. I'm em= ployed 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 e= fforts 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= ht= tps://elists.isoc.org/mailman/listinfo/dnssec-coord that is open to anyone to join.

Dan York

Senior Content Strategist, Internet Socie= ty

york@iso= c.org +1-802-735-1624

Jabber: york@jabber.isoc.org

Skype: danyork http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

--_000_D10D2737322D40CC8C8FB368A4A8CD24isocorg_-- From nobody Mon Apr 28 14:50:28 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1329C1A6F0C for ; Mon, 28 Apr 2014 14:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x03Eir1R92Nn for ; Mon, 28 Apr 2014 14:50:21 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id 241131A6FB8 for ; Mon, 28 Apr 2014 14:50:21 -0700 (PDT) Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB244.namprd06.prod.outlook.com (10.242.191.153) with Microsoft SMTP Server (TLS) id 15.0.929.12; Mon, 28 Apr 2014 21:50:18 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.2.49]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.2.49]) with mapi id 15.00.0929.001; Mon, 28 Apr 2014 21:50:18 +0000 From: Dan York To: Trevor Freeman Thread-Topic: [perpass] Is DNSDEC a viable technology for perpass? Thread-Index: Ac9jEJV0t/SMThoOQSO6AKB0jSL/VAADBzsAAAKcUYAAAIpvAAAAopKA Date: Mon, 28 Apr 2014 21:50:17 +0000 Message-ID: References: <4c73ca3fa5c24ace8dce760932e2f791@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <1398715312.17858.535.camel@tochox.rolamasao.org> <68855aa3650248608cac2a6377f7e48e@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <9173e62849894476ab29b6c1e49f268f@DFM-TK5MBX15-05.exchange.corp.microsoft.com> In-Reply-To: <9173e62849894476ab29b6c1e49f268f@DFM-TK5MBX15-05.exchange.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2604:6000:9fc0:53:801e:5527:2cfe:8df6] x-forefront-prvs: 01952C6E96 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(428001)(377454003)(24454002)(199002)(189002)(99286001)(33656001)(99396002)(79102001)(1511001)(83322001)(19580395003)(19580405001)(50986999)(81542001)(101416001)(81342001)(54356999)(76176999)(86362001)(87936001)(82746002)(83716003)(92566001)(2656002)(92726001)(80022001)(15975445006)(31966008)(46102001)(74662001)(74502001)(76482001)(80976001)(15202345003)(20776003)(77982001)(16601075003)(15395725003)(4396001)(36756003)(16236675002)(100906001)(3826001)(3667265003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB244; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:BB82718B.2F104D20.F9E33F54.D440F9C1.201EE; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: isoc.org does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_AFE2DF81A2974B929F2BA9D456F8A49Cisocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/DhkYGj80C4rcQ6BEGYpLRYR316w Cc: =?iso-8859-1?Q?Noel_David_Torres_Ta=F1o?= , "perpass@ietf.org" Subject: Re: [perpass] Is DNSDEC a viable technology for perpass? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 21:50:25 -0000 --_000_AFE2DF81A2974B929F2BA9D456F8A49Cisocorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Trevor, On Apr 28, 2014, at 5:32 PM, Trevor Freeman > wrote: I spoke to soon. While the US government domains is signed, the actual web= site is not in many cases. For example: www.dhs.gov is a cname entry www.dhs.gov.edgekey.net which is unsigned. This is in turn a CNAME to another unsigned domain www.dhs.gov.edgekey.net is a CNAME to e6485= .dscb.akamaiedge.net Yes, support of DNSSEC by content distribution networks (CDNs) remains one = of the stumbling blocks to getting full DNSSEC support out there for web si= tes. Some CDNs *do* support DNSSEC, but not for all customers, and other s= imply don't. We definitely need to see more CDN customers *asking* their C= DN providers for DNSSEC-signing. Dan -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ --_000_AFE2DF81A2974B929F2BA9D456F8A49Cisocorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <3100EE1CB8341E4F9D0F6DD1EF3367D8@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Trevor,

On Apr 28, 2014, at 5:32 PM, Trevor Freeman <trevorf@exchange.microsoft.com>

wrote:

I spoke to soon. While the US gov= ernment domains is signed, the actual web site is not in many cases.<= o:p>

For example:
www.dhs.gov<= /a> is a cname entry www.dhs.gov.edgekey.net = which is unsigned.

This is in turn a CNAME to anothe= r unsigned domain

= www.dhs.gov.edgekey.net is a CNAME to e6485.dscb.akamaiedge.net

Yes, support of DNSSEC by content distribution networks (CDNs) remains= one of the stumbling blocks to getting full DNSSEC support out there for w= eb sites. Some CDNs *do* support DNSSEC, but not for all customers, a= nd other simply don't. We definitely need to see more CDN customers *asking* their CDN providers for DNSSEC-sig= ning.

Dan

Dan York

Senior Content Strategist, Internet Socie= ty

york@iso= c.org +1-802-735-1624

Jabber: york@jabber.isoc.org

Skype: danyork http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

--_000_AFE2DF81A2974B929F2BA9D456F8A49Cisocorg_-- From nobody Mon Apr 28 15:08:21 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA8E1A6FB7 for ; Mon, 28 Apr 2014 15:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMYPqWzg9eW1 for ; Mon, 28 Apr 2014 15:07:42 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 515EB1A7035 for ; Mon, 28 Apr 2014 15:07:39 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id kp14so3038178pab.0 for ; Mon, 28 Apr 2014 15:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=o1a2Kjvv9PaOEpn2jJSkg0LDatOmJoBxRzTeeB/SnMM=; b=jH+fsn15gIxN2Ib9N2R+6vzZmipvl7mPP381SLWGW9Ob8Rw6Nz0YgcnwnR7hPXx0AZ DlmhTmQOO+OMP4LwAvs2OsYp5mAmpGMzhfYIAOwGjOdV0hN3qFM0W8Lr67gg7OO8vI+l F8U/QY4q2mqYAbrsnwZeAPpfkNc886T8Y1D5UtGM1JDI0zujbOlUY7tPV8rtGZdNpVUK JohzoegoEK0M/wk/1vy1otyBa70EdQFPLiUfczSJ2Jgg1Ojj8ARpmwDTjvqPWiONa4bo JWavEYPQpIe+1BX4hZCYOq46wTjWQQJu/cH3T6B28DVOe/pac8EdiKtnQINMKJWPef/k EhJw== X-Received: by 10.66.186.238 with SMTP id fn14mr11345302pac.135.1398722858574; Mon, 28 Apr 2014 15:07:38 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id yv5sm37212744pbb.49.2014.04.28.15.07.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Apr 2014 15:07:37 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_4A867450-40E5-4D50-87AD-2A98F0B78B6D" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Douglas Otis In-Reply-To: <9173e62849894476ab29b6c1e49f268f@DFM-TK5MBX15-05.exchange.corp.microsoft.com> Date: Mon, 28 Apr 2014 15:07:37 -0700 Message-Id: <5E9948EB-9896-4057-B5D4-50343EFEA39F@gmail.com> References: <4c73ca3fa5c24ace8dce760932e2f791@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <1398715312.17858.535.camel@tochox.rolamasao.org> <68855aa3650248608cac2a6377f7e48e@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <9173e62849894476ab29b6c1e49f268f@DFM-TK5MBX15-05.exchange.corp.microsoft.com> To: Trevor Freeman X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/TwEsKeVsCl98jwqUuy_daPBDGX8 Cc: =?iso-8859-1?Q?Noel_David_Torres_Ta=F1o?= , "perpass@ietf.org" Subject: Re: [perpass] Is DNSDEC a viable technology for perpass? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 22:07:50 -0000 --Apple-Mail=_4A867450-40E5-4D50-87AD-2A98F0B78B6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Apr 28, 2014, at 2:32 PM, Trevor Freeman = wrote: > I spoke to soon. While the US government domains is signed, the = actual web site is not in many cases. > For example: > www.dhs.gov is a cname entry www.dhs.gov.edgekey.net which is = unsigned. > This is in turn a CNAME to another unsigned domain > =20 > www.dhs.gov.edgekey.net is a CNAME to e6485.dscb.akamaiedge.net Dear Trevor, Yes, there are many such CNAME wildcards in use. A poor practice from = many perspectives. =20 Comcast has been helpful in vetting DNSSEC use. See = http://dns.comcast.net. = http://tools.ietf.org/html/draft-start-tls-over-dns-00 solves many = deployment and privacy issues. DNSSEC should be considered a much = needed work in progress. Regards, Douglas Otis =20 > From: perpass [mailto:perpass-bounces@ietf.org] On Behalf Of Trevor = Freeman > Sent: Monday, April 28, 2014 2:17 PM > To: Noel David Torres Ta=F1o; perpass@ietf.org > Subject: Re: [perpass] Is DNSDEC a viable technology for perpass? > =20 > Hi Noel, > =20 > If DNNSEC is used in corporations, that may be an interesting data = point but perpass is specify looking at the interne so it does not help = much. > =20 > I understand they could be some benefit to adding some other filter to = the data but the number to try and try to add a better quality metric. = But absent that, the number is what is it. Happy to have the discussion = on how we would consider what to filter on and maybe Verisign could = provide more attributes with the data for use to mine the information. =20= > =20 > I did some ad-hoc research and amongst the prominent internet services = or financial institutions, the seems little evidence of DNSSEC. The = only bright spot seemed to be government web sites, though here the = deployment was still inconsistent in that government agencies have many = web sites not part of the base domain and these were often not signed. > =20 > Trevor > =20 > -----Original Message----- > From: perpass [mailto:perpass-bounces@ietf.org] On Behalf Of Noel = David Torres Ta=F1o > Sent: Monday, April 28, 2014 1:02 PM > To: perpass@ietf.org > Subject: Re: [perpass] Is DNSDEC a viable technology for perpass? > =20 > El lun, 28-04-2014 a las 18:38 +0000, Trevor Freeman escribi=F3: > > We have a range of technologies in the toolkit to address issues > > identified by perpass. > > > >=20 > > > > One of the candidate technologies is DNSSEC. At a technology level = it > > has much to commend it. > > > >=20 > > > > The vast majority of critical TLDs are signed, so another good point > > in its favor. > > > >=20 > > > > However when you look at the next tier down, the statistics point to = a > > problem. > > > >=20 > > > > According to the Verisign labs scoreboard, 340K+ domains in the .com > > namespace are secured by DNSSEC > > > > http://scoreboard.verisignlabs.com/ > > > >=20 > > > > If you express that number as % that is about 0.4% and the growth > > trend is about 0.1% per year > > > > http://scoreboard.verisignlabs.com/percent-trace.png > > > >=20 > > > > The trend seems about 2 orders of magnitude below where we need to = be > > for DNSSEC to be viable in a realistic timescale. > > > >=20 > > > > Am I misinterpreting the data? If not, then do we have consensus on > > what is blocking deployment? > > > >=20 > > > > Trevor > > > >=20 > > > Which are the numbers for .org ? > =20 > This one should have a little percentage of garbage, parked domains, = etc. Moreover, it is kess used by corporations with large IT departments = and more used by small organizations like Libre Software projects. > =20 > And it is very important to trust the software you download. > =20 > Regards > =20 > Noel > er Envite > =20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_4A867450-40E5-4D50-87AD-2A98F0B78B6D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

On Apr 28, 2014, = at 2:32 PM, Trevor Freeman <trevorf@exchange.microsoft.= com> wrote:

I spoke to soon. While the US government domains = is signed, the actual web site is not in many = cases.
For example:
www.dhs.gov is a cname entry www.dhs.gov.edgekey.net which is = unsigned.
This is in turn a CNAME to another unsigned = domain

www.dhs.gov.edgekey.net is a CNAME to e6485.dscb.akamaiedge.net

Dear Trevor,

Yes, = there are many such CNAME wildcards in use. A poor practice from = many perspectives.

Comcast has been = helpful in vetting DNSSEC use. See http://dns.comcast.net. http://too= ls.ietf.org/html/draft-start-tls-over-dns-00 solves many = deployment and privacy issues. DNSSEC should be considered a much = needed work in = progress.

Regards,
Douglas = Otis

From: perpass [mailto:perpass-bounces@ietf.org] On Behalf Of Trevor = Freeman
Sent: Monday, April 28, 2014 2:17 = PM
To: Noel = David Torres Ta=F1o; perpass@ietf.org
Subject: Re: [perpass] Is DNSDEC a = viable technology for perpass?

Hi = Noel,

If DNNSEC is used in corporations, that may be an = interesting data point but perpass is specify looking at the interne so = it does not help much.

I = understand they could be some benefit to adding some other filter to the = data but the number to try and try to add a better quality metric. But = absent that, the number is what is it. Happy to have the discussion on = how we would consider what to filter on and maybe Verisign could provide = more attributes with the data for use to mine the information. =

I did some = ad-hoc research and amongst the prominent internet services or financial = institutions, the seems little evidence of DNSSEC. The only bright = spot seemed to be government web sites, though here the deployment was = still inconsistent in that government agencies have many web sites not = part of the base domain and these were often not = signed.

Trevor

-----Original Message-----
From: perpass [mailto:perpass-bounces@ietf.org] = On Behalf Of Noel David Torres Ta=F1o
Sent: Monday, April 28, 2014 = 1:02 PM
To: perpass@ietf.org
Subject: Re: = [perpass] Is DNSDEC a viable technology for = perpass?

El lun, = 28-04-2014 a las 18:38 +0000, Trevor Freeman = escribi=F3:
> 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.
>
>
>
> The = vast majority of critical TLDs are signed, so another good = point
> in its = favor.
>
>
>
> = However when you look at the next tier down, the statistics point to = a
> = problem.
>
>
>
> = According to the Verisign labs scoreboard, 340K+ domains in the = .com
> namespace are secured by = DNSSEC
>
> http://scoreboard.verisignlabs.com/
>
>
>
> If = you express that number as % that is about 0.4% and the = growth
> trend is about = 0.1% per year
>
> http://scoreboard.verisignlabs.com/percent-trace.png
>
>
>
> 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? If not, then do we have consensus = on
> what is blocking = deployment?
>
>
>
> = Trevor
>
>
>
Which are = the numbers for .org ?

This one = should have a little percentage of garbage, parked domains, etc. = Moreover, it is kess used by corporations with large IT departments and = more used by small organizations like Libre Software = projects.

And it is = very important to trust the software you download.

Regards

Noel
er = Envite

________________________________= _______________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass

= --Apple-Mail=_4A867450-40E5-4D50-87AD-2A98F0B78B6D-- From nobody Mon Apr 28 15:10:32 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE9D1A883A for ; Mon, 28 Apr 2014 15:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89NQly1kdaOI for ; Mon, 28 Apr 2014 15:10:10 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id D7E551A6FCE for ; Mon, 28 Apr 2014 15:10:09 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id b13so958429wgh.4 for ; Mon, 28 Apr 2014 15:10:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JZYo1at+fO5Tk9VIjbMBFLWH84RtGEhKoLG3nZKmbOE=; b=dLrS+4+/vhqdYsOauMeh2lFum+UzX/snTS03V/kP1wv3OnAXIkv9IAKCDwIcg/YsN4 1+290qewzYvHknahoagVxZcVb21MSCLlmyTbySQHhNYASfuzv5ZaYM5SmtDtIN+L3usf vb9/RhH80qzqwB8quLXfP7DcnNyV0E6mOkIdSkVe8SLVHNVRZHb78KAmwdZIW8FZOZ07 x5YGVPtrEEMwczloN4INIddnN5twuH9M0owHSjsP1KwxYmjsKHK6woBx9gUKvYQzBJXM 2o64TMrxFExwcgsxg+6MgDecBODaP1xk6gkA0ZmBSKxI/cYJ/kSb76Wvp59H2MSjGRpn bPZQ== X-Gm-Message-State: ALoCoQkMGHCQ2VKnJVK/4TWRoEP6rJTOlGgp/hdYNxu1zJmcfONlwwNSce9GGsoJ8ODbdpKIDK3H MIME-Version: 1.0 X-Received: by 10.180.105.132 with SMTP id gm4mr17298901wib.39.1398723008535; Mon, 28 Apr 2014 15:10:08 -0700 (PDT) Received: by 10.194.54.162 with HTTP; Mon, 28 Apr 2014 15:10:08 -0700 (PDT) X-Originating-IP: [98.244.98.35] In-Reply-To: <82d65ea8e469437cb74d96afd81be11c@DFM-TK5MBX15-05.exchange.corp.microsoft.com> References: <4c73ca3fa5c24ace8dce760932e2f791@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <82d65ea8e469437cb74d96afd81be11c@DFM-TK5MBX15-05.exchange.corp.microsoft.com> Date: Mon, 28 Apr 2014 18:10:08 -0400 Message-ID: From: Warren Kumari To: Trevor Freeman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/HfK0T4H8cDBbnf3zbf56tIzHKIw Cc: "perpass@ietf.org" Subject: Re: [perpass] Is DNSDEC a viable technology for perpass? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 22:10:21 -0000 On Mon, Apr 28, 2014 at 4:46 PM, Trevor Freeman wrote: > Hi Warren, > > Granted DNNSEC does not by itself provide encryption but that is like say= ing X.509 does not do encryption, all it does is sign keys. Generally ther= e are two ways DNNSEC could be useful. One way, as you point out is to auth= enticate encryption keys. The other way is to detect attempts to subvert DN= S name resolution which may induce me to disclose information to someone. W= e cannot assume all pervasive monitoring is totally passive. OK, fully agree. I just (re)read my email to you and realized I sounded like a jackass -- that was not my intent[0]. W [0]: When I am *intending* to sound like an ass, y'all will know :-P > > Trevor > > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net] > Sent: Monday, April 28, 2014 1:20 PM > To: Trevor Freeman > Cc: perpass@ietf.org > Subject: Re: [perpass] Is DNSDEC a viable technology for perpass? > > On Mon, Apr 28, 2014 at 2:38 PM, Trevor Freeman 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. >> >> > > For which aspects of perpass? DNSSEC provides no encryption, so the fact= that I'm browsing to something on www.nakedfurries.com is visible to all..= . > > Don't get me wrong -- I'm a big DNSSEC (and DANE :-)) proponent, but folk= often seem to miss the fact that DNSSEC doesn't do what the name implies..= . > > W > > > > >> >> The vast majority of critical TLDs are signed, so another good point >> in its favor. >> >> >> >> However when you look at the next tier down, the statistics point to a >> problem. >> >> >> >> According to the Verisign labs scoreboard, 340K+ domains in the .com >> namespace are secured by DNSSEC >> >> http://scoreboard.verisignlabs.com/ >> >> >> >> If you express that number as % that is about 0.4% and the growth >> trend is about 0.1% per year >> >> http://scoreboard.verisignlabs.com/percent-trace.png >> >> >> >> 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? If not, then do we have consensus on >> what is blocking deployment? >> >> >> >> Trevor >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >> From nobody Tue Apr 29 05:39:17 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02111A08BB for ; Tue, 29 Apr 2014 05:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfSkQSoWnNQM for ; Tue, 29 Apr 2014 05:39:11 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id B44291A0756 for ; Tue, 29 Apr 2014 05:39:10 -0700 (PDT) Received: from BN1PR06MB119.namprd06.prod.outlook.com (10.255.204.25) by BN1PR06MB119.namprd06.prod.outlook.com (10.255.204.25) with Microsoft SMTP Server (TLS) id 15.0.929.12; Tue, 29 Apr 2014 12:39:07 +0000 Received: from BN1PR06MB119.namprd06.prod.outlook.com ([169.254.14.239]) by BN1PR06MB119.namprd06.prod.outlook.com ([169.254.14.239]) with mapi id 15.00.0929.001; Tue, 29 Apr 2014 12:39:07 +0000 From: Robin Wilton To: Douglas Otis Thread-Topic: [perpass] Is DNSDEC a viable technology for perpass? Thread-Index: Ac9jEJV0t/SMThoOQSO6AKB0jSL/VAADBzsAAAKcUYAAAIpvAAABPYuAAB5mIQA= Date: Tue, 29 Apr 2014 12:39:06 +0000 Message-ID: References: <4c73ca3fa5c24ace8dce760932e2f791@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <1398715312.17858.535.camel@tochox.rolamasao.org> <68855aa3650248608cac2a6377f7e48e@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <9173e62849894476ab29b6c1e49f268f@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <5E9948EB-9896-4057-B5D4-50343EFEA39F@gmail.com> In-Reply-To: <5E9948EB-9896-4057-B5D4-50343EFEA39F@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [94.174.34.240] x-forefront-prvs: 0196A226D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(428001)(13464003)(51704005)(199002)(189002)(377424004)(377454003)(24454002)(86362001)(16601075003)(99396002)(83322001)(19580395003)(19580405001)(80976001)(99936001)(50986999)(15975445006)(82746002)(76176999)(2656002)(54356999)(83716003)(87936001)(101416001)(92726001)(99286001)(92566001)(83072002)(85852003)(36756003)(81542001)(81342001)(46102001)(4396001)(77982001)(76482001)(33656001)(15202345003)(20776003)(31966008)(74662001)(74502001)(16236675002)(66066001)(80022001)(79102001)(100906001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR06MB119; H:BN1PR06MB119.namprd06.prod.outlook.com; FPR:ECBCF1C5.A2F68D20.B2F77FBF.4EE8F341.205E1; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: isoc.org does not designate permitted sender hosts) Content-Type: multipart/signed; boundary="Apple-Mail=_A93B7821-FF88-48E4-BD9D-51A26A57B134"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/pif_kkO4Fd8vVxzkYhgorCVwQks Cc: =?iso-8859-1?Q?Noel_David_Torres_Ta=F1o?= , Trevor Freeman , "perpass@ietf.org" Subject: Re: [perpass] Is DNSDEC a viable technology for perpass? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 12:39:15 -0000 --Apple-Mail=_A93B7821-FF88-48E4-BD9D-51A26A57B134 Content-Type: multipart/alternative; boundary="Apple-Mail=_BDEAF99A-44D8-435A-A186-66DA2A3401AF" --Apple-Mail=_BDEAF99A-44D8-435A-A186-66DA2A3401AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 28 Apr 2014, at 23:07, Douglas Otis wrote: >=20 >=20 > On Apr 28, 2014, at 2:32 PM, Trevor Freeman = wrote: >=20 >> I spoke to soon. While the US government domains is signed, the = actual web site is not in many cases. >> For example: >> www.dhs.gov is a cname entry www.dhs.gov.edgekey.net which is = unsigned. >> This is in turn a CNAME to another unsigned domain >> =20 >> www.dhs.gov.edgekey.net is a CNAME to e6485.dscb.akamaiedge.net >=20 > Dear Trevor, >=20 > Yes, there are many such CNAME wildcards in use. A poor practice from = many perspectives. =20 >=20 > Comcast has been helpful in vetting DNSSEC use. See = http://dns.comcast.net. = http://tools.ietf.org/html/draft-start-tls-over-dns-00 solves many = deployment and privacy issues. DNSSEC should be considered a much = needed work in progress. >=20 > Regards, > Douglas Otis PKI already suffers from the fact that its trust anchors do not align = well (or, usually, at all) with the trust factors that underpin = applications/services. Cloud architectures seem to me to exacerbate that = state of affairs, because they often introduce a further level of = abstraction in the certificate structure. I've seen this in two forms, = each of which bears similarities to the akamai example Trevor cited = above: 1 - you visit "nakedfurries.com" (sorry, Warren ;^) ) but because their = website is hosted, you see certificates for "cloudstorm.net" instead or = as well, which doesn't contribute anything meaningful to the user's = assessment of trust; 2 - the cloud service provider adds seemingly random qualifiers to the = certificate label ( e.g. fjdo7pspddlfhe544gr6g.servicename.com). Again, = this doesn't add to the user's trust assessment, and can look = suspiciously as though the cert label is being used as the vehicle for a = unique tracking ID. Yrs., Robin >=20 > =20 >> From: perpass [mailto:perpass-bounces@ietf.org] On Behalf Of Trevor = Freeman >> Sent: Monday, April 28, 2014 2:17 PM >> To: Noel David Torres Ta=F1o; perpass@ietf.org >> Subject: Re: [perpass] Is DNSDEC a viable technology for perpass? >> =20 >> Hi Noel, >> =20 >> If DNNSEC is used in corporations, that may be an interesting data = point but perpass is specify looking at the interne so it does not help = much. >> =20 >> I understand they could be some benefit to adding some other filter = to the data but the number to try and try to add a better quality = metric. But absent that, the number is what is it. Happy to have the = discussion on how we would consider what to filter on and maybe Verisign = could provide more attributes with the data for use to mine the = information. =20 >> =20 >> I did some ad-hoc research and amongst the prominent internet = services or financial institutions, the seems little evidence of DNSSEC. = The only bright spot seemed to be government web sites, though here the = deployment was still inconsistent in that government agencies have many = web sites not part of the base domain and these were often not signed. >> =20 >> Trevor >> =20 >> -----Original Message----- >> From: perpass [mailto:perpass-bounces@ietf.org] On Behalf Of Noel = David Torres Ta=F1o >> Sent: Monday, April 28, 2014 1:02 PM >> To: perpass@ietf.org >> Subject: Re: [perpass] Is DNSDEC a viable technology for perpass? >> =20 >> El lun, 28-04-2014 a las 18:38 +0000, Trevor Freeman escribi=F3: >> > We have a range of technologies in the toolkit to address issues >> > identified by perpass. >> > >> >=20 >> > >> > One of the candidate technologies is DNSSEC. At a technology level = it >> > has much to commend it. >> > >> >=20 >> > >> > The vast majority of critical TLDs are signed, so another good = point >> > in its favor. >> > >> >=20 >> > >> > However when you look at the next tier down, the statistics point = to a >> > problem. >> > >> >=20 >> > >> > According to the Verisign labs scoreboard, 340K+ domains in the = .com >> > namespace are secured by DNSSEC >> > >> > http://scoreboard.verisignlabs.com/ >> > >> >=20 >> > >> > If you express that number as % that is about 0.4% and the growth >> > trend is about 0.1% per year >> > >> > http://scoreboard.verisignlabs.com/percent-trace.png >> > >> >=20 >> > >> > The trend seems about 2 orders of magnitude below where we need to = be >> > for DNSSEC to be viable in a realistic timescale. >> > >> >=20 >> > >> > Am I misinterpreting the data? If not, then do we have consensus on >> > what is blocking deployment? >> > >> >=20 >> > >> > Trevor >> > >> >=20 >> > >> Which are the numbers for .org ? >> =20 >> This one should have a little percentage of garbage, parked domains, = etc. Moreover, it is kess used by corporations with large IT departments = and more used by small organizations like Libre Software projects. >> =20 >> And it is very important to trust the software you download. >> =20 >> Regards >> =20 >> Noel >> er Envite >> =20 >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_BDEAF99A-44D8-435A-A186-66DA2A3401AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

On 28 Apr 2014, at 23:07, Douglas Otis wrote:

On Apr 28, 2014, = at 2:32 PM, Trevor Freeman <trevorf@exchange.microsoft.= com> wrote:

I spoke to soon. While the US government domains = is signed, the actual web site is not in many = cases.
For example:
www.dhs.gov is a cname entry www.dhs.gov.edgekey.net which is = unsigned.
This is in turn a CNAME to another unsigned = domain

www.dhs.gov.edgekey.net is a CNAME to e6485.dscb.akamaiedge.net

Dear Trevor,

Yes, = there are many such CNAME wildcards in use. A poor practice from = many perspectives.

Comcast has been = helpful in vetting DNSSEC use. See http://dns.comcast.net. http://too= ls.ietf.org/html/draft-start-tls-over-dns-00 solves many = deployment and privacy issues. DNSSEC should be considered a much = needed work in = progress.

Regards,
Douglas = Otis

PKI already = suffers from the fact that its trust anchors do not align well (or, = usually, at all) with the trust factors that underpin = applications/services. Cloud architectures seem to me to exacerbate that = state of affairs, because they often introduce a further level of = abstraction in the certificate structure. I've seen this in two forms, = each of which bears similarities to the akamai example Trevor cited = above:

1 - you visit "nakedfurries.com" (sorry, Warren = ;^) ) but because their website is hosted, you see certificates = for "cloudstorm.net" instead or as = well, which doesn't contribute anything meaningful to the user's = assessment of trust;

2 - the cloud service = provider adds seemingly random qualifiers to the certificate label ( = e.g. fjdo7pspddlfhe544gr6= g.servicename.com). Again, this doesn't add to the user's trust = assessment, and can look suspiciously as though the cert label is being = used as the vehicle for a unique tracking = ID.

Yrs.,

Robin

From: perpass [mailto:perpass-bounces@ietf.org] On Behalf Of Trevor = Freeman
Sent: Monday, April 28, 2014 2:17 = PM
To: Noel = David Torres Ta=F1o; perpass@ietf.org
Subject: Re: [perpass] Is DNSDEC a = viable technology for perpass?

Hi = Noel,

If DNNSEC is used in corporations, that may be an = interesting data point but perpass is specify looking at the interne so = it does not help much.

I = understand they could be some benefit to adding some other filter to the = data but the number to try and try to add a better quality metric. But = absent that, the number is what is it. Happy to have the discussion on = how we would consider what to filter on and maybe Verisign could provide = more attributes with the data for use to mine the information. =

I did some = ad-hoc research and amongst the prominent internet services or financial = institutions, the seems little evidence of DNSSEC. The only bright = spot seemed to be government web sites, though here the deployment was = still inconsistent in that government agencies have many web sites not = part of the base domain and these were often not = signed.

Trevor

-----Original Message-----
From: perpass [mailto:perpass-bounces@ietf.org] = On Behalf Of Noel David Torres Ta=F1o
Sent: Monday, April 28, 2014 = 1:02 PM
To: perpass@ietf.org
Subject: Re: = [perpass] Is DNSDEC a viable technology for = perpass?

El lun, = 28-04-2014 a las 18:38 +0000, Trevor Freeman = escribi=F3:
> 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.
>
>
>
> The = vast majority of critical TLDs are signed, so another good = point
> in its = favor.
>
>
>
> = However when you look at the next tier down, the statistics point to = a
> = problem.
>
>
>
> = According to the Verisign labs scoreboard, 340K+ domains in the = .com
> namespace are secured by = DNSSEC
>
> http://scoreboard.verisignlabs.com/
>
>
>
> If = you express that number as % that is about 0.4% and the = growth
> trend is about = 0.1% per year
>
> http://scoreboard.verisignlabs.com/percent-trace.png
>
>
>
> 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? If not, then do we have consensus = on
> what is blocking = deployment?
>
>
>
> = Trevor
>
>
>
Which are = the numbers for .org ?

This one = should have a little percentage of garbage, parked domains, etc. = Moreover, it is kess used by corporations with large IT departments and = more used by small organizations like Libre Software = projects.

And it is = very important to trust the software you download.

Regards

Noel
er = Envite

________________________________= _______________
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

= --Apple-Mail=_BDEAF99A-44D8-435A-A186-66DA2A3401AF-- --Apple-Mail=_A93B7821-FF88-48E4-BD9D-51A26A57B134 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlNfnSoACgkQx1kEWLxmyT0nuQCghrEVEatseLXM3WqpQ0GV9x0N BzsAoLpOTPoA1WYcuoXP5FnCJVWTKSdA =FDes -----END PGP SIGNATURE----- --Apple-Mail=_A93B7821-FF88-48E4-BD9D-51A26A57B134-- From nobody Tue Apr 29 05:59:17 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2051A08DA for ; Tue, 29 Apr 2014 05:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQ0B7dEy52Lo for ; Tue, 29 Apr 2014 05:59:11 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id A87161A075D for ; Tue, 29 Apr 2014 05:59:11 -0700 (PDT) Received: from BN1PR09MB057.namprd09.prod.outlook.com (10.255.201.143) by BN1PR09MB059.namprd09.prod.outlook.com (10.255.201.153) with Microsoft SMTP Server (TLS) id 15.0.929.12; Tue, 29 Apr 2014 12:59:09 +0000 Received: from BN1PR09MB057.namprd09.prod.outlook.com ([169.254.13.20]) by BN1PR09MB057.namprd09.prod.outlook.com ([169.254.13.20]) with mapi id 15.00.0929.001; Tue, 29 Apr 2014 12:59:09 +0000 From: "Rose, Scott" To: Dan York Thread-Topic: [perpass] Is DNSDEC a viable technology for perpass? Thread-Index: Ac9jEJV0t/SMThoOQSO6AKB0jSL/VAADBzsAAAKcUYAAAIpvAAAAopKAAB+954A= Date: Tue, 29 Apr 2014 12:59:08 +0000 Message-ID: <74E729A7-B72B-47D0-B43E-F52E83259B25@nist.gov> References: <4c73ca3fa5c24ace8dce760932e2f791@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <1398715312.17858.535.camel@tochox.rolamasao.org> <68855aa3650248608cac2a6377f7e48e@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <9173e62849894476ab29b6c1e49f268f@DFM-TK5MBX15-05.exchange.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.6] x-forefront-prvs: 0196A226D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(377454003)(51704005)(24454002)(99286001)(99396002)(83322001)(15975445006)(19580395003)(19580405001)(80976001)(87936001)(2656002)(15395725003)(81542001)(81342001)(82746002)(83716003)(76482001)(4396001)(80022001)(66066001)(20776003)(46102001)(36756003)(77982001)(76176999)(92726001)(15202345003)(92566001)(85852003)(101416001)(15974865002)(86362001)(83072002)(74502001)(31966008)(54356999)(74662001)(50986999)(33656001)(79102001)(100906001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR09MB059; H:BN1PR09MB057.namprd09.prod.outlook.com; FPR:B8064187.AF3457E0.F8CB9F74.804029CD.202F0; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: nist.gov does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8E3E403CC8038E48BC8A362B8DB6EB07@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/A-dNMyEyXGTYFyILsC0ONcNRVkM Cc: =?iso-8859-1?Q?Noel_David_Torres_Ta=F1o?= , Trevor Freeman , "perpass@ietf.org" Subject: Re: [perpass] Is DNSDEC a viable technology for perpass? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 12:59:14 -0000 On Apr 28, 2014, at 5:50 PM, Dan York wrote: > Trevor, >=20 > On Apr 28, 2014, at 5:32 PM, Trevor Freeman > wrote: >=20 >> I spoke to soon. While the US government domains is signed, the actual = web site is not in many cases. >> For example: >> www.dhs.gov is a cname entry www.dhs.gov.edgekey.net which is unsigned. >> This is in turn a CNAME to another unsigned domain >> =20 >> www.dhs.gov.edgekey.net is a CNAME to e6485.dscb.akamaiedge.net >=20 > Yes, support of DNSSEC by content distribution networks (CDNs) remains on= e of the stumbling blocks to getting full DNSSEC support out there for web = sites. Some CDNs *do* support DNSSEC, but not for all customers, and other= simply don't. We definitely need to see more CDN customers *asking* their= CDN providers for DNSSEC-signing. >=20 (off topic really) CDN's are the issue here, but another thing seen in DNSSEC deployment in .g= ov is the problem seen in mandated deployments of other tech in .gov (like = IPv6 :). Admins only do the minimum of what will be checked. Then on to t= he next fire. So if the auditors only know your 2nd level domains, some zo= nes skip signing their lower level delegations. Or if it is a CNAME to a n= on-.gov, the target zone isn't signed since it isn't in .gov and won't coun= t against you in the audit.=20 Sadly doing what's best is secondary to doing what the audit covers. =20 Scott > Dan >=20 > -- > Dan York > Senior Content Strategist, Internet Society > york@isoc.org +1-802-735-1624 > Jabber: york@jabber.isoc.org=20 > Skype: danyork http://twitter.com/danyork >=20 > http://www.internetsociety.org/deploy360/=20 >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scott.rose@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Tue Apr 29 15:55:26 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3EF41A09BE for ; Tue, 29 Apr 2014 15:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrQxu2rP44aM for ; Tue, 29 Apr 2014 15:55:11 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2on0653.outbound.o365filtering.com [IPv6:2a01:111:f400:fc04::653]) by ietfa.amsl.com (Postfix) with ESMTP id 2744F1A0740 for ; Tue, 29 Apr 2014 15:55:10 -0700 (PDT) Received: from BL2SR01CA103.namsdf01.sdf.exchangelabs.com (10.255.109.148) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) with Microsoft SMTP Server (TLS) id 15.0.944.2; Tue, 29 Apr 2014 22:54:46 +0000 Received: from BY1FFOFD001.ffo.gbl (2a01:111:f400:7c00::88) by BL2SR01CA103.outlook.office365.com (2a01:111:e400:c01::20) with Microsoft SMTP Server (TLS) id 15.0.944.2 via Frontend Transport; Tue, 29 Apr 2014 22:54:46 +0000 Received: from hybrid.exchange.microsoft.com (131.107.159.99) by BY1FFOFD001.mail.o365filtering.com (10.1.16.83) with Microsoft SMTP Server (TLS) id 15.0.939.3 via Frontend Transport; Tue, 29 Apr 2014 22:54:46 +0000 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com (157.54.109.44) by DFM-TK5EDG15-01.exchange.corp.microsoft.com (157.54.27.96) with Microsoft SMTP Server (TLS) id 15.0.913.17; Tue, 29 Apr 2014 15:54:39 -0700 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com (157.54.109.44) by DFM-TK5MBX15-05.exchange.corp.microsoft.com (157.54.109.44) with Microsoft SMTP Server (TLS) id 15.0.913.17; Tue, 29 Apr 2014 15:54:31 -0700 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com ([157.54.109.44]) by DFM-TK5MBX15-05.exchange.corp.microsoft.com ([169.254.5.13]) with mapi id 15.00.0913.011; Tue, 29 Apr 2014 15:54:31 -0700 From: Trevor Freeman To: Dan York Thread-Topic: [perpass] Is DNSDEC a viable technology for perpass? Thread-Index: Ac9jEJV0t/SMThoOQSO6AKB0jSL/VAAGswyAADBxIWA= Date: Tue, 29 Apr 2014 22:54:31 +0000 Message-ID: <565e30ccbded447185c88246d6468097@DFM-TK5MBX15-05.exchange.corp.microsoft.com> References: <4c73ca3fa5c24ace8dce760932e2f791@DFM-TK5MBX15-05.exchange.corp.microsoft.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.13] Content-Type: multipart/alternative; boundary="_000_565e30ccbded447185c88246d6468097DFMTK5MBX1505exchangeco_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.159.99; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(377454003)(199002)(189002)(24454002)(85306002)(87266001)(93516002)(80022001)(2656002)(87936001)(71186001)(81342001)(66066001)(33646001)(83072002)(85852003)(77982001)(79102001)(90146001)(47976003)(47736002)(69226001)(51856002)(56776002)(63696004)(92566001)(93136001)(20776003)(98676001)(54316003)(54356002)(47446003)(50986002)(94316002)(49866002)(59766002)(65816002)(56816006)(99396002)(53806002)(512954002)(15395725004)(46102001)(74706001)(16236675003)(97186001)(97736001)(97336001)(15202345003)(95666003)(2009001)(74502001)(81542001)(74662001)(76482001)(31966008)(74876001)(15975445006)(74366001)(77096001)(84326002)(84676001)(81816001)(76796001)(76786001)(19300405004)(95416001)(94946001)(4396001)(6806004)(83322001)(44976005)(81686001)(80976001)(19580395003)(19580405001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB605; H:hybrid.exchange.microsoft.com; FPR:; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Exchange-Antispam-Report-Test: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 0196A226D1 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/iWcKqFNS1rG1Cn7GjkH-trb25_8 Cc: "perpass@ietf.org" Subject: Re: [perpass] Is DNSDEC a viable technology for perpass? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 22:55:20 -0000 --_000_565e30ccbded447185c88246d6468097DFMTK5MBX1505exchangeco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dan, Yes I want to consider the DNS authentication of encryption keys as one sce= nario 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 goo= dness. It seems a little disturbing that it took a stick to get some level of DNSS= EC 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 carro= ts to drive dependents. You are correct in that the Dutch government was o= ne of the two governments I could find who's public web site was actually D= NSSEC secured, despite many of the parent domain being signed. The only oth= er was Estonia. As you pointed out, there are a large number of content distribution networ= ks hosting sites on behalf of organizations with signed domains, who have n= ot signed their own domain thereby breaking the chain of trust to the web s= ite 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 mostl= y migrating to cloud services of some form. Aside from inviting speakers, = has the been any research done with organizations on why they are not adopt= ing 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 tim= e 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 i= nternet being DANE protected for example. Trevor From: Dan York [mailto:york@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 > 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 m= uch to commend it. Which of the perpass issues do you see DNSSEC helping with? If I look at h= ttp://tools.ietf.org/html/draft-trammell-perpass-ppa-01 or http://tools.iet= f.org/html/draft-tschofenig-perpass-surveillance-01 or other documents that= have been circulated, they are almost all related to concerns around priva= cy 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 D= NSSEC 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, fo= r instance, where 87% of all domains are DNSSEC-signed ( http://fedv6-deplo= yment.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 trac= king a number of other statistics sites that monitor the DNSSEC status of v= arious TLDs at: http://www.internetsociety.org/deploy360/dnssec/statistics/ You are correct, though, that overall the % of domains signed with DNSSEC i= s 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 convers= ation 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 o= f years that we have the fundamental bootstrapping issue with DNSSEC where = we need both more signing of domains and more deployment of DNSSEC-validati= ng DNS resolvers. The challenge has been that people say "why should I bot= her signing my domain when 'no one' is validating" and on the opposite side= ISPs and other network operators say "why should I enable DNSSEC validatio= n 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 val= id: http://www.internetsociety.org/deploy360/resources/whitepaper-challenges-an= d-opportunities-in-deploying-dnssec/ The good news is that we've seen some good growth on the validation side, h= elped largely by Google turning on full DNSSEC validation in their Public D= NS servers and Comcast enabling DNSSEC validation in their large network in= North America. Additionally, many ISPs in countries such as Sweden, the N= etherlands, the Czech Republic and Brazil have turned on DNSSEC validation.= Geoff Huston, George Michaelson and the rest of the team at APNIC Labs h= ave done a number of DNSSEC validation measurement projects and presented t= hose at various conferences. At RIPE67 last October, his set of slides ( = https://ripe67.ripe.net/presentations/111-2013-10-15-dnssec.pdf ) was showi= ng 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 so= me countries. We also now have DNSSEC validation easily configurable in most all the majo= r DNS resolvers, including BIND, Unbound and Microsoft Windows Server 2012.= It was also recently added to dnsmasq, a DNS server widely used in many s= maller environments. So the conditions are now right to get more DNSSEC va= lidation occurring - this was one of the roadblocks for some time. We als= o 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 DNS= SEC records. There are still some operational issues to sort out regarding deploying DNS= SEC validation that have been documented by Wes Hardaker, Olafur Gudmundsso= n 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 a= re working on them, although many of them are not anything that the IETF ca= n do anything directly about. There are a few standardization issues that a= re being worked through within the DNSOP working group, such as how a paren= t 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 h= as 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 Agr= eement (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 hostin= g providers offer DNSSEC-signing. It would also be helpful to have more co= ntent 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 d= eploy it. It's on "their list" of things to implement... but hasn't bubble= d up enough in the priorities. Many of us view DANE as a key driver here a= s 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 S= ATIN 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 aroun= d these issues. I'm employed by the Internet Society on the Deploy360 prog= ram where a large part of my work is focused on how we accelerate DNSSEC de= ployment... so I'm here to help on these points. Regards, Dan P.S. And if anyone is interested in being involved specifically with effort= s around advancing DNSSEC deployment (both inside the IETF but more so outs= ide in the larger industry), we have a separate mailing list set up at htt= ps://elists.isoc.org/mailman/listinfo/dnssec-coord that is open to anyone = to join. -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ --_000_565e30ccbded447185c88246d6468097DFMTK5MBX1505exchangeco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dan,=

<= /p>

Yes I want to consider th= e DNS authentication of encryption keys as one scenario which has a depende= ncy on DNSSEC so we quickly get full circle.

<= /p>

There have been a number = of people who have offered opinions in this area, and none so far have poin= ted to a technology issue as holding up deployment. Far from it, there seems to be advances in many area. This all seems goodness.=

<= /p>

It seems a little disturb= ing 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 carr= ots 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 wa= s actually DNSSEC secured, despite many of the parent domain being signed. The only other was Estonia.

<= /p>

As you pointed out, there= are a large number of content distribution networks hosting sites on behal= f of organizations with signed domains, who have not signed their own domain thereby breaking the chain of trust to the web site dns r= ecord. We seem to be missing the carrot to get them to sign. What is the va= lue proposition that would convince them to sign their domain?

<= /p>

I note that there is a se= ssion 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 mi= grating to cloud services of some form. Aside from inviting speakers,= has the been any research done with organizations on why they are not adop= ting DNSSEC?

<= /p>

It may also be fruitful t= o think about what are the next set of deployment goals in terms of what sc= enarios 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 work= s. Do we want to look at a percentage of the email sent over the internet b= eing DANE protected for example.

<= /p>

Trevor<= /p>

<= /p>

From: Dan Yo= rk [mailto:york@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 <trevorf@exchange.microsoft.co= m>

wrote:

We have a range of technologies in the = toolkit to address issues identified by perpass.

One of the candidate technologies is DN= SSEC. At a technology level it has much to commend it.

Which of the perpass issues do you see DNSSEC helpin= g with? If I look at http://tools.ietf.org/html/draft-trammell-perpass= -ppa-01 or http://tools.ietf.org/html/draft-tschofenig-p= erpass-surveillance-01 or other documents that have been circulated, they are almost all related to = concerns around privacy and more specifically confidentiality... which is n= ot a focus of DNSSEC. DNSSEC is focused on ensuring the *integrity* o= f the information carried in DNS queries, although when coupled with DANE for TLS certificates it can help with conf= identiality, too.

The trend seems about 2 orders of magni= tude below where we need to be for DNSSEC to be viable in a realistic times= cale.

Am I misinterpreting the data?

No, you're not misinterpreting the data for .COM. &n= bsp;Only a very small % of .com domains are signed. The story is bett= er in other TLDs such as .GOV, for instance, where 87% of all domains are D= NSSEC-signed ( http://fedv6-deployment.antd.nist.gov/snap-all.html ). Attaining this high level, of course, took a mandate from the US gov= ernment to all agencies.

Over in .NL, there are 1.7 million domains signed re= presenting about 31% of all .NL domains (see right sidebar of https://www.sidn.nl/ ). We are tra= cking a number of other statistics sites that monitor the DNSSEC status of various TLDs at:

http://www.internetsociety.org/deploy360/dnssec/statist= ics/

You are correct, though, that overall the % of domai= ns signed with DNSSEC is low.

If not, then do we have consensus on wh= at 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 fr= om conversations with a good number of people within what I'll call the &qu= ot;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 resol= vers. The challenge has been that people say "why should I bothe= r signing my domain when 'no one' is validating" and on the opposite side ISPs and other network operators say "why sh= ould I enable DNSSEC validation in my DNS resolvers where there aren't a lo= t 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:

htt= p://www.internetsociety.org/deploy360/resources/whitepaper-challenges-and-o= pportunities-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 valid= ation 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. Ge= off Huston, George Michaelson and the rest of the team at APNIC Labs have d= one 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/1= 11-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 som= e countries.

We also now have DNSSEC validation easily configurab= le in most all the major DNS resolvers, including BIND, Unbound and Microso= ft 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 occurr= ing - this was one of the roadblocks for some time. We also have the= new getdns API ( http://w= ww.vpnc.org/getdns-api/ ) that provides an easier way for application developers to get to DNS info and to get DNSSEC record= s.

There are still some operational issues to sort out = regarding deploying DNSSEC validation that have been documented by Wes Hard= aker, Olafur Gudmundsson and Suresh Krishnaswamy in a draft in the DNSOP wo= rking 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 an= ything that the IETF can do anything directly about. There are a few standa= rdization issues that are being worked through within the DNSOP working group, such as how a parent zone is alert= ed 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 c= hallenge historically has been that many registrars have not provided any w= ay to let you add DS or DNSKEY records to your domain info, which would the= n be passed up to your TLD. That is now changing because ICANN's 2013 Registrar Accreditation Agreement (RA= A) requires registrars to support the passing of DNSSEC records - and to se= ll the newgTLDs, registrars have to sign the 2013 RAA. So we're seein= g 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 woul= d 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 ge= tting many websites signed.

Perhaps a more fundamental factor "blocking&quo= t; 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&q= uot; 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 p= rovides a real use case for how DNSSEC can help add a layer of trust to you= r web security infrastructure.

I could go on... and probably what I should do is wr= ite 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 iss= ues. I'm employed by the Internet Society on the Deploy360 program wh= ere a large part of my work is focused on how we accelerate DNSSEC deployme= nt... so I'm here to help on these points.

Regards,

Dan

P.S. And if anyone is interested in being involved s= pecifically with efforts around advancing DNSSEC deployment (both inside th= e IETF but more so outside in the larger industry), we have a separate mail= ing list set up at https://elists.isoc.org/mailman/listinfo/dnssec-coord&n= bsp; that is open to anyone to join.

Dan York

Senior Conte= nt Strategist, Internet Society

york@isoc.org +1-802-735-1624

Jabber: york@jabber.isoc.org =

Skype: danyo= rk http://twitter.com/danyork<= /o:p>

<= /o:p>

http://www.internetsociety.org/de= ploy360/

--_000_565e30ccbded447185c88246d6468097DFMTK5MBX1505exchangeco_-- From nobody Tue Apr 29 16:03:20 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C981A0992 for ; Tue, 29 Apr 2014 16:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmXD8VFP_6hH for ; Tue, 29 Apr 2014 16:03:16 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 33B0B1A0948 for ; Tue, 29 Apr 2014 16:03:16 -0700 (PDT) Received: from [192.168.0.13] (cpe-23-241-118-60.socal.res.rr.com [23.241.118.60]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3TN2ooQ006683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 29 Apr 2014 16:02:54 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=windows-1252 From: manning bill In-Reply-To: <565e30ccbded447185c88246d6468097@DFM-TK5MBX15-05.exchange.corp.microsoft.com> Date: Tue, 29 Apr 2014 16:02:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2CA6BA9D-6445-4BC4-9207-BF9098045ADB@isi.edu> References: <4c73ca3fa5c24ace8dce760932e2f791@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <565e30ccbded447185c88246d6468097@DFM-TK5MBX15-05.exchange.corp.microsoft.com> To: Trevor Freeman X-Mailer: Apple Mail (2.1874) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/HkAAClvNdrkg6J0B1lHYsGU8GBA Cc: "perpass@ietf.org" , Dan York Subject: Re: [perpass] Is DNSDEC a viable technology for perpass? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 23:03:18 -0000 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-=85 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=85. = 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 = wrote: > Hi Dan, > =20 > 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. =20 > =20 > 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. > =20 > 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=92t 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=92s = public web site was actually DNSSEC secured, despite many of the parent = domain being signed. The only other was Estonia. > =20 > 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? > =20 > 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? > =20 > 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. > =20 > Trevor > =20 > From: Dan York [mailto:york@isoc.org]=20 > 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? > =20 > Trevor, > =20 > On Apr 28, 2014, at 2:38 PM, Trevor Freeman = > wrote: >=20 >=20 > We have a range of technologies in the toolkit to address issues = identified by perpass. > =20 > One of the candidate technologies is DNSSEC. At a technology level it = has much to commend it. > =20 > 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. > =20 > The trend seems about 2 orders of magnitude below where we need to be = for DNSSEC to be viable in a realistic timescale. > =20 > Am I misinterpreting the data? > =20 > 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. =20 > =20 > 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/ > =20 > You are correct, though, that overall the % of domains signed with = DNSSEC is low.=20 >=20 >=20 > If not, then do we have consensus on what is blocking deployment? > =20 > 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: > =20 > = http://www.internetsociety.org/deploy360/resources/whitepaper-challenges-a= nd-opportunities-in-deploying-dnssec/ > =20 > 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. > =20 > 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. > =20 > 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: > =20 > http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance > =20 > 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.=20 > =20 > 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. > =20 > 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. > =20 > 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. > =20 > 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. > =20 > Regards, > Dan > =20 > 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. > =20 > -- > Dan York > Senior Content Strategist, Internet Society > york@isoc.org +1-802-735-1624 > Jabber: york@jabber.isoc.org=20 > Skype: danyork http://twitter.com/danyork > =20 > http://www.internetsociety.org/deploy360/=20 > =20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From nobody Tue Apr 29 16:15:17 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCC91A09E1 for ; Tue, 29 Apr 2014 16:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRDIHU4I_dsr for ; Tue, 29 Apr 2014 16:15:11 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2on0659.outbound.o365filtering.com [IPv6:2a01:111:f400:fc04::659]) by ietfa.amsl.com (Postfix) with ESMTP id 3100F1A09DF for ; Tue, 29 Apr 2014 16:15:11 -0700 (PDT) Received: from BLUSR01CA102.namsdf01.sdf.exchangelabs.com (10.255.124.147) by BLUSR01MB601.namsdf01.sdf.exchangelabs.com (10.255.124.166) with Microsoft SMTP Server (TLS) id 15.0.944.2; Tue, 29 Apr 2014 23:14:47 +0000 Received: from SN2FFOFD001.ffo.gbl (10.255.124.132) by BLUSR01CA102.outlook.office365.com (10.255.124.147) with Microsoft SMTP Server (TLS) id 15.0.944.2 via Frontend Transport; Tue, 29 Apr 2014 23:14:46 +0000 Received: from hybrid.exchange.microsoft.com (131.107.159.100) by SN2FFOFD001.mail.o365filtering.com (10.111.201.20) with Microsoft SMTP Server (TLS) id 15.0.939.3 via Frontend Transport; Tue, 29 Apr 2014 23:14:46 +0000 Received: from DFM-TK5MBX15-07.exchange.corp.microsoft.com (157.54.109.46) by DFM-TK5EDG15-02.exchange.corp.microsoft.com (157.54.27.97) with Microsoft SMTP Server (TLS) id 15.0.913.17; Tue, 29 Apr 2014 16:14:41 -0700 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com (157.54.109.44) by DFM-TK5MBX15-07.exchange.corp.microsoft.com (157.54.109.46) with Microsoft SMTP Server (TLS) id 15.0.913.17; Tue, 29 Apr 2014 16:14:40 -0700 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com ([157.54.109.44]) by DFM-TK5MBX15-05.exchange.corp.microsoft.com ([169.254.5.13]) with mapi id 15.00.0913.011; Tue, 29 Apr 2014 16:14:39 -0700 From: Trevor Freeman To: manning bill Thread-Topic: [perpass] Is DNSDEC a viable technology for perpass? Thread-Index: Ac9jEJV0t/SMThoOQSO6AKB0jSL/VAAGswyAADBxIWAAEyq4AAAOcXtg Date: Tue, 29 Apr 2014 23:14:39 +0000 Message-ID: <52b4fe7cb17c440e9bd307223b6d857f@DFM-TK5MBX15-05.exchange.corp.microsoft.com> References: <4c73ca3fa5c24ace8dce760932e2f791@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <565e30ccbded447185c88246d6468097@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <2CA6BA9D-6445-4BC4-9207-BF9098045ADB@isi.edu> In-Reply-To: <2CA6BA9D-6445-4BC4-9207-BF9098045ADB@isi.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.159.100; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(13464003)(24454002)(51704005)(377454003)(189002)(199002)(69226001)(76796001)(85306002)(76786001)(23726002)(84676001)(74502001)(31966008)(74662001)(95666003)(81342001)(76482001)(95416001)(2656002)(2171001)(87936001)(81542001)(46102001)(80976001)(44976005)(19580395003)(83322001)(19580405001)(81686001)(81816001)(6806004)(94946001)(15975445006)(47776003)(79102001)(20776003)(77982001)(66066001)(77096001)(15395725004)(46406003)(80022001)(97186001)(98676001)(99396002)(87266001)(97736001)(2009001)(97756001)(97336001)(63696004)(56776002)(47976003)(47736002)(50986002)(59766002)(65816002)(56816006)(51856002)(49866002)(47446003)(54356002)(54316003)(53806002)(15202345003)(4396001)(93886001)(83072002)(93516002)(33646001)(90146001)(74706001)(74876001)(94316002)(74366001)(92566001)(50466002)(93136001)(85852003)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUSR01MB601; H:hybrid.exchange.microsoft.com; FPR:; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Exchange-Antispam-Report-Test: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 0196A226D1 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/aRnkj4ekxhK7QVWHSF7KNYWptqk Cc: "perpass@ietf.org" , Dan York Subject: Re: [perpass] Is DNSDEC a viable technology for perpass? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 23:15:15 -0000 Are you referring to the assumption in the model that a domain in in contro= l 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:bmanning@isi.edu]=20 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 answe= r then (and now) is -outsource-... but this path is fraught with peril if w= e truly want trusted systems. Or we can just use the Baidu/Tata/Microsoft key escrow facilities.... and w= e are back to square one! Solving this problem requires folks to own/manage their personal digital id= entity. /bill Neca eos omnes. Deus suos agnoscet. On 29April2014Tuesday, at 15:54, Trevor Freeman wrote: > Hi Dan, > =20 > Yes I want to consider the DNS authentication of encryption keys as one s= cenario which has a dependency on DNSSEC so we quickly get full circle. =20 > =20 > 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 deployme= nt. Far from it, there seems to be advances in many area. This all seems g= oodness. > =20 > It seems a little disturbing that it took a stick to get some level of DN= SSEC deployment in the .gov domain. That model is hard to replicate elsewhe= re so I don't see it as a general solution to deployment. I much prefer car= rots 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 o= ther was Estonia. > =20 > As you pointed out, there are a large number of content distribution netw= orks 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. Wha= t is the value proposition that would convince them to sign their domain? > =20 > I note that there is a session at the forthcoming ICANN DNSSEC workshop o= n DNSSEC and the enterprise. What about small and mediums sized organizatio= ns who have typical lower security skill and smaller budgets? They are mos= tly migrating to cloud services of some form. Aside from inviting speakers= , has the been any research done with organizations on why they are not ado= pting DNSSEC? > =20 > It may also be fruitful to think about what are the next set of deploymen= t goals in terms of what scenarios do we want to work. I would submit its t= ime to move on from how many of the TLDS are signed onto tangible goals lik= e what works. Do we want to look at a percentage of the email sent over the= internet being DANE protected for example. > =20 > Trevor > =20 > From: Dan York [mailto:york@isoc.org]=20 > 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? > =20 > Trevor, > =20 > On Apr 28, 2014, at 2:38 PM, Trevor Freeman > wrote: >=20 >=20 > We have a range of technologies in the toolkit to address issues identifi= ed by perpass. > =20 > One of the candidate technologies is DNSSEC. At a technology level it has= much to commend it. > =20 > 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.i= etf.org/html/draft-tschofenig-perpass-surveillance-01 or other documents th= at have been circulated, they are almost all related to concerns around pri= vacy and more specifically confidentiality... which is not a focus of DNSSE= C. DNSSEC is focused on ensuring the *integrity* of the information carrie= d in DNS queries, although when coupled with DANE for TLS certificates it c= an help with confidentiality, too. > =20 > The trend seems about 2 orders of magnitude below where we need to be for= DNSSEC to be viable in a realistic timescale. > =20 > Am I misinterpreting the data? > =20 > 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-dep= loyment.antd.nist.gov/snap-all.html ). Attaining this high level, of cours= e, took a mandate from the US government to all agencies. =20 > =20 > 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 tr= acking a number of other statistics sites that monitor the DNSSEC status of= various TLDs at: > http://www.internetsociety.org/deploy360/dnssec/statistics/ > =20 > You are correct, though, that overall the % of domains signed with DNSSEC= is low.=20 >=20 >=20 > If not, then do we have consensus on what is blocking deployment? > =20 > I don't know that there is a "consensus"... and I could have a long conve= rsation 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 wher= e we need both more signing of domains and more deployment of DNSSEC-valida= ting DNS resolvers. The challenge has been that people say "why should I b= other signing my domain when 'no one' is validating" and on the opposite si= de ISPs and other network operators say "why should I enable DNSSEC validat= ion 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 th= e UK and while the situation *has* improved, many of the points are still v= alid: > =20 > http://www.internetsociety.org/deploy360/resources/whitepaper-challenges-= and-opportunities-in-deploying-dnssec/ > =20 > 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 validatio= n. 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 sho= wing 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. > =20 > We also now have DNSSEC validation easily configurable in most all the ma= jor DNS resolvers, including BIND, Unbound and Microsoft Windows Server 201= 2. 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 a= lso have the new getdns API ( http://www.vpnc.org/getdns-api/ ) that provid= es an easier way for application developers to get to DNS info and to get D= NSSEC records. > =20 > There are still some operational issues to sort out regarding deploying D= NSSEC validation that have been documented by Wes Hardaker, Olafur Gudmunds= son and Suresh Krishnaswamy in a draft in the DNSOP working group: > =20 > http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance > =20 > 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 par= ent zone is alerted when a key changes in a child zone. There's a secure k= ey transfer mechanism working through EPPEXT.=20 > =20 > 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 you= r TLD. That is now changing because ICANN's 2013 Registrar Accreditation A= greement (RAA) requires registrars to support the passing of DNSSEC records= - and to sell the newgTLDs, registrars have to sign the 2013 RAA. So we'r= e seeing more registrars offering at least some base level of DNSSEC suppor= t. > =20 > 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 an= d have it "just work" - for example, it would be great to see more DNS host= ing providers offer DNSSEC-signing. It would also be helpful to have more = content distribution networks (CDNs) supporting DNSSEC, as this is a barrie= r for getting many websites signed. > =20 > Perhaps a more fundamental factor "blocking" deployment is just that peop= le 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 bubb= led 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 trus= t to your web security infrastructure. > =20 > 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 aro= und these issues. I'm employed by the Internet Society on the Deploy360 pr= ogram where a large part of my work is focused on how we accelerate DNSSEC = deployment... so I'm here to help on these points. > =20 > Regards, > Dan > =20 > P.S. And if anyone is interested in being involved specifically with effo= rts around advancing DNSSEC deployment (both inside the IETF but more so ou= tside in the larger industry), we have a separate mailing list set up at h= ttps://elists.isoc.org/mailman/listinfo/dnssec-coord that is open to anyon= e to join. > =20 > -- > Dan York > Senior Content Strategist, Internet Society > york@isoc.org +1-802-735-1624 > Jabber: york@jabber.isoc.org=20 > Skype: danyork http://twitter.com/danyork > =20 > http://www.internetsociety.org/deploy360/=20 > =20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From nobody Wed Apr 30 11:27:27 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E141A1A886B for ; Wed, 30 Apr 2014 11:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0IA4xC0Aku9 for ; Wed, 30 Apr 2014 11:27:22 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 22AB91A8878 for ; Wed, 30 Apr 2014 11:27:21 -0700 (PDT) Received: from [128.9.184.144] ([128.9.184.144]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s3UIR6Ku017191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 30 Apr 2014 11:27:07 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=us-ascii From: manning bill In-Reply-To: <52b4fe7cb17c440e9bd307223b6d857f@DFM-TK5MBX15-05.exchange.corp.microsoft.com> Date: Wed, 30 Apr 2014 11:27:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4c73ca3fa5c24ace8dce760932e2f791@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <565e30ccbded447185c88246d6468097@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <2CA6BA9D-6445-4BC4-9207-BF9098045ADB@isi.edu> <52b4fe7cb17c440e9bd307223b6d857f@DFM-TK5MBX15-05.exchange.corp.microsoft.com> To: Trevor Freeman X-Mailer: Apple Mail (2.1874) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/vRgbGXjW6ivR0di3lMOGGnG2TMA Cc: "perpass@ietf.org" , Dan York Subject: Re: [perpass] Is DNSDEC a viable technology for perpass? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 18:27:26 -0000 yes. /bill Neca eos omnes. Deus suos agnoscet. On 29April2014Tuesday, at 16:14, Trevor Freeman = 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. >=20 > -----Original Message----- > From: manning bill [mailto:bmanning@isi.edu]=20 > 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? >=20 > 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! >=20 > Solving this problem requires folks to own/manage their personal = digital identity. >=20 > /bill > Neca eos omnes. Deus suos agnoscet. >=20 > On 29April2014Tuesday, at 15:54, Trevor Freeman = wrote: >=20 >> Hi Dan, >>=20 >> 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. =20 >>=20 >> 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. >>=20 >> 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. >>=20 >> 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? >>=20 >> 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? >>=20 >> 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. >>=20 >> Trevor >>=20 >> From: Dan York [mailto:york@isoc.org]=20 >> 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? >>=20 >> Trevor, >>=20 >> On Apr 28, 2014, at 2:38 PM, Trevor Freeman = >> wrote: >>=20 >>=20 >> We have a range of technologies in the toolkit to address issues = identified by perpass. >>=20 >> One of the candidate technologies is DNSSEC. At a technology level it = has much to commend it. >>=20 >> 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. >>=20 >> The trend seems about 2 orders of magnitude below where we need to be = for DNSSEC to be viable in a realistic timescale. >>=20 >> Am I misinterpreting the data? >>=20 >> 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. =20 >>=20 >> 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/ >>=20 >> You are correct, though, that overall the % of domains signed with = DNSSEC is low.=20 >>=20 >>=20 >> If not, then do we have consensus on what is blocking deployment? >>=20 >> 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: >>=20 >> = http://www.internetsociety.org/deploy360/resources/whitepaper-challenges-a= nd-opportunities-in-deploying-dnssec/ >>=20 >> 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. >>=20 >> 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. >>=20 >> 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: >>=20 >> = http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance >>=20 >> 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.=20 >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> Regards, >> Dan >>=20 >> 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. >>=20 >> -- >> Dan York >> Senior Content Strategist, Internet Society >> york@isoc.org +1-802-735-1624 >> Jabber: york@jabber.isoc.org=20 >> Skype: danyork http://twitter.com/danyork >>=20 >> http://www.internetsociety.org/deploy360/=20 >>=20 >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >=20 From nobody Wed Apr 30 12:08:49 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687361A8897 for ; Wed, 30 Apr 2014 12:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGap8LrIE3PX for ; Wed, 30 Apr 2014 12:08:45 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) by ietfa.amsl.com (Postfix) with ESMTP id 444D41A8891 for ; Wed, 30 Apr 2014 12:08:45 -0700 (PDT) Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB242.namprd06.prod.outlook.com (10.242.191.142) with Microsoft SMTP Server (TLS) id 15.0.929.12; Wed, 30 Apr 2014 19:08:42 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.2.21]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.2.21]) with mapi id 15.00.0929.001; Wed, 30 Apr 2014 19:08:41 +0000 From: Dan York To: Trevor Freeman Thread-Topic: [perpass] Is DNSDEC a viable technology for perpass? Thread-Index: Ac9jEJV0t/SMThoOQSO6AKB0jSL/VAAGswyAADBxIWAALpyeAA== Date: Wed, 30 Apr 2014 19:08:40 +0000 Message-ID: <339296B6-3650-4EC6-A703-3DDD0F2522D8@isoc.org> References: <4c73ca3fa5c24ace8dce760932e2f791@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <565e30ccbded447185c88246d6468097@DFM-TK5MBX15-05.exchange.corp.microsoft.com> In-Reply-To: <565e30ccbded447185c88246d6468097@DFM-TK5MBX15-05.exchange.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2604:6000:9fc0:53:801e:5527:2cfe:8df6] x-forefront-prvs: 0197AFBD92 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(428001)(52604005)(377454003)(24454002)(189002)(199002)(36756003)(16236675002)(77982001)(15395725003)(15975445006)(83322001)(2656002)(19580405001)(19580395003)(1511001)(74502001)(31966008)(79102001)(74662001)(92566001)(20776003)(83072002)(83716003)(46102001)(76482001)(85852003)(4396001)(80022001)(86362001)(33656001)(15202345003)(87936001)(81342001)(54356999)(76176999)(81542001)(50986999)(80976001)(101416001)(92726001)(99286001)(99396002)(82746002)(100906001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB242; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:6E40F145.A6329381.B9DF717B.8E68F961.20607; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: isoc.org does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_339296B636504EC6A7033DDD0F2522D8isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/vbpR74zBhEYIMPpVzT8vizeUedM Cc: "perpass@ietf.org" Subject: Re: [perpass] Is DNSDEC a viable technology for perpass? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 19:08:48 -0000 --_000_339296B636504EC6A7033DDD0F2522D8isocorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Trevor, Comments inline... On Apr 29, 2014, at 6:54 PM, Trevor Freeman > wrote: Yes I want to consider the DNS authentication of encryption keys as one sce= nario which has a dependency on DNSSEC so we quickly get full circle. Thanks for explaining where your focus is. 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 goo= dness. Yes, for the most part the issues holding up DNSSEC deployment are NOT tech= nology-related. That said, there *are* some remaining technology issues t= hat do cause problems, most notably the key rollover issue being discussed = in multiple drafts within DNSOP right now. Additionally, while we have com= e far in automation, there are still ways we could make the DNSSEC signing = process even easier for smaller and less tech-savvy users. But overall the technology behind DNSSEC is very solid and is not the deplo= yment challenge. It seems a little disturbing that it took a stick to get some level of DNS= SEC deployment in the .gov domain. That model is hard to replicate elsewher= e so I don=92t see it as a general solution to deployment. Neither do I. And, as Scott Rose so rightly pointed out in a message earli= er in this thread, a mandate often means that people will do exactly the ba= re minimum necessary to comply with the mandate... and nothing more. As a = result we wind up with implementations that do not, in fact, deliver the fu= ll level of security and are not "complete" in the way that we would think = want them to be. As you pointed out, there are a large number of content distribution networ= ks hosting sites on behalf of organizations with signed domains, who have n= ot signed their own domain thereby breaking the chain of trust to the web s= ite 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? Customers asking them for it! That is the big missing piece that people at= multiple CDN providers have said to either me or others I know. There *is= * a certain level of complexity in what they do as a CDN that makes signing= it all non-trivial. However, some CDNs *are* offering DNSSEC-signing to c= ertain customers.... and if more customers were asking for it, I'm sure mor= e CDNs would offer it. So we go back to needing to get the end customer aw= are of the value of DNSSEC - and then requesting it from their vendors. 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 mostl= y migrating to cloud services of some form. Speaking as one of the members of the program committee for that upcoming I= CANN DNSSEC Workshop in London, we'd love to have someone offer to speak on= that topic. The call for participation can be found on multiple mailing l= ists or here: http://www.internetsociety.org/deploy360/blog/2014/04/call-for-participatio= n-icann-50-dnssec-workshop-on-25-june-in-london/ Aside from inviting speakers, has the been any research done with organizat= ions on why they are not adopting DNSSEC? Yes, a number of us have spoken with a good number of organizations about w= hy. In most cases for the folks I've spoken with it comes down to a lack o= f understanding of what DNSSEC can do... and even when they do understand, = the reality that they have 37 other higher IT priorities that they need to = get implemented right now because they are very often operating in perpetua= l crisis mode and whatever has the highest priority gets implemented. Many= people are finally getting around to IPv6 implementations because we are, = in fact, finally running out of IPv4 addresses. There isn't the same urgen= cy *yet* for DNSSEC for many people. This is why I and others have been t= alking up the value offered by DANE. 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 tim= e 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 i= nternet being DANE protected for example. Yes... and we are definitely working on those deployment goals. But this i= s where I think we really get out of the IETF territory of standards and ge= t more into the operational side of things. Rather than discuss this here = on the perpass list, I'd encourage you to join the https://elists.isoc.org/= mailman/listinfo/dnssec-coord list and engage in this discussion there. = (Unless others feel it should stay on this list... where I'm happy to discu= ss this, obviously... but I feel like we're going outside of areas that are= in scope for the IETF.) My 2 cents, Dan -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ --_000_339296B636504EC6A7033DDD0F2522D8isocorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7167832D4F56E6469FB00114DB2A4ACF@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Trevor,

Comments inline...

On Apr 29, 2014, at 6:54 PM, Trevor Freeman <trevorf@exchange.microsoft.com>

wrote:

Yes I want to consider the DNS authentication of encrypti= on keys as one scenario which has a dependency on DNSSEC so we quickly get = full circle.

Thanks for explaining where your focus is.

There have been a number of people who have offered opini= ons in this area, and none so far have pointed to a technology issue as hol= ding up deployment. Far from it, there seems to be advances in many area. This all seems goodness.

Yes, for the most part the issues holding up DNSSEC deployment are NOT tech= nology-related. That said, there *are* some remaining technology iss= ues that do cause problems, most notably the key rollover issue being discu= ssed in multiple drafts within DNSOP right now. Additionally, while we have come far in automation, there= are still ways we could make the DNSSEC signing process even easier for sm= aller and less tech-savvy users.

But overall the technology behind DNSSEC is very solid and is not the = deployment challenge.

It seems a little disturbi= ng that it took a stick to get some level of DNSSEC deployment in the .gov domain. That model is hard to replicate e= lsewhere so I don=92t see it as a general solution to deployment.

Neither do I. And, as Scott Rose so rightly pointed out in a message = earlier in this thread, a mandate often means that people will do exactly t= he bare minimum necessary to comply with the mandate... and nothing more. &= nbsp;As a result we wind up with implementations that do not, in fact, deliver the full level of security and are not "= ;complete" in the way that we would think want them to be.

As you pointed out, there are a large number of content d= istribution networks hosting sites on behalf of organizations with signed d= omains, 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 pr= oposition that would convince them to sign their domain?

Customers asking them for it! That is the big missing piece that peop= le at multiple CDN providers have said to either me or others I know. = ;There *is* a certain level of complexity in what they do as a CDN that mak= es signing it all non-trivial. However, some CDNs *are* offering DNSSEC-signing to certain customers.... and if more cu= stomers were asking for it, I'm sure more CDNs would offer it. So we = go back to needing to get the end customer aware of the value of DNSSEC - a= nd then requesting it from their vendors.

I note that there is a session at the forthcoming ICANN D= NSSEC workshop on DNSSEC and the enterprise. What about small and mediums s= ized organizations who have typical lower security skill and smaller budgets? They are mostly migrating = to cloud services of some form.

Speaking as one of the members of the program committee for that upcom= ing ICANN DNSSEC Workshop in London, we'd love to have someone offer to spe= ak on that topic. The call for participation can be found on multiple= mailing lists or here:

http://ww= w.internetsociety.org/deploy360/blog/2014/04/call-for-participation-icann-5= 0-dnssec-workshop-on-25-june-in-london/

Aside from inviting speakers, has the been any research d= one with organizations on why they are not adopting DNSSEC?

Yes, a number of us have spoken with a good number of organizations about w= hy. In most cases for the folks I've spoken with it comes down to a l= ack of understanding of what DNSSEC can do... and even when they do underst= and, the reality that they have 37 other higher IT priorities that they need to get implemented right now because t= hey are very often operating in perpetual crisis mode and whatever has the = highest priority gets implemented. Many people are finally getting ar= ound to IPv6 implementations because we are, in fact, finally running out of IPv4 addresses. There isn't = the same urgency *yet* for DNSSEC for many people. This is why I and= others have been talking up the value offered by DANE.

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 wo= uld 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 DAN= E protected for example.

Yes... and we are definitely working on those deployment goals. = But this is where I think we really get out of the IETF territory of standa= rds and get more into the operational side of things. Rather than dis= cuss this here on the perpass list, I'd encourage you to join the https://elists.isoc.org/mailman/listinfo/dnssec-coord = ;list and engage in this discussion there. (Unless others feel= it should stay on this list... where I'm happy to discuss this, obviously... but I feel like we're going outside of areas that are i= n scope for the IETF.)

My 2 cents,

Dan

Dan York

Senior Content Strategist, Internet Socie= ty

york@iso= c.org +1-802-735-1624

Jabber: york@jabber.isoc.org

Skype: danyork http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

--_000_339296B636504EC6A7033DDD0F2522D8isocorg_-- From nobody Wed Apr 30 12:12:55 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B311A889A for ; Wed, 30 Apr 2014 12:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfYR6eSCMUzu for ; Wed, 30 Apr 2014 12:12:46 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 205EF1A8839 for ; Wed, 30 Apr 2014 12:12:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 7D9B02C403B; Wed, 30 Apr 2014 12:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AhP7OARbb1zq; Wed, 30 Apr 2014 12:12:40 -0700 (PDT) Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 8D9C22C400C; Wed, 30 Apr 2014 12:12:40 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8EC6087E-F072-4D6F-B345-FAD32F426ACE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Nicholas Weaver In-Reply-To: <339296B6-3650-4EC6-A703-3DDD0F2522D8@isoc.org> Date: Wed, 30 Apr 2014 12:12:39 -0700 Message-Id: References: <4c73ca3fa5c24ace8dce760932e2f791@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <565e30ccbded447185c88246d6468097@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <339296B6-3650-4EC6-A703-3DDD0F2522D8@isoc.org> To: Dan York X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/oCLZs8gTxHm4PpXL8Og7I-c7uJA Cc: Trevor Freeman , "perpass@ietf.org" , Nicholas Weaver Subject: Re: [perpass] Is DNSDEC a viable technology for perpass? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 19:12:48 -0000 --Apple-Mail=_8EC6087E-F072-4D6F-B345-FAD32F426ACE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 30, 2014, at 12:08 PM, Dan York wrote: >> 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. >=20 > Yes, for the most part the issues holding up DNSSEC deployment are NOT = technology-related. That said, there *are* some remaining technology = issues that do cause problems, most notably the key rollover issue being = discussed in multiple drafts within DNSOP right now. Additionally, = while we have come far in automation, there are still ways we could make = the DNSSEC signing process even easier for smaller and less tech-savvy = users. >=20 > But overall the technology behind DNSSEC is very solid and is not the = deployment challenge. There is one key problem with DNSSEC to the user's system: 1%+ of the = network rejects it, because the user is behind a device which blocks = 3rd-party DNS requests and forces all requests through a = non-DNSSEC-supporting recursive resolver. =20 This means that any protocol which uses DNSSEC to distribute key = material needs an alternate mechanism to transmit the DNSSEC information = to the client. -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_8EC6087E-F072-4D6F-B345-FAD32F426ACE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJTYUsnAAoJEG2B1w+SDi/u5BsQALrIZKboqjpIJx6cPoy+pJAb QWGrM40lPpcdIOWHejaN+tq8/kcHHMRLZ3aWkKEPSBpNcicTcwO0brcqBG6RFYUI hf3S1GYp+5wFCLDwghwzpqQ2U8EHYXhAJ0KMbOozIX+bpmlkDygrvgFw/MIfQtVr 0fE58gbyZAbWrbTWaHGtoKlqQLDdQ1u/xxSIckzN4dPnpPxdi6sL/qINA3IDO8Vg wHbK8cah9+lVICy1Id8eMNfPvzIkXd2p6paNydE8yzSuvm4m28LhMNkKu5m0TgZW VjGWu99pcV5XJL+JoMtgcufTaEzh658hdlWcK9ZYBBjs4nfrMx2sE/pQzgWew55Q oFFrbgzlqYCn1jqpGTKPaJFY/3xU4KPwg2ioHXDMq5MsCqzVGztptvJCS4MpXkK9 n3qa1ZaMezT7NUDgiN+Hx+sgB045udBvqwNJVdICM7WwBM8AMb96XCi7abLRb8l7 8MzUw9c9kbH/y8Uozt7n+JdCrV+ko5AXKnjg+BpuujI11/t3s1SNKseQxkGPrHAk XAyOugWXb/vKBuWG38CaD+2oURUlXReksBhiw6vQRhC8sB3H6ioaRNlz6o7gY4nh U0Dr9xfaXJ9dv+5audJGBXf9fHWVOI/laGXwQ66fD3qWrNFIfRHIxGfI58c0WmLN QqXd50ZkxfOhAJSYk+4x =WHSV -----END PGP SIGNATURE----- --Apple-Mail=_8EC6087E-F072-4D6F-B345-FAD32F426ACE-- From nobody Wed Apr 30 13:01:57 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCB71A8893 for ; Wed, 30 Apr 2014 13:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQqbvz1x2fsL for ; Wed, 30 Apr 2014 13:01:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) by ietfa.amsl.com (Postfix) with ESMTP id A22E71A8895 for ; Wed, 30 Apr 2014 13:01:51 -0700 (PDT) Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB244.namprd06.prod.outlook.com (10.242.191.153) with Microsoft SMTP Server (TLS) id 15.0.929.12; Wed, 30 Apr 2014 20:01:48 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.2.21]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.2.21]) with mapi id 15.00.0929.001; Wed, 30 Apr 2014 20:01:48 +0000 From: Dan York To: Nicholas Weaver Thread-Topic: [perpass] Is DNSDEC a viable technology for perpass? Thread-Index: Ac9jEJV0t/SMThoOQSO6AKB0jSL/VAAGswyAADBxIWAALpyeAAAAI52AAAG21wA= Date: Wed, 30 Apr 2014 20:01:46 +0000 Message-ID: <0D5CA243-DBE9-4122-8844-05DF4944409A@isoc.org> References: <4c73ca3fa5c24ace8dce760932e2f791@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <565e30ccbded447185c88246d6468097@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <339296B6-3650-4EC6-A703-3DDD0F2522D8@isoc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2604:6000:9fc0:53:801e:5527:2cfe:8df6] x-forefront-prvs: 0197AFBD92 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(428001)(24454002)(189002)(199002)(377454003)(76482001)(74502001)(74662001)(31966008)(46102001)(77982001)(81542001)(81342001)(83716003)(87936001)(20776003)(86362001)(2656002)(2171001)(92726001)(99286001)(80022001)(82746002)(50986999)(36756003)(16236675002)(92566001)(99396002)(15202345003)(15975445006)(83072002)(85852003)(33656001)(79102001)(80976001)(83322001)(4396001)(15395725003)(101416001)(76176999)(54356999)(19580405001)(19580395003)(100906001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB244; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:BFC8553F.2FFCA7E3.B9D333C8.A4149B8.20202; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: isoc.org does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_0D5CA243DBE94122884405DF4944409Aisocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/b1Ua7-DZO8Apv-MhZ3XzccnExLA Cc: "perpass@ietf.org" , Trevor Freeman Subject: Re: [perpass] Is DNSDEC a viable technology for perpass? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 20:01:56 -0000 --_000_0D5CA243DBE94122884405DF4944409Aisocorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Apr 30, 2014, at 3:12 PM, Nicholas Weaver > wrote: On Apr 30, 2014, at 12:08 PM, Dan York = > wrote: But overall the technology behind DNSSEC is very solid and is not the deplo= yment challenge. There is one key problem with DNSSEC to the user's system: 1%+ of the netwo= rk rejects it, because the user is behind a device which blocks 3rd-party D= NS requests and forces all requests through a non-DNSSEC-supporting recursi= ve resolver. Yes, this is an issue. Wes Hardaker, Olafur Gudmundsson and Suresh Krishna= swamy have done a good job of documenting this and other related issues in = this I-D: http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance (And they are certainly open to comments and feedback on the draft.) Dan -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ --_000_0D5CA243DBE94122884405DF4944409Aisocorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9DE3B58EC599B14388633759F1C81C28@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

On Apr 30, 2014, at 3:12 PM, Nicholas Weaver <nweaver@icsi.berkeley.edu> wrote:

On Apr 30, 2014, at 12:08 PM, Dan York <york@isoc.org> wrote:

But overall the technology behind DNSSEC is very solid and is not the deplo= yment challenge.

There is one key problem with DNSSEC to the user's system: 1%+ of the n= etwork rejects it, because the user is behind a device which blocks 3rd-par= ty DNS requests and forces all requests through a non-DNSSEC-supporting rec= ursive resolver.

Yes, this is an issue. Wes Hardaker, Olafur Gudmundsson and Sure= sh Krishnaswamy have done a good job of documenting this and other related = issues in this I-D:

http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoida= nce

(And they are certainly open to comments and feedback on the draft.)

Dan

Dan York

Senior Content Strategist, Internet Socie= ty

york@iso= c.org +1-802-735-1624

Jabber: york@jabber.isoc.org

Skype: danyork http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

--_000_0D5CA243DBE94122884405DF4944409Aisocorg_--