From york at isoc.org Thu Sep 6 09:25:25 2012 From: york at isoc.org (Dan York) Date: Thu, 6 Sep 2012 09:25:25 -0400 Subject: [Dnssec-deployment] Al-Jazeera website hit by DNS poisoning Message-ID: <210B71AF-7391-45F5-A495-D8909D14FF73@isoc.org> I'm seeing a good number of reports out about at least one of Al-Jazeera's website being hit by DNS poisoning. One example: http://www.securityweek.com/al-jazeera-website-hack-caused-dns-poisoning I've also seen a number of tweets from various people pointing out that DNSSEC could have prevented this. And yes, if the Al-Jazeera zones were signed and if people browsing were using DNSSEC-validating DNS resolvers, they might have at least been prevented from seeing the spoofed site. (They also would have been prevented from seeing the real site.) Anyway, for those of us promoting DNSSEC deployment, here's a very current and very real example of DNS poisoning. Regards, Dan -- Dan York Senior Content Strategist, Internet Society york at isoc.org +1-802-735-1624 Jabber: york at jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20120906/c0b4e13a/attachment.html From bortzmeyer at nic.fr Thu Sep 6 09:34:14 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 6 Sep 2012 15:34:14 +0200 Subject: [Dnssec-deployment] Al-Jazeera website hit by DNS poisoning In-Reply-To: <210B71AF-7391-45F5-A495-D8909D14FF73@isoc.org> References: <210B71AF-7391-45F5-A495-D8909D14FF73@isoc.org> Message-ID: <20120906133414.GA10307@nic.fr> On Thu, Sep 06, 2012 at 09:25:25AM -0400, Dan York wrote a message of 80 lines which said: > I'm seeing a good number of reports out about at least one of > Al-Jazeera's website being hit by DNS poisoning. Unfortunately, none of these reports produce any evidence (not even a dig output). The screenshot in the article could have been made by a classical Web attack as well. Since the press and the PHBs say "DNS poisoning" at every possible opportunity, I would say we have no real information about the technique used by the attacker. > I've also seen a number of tweets from various people pointing out > that DNSSEC could have prevented this. The mentioned article says "Disruption to Al Jazeera sites was caused by poisoning of DNS servers owned and run by an external company". If this is true, it means the DNS hoster was simply cracked. In this case, DNSSEC would *not* have prevented anything. So, if you are patient enough to reply to the reporters, the message is: next time, use dig and send the complete output to an expert (or ask her to run dig). From warren at kumari.net Thu Sep 6 09:42:25 2012 From: warren at kumari.net (Warren Kumari) Date: Thu, 6 Sep 2012 09:42:25 -0400 Subject: [Dnssec-deployment] Al-Jazeera website hit by DNS poisoning In-Reply-To: <210B71AF-7391-45F5-A495-D8909D14FF73@isoc.org> References: <210B71AF-7391-45F5-A495-D8909D14FF73@isoc.org> Message-ID: <7DB8B0FE-B6C2-4474-BC53-AE973A99F26B@kumari.net> On Sep 6, 2012, at 9:25 AM, Dan York wrote: > I'm seeing a good number of reports out about at least one of Al-Jazeera's website being hit by DNS poisoning. One example: > > http://www.securityweek.com/al-jazeera-website-hack-caused-dns-poisoning > > I've also seen a number of tweets from various people pointing out that DNSSEC could have prevented this. And yes, if the Al-Jazeera zones were signed and if people browsing were using DNSSEC-validating DNS resolvers, they might have at least been prevented from seeing the spoofed site. (They also would have been prevented from seeing the real site.) I suspect (although I have no proof yet) this this was not a DNS *cache* poisoning attack, but rather a failure of security in the registrar / auth servers. This suspicion is due to a number of run-ins with the Syrian Electronic Army and their modus operandi. The fact that this affected everyone access in the site (and not just the folk using a subset of resolvers) lends weight to this suspicion (as does the fact that it wasn't registered through a brand protection agency (e.g: MM / CSC / DTNT) Once you lose access at the registrar, or control of your auth servers[0], you have lost, regardless of DNSSEC? W [0]: Yes, may not, if you have off-line signing and / or hidden masters that serve the signed zone to your actual auth servers, but in the most widely deployed case, signing happens by BIND, on the auth servers :-P > > Anyway, for those of us promoting DNSSEC deployment, here's a very current and very real example of DNS poisoning. > > Regards, > Dan > > -- > Dan York > Senior Content Strategist, Internet Society > york at isoc.org +1-802-735-1624 > Jabber: york at jabber.isoc.org > Skype: danyork http://twitter.com/danyork > > http://www.internetsociety.org/deploy360/ > -- "When it comes to glittering objects, wizards have all the taste and self-control of a deranged magpie." -- Terry Pratchett From york at isoc.org Thu Sep 6 10:03:04 2012 From: york at isoc.org (Dan York) Date: Thu, 6 Sep 2012 10:03:04 -0400 Subject: [Dnssec-deployment] Al-Jazeera website hit by DNS poisoning In-Reply-To: <7DB8B0FE-B6C2-4474-BC53-AE973A99F26B@kumari.net> References: <210B71AF-7391-45F5-A495-D8909D14FF73@isoc.org> <7DB8B0FE-B6C2-4474-BC53-AE973A99F26B@kumari.net> Message-ID: Warren, On Sep 6, 2012, at 9:42 AM, Warren Kumari wrote: > I suspect (although I have no proof yet) this this was not a DNS *cache* poisoning attack, but rather a failure of security in the registrar / auth servers. Yes... in giving it a few more moments of thought I agree with both you and Stephane that this sounds much more like someone cracked the servers at whatever DNS hosting provider was/is providing DNS for Al-Jazeera's domains. > Once you lose access at the registrar, or control of your auth servers[0], you have lost, regardless of DNSSEC? Yep! Thanks for chiming in, Dan -- Dan York Senior Content Strategist, Internet Society york at isoc.org +1-802-735-1624 Jabber: york at jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ From york at isoc.org Thu Sep 6 10:07:20 2012 From: york at isoc.org (Dan York) Date: Thu, 6 Sep 2012 10:07:20 -0400 Subject: [Dnssec-deployment] Al-Jazeera website hit by DNS poisoning In-Reply-To: <20120906133414.GA10307@nic.fr> References: <210B71AF-7391-45F5-A495-D8909D14FF73@isoc.org> <20120906133414.GA10307@nic.fr> Message-ID: <2A66205C-5BA9-4CA0-B750-C233115B9418@isoc.org> Stephane, On Sep 6, 2012, at 9:34 AM, Stephane Bortzmeyer wrote: > Unfortunately, none of these reports produce any evidence (not even a > dig output). The screenshot in the article could have been made by a > classical Web attack as well. Since the press and the PHBs say "DNS > poisoning" at every possible opportunity, I would say we have no real > information about the technique used by the attacker. Agreed! > The mentioned article says "Disruption to Al Jazeera sites was caused > by poisoning of DNS servers owned and run by an external company". If > this is true, it means the DNS hoster was simply cracked. Yes, in thinking about it more I agree with you and Warren on this. > In this > case, DNSSEC would *not* have prevented anything. Agreed, since the attacker would be in control of authoritative servers and can simply issue correctly-signed zones with bogus data. > So, if you are patient enough to reply to the reporters, the message > is: next time, use dig and send the complete output to an expert (or > ask her to run dig). Ha! Somehow I don't see that happening in the pace at which the media operates today, i.e. "publish first and then (maybe, but often not) worry about corrections later". Thanks, Dan -- Dan York Senior Content Strategist, Internet Society york at isoc.org +1-802-735-1624 Jabber: york at jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20120906/7057e2f7/attachment.html From jeroen at unfix.org Thu Sep 6 10:20:27 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 06 Sep 2012 16:20:27 +0200 Subject: [Dnssec-deployment] Al-Jazeera website hit by DNS poisoning In-Reply-To: <2A66205C-5BA9-4CA0-B750-C233115B9418@isoc.org> References: <210B71AF-7391-45F5-A495-D8909D14FF73@isoc.org> <20120906133414.GA10307@nic.fr> <2A66205C-5BA9-4CA0-B750-C233115B9418@isoc.org> Message-ID: <5048B12B.1040802@unfix.org> On 2012-09-06 16:07 , Dan York wrote: [..] >> In this >> case, DNSSEC would *not* have prevented anything. > > Agreed, since the attacker would be in control of authoritative servers > and can simply issue correctly-signed zones with bogus data. Kinda depends on your deployment model I would say. For DNS servers that I run we are pushing the full configuration, thus the fully signed zones but without the private key material from a central box to those DNS servers. The authoritative (frontend) hosts thus only serve static data. As such, they would have to compromise the backend box to be able to insert or modify records before the signing happens. And of course, unless you analyze the logs on the frontend boxes where that backend box is unknown lest somebody does proper research next to that backend box hopefully being quite a bit more protected than other hosts. The actual DNS servers, thus that are exposed in NS records, could thus be hacked, but they would not be able to sign anything. Of course, if one can hack those you could just as well take the box offline which would break it and moreover at the current point in time very few endusers do validation thus DNSSEC lossage would not be noticed that much. The fact of course that anything of your infrastructure gets compromised is just a bad thing, it does not matter which node it is, as it will cause some issues somewhere and likely one has a similar security issue on another host in ones network. Greets, Jeroen From sm at resistor.net Thu Sep 6 11:44:00 2012 From: sm at resistor.net (SM) Date: Thu, 06 Sep 2012 08:44:00 -0700 Subject: [Dnssec-deployment] Al-Jazeera website hit by DNS poisoning In-Reply-To: <20120906133414.GA10307@nic.fr> References: <210B71AF-7391-45F5-A495-D8909D14FF73@isoc.org> <20120906133414.GA10307@nic.fr> Message-ID: <6.2.5.6.2.20120906082223.0abb85f0@resistor.net> At 06:34 06-09-2012, Stephane Bortzmeyer wrote: >Unfortunately, none of these reports produce any evidence (not even a >dig output). The screenshot in the article could have been made by a >classical Web attack as well. Since the press and the PHBs say "DNS >poisoning" at every possible opportunity, I would say we have no real >information about the technique used by the attacker. https://twitter.com/babarmust/status/243112297017507840 People believe when they lack information. :-) For the archives: aljazeera.com. 3600 IN SOA admin.itmdb.net. dl-cdn_infrastructure.level3.com. 1346913566 10800 2700 3600000 900 aljazeera.com. 14400 IN NS a.ns.itmdb.net. aljazeera.com. 14400 IN NS b.ns.itmdb.net. aljazeera.com. 14400 IN NS d.ns.itmdb.net. Regards, -sm From york at isoc.org Fri Sep 7 06:29:50 2012 From: york at isoc.org (Dan York) Date: Fri, 7 Sep 2012 06:29:50 -0400 Subject: [Dnssec-deployment] .NL just became the first TLD to cross over 1 million DNSSEC-signed domain names! Message-ID: You can see the good news at: http://xs.powerdns.com/dnssec-nl-graph/ https://www.sidn.nl/ and both SIDN and Bert have been tweeting about it: https://twitter.com/SIDN/statuses/244006014804951040 https://twitter.com/PowerDNS_Bert/statuses/244005801516220416 along with Bert's note that .NL had more signed delegations added yesterday than .COM has in total! :-) https://twitter.com/PowerDNS_Bert/statuses/244013726917853184 Naturally I've put up a blog post to do our part in helping celebrate this milestone: http://www.internetsociety.org/deploy360/blog/2012/09/nl-becomes-first-tld-to-pass-1-million-dnssec-signed-domain-names/ Kudos to all the folks in NL for making this happen! Dan -- Dan York Senior Content Strategist, Internet Society york at isoc.org +1-802-735-1624 Jabber: york at jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20120907/c61abd50/attachment.html From andreev.peter at gmail.com Fri Sep 7 07:27:54 2012 From: andreev.peter at gmail.com (Peter Andreev) Date: Fri, 7 Sep 2012 15:27:54 +0400 Subject: [Dnssec-deployment] .NL just became the first TLD to cross over 1 million DNSSEC-signed domain names! In-Reply-To: References: Message-ID: Great news! However, what was the main cause for such DNSSec-boom? 2012/9/7 Dan York : > You can see the good news at: > > http://xs.powerdns.com/dnssec-nl-graph/ > https://www.sidn.nl/ > > and both SIDN and Bert have been tweeting about it: > > https://twitter.com/SIDN/statuses/244006014804951040 > https://twitter.com/PowerDNS_Bert/statuses/244005801516220416 > > along with Bert's note that .NL had more signed delegations added yesterday > than .COM has in total! :-) > > https://twitter.com/PowerDNS_Bert/statuses/244013726917853184 > > Naturally I've put up a blog post to do our part in helping celebrate this > milestone: > > http://www.internetsociety.org/deploy360/blog/2012/09/nl-becomes-first-tld-to-pass-1-million-dnssec-signed-domain-names/ > > Kudos to all the folks in NL for making this happen! > > Dan > > -- > Dan York > Senior Content Strategist, Internet Society > york at isoc.org +1-802-735-1624 > Jabber: york at jabber.isoc.org > Skype: danyork http://twitter.com/danyork > > http://www.internetsociety.org/deploy360/ > -- AP From dot at dotat.at Fri Sep 7 07:31:20 2012 From: dot at dotat.at (Tony Finch) Date: Fri, 7 Sep 2012 12:31:20 +0100 Subject: [Dnssec-deployment] .NL just became the first TLD to cross over 1 million DNSSEC-signed domain names! In-Reply-To: References: Message-ID: Peter Andreev wrote: > > However, what was the main cause for such DNSSec-boom? https://twitter.com/fanf/status/244014736805621760 > > @SIDN Do you have a discount for DNSSEC or some other incentive? https://twitter.com/SIDN/status/244016083810521088 > > @fanf Yes, correct, we're giving a discount. https://twitter.com/PowerDNS_Bert/status/244015898061598720 > > @fanf you discovered the secret. Net effect: that many 'normal' domains > are now secure, but those of banks aren't. This will get them to. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From bert.hubert at netherlabs.nl Fri Sep 7 07:48:46 2012 From: bert.hubert at netherlabs.nl (bert hubert) Date: Fri, 7 Sep 2012 13:48:46 +0200 Subject: [Dnssec-deployment] .NL just became the first TLD to cross over 1 million DNSSEC-signed domain names! In-Reply-To: References: Message-ID: <20120907114845.GA17013@xs.powerdns.com> On Fri, Sep 07, 2012 at 12:31:20PM +0100, Tony Finch wrote: > https://twitter.com/PowerDNS_Bert/status/244015898061598720 > > > > @fanf you discovered the secret. Net effect: that many 'normal' domains > > are now secure, but those of banks aren't. This will get them to. Let me elaborate on that a little. In several countries (including at least Sweden, The Czech Republic, The Netherlands), a small discount is given for secured delegations. Such small discounts do add up for bulk domain operators though. The net effect of this has been that many domain names are now signed, with an emphasis on those used by smaller organizations. Most larger organizations will either host their domain themselves, or with a registrar or operator not swayed by small discounts. The interesting dynamic is now that my favorite Chinese restaurant is more likely to have a DNSSEC signed domain than my bank is. In addition, since such high levels of domains are now secure in the countries mentioned above, this has created pressure on access providers to actually start validating, and many are. Over time, this will create pressure on banks to no longer 'lag' in their security posture compared to local Chinese restaurants. In this sense, the small DNSSEC subsidy supplied today is effectively working 'from below' to get the more staid but also perhaps more important domain name owners on board with DNSSEC. So, paradoxically, local Chinese restaurants are helping us secure banks. Bert -- PowerDNS Website: http://www.powerdns.com/ PowerDNS Community Website: http://wiki.powerdns.com/ PowerDNS is supported and developed by Netherlabs: http://www.netherlabs.nl From andreev.peter at gmail.com Fri Sep 7 08:01:40 2012 From: andreev.peter at gmail.com (Peter Andreev) Date: Fri, 7 Sep 2012 16:01:40 +0400 Subject: [Dnssec-deployment] .NL just became the first TLD to cross over 1 million DNSSEC-signed domain names! In-Reply-To: <20120907114845.GA17013@xs.powerdns.com> References: <20120907114845.GA17013@xs.powerdns.com> Message-ID: 2012/9/7 bert hubert : > On Fri, Sep 07, 2012 at 12:31:20PM +0100, Tony Finch wrote: >> https://twitter.com/PowerDNS_Bert/status/244015898061598720 >> > >> > @fanf you discovered the secret. Net effect: that many 'normal' domains >> > are now secure, but those of banks aren't. This will get them to. > > > Let me elaborate on that a little. > > In several countries (including at least Sweden, The Czech Republic, The > Netherlands), a small discount is given for secured delegations. Such small > discounts do add up for bulk domain operators though. > > The net effect of this has been that many domain names are now signed, with > an emphasis on those used by smaller organizations. Most larger > organizations will either host their domain themselves, or with a registrar > or operator not swayed by small discounts. > > The interesting dynamic is now that my favorite Chinese restaurant is > more likely to have a DNSSEC signed domain than my bank is. > > In addition, since such high levels of domains are now secure in the > countries mentioned above, this has created pressure on access providers to > actually start validating, and many are. > > Over time, this will create pressure on banks to no longer 'lag' in their > security posture compared to local Chinese restaurants. > > In this sense, the small DNSSEC subsidy supplied today is effectively > working 'from below' to get the more staid but also perhaps more important > domain name owners on board with DNSSEC. > > So, paradoxically, local Chinese restaurants are helping us secure banks. > > Bert Thank you, Bert! I was afraid that such discounts could lead to "dnssec-by-default" without notifying registrants or without providing them with extensive information on what DNSSec is and could play a bad joke in the future, but you made things clear. But now discounts looks for me not so bad as before. > > -- > PowerDNS Website: http://www.powerdns.com/ > PowerDNS Community Website: http://wiki.powerdns.com/ > PowerDNS is supported and developed by Netherlabs: http://www.netherlabs.nl -- AP From Roland.vanRijswijk at surfnet.nl Fri Sep 7 08:44:07 2012 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk - Deij) Date: Fri, 7 Sep 2012 14:44:07 +0200 Subject: [Dnssec-deployment] .NL just became the first TLD to cross over 1 million DNSSEC-signed domain names! In-Reply-To: References: <20120907114845.GA17013@xs.powerdns.com> Message-ID: Hi Peter, On 7 sep. 2012, at 14:01, Peter Andreev wrote: > I was afraid that such discounts could lead to "dnssec-by-default" > without notifying registrants or without providing them with extensive > information on what DNSSec is and could play a bad joke in the future, > but you made things clear. But now discounts looks for me not so bad > as before. To some extent your fear is founded in fact, luckily the people at SIDN - the registry - have been very pro-active in chasing problems. I've been sharing validation failures for .nl domains with them which they follow-up on. So far, their experience is that the registrars have been very quick in fixing any issues and their attitude has been very positive, they learn quickly. Thus, even though the number of DNSSEC signed domains has skyrocketed in .nl, the number of issues this has caused is negligible (< 0,005% of signed domains at the moment). Cheers, Roland -- Roland M. van Rijswijk - Deij -- SURFnet bv -- w: http://www.surfnet.nl/en/ -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From miek at miek.nl Fri Sep 7 08:50:30 2012 From: miek at miek.nl (Miek Gieben) Date: Fri, 7 Sep 2012 14:50:30 +0200 Subject: [Dnssec-deployment] .NL just became the first TLD to cross over 1 million DNSSEC-signed domain names! In-Reply-To: References: <20120907114845.GA17013@xs.powerdns.com> Message-ID: <20120907125030.GF17979@miek.nl> [ Quoting in "Re: [Dnssec-deployment] .NL just be..." ] > To some extent your fear is founded in fact, luckily the people at SIDN - the > registry - have been very pro-active in chasing problems. I've been sharing > validation failures for .nl domains with them which they follow-up on. So far, > their experience is that the registrars have been very quick in fixing any > issues and their attitude has been very positive, they learn quickly. Thus, > even though the number of DNSSEC signed domains has skyrocketed in .nl, the > number of issues this has caused is negligible (< 0,005% of signed domains at > the moment). And we (SIDN) are even stepping up in these efforts. We do hope that this is a temporary thing and DNSSEC becomes the norm. Regards, -- Miek Gieben http://miek.nl -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20120907/ef00e880/attachment.bin From bert.hubert at netherlabs.nl Fri Sep 7 09:28:57 2012 From: bert.hubert at netherlabs.nl (bert hubert) Date: Fri, 7 Sep 2012 15:28:57 +0200 Subject: [Dnssec-deployment] .NL just became the first TLD to cross over 1 million DNSSEC-signed domain names! In-Reply-To: References: <20120907114845.GA17013@xs.powerdns.com> Message-ID: <20120907132857.GC17013@xs.powerdns.com> On Fri, Sep 07, 2012 at 02:44:07PM +0200, Roland van Rijswijk - Deij wrote: > on. So far, their experience is that the registrars have been very quick > in fixing any issues and their attitude has been very positive, they learn > quickly. Thus, even though the number of DNSSEC signed domains has > skyrocketed in .nl, the number of issues this has caused is negligible (< > 0,005% of signed domains at the moment). This is a tribute to the registrars working very well with SIDN and in most cases with us & the PowerDNS community. SIDN, Surfnet and other vendors have worked very hard to make this a success, also because we realized that an early failure in large scale DNSSEC signing could cause premature rejection of DNSSEC, based on the perception that 'DNSSEC failed'. During the 'million domain march', we have found a lot of issues (often spotted by Roland): * issues purely having to do with DNS data, * issues with securing delegations to domains you don't actually host (the most common problem) * and finally issues within PowerDNS. This has led to important improvements to the PowerDNS Authoritative Nameserver, which will soon be released. The currently released version (3.1) is safe to run for most deployments, by the way. But to get to the 0.005% number Roland quotes above, you'll need 3.1.1 (or whatever we decide to call it). The large scale signing processes in Sweden and The Netherlands have led to a 'Best Current Practices' (and the Best Current Problems) page which can be found on http://wiki.powerdns.com/trac/wiki/LargeScaleDNSSECBCP The second most used DNSSEC implementation in the Netherlands is proprietary to its operator. I'm not sure what the third most used implementation is. I consider it likely that eventually we'll write a document summarizing the close interplay between registry, registrars and vendors that led to the relatively trouble free signing of a million domains. This might help subsequent migrations. Bert -- PowerDNS Website: http://www.powerdns.com/ PowerDNS Community Website: http://wiki.powerdns.com/ PowerDNS is supported and developed by Netherlabs: http://www.netherlabs.nl > > Cheers, > > Roland > > -- Roland M. van Rijswijk - Deij > -- SURFnet bv > -- w: http://www.surfnet.nl/en/ > -- t: +31-30-2305388 > -- e: roland.vanrijswijk at surfnet.nl > > From jeroen at unfix.org Fri Sep 7 09:52:52 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 07 Sep 2012 15:52:52 +0200 Subject: [Dnssec-deployment] .NL just became the first TLD to cross over 1 million DNSSEC-signed domain names! In-Reply-To: <20120907132857.GC17013@xs.powerdns.com> References: <20120907114845.GA17013@xs.powerdns.com> <20120907132857.GC17013@xs.powerdns.com> Message-ID: <5049FC34.4020300@unfix.org> First off of course: congrats to all the people involved, awesome work! On 2012-09-07 15:28 , bert hubert wrote: [..] > The large scale signing processes in Sweden and The Netherlands have led to > a 'Best Current Practices' (and the Best Current Problems) page which can be > found on http://wiki.powerdns.com/trac/wiki/LargeScaleDNSSECBCP Every once in a while I peek at DNSSEC and then I notice that the primary thing missing is a simple "Automated DNSSEC HOWTO" for people where you can point to them to and say 'if you want to do DNSSEC for everything just run this and that. >From my view there are three phases: 1) Sign Records in the zones one has This is easy in most cases. Typically just a zonesigner away or other method depending on the choice of DNS code one is running. eg using (mind wrapping of long urls): https://www.dnssec-tools.org/wiki/index.php/Authoritative_Zone_Administrator http://alan.clegg.com/files/DNSSEC_in_6_minutes.pdf ftp://ftp.isc.org/isc/pubs/pres/NANOG/50/DNSSEC-NANOG50.pdf http://doc.powerdns.com/powerdnssec-auth.html 2) Feed DS records to upstream registry/registrar Depends on the registrar/registry involved, and there is little to no data on this from what I am aware of. It would be really cool if some place has a central repo/wiki for storing details on how various places work. Possibly this comes close: http://www.internetsociety.org/deploy360/resources/dnssec-registrars/ but it does not have any links/scripts to automated ways of doing it and for a 100.000 sites you are not going to click everywhere. There is: http://sourceforge.net/projects/dskm/files/ which apparently does it for Joker and RIPE (ip6.arpa) data. I've got one for ISC DLV, but that is not something one should be using for the long run. Note that I keep a list of DNSSEC in combo with IPv6 registrars at: https://www.sixxs.net/faq/dns/?faq=ipv6glue wouldn't mind adding data or pointing to resources to get this step done. 3) Key-roll over and re-feeding that to the upstream Likely close to the 2nd step from an automation point of view. Love to get input on these, especially on where we could note this down and make it easy to find for the rest of the 4M .nl domains and more importantly: the rest of the world. Greets, Jeroen (BTW: The primary value I see in DNSSEC is that DANE hopefully is happening and thus hopefully also removes this annoying TLS certificate business) From Roland.vanRijswijk at surfnet.nl Fri Sep 7 09:59:31 2012 From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk - Deij) Date: Fri, 7 Sep 2012 15:59:31 +0200 Subject: [Dnssec-deployment] .NL just became the first TLD to cross over 1 million DNSSEC-signed domain names! In-Reply-To: <5049FC34.4020300@unfix.org> References: <20120907114845.GA17013@xs.powerdns.com> <20120907132857.GC17013@xs.powerdns.com> <5049FC34.4020300@unfix.org> Message-ID: <1762D54C-D9BB-4425-A3F6-2AB225C8A6A9@surfnet.nl> Hi Jeroen, On 7 sep. 2012, at 15:52, Jeroen Massar wrote: > First off of course: congrats to all the people involved, awesome work! > > On 2012-09-07 15:28 , bert hubert wrote: > [..] >> The large scale signing processes in Sweden and The Netherlands have led to >> a 'Best Current Practices' (and the Best Current Problems) page which can be >> found on http://wiki.powerdns.com/trac/wiki/LargeScaleDNSSECBCP > > Every once in a while I peek at DNSSEC and then I notice that the > primary thing missing is a simple "Automated DNSSEC HOWTO" for people > where you can point to them to and say 'if you want to do DNSSEC for > everything just run this and that. [snip] Nice summary for the authoritative side, may I shamelessly self-promote our (SURFnet's) HOWTO for validation on the resolver side? http://www.surfnet.nl/Documents/rapport_Deploying_DNSSEC_v20.pdf Recently updated and now including instructions for MS Windows Server 2012 :-) Cheers, Roland -- Roland M. van Rijswijk - Deij -- SURFnet bv -- w: http://www.surfnet.nl/en/ -- t: +31-30-2305388 -- e: roland.vanrijswijk at surfnet.nl From york at isoc.org Fri Sep 7 10:00:33 2012 From: york at isoc.org (Dan York) Date: Fri, 7 Sep 2012 10:00:33 -0400 Subject: [Dnssec-deployment] .NL just became the first TLD to cross over 1 million DNSSEC-signed domain names! In-Reply-To: <20120907132857.GC17013@xs.powerdns.com> References: <20120907114845.GA17013@xs.powerdns.com> <20120907132857.GC17013@xs.powerdns.com> Message-ID: Bert, On Sep 7, 2012, at 9:28 AM, bert hubert wrote: > The large scale signing processes in Sweden and The Netherlands have led to > a 'Best Current Practices' (and the Best Current Problems) page which can be > found on http://wiki.powerdns.com/trac/wiki/LargeScaleDNSSECBCP Good document. Thanks for writing it. And thanks for separating the issues into ones that are PowerDNS-related and ones that are more generic. > I consider it likely that eventually we'll write a document summarizing the > close interplay between registry, registrars and vendors that led to the > relatively trouble free signing of a million domains. This might help > subsequent migrations. Please do! That would be extremely helpful as a case study to provide to others. If I can help at all, please let me know. This is the kind of info we'd love to promote through Deploy360. Dan -- Dan York Senior Content Strategist, Internet Society york at isoc.org +1-802-735-1624 Jabber: york at jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20120907/2abe48ed/attachment.html From regnauld at nsrc.org Fri Sep 7 10:11:58 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Fri, 7 Sep 2012 16:11:58 +0200 Subject: [Dnssec-deployment] .NL just became the first TLD to cross over 1 million DNSSEC-signed domain names! In-Reply-To: <5049FC34.4020300@unfix.org> References: <20120907114845.GA17013@xs.powerdns.com> <20120907132857.GC17013@xs.powerdns.com> <5049FC34.4020300@unfix.org> Message-ID: <20120907141158.GB86960@macbook.bluepipe.net> Jeroen Massar (jeroen) writes: > > (BTW: The primary value I see in DNSSEC is that DANE hopefully is > happening and thus hopefully also removes this annoying TLS certificate > business) That's a very restrictive view of the value of DNSSEC, and X.509 certicates are unlikely to go away, if only for the reason that, with EV certificates at least (http://en.wikipedia.org/wiki/Extended_Validation_Certificate#Issuing_criteria) you pay an independent (no laughing) third party to assert YOUR identity/ credentials. Now, I sure don't care about this assertion in most cases, and would be very happy with a self-signed, DANE authenticated X.509 cert, but maybe there is a business in paying Thawte (or other SSL vendor) to publish TLSA signed records for one's own X.509 (aka SSL) certificates. I don't know, call it philco.certs.thawte.com (or philco.thawte.com.cert ? ;) Phil From jeroen at unfix.org Fri Sep 7 10:56:53 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 07 Sep 2012 16:56:53 +0200 Subject: [Dnssec-deployment] .NL just became the first TLD to cross over 1 million DNSSEC-signed domain names! In-Reply-To: <1762D54C-D9BB-4425-A3F6-2AB225C8A6A9@surfnet.nl> References: <20120907114845.GA17013@xs.powerdns.com> <20120907132857.GC17013@xs.powerdns.com> <5049FC34.4020300@unfix.org> <1762D54C-D9BB-4425-A3F6-2AB225C8A6A9@surfnet.nl> Message-ID: <504A0B35.2080303@unfix.org> On 2012-09-07 15:59 , Roland van Rijswijk - Deij wrote: [..] > Nice summary for the authoritative side, may I shamelessly > self-promote our (SURFnet's) HOWTO for validation on the resolver > side? > > http://www.surfnet.nl/Documents/rapport_Deploying_DNSSEC_v20.pdf > > Recently updated and now including instructions for MS Windows Server > 2012 :-) I've added that to the DNSSEC page. On 2012-09-07 16:11 , Phil Regnauld wrote:> Jeroen Massar (jeroen) writes: >> >> (BTW: The primary value I see in DNSSEC is that DANE hopefully is >> happening and thus hopefully also removes this annoying TLS >> certificate business) > > That's a very restrictive view of the value of DNSSEC I do not find that restrictive, there simply is a lot of value in the validation that DNSSEC provides, DANE being one of the portions that I like the most. > and X.509 > certicates are unlikely to go away, if only for the reason that, with > EV certificates at least [..] you pay an independent (no laughing) > third party to assert YOUR identity/ credentials. The 'pay' portion is what is annoying about them. Prices for these certificates, especially wildcard ones, are disproportionate to the work and validity checking that goes into them and they do not have any value then still as a compromise might simply replace the content of a site, the cool "EV" tag does not state anything about the actual content, it just states that you are likely talking to the right company, which is what DANE also does but at a nearly no-cost factor. > Now, I sure don't care about this assertion in most cases, and would > be very happy with a self-signed, DANE authenticated X.509 cert, but > maybe there is a business in paying Thawte (or other SSL vendor) to > publish TLSA signed records for one's own X.509 (aka SSL) > certificates. I don't know, call it philco.certs.thawte.com (or It definitely is a business, just like domaining is (especially in light of all the new GTLDs that are coming). Greets, Jeroen From regnauld at nsrc.org Fri Sep 7 11:39:27 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Fri, 7 Sep 2012 17:39:27 +0200 Subject: [Dnssec-deployment] .NL just became the first TLD to cross over 1 million DNSSEC-signed domain names! In-Reply-To: <504A0B35.2080303@unfix.org> References: <20120907114845.GA17013@xs.powerdns.com> <20120907132857.GC17013@xs.powerdns.com> <5049FC34.4020300@unfix.org> <1762D54C-D9BB-4425-A3F6-2AB225C8A6A9@surfnet.nl> <504A0B35.2080303@unfix.org> Message-ID: <20120907153927.GF86960@macbook.bluepipe.net> Jeroen Massar (jeroen) writes: > Prices for these certificates, especially wildcard ones, are > disproportionate to the work and validity checking that goes into them > and they do not have any value then still as a compromise might simply > replace the content of a site, the cool "EV" tag does not state anything > about the actual content, it just states that you are likely talking to > the right company, which is what DANE also does but at a nearly no-cost > factor. Nope, DANE/DNSSEC only states that you are fairly certain to receiving data from the owner of the zone contents. > It definitely is a business, just like domaining is (especially in light > of all the new GTLDs that are coming). Sure, but no one forces you to buy SSL/X.509 certificates either :) Mind you, I'm not particularly impressed by the certificate market in general :) From jakob at kirei.se Mon Sep 10 16:57:38 2012 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 10 Sep 2012 22:57:38 +0200 Subject: [Dnssec-deployment] FYI: New Version Notification for draft-jabley-dnssec-trust-anchor-05.txt References: <20120910205138.20104.54094.idtracker@ietfa.amsl.com> Message-ID: <8753E354-48BC-4F35-985E-B6A3B87E74D4@kirei.se> Greetings, We've just updated our draft on "DNSSEC Trust Anchor Publication for the Root Zone". As you may be aware of, an implementation of this draft is being shipped as part of Microsoft Windows Server 2012. If there are other implementations out there, please let us know. Issues with this draft can be submitted via email to the authors, or via https://github.com/kirei/dnssec-ta-draft/issues. jakob Begin forwarded message: > From: internet-drafts at ietf.org > Subject: New Version Notification for draft-jabley-dnssec-trust-anchor-05.txt > Date: 10 september 2012 22:51:38 CEST > To: jakob at kirei.se > Cc: gubailey at microsoft.com, joe.abley at icann.org > > > A new version of I-D, draft-jabley-dnssec-trust-anchor-05.txt > has been successfully submitted by Jakob Schlyter and posted to the > IETF repository. > > Filename: draft-jabley-dnssec-trust-anchor > Revision: 05 > Title: DNSSEC Trust Anchor Publication for the Root Zone > Creation date: 2012-09-10 > WG ID: Individual Submission > Number of pages: 19 > URL: http://www.ietf.org/internet-drafts/draft-jabley-dnssec-trust-anchor-05.txt > Status: http://datatracker.ietf.org/doc/draft-jabley-dnssec-trust-anchor > Htmlized: http://tools.ietf.org/html/draft-jabley-dnssec-trust-anchor-05 > Diff: http://www.ietf.org/rfcdiff?url2=draft-jabley-dnssec-trust-anchor-05 > > Abstract: > The root zone of the Domain Name System (DNS) has been > cryptographically signed using DNS Security Extensions (DNSSEC). > > In order to obtain secure answers from the root zone of the DNS using > DNSSEC, a client must configure a suitable trust anchor. This > document describes how such trust anchors are published. > > > > > The IETF Secretariat > -- Jakob Schlyter Kirei AB - http://www.kirei.se/ From Ralf.Weber at nominum.com Tue Sep 11 04:57:46 2012 From: Ralf.Weber at nominum.com (Ralf Weber) Date: Tue, 11 Sep 2012 08:57:46 +0000 Subject: [Dnssec-deployment] FYI: New Version Notification for draft-jabley-dnssec-trust-anchor-05.txt In-Reply-To: <8753E354-48BC-4F35-985E-B6A3B87E74D4@kirei.se> References: <20120910205138.20104.54094.idtracker@ietfa.amsl.com> <8753E354-48BC-4F35-985E-B6A3B87E74D4@kirei.se> Message-ID: Moin! On 10.09.2012, at 22:57, Jakob Schlyter wrote: > Greetings, > > We've just updated our draft on "DNSSEC Trust Anchor Publication for the Root Zone". As you may be aware of, an implementation of this draft is being shipped as part of Microsoft Windows Server 2012. If there are other implementations out there, please let us know. Nominum Vantio is shipped with a script (vantio_getrootkey) that does that. So long -Ralf --- Ralf Weber Senior Infrastructure Architect Nominum Inc. 2000 Seaport Blvd. Suite 400 Redwood City, California 94063 ralf.weber at nominum.com From wouter at nlnetlabs.nl Tue Sep 11 10:46:29 2012 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Tue, 11 Sep 2012 16:46:29 +0200 Subject: [Dnssec-deployment] FYI: New Version Notification for draft-jabley-dnssec-trust-anchor-05.txt In-Reply-To: References: <20120910205138.20104.54094.idtracker@ietfa.amsl.com> <8753E354-48BC-4F35-985E-B6A3B87E74D4@kirei.se> Message-ID: <504F4EC5.9070604@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 09/11/2012 10:57 AM, Ralf Weber wrote: > On 10.09.2012, at 22:57, Jakob Schlyter wrote: >> We've just updated our draft on "DNSSEC Trust Anchor Publication >> for the Root Zone". As you may be aware of, an implementation of >> this draft is being shipped as part of Microsoft Windows Server >> 2012. If there are other implementations out there, please let us >> know. > Nominum Vantio is shipped with a script (vantio_getrootkey) that > does that. Unbound has a Posix-C program (unbound-anchor) that does that. It is written to deal with 'nothing works'. Implements RFC5011, for better server-loads. BSD licensed open source. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQT07EAAoJEJ9vHC1+BF+NbkUP/jbpdq1U+eS9MMwZnT/zv63t jzmX/bRIkWrHXtwiuFlOi6S0spgHYmUwvZgDQJyNjpIs+F/jYnmj4YB1zVTGgnTi lBN3+WLHkmiIt2U3xPxQmOFD22PiUfTBrBU0MUag+TkX/6oar/OG178NKmraZMpY GIoMGA9WP6yvse3HTxzfahIkCMN5ftv+j7yttcnCEBr2hzH+9RlhiRVWdQ6uUQLO T0sV8+567Y8spb2abBGmWC72GmDKkE/MVhpPqJSE2Tg7vF5PyeUTOPvpWK/JPNHa zVRZfGCQG8Twaa1aaKNNS82CnVacLHloQGBok49W8spKFaYT9hdynzwWyM9Gu4x2 3zAJ8cex01cf2KCKotENqvYt5iMhCwcGVogUul/TQ3T0NM1Niprch3R1q/YI+n1I fTSbDkviPzr5xs/EZ8TP+BQUJxSnv2t+t/hSAdUQeAVoON7i77CujQlDoFk6Zl4C msyAzNxGa6XUCUjMyXMM7+Nx1VnCepGCMgt4+GrMMPA/kwl2r7wqStANbOZWnaCs 2+UAAS3kDDkdjVV6s3ek2Bkyfy0qgXjoXDHEoTkJBYpu9hbp12c8gTEoL1bhtDO6 v7HRwZaYTZRexN4EjbTUu7ldEb5HKYWU/K2uMGdm2TxCJPWTyDUGU482kgaELguA qnLDgr0t9VL6z8jnIF+H =LFDj -----END PGP SIGNATURE----- From heland at afilias.info Thu Sep 13 09:51:19 2012 From: heland at afilias.info (Howard Eland) Date: Thu, 13 Sep 2012 08:51:19 -0500 Subject: [Dnssec-deployment] .HN Zone to go Invalid during Transition Message-ID: <7C1BFAEB-138C-4269-84E5-9B17E2FB8FA6@afilias.info> All, Honduras has begun the transition of registry service providers for the .HN ccTLD from Afilias to CoCCA. The transition is scheduled to be completed by the end of September, 2012. The Sponsoring Organisation responsible for .HN has decided to take the .HN zone invalid during the DNS migration. Currently, there is only a single signed delegation in the .HN zone (and it's Afilias.HN), so the impact should be minimal. The note is just to provide forewarning when folks see that the .HN DS record in the root has disappeared. We are unaware of the Sponsoring Organization's plans for DNSSEC in the .HN zone following the transition. Regards, Howard Eland Sr. Director - Content Propagation and Resolution Afilias From regnauld at nsrc.org Thu Sep 13 10:01:14 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 13 Sep 2012 16:01:14 +0200 Subject: [Dnssec-deployment] .HN Zone to go Invalid during Transition In-Reply-To: <7C1BFAEB-138C-4269-84E5-9B17E2FB8FA6@afilias.info> References: <7C1BFAEB-138C-4269-84E5-9B17E2FB8FA6@afilias.info> Message-ID: <20120913140114.GG28513@macbook.bluepipe.net> Howard Eland (heland) writes: > All, > > Honduras has begun the transition of registry service providers for the > .HN ccTLD from Afilias to CoCCA. The transition is scheduled to be > completed by the end of September, 2012. The Sponsoring Organisation > responsible for .HN has decided to take the .HN zone invalid during the > DNS migration. Currently, there is only a single signed delegation in the > .HN zone (and it's Afilias.HN), so the impact should be minimal. Do you mean the zone will be unvalidatable, or insecure ? > The note is just to provide forewarning when folks see that the .HN DS > record in the root has disappeared. If the DS is removed, it's just insecure, and not even afilias.hn should be affected. > We are unaware of the Sponsoring Organization's plans for DNSSEC in the > .HN zone following the transition. I'm not sure there is DNSSEC support in the CoCCA platform yet... Thanks for the heads up. Cheers, Phil From heland at afilias.info Thu Sep 13 10:20:23 2012 From: heland at afilias.info (Howard Eland) Date: Thu, 13 Sep 2012 09:20:23 -0500 Subject: [Dnssec-deployment] .HN Zone to go Invalid during Transition In-Reply-To: <20120913140114.GG28513@macbook.bluepipe.net> References: <7C1BFAEB-138C-4269-84E5-9B17E2FB8FA6@afilias.info> <20120913140114.GG28513@macbook.bluepipe.net> Message-ID: On Sep 13, 2012, at 9:01 AM, Phil Regnauld wrote: > Howard Eland (heland) writes: >> All, >> >> Honduras has begun the transition of registry service providers for the >> .HN ccTLD from Afilias to CoCCA. The transition is scheduled to be >> completed by the end of September, 2012. The Sponsoring Organisation >> responsible for .HN has decided to take the .HN zone invalid during the >> DNS migration. Currently, there is only a single signed delegation in the >> .HN zone (and it's Afilias.HN), so the impact should be minimal. > > Do you mean the zone will be unvalidatable, or insecure ? Once cut-over, we will not be signing the .HN zone. I cannot make any claims for the new provider as to when they will generate their own DNSKEY and start signing. For some period, it will indeed be invalid. (this should answer Joe's query as well, so I'll not replicate that portion of the thread with a duplicate reply). > >> The note is just to provide forewarning when folks see that the .HN DS >> record in the root has disappeared. > > If the DS is removed, it's just insecure, and not even afilias.hn should > be affected. Agreed. That is not the only action that will be occurring, but the removal of the DS is the first thing folks on this list will see. > >> We are unaware of the Sponsoring Organization's plans for DNSSEC in the >> .HN zone following the transition. > > I'm not sure there is DNSSEC support in the CoCCA platform yet... > > Thanks for the heads up. No problem. -Howard > > Cheers, > Phil From el at lisse.NA Thu Sep 13 10:49:55 2012 From: el at lisse.NA (Dr Eberhard Lisse) Date: Thu, 13 Sep 2012 16:49:55 +0200 Subject: [Dnssec-deployment] .HN Zone to go Invalid during Transition In-Reply-To: References: <7C1BFAEB-138C-4269-84E5-9B17E2FB8FA6@afilias.info> <20120913140114.GG28513@macbook.bluepipe.net> Message-ID: <5051F293.30102@lisse.NA> >From what I hear .HN remains committed to DNSSEC and will use PCH's platform, with which many, including me, are very happy with. el on 2012-09-13 16:20 Howard Eland said the following: > > On Sep 13, 2012, at 9:01 AM, Phil Regnauld wrote: > >> Howard Eland (heland) writes: >>> All, >>> >>> Honduras has begun the transition of registry service providers >>> for the .HN ccTLD from Afilias to CoCCA. The transition is >>> scheduled to be completed by the end of September, 2012. The >>> Sponsoring Organisation responsible for .HN has decided to take >>> the .HN zone invalid during the DNS migration. Currently, there >>> is only a single signed delegation in the .HN zone (and it's >>> Afilias.HN), so the impact should be minimal. >> >> Do you mean the zone will be unvalidatable, or insecure ? > > Once cut-over, we will not be signing the .HN zone. I cannot make > any claims for the new provider as to when they will generate > their own DNSKEY and start signing. For some period, it will > indeed be invalid. (this should answer Joe's query as well, so > I'll not replicate that portion of the thread with a duplicate > reply). > >> >>> The note is just to provide forewarning when folks see that the >>> .HN DS record in the root has disappeared. >> >> If the DS is removed, it's just insecure, and not even >> afilias.hn should be affected. > > Agreed. That is not the only action that will be occurring, but > the removal of the DS is the first thing folks on this list will > see. > >> >>> We are unaware of the Sponsoring Organization's plans for DNSSEC >>> in the .HN zone following the transition. >> >> I'm not sure there is DNSSEC support in the CoCCA platform >> yet... >> >> Thanks for the heads up. > > No problem. > > -Howard > >> >> Cheers, >> Phil -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el at lisse.NA el108-ARIN / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Please do NOT email to this address Bachbrecht, Namibia ;____/ if it is DNS related in ANY way From wouter at nlnetlabs.nl Thu Sep 13 10:51:07 2012 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Thu, 13 Sep 2012 16:51:07 +0200 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 Message-ID: <5051F2DB.7090204@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, With RFC6725 the DNSSEC algorithm RSAMD5 has gotten status DEPRECATED (it used to have status NOT RECOMMENDED from RFC4034 and before). We want to publish Unbound with a codechange, so that the MD5 signed zones are treated as unsigned: the MD5 algorithm is not used for security, but the domains are still accessible (but insecurely so). Are there still people using RSAMD5 for signing their zones? If so, when do you plan to move away from it? Secspider saw 0 zones with RSAMD5. Is there still signer software that allows RSAMD5 zonesigning? Should we wait for you to disable that (or print caution statements that it is deprecated) ? Unbound respects FIPS standards (if enabled on the machine) and disables MD5 usage if so - this is already deployed. There is an argument that there is no evidence of weakness of MD5 for DNSSEC (but there is for other MD5 usage), and we should keep md5 support enabled, but perhaps have an option. But this goes against the RFC. Are there considerations that we have missed? We want to deploy the new RFC standards action, but we do not want unilateral actions. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQUfLbAAoJEJ9vHC1+BF+NWksP/A4kjcnENHCQxyMcKAURYpuL 3VaAJPPKgbYHVmBgR6BA+U5yjLlEqa8CG28ne0w8hFSeNdqbRsnbixRZb2jY9vxW M65RIaQ68Aop8NKimrbwE00zzagZciWy3rh6vAWo8Uos80xifmbfyDpM+8bymj9e 8UaQg3RSjAVVctYbISNqPjtm50wxNtNSnPXvh/sB0uA1M3S264OTfRszYsqXqP/L nqh8HL8t0bpsKPnNsfXmdPbinS6KvnA/evhQ+NfBXUcwkTqb8J7vkhdxWppj9jY8 Qun9+f2lwjLgh2p1PV09Jx74AMZD9c70afVroxuKM00XjMBa68KEXKdONttSW3E7 ro/R0lVapcnj3xdQYIS7tVN7t8AGEYaCRbUVoN+m/pzdg6y3dVvObKozW/UaGuzK OWG5at/PPamKVLXdVptfoD3SJhcKH2zrmB1pYLoAvBaA1+Q8rdwdZMVvPdIADHXQ Wk48D57YLZaPQbYcSAsBEnhLGS00QnsSoJ/44blPaBbABLZgYCYZgZ1xI1QLXDbf OISQ4C7b2jqrq1w09q4UN3xY4QZ0Hc2BvRF+Ut7rIgf7u0PMXzMWHNrOStjoM+ad vvRMz4gPJ5eW7DayLVI0m1QCoG5MibADw1WIQ/jHO9ep8FgPX15jIyxXY7zvcgLI ALWM8+jkN2sxYN+9b0VG =R19a -----END PGP SIGNATURE----- From antoin.verschuren at sidn.nl Thu Sep 13 10:53:57 2012 From: antoin.verschuren at sidn.nl (Antoin Verschuren) Date: Thu, 13 Sep 2012 16:53:57 +0200 Subject: [Dnssec-deployment] .HN Zone to go Invalid during Transition In-Reply-To: References: <7C1BFAEB-138C-4269-84E5-9B17E2FB8FA6@afilias.info> <20120913140114.GG28513@macbook.bluepipe.net> Message-ID: <5051F385.6080700@sidn.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13-09-12 16:20, Howard Eland wrote: > > On Sep 13, 2012, at 9:01 AM, Phil Regnauld wrote: > >> Howard Eland (heland) writes: >>> All, >>> >>> Honduras has begun the transition of registry service providers >>> for the .HN ccTLD from Afilias to CoCCA. The transition is >>> scheduled to be completed by the end of September, 2012. The >>> Sponsoring Organisation responsible for .HN has decided to take >>> the .HN zone invalid during the DNS migration. Currently, >>> there is only a single signed delegation in the .HN zone (and >>> it's Afilias.HN), so the impact should be minimal. >> >> Do you mean the zone will be unvalidatable, or insecure ? > > Once cut-over, we will not be signing the .HN zone. I cannot make > any claims for the new provider as to when they will generate their > own DNSKEY and start signing. For some period, it will indeed be > invalid. (this should answer Joe's query as well, so I'll not > replicate that portion of the thread with a duplicate reply). Hmm, this is a missed opportunity for Honduras to be the first TLD to do a DNSSEC secure transfer.... (http://www.sidnlabs.nl/fileadmin/sidnlabs/uploads/downloads/Secure_transfers_-EN.pdf) - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren at sidn.nl xmpp:antoin at jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJQUfOEAAoJEDqHrM883AgnOf0IAKjq6DE1Fsi0whbI/FzTARV1 y4ScMATo93aVoET8R9U/wgtmF/ATyvlmtoOm7uLJDfStSjkqW8Om/5/pJ0whvByJ zgRDWhqZUxa+DUfNKESwykxrAfLPDym0OeoxtZSn3jdT5uprflyByKzMzbe68z5E +RvJ6/lqWAt+A214X9GJK4vos5NPB2LQ0xADLTnBQvbFeoeTc8PmElLpDhrFPYuI UjXro0Od6KJCQvE9cnIse0tJwgw3jbia5nFTKCsoLCyZuBAvYyGu9k4BnDXkVh6/ 7R27mPfeXey/FQmZm4MAWRSmWbFukrArlrp3x3KDme3dWf39IrjL37Yp8ThYiPA= =GFnD -----END PGP SIGNATURE----- From el at lisse.NA Thu Sep 13 11:03:39 2012 From: el at lisse.NA (Dr Eberhard Lisse) Date: Thu, 13 Sep 2012 17:03:39 +0200 Subject: [Dnssec-deployment] .HN Zone to go Invalid during Transition In-Reply-To: <5051F385.6080700@sidn.nl> References: <7C1BFAEB-138C-4269-84E5-9B17E2FB8FA6@afilias.info> <20120913140114.GG28513@macbook.bluepipe.net> <5051F385.6080700@sidn.nl> Message-ID: <5051F5CB.3090006@lisse.NA> Maybe Afilias and PCH could get together and see whether this can bed one. el on 2012-09-13 16:53 Antoin Verschuren said the following: [...] > Hmm, this is a missed opportunity for Honduras to be the first TLD > to do a DNSSEC secure transfer.... > > (http://www.sidnlabs.nl/fileadmin/sidnlabs/uploads/downloads/Secure_transfers_-EN.pdf) -- > > Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el at lisse.NA el108-ARIN / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Please do NOT email to this address Bachbrecht, Namibia ;____/ if it is DNS related in ANY way From heland at afilias.info Thu Sep 13 11:07:25 2012 From: heland at afilias.info (Howard Eland) Date: Thu, 13 Sep 2012 10:07:25 -0500 Subject: [Dnssec-deployment] .HN Zone to go Invalid during Transition In-Reply-To: <5051F5CB.3090006@lisse.NA> References: <7C1BFAEB-138C-4269-84E5-9B17E2FB8FA6@afilias.info> <20120913140114.GG28513@macbook.bluepipe.net> <5051F385.6080700@sidn.nl> <5051F5CB.3090006@lisse.NA> Message-ID: <4C906F71-38C7-4CB5-83EA-739DC25D3A2D@afilias.info> On Sep 13, 2012, at 10:03 AM, Dr Eberhard Lisse wrote: > Maybe Afilias and PCH could get together and see whether this can bed one. We did. The decision was made by the Sponsoring Organization. -Howard > > el > > on 2012-09-13 16:53 Antoin Verschuren said the following: > [...] >> Hmm, this is a missed opportunity for Honduras to be the first TLD >> to do a DNSSEC secure transfer.... >> >> (http://www.sidnlabs.nl/fileadmin/sidnlabs/uploads/downloads/Secure_transfers_-EN.pdf) > > > -- >> >> > Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) > el at lisse.NA el108-ARIN / * | Telephone: +264 81 124 6733 (cell) > PO Box 8421 \ / Please do NOT email to this address > Bachbrecht, Namibia ;____/ if it is DNS related in ANY way From paul.hoffman at vpnc.org Thu Sep 13 11:13:00 2012 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Thu, 13 Sep 2012 08:13:00 -0700 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 In-Reply-To: <5051F2DB.7090204@nlnetlabs.nl> References: <5051F2DB.7090204@nlnetlabs.nl> Message-ID: On Sep 13, 2012, at 7:51 AM, W.C.A. Wijngaards wrote: > Unbound respects FIPS standards (if enabled on the machine) and > disables MD5 usage if so - this is already deployed. Pedantic point: which FIPS documents are you talking about? You may have misinterpreted some guidelines there. I'm not saying you shouldn't turn off RSAMD5 signing and validation, just that you shouldn't pin this on FIPS. > There is an argument that there is no evidence of weakness of MD5 for > DNSSEC (but there is for other MD5 usage), and we should keep md5 > support enabled, but perhaps have an option. But this goes against > the RFC. I am the person who keeps reminding the world of the lack of any known weakness for RSAMD5 in DNSSEC. Having said that, it is just fine to say "and still want to discourage people from using it". Taking it out of a significant piece of software is a very good way to discourage its use, regardless of whether there is an actual known weakness. > Are there considerations that we have missed? We want to deploy the > new RFC standards action, but we do not want unilateral actions. To do the former, you have to do the latter. That was one of the purposes of the RFC. --Paul Hoffman From rickardb at certezza.net Thu Sep 13 11:15:01 2012 From: rickardb at certezza.net (Rickard Bellgrim) Date: Thu, 13 Sep 2012 17:15:01 +0200 Subject: [Dnssec-deployment] .HN Zone to go Invalid during Transition In-Reply-To: <5051F5CB.3090006@lisse.NA> References: <7C1BFAEB-138C-4269-84E5-9B17E2FB8FA6@afilias.info> <20120913140114.GG28513@macbook.bluepipe.net> <5051F385.6080700@sidn.nl> <5051F5CB.3090006@lisse.NA> Message-ID: <24F19A4D7888A7459659F4C7F579A29C0F5878A8@mail01.certezza.local> > Maybe Afilias and PCH could get together and see whether this can bed one. It can be done. Although .SE did not change the NS, only changed signer. The attached pictures illustrate the following: 1. .SE have published new keys in zone. Uploaded new DS to root. 2. Switch signer and use the new keys. 3. Remove post-published keys and remove old DS. There were more steps involved than the number of pictures. Similar to the ones by Antoin. // Rickard -------------- next part -------------- A non-text attachment was scrubbed... Name: 3.remove.old.data.png Type: image/png Size: 65895 bytes Desc: 3.remove.old.data.png Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20120913/82417e20/attachment-0003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: 2.switch.system.png Type: image/png Size: 87076 bytes Desc: 2.switch.system.png Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20120913/82417e20/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.prepare.png Type: image/png Size: 93392 bytes Desc: 1.prepare.png Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20120913/82417e20/attachment-0005.png From el at lisse.NA Thu Sep 13 11:19:54 2012 From: el at lisse.NA (Dr Eberhard Lisse) Date: Thu, 13 Sep 2012 17:19:54 +0200 Subject: [Dnssec-deployment] .HN Zone to go Invalid during Transition In-Reply-To: <24F19A4D7888A7459659F4C7F579A29C0F5878A8@mail01.certezza.local> References: <7C1BFAEB-138C-4269-84E5-9B17E2FB8FA6@afilias.info> <20120913140114.GG28513@macbook.bluepipe.net> <5051F385.6080700@sidn.nl> <5051F5CB.3090006@lisse.NA> <24F19A4D7888A7459659F4C7F579A29C0F5878A8@mail01.certezza.local> Message-ID: <5051F99A.6090900@lisse.NA> I am quite interested in this, would love to see a presentation at ICANN TechDay (next one jointly with OARC in Toronto in October). greetings, el on 2012-09-13 17:15 Rickard Bellgrim said the following: >> Maybe Afilias and PCH could get together and see whether this can bed one. > > It can be done. Although .SE did not change the NS, only changed signer. > > The attached pictures illustrate the following: > 1. .SE have published new keys in zone. Uploaded new DS to root. > 2. Switch signer and use the new keys. > 3. Remove post-published keys and remove old DS. > > There were more steps involved than the number of pictures. > Similar to the ones by Antoin. > > // Rickard > -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el at lisse.NA el108-ARIN / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Please do NOT email to this address Bachbrecht, Namibia ;____/ if it is DNS related in ANY way From pk at ISOC.DE Thu Sep 13 11:46:06 2012 From: pk at ISOC.DE (Peter Koch) Date: Thu, 13 Sep 2012 17:46:06 +0200 Subject: [Dnssec-deployment] .HN Zone to go Invalid during Transition In-Reply-To: <5051F385.6080700@sidn.nl> References: <7C1BFAEB-138C-4269-84E5-9B17E2FB8FA6@afilias.info> <20120913140114.GG28513@macbook.bluepipe.net> <5051F385.6080700@sidn.nl> Message-ID: <20120913154606.GJ7055@x28.adm.denic.de> [assuming $subject =~ s/invalid/insecure/;] On Thu, Sep 13, 2012 at 04:53:57PM +0200, Antoin Verschuren wrote: > Hmm, this is a missed opportunity for Honduras to be the first TLD to > do a DNSSEC secure transfer.... > > (http://www.sidnlabs.nl/fileadmin/sidnlabs/uploads/downloads/Secure_transfers_-EN.pdf) indeed - except that the dropbox approach for the ZSK described in the very recently expired internet draft and your excellent implementation report would need to be simulated. -Peter From ajs at anvilwalrusden.com Thu Sep 13 11:56:23 2012 From: ajs at anvilwalrusden.com (Andrew Sullivan) Date: Thu, 13 Sep 2012 11:56:23 -0400 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 In-Reply-To: <5051F2DB.7090204@nlnetlabs.nl> References: <5051F2DB.7090204@nlnetlabs.nl> Message-ID: <20120913155623.GD89509@mx1.yitter.info> On Thu, Sep 13, 2012 at 04:51:07PM +0200, W.C.A. Wijngaards wrote: > With RFC6725 the DNSSEC algorithm RSAMD5 has gotten status DEPRECATED > (it used to have status NOT RECOMMENDED from RFC4034 and before). You know, in all the back and forth over that document during the incredible length of time it took to publish, as far as I recall nobody ever asked what "deprecated" meant in the context. You'd think one of our eagle-eyed observers would have asked whether "deprecated" meant "don't use this for signing" or "don't use this for validating" or both. Sigh. > We want to publish Unbound with a codechange, so that the MD5 signed > zones are treated as unsigned: the MD5 algorithm is not used for > security, but the domains are still accessible (but insecurely so). In principle, it seems to me that it would be better to work on the signing and publishing side first. That is, the tools for signing should simply refuse to sign using RSAMD5, the serving zones ought to need special configuration to serve RSAMD5-signed zones, and so on. Once those changes are widely deployed, then it would be time to change the validators. But given the circumstances . . . > Are there still people using RSAMD5 for signing their zones? If so, > when do you plan to move away from it? Secspider saw 0 zones with RSAMD5. . . .I don't really see any harm in the code change. Best, A -- Andrew Sullivan ajs at anvilwalrusden.com From paul.hoffman at vpnc.org Thu Sep 13 12:27:42 2012 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Thu, 13 Sep 2012 09:27:42 -0700 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 In-Reply-To: <20120913155623.GD89509@mx1.yitter.info> References: <5051F2DB.7090204@nlnetlabs.nl> <20120913155623.GD89509@mx1.yitter.info> Message-ID: <554E4B49-F60F-4B2B-9A37-BEFBFC5F5311@vpnc.org> On Sep 13, 2012, at 8:56 AM, Andrew Sullivan wrote: > On Thu, Sep 13, 2012 at 04:51:07PM +0200, W.C.A. Wijngaards wrote: > >> With RFC6725 the DNSSEC algorithm RSAMD5 has gotten status DEPRECATED >> (it used to have status NOT RECOMMENDED from RFC4034 and before). > > You know, in all the back and forth over that document during the > incredible length of time it took to publish, as far as I recall > nobody ever asked what "deprecated" meant in the context. I'm pretty sure we did. > You'd think > one of our eagle-eyed observers would have asked whether "deprecated" > meant "don't use this for signing" or "don't use this for validating" > or both. Sigh. ...and that was the basis of the discussion. There were enough people who said "if software can't validate X, no one will sign with it". This was also linked to the DNSEXT WG's (terrible, in my mind) decision to put GOST on standards track, so that developers felt a need to include it in their validating code. >> We want to publish Unbound with a codechange, so that the MD5 signed >> zones are treated as unsigned: the MD5 algorithm is not used for >> security, but the domains are still accessible (but insecurely so). > > In principle, it seems to me that it would be better to work on the > signing and publishing side first. That is, the tools for signing > should simply refuse to sign using RSAMD5, the serving zones ought to > need special configuration to serve RSAMD5-signed zones, and so on. > Once those changes are widely deployed, then it would be time to > change the validators. But given the circumstances . . . Yes, those circumstances. If nearly no one is actually signing with RSAMD5 today, this is probably as good of a time as any to say "we'll kill it off by having significant software not validating". For those who care about the cryptography: the next thing up will be to deprecate validation of 768-bit RSA keys. Unlike the preimage strength of MD5 (which is still unchallenged), the actual key strength of RSA768 is known to be going down every year, and will go down *faster* over time due to better factorization methods. Then we'll go after RSA1204 some years later. --Paul Hoffman From casey at deccio.net Thu Sep 13 12:48:25 2012 From: casey at deccio.net (Casey Deccio) Date: Thu, 13 Sep 2012 09:48:25 -0700 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 In-Reply-To: <5051F2DB.7090204@nlnetlabs.nl> References: <5051F2DB.7090204@nlnetlabs.nl> Message-ID: On Thu, Sep 13, 2012 at 7:51 AM, W.C.A. Wijngaards wrote: > Are there still people using RSAMD5 for signing their zones? If so, > when do you plan to move away from it? FWIW, DNSViz sees the following zones that use RSAMD5: sandelman.ottawa.on.ca sandelman.ca rp.secret-wg.org ll.mit.edu nettools.fr Although, they largely look abandoned, and only rp.secret-wg.org has a chain to the root. Casey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20120913/f992a83a/attachment.html From paul.hoffman at vpnc.org Thu Sep 13 13:19:38 2012 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Thu, 13 Sep 2012 10:19:38 -0700 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 In-Reply-To: References: <5051F2DB.7090204@nlnetlabs.nl> Message-ID: On Sep 13, 2012, at 9:48 AM, Casey Deccio wrote: > FWIW, DNSViz sees the following zones that use RSAMD5: > > sandelman.ottawa.on.ca > sandelman.ca > rp.secret-wg.org Those three keys are probably there as jokes or for experimentation. (IETFers on this will will recognize Michael Richardson for the first two and Olaf Kolkman for the third.) --Paul Hoffman From richard.lamb at icann.org Thu Sep 13 13:20:02 2012 From: richard.lamb at icann.org (Richard Lamb) Date: Thu, 13 Sep 2012 10:20:02 -0700 Subject: [Dnssec-deployment] .HN Zone to go Invalid during Transition In-Reply-To: <20120913140114.GG28513@macbook.bluepipe.net> References: <7C1BFAEB-138C-4269-84E5-9B17E2FB8FA6@afilias.info> <20120913140114.GG28513@macbook.bluepipe.net> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F34186BA37AD6A9@EXVPMBX100-1.exc.icann.org> This one of those things small minds like mine often contemplate. If I had the logic, mathematical, or number theory capacity that most of my colleagues have, this ought to be trivial but you know what they say: "those that cant - do. Those that cant do - teach" - oops - sorry Phil, you are of course the exception. At least you don't teach PE. ;-) I may be completely wrong but here is my personal stab at an operator change: AO=acquiring operator, RO=relinquishing operator, NSR,DSR,KR,ZA=NS/DS/KSK/ZSK for RO NSA,DSA,KA,ZA=NS/DS/KSK/ZSK for AO and (x)y is x signed by key y AO: makes a zone that is copy of the current zone (serial unchanged) except DNSKEY RRset=(KA,ZR,ZA)KA and NS RRset=(NSR,NSA)ZA. Publish on NSA. Admin: Request parent to add DSA to list - wont validate but existing validatable path to DSR should be ok. RO: makes a zone with DNSKEY RRset=(KR,ZR,ZA)KR (and serial incremented) and publishes it on NSR. Twiddle thumbs wait for parent+cache RO: makes zone with NS RRset=(NSR,NSA)ZR (and serial incremented) and publishes. Admin: Request parent to add NSA to list. Twiddle thumbs wait for parent+cache AO: makes a zone with NS RRset=(NSA)ZA (and serial incremented past RO) and publishes on NSA. RO: stops serving zone. Admin: Request parent to remove NSR from list. Twiddle thumbs wait for parent+cache AO makes a zone with DNSKEY RRset=(KA,ZA)KA (and serial incremented) and publishes Admin: Request parent to remove DSR from list. Twiddle thumbs wait for parent+cache DONE Now let me go try it on something.... I know there is most likely a way to interact with the parent less and it is too bad Peter's draft expired as I do think guidance on operator rollover with DNSSEC is needed. -Rick -----Original Message----- From: dnssec-deployment-bounces at dnssec-deployment.org [mailto:dnssec-deployment-bounces at dnssec-deployment.org] On Behalf Of Phil Regnauld Sent: Thursday, September 13, 2012 7:01 AM To: Howard Eland Cc: DNSSEC deployment Subject: Re: [Dnssec-deployment] .HN Zone to go Invalid during Transition Howard Eland (heland) writes: > All, > > Honduras has begun the transition of registry service providers for > the .HN ccTLD from Afilias to CoCCA. The transition is scheduled to > be completed by the end of September, 2012. The Sponsoring > Organisation responsible for .HN has decided to take the .HN zone > invalid during the DNS migration. Currently, there is only a single > signed delegation in the .HN zone (and it's Afilias.HN), so the impact should be minimal. Do you mean the zone will be unvalidatable, or insecure ? > The note is just to provide forewarning when folks see that the .HN DS > record in the root has disappeared. If the DS is removed, it's just insecure, and not even afilias.hn should be affected. > We are unaware of the Sponsoring Organization's plans for DNSSEC in > the .HN zone following the transition. I'm not sure there is DNSSEC support in the CoCCA platform yet... Thanks for the heads up. Cheers, Phil From mcr at sandelman.ca Thu Sep 13 17:37:26 2012 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 13 Sep 2012 17:37:26 -0400 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 In-Reply-To: References: <5051F2DB.7090204@nlnetlabs.nl> Message-ID: <31406.1347572246@obiwan.sandelman.ca> >>>>> "Casey" == Casey Deccio writes: Casey> On Thu, Sep 13, 2012 at 7:51 AM, W.C.A. Wijngaards wrote: >> Are there still people using RSAMD5 for signing their zones? If so, >> when do you plan to move away from it? Casey> FWIW, DNSViz sees the following zones that use RSAMD5: Casey> sandelman.ottawa.on.ca Casey> sandelman.ca Yup. Also has exponent 3, I think. The machine which is the stealth primary for my zone, hasn't died so badly to make me replace it, but hasn't worked well enough for some time to permit me to upgrade the signing tools beyond bind 9.3.xyz-SOMEDATEIN2003. Then my zone was supposed to move to the Xelerance dnsX signing appliance, but various things got in the way of that happening.... oh yeah, the .ca folks didn't know how to take DS records, and then they did friends and family, and then that finished, and what's the point in fixing my zone if can't be trusted anyway... I was actually working again today on a VM with a clean install of dnssec-tools. If someone wants an empty debian squeeze VM with dnssec-tools installed, let me know. I have another zone, dasblinkenled.org, which was DNSSEC signed at some point. I could sign it again with RSAMD5, with a really long expiry time, and just leave it online as a test... (or a subzone would work as well, I guess) -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From olaf at NLnetLabs.nl Fri Sep 14 03:05:26 2012 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Fri, 14 Sep 2012 09:05:26 +0200 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 In-Reply-To: References: <5051F2DB.7090204@nlnetlabs.nl> Message-ID: <748D5DB6-5B67-40E8-9FAC-0E29A3BC12C3@NLnetLabs.nl> On Sep 13, 2012, at 6:48 PM, Casey Deccio wrote: > Although, they largely look abandoned, and only rp.secret-wg.org has a chain to the root. Oh.. help... That is the domain that serves the BSRPDNSC ( https://bert.secret-wg.org/Tools/index.html#Tool_3 ) If that is treated as insecure we will not be able to trust any calculation.... --Olaf PS. Pedantic nit ;-) : 'look largely abandoned', if your assumption is that the service offered is WWW. In this case the service offered is an application on top of DNS. NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf at NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20120914/29b64ae8/attachment-0001.html From pawal at blipp.com Fri Sep 14 04:52:23 2012 From: pawal at blipp.com (=?iso-8859-1?Q?Patrik_Wallstr=F6m?=) Date: Fri, 14 Sep 2012 10:52:23 +0200 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 In-Reply-To: <5051F2DB.7090204@nlnetlabs.nl> References: <5051F2DB.7090204@nlnetlabs.nl> Message-ID: <57BCC628-7BAF-4FF0-BC4E-FEBF720A2E4B@blipp.com> On Sep 13, 2012, at 4:51 PM, W.C.A. Wijngaards wrote: > Hi, > > With RFC6725 the DNSSEC algorithm RSAMD5 has gotten status DEPRECATED > (it used to have status NOT RECOMMENDED from RFC4034 and before). > > We want to publish Unbound with a codechange, so that the MD5 signed > zones are treated as unsigned: the MD5 algorithm is not used for > security, but the domains are still accessible (but insecurely so). > > Are there still people using RSAMD5 for signing their zones? If so, > when do you plan to move away from it? Secspider saw 0 zones with RSAMD5. I have not seen any such keys in the .se zone either (and I look at all of them). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20120914/1881fa45/attachment.bin From dot at dotat.at Fri Sep 14 06:16:15 2012 From: dot at dotat.at (Tony Finch) Date: Fri, 14 Sep 2012 11:16:15 +0100 Subject: [Dnssec-deployment] .HN Zone to go Invalid during Transition In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F34186BA37AD6A9@EXVPMBX100-1.exc.icann.org> References: <7C1BFAEB-138C-4269-84E5-9B17E2FB8FA6@afilias.info> <20120913140114.GG28513@macbook.bluepipe.net> <41F6C547EA49EC46B4EE1EB2BC2F34186BA37AD6A9@EXVPMBX100-1.exc.icann.org> Message-ID: Richard Lamb wrote: > > I may be completely wrong but here is my personal stab at an operator > change: Almost but not completely right. > AO=acquiring operator, RO=relinquishing operator, > NSR,DSR,KR,ZA=NS/DS/KSK/ZSK for RO > NSA,DSA,KA,ZA=NS/DS/KSK/ZSK for AO > and (x)y is x signed by key y > > AO: makes a zone that is copy of the current zone (serial unchanged) > except DNSKEY RRset=(KA,ZR,ZA)KA and NS RRset=(NSR,NSA)ZA. Publish on > NSA. > > Admin: Request parent to add DSA to list - wont validate but existing > validatable path to DSR should be ok. > > RO: makes a zone with DNSKEY RRset=(KR,ZR,ZA)KR (and serial incremented) > and publishes it on NSR. > > Twiddle thumbs wait for parent+cache > > RO: makes zone with NS RRset=(NSR,NSA)ZR (and serial incremented) and publishes. > > Admin: Request parent to add NSA to list. (*) > Twiddle thumbs wait for parent+cache > > AO: makes a zone with NS RRset=(NSA)ZA (and serial incremented past RO) and publishes on NSA. > > RO: stops serving zone. This is too early. Clients will still have cached the NS RRsets containing NSR. You can in fact cut straight over to the NSA RRset at point (*). If you do that, then at this point all your clients should be on the new operator with the new keys, so you can delete all of the old setup without further waiting. > Admin: Request parent to remove NSR from list. > > Twiddle thumbs wait for parent+cache > > AO makes a zone with DNSKEY RRset=(KA,ZA)KA (and serial incremented) and publishes > > Admin: Request parent to remove DSR from list. > > Twiddle thumbs wait for parent+cache > > DONE Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From Ed.Lewis at neustar.biz Fri Sep 14 09:04:29 2012 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 14 Sep 2012 09:04:29 -0400 Subject: [Dnssec-deployment] Exponent 3 - was Re: Stop validation ... In-Reply-To: <31406.1347572246@obiwan.sandelman.ca> References: <5051F2DB.7090204@nlnetlabs.nl> <31406.1347572246@obiwan.sandelman.ca> Message-ID: At 17:37 -0400 9/13/12, Michael Richardson wrote: >Yup. Also has exponent 3, I think. From what I understand, exponent 3 is no longer, um, "diseased." (Saying this assuming the above comment is written as sort of an apology for using 3). I mention this to elicit more crypto-competent people to comment. Where I get that notion is http://www.imperialviolet.org/2012/03/16/rsae.html and http://www.imperialviolet.org/2012/03/17/rsados.html. That exponent (3) is used in some high profile zones. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From thierry.moreau at connotech.com Fri Sep 14 09:55:34 2012 From: thierry.moreau at connotech.com (Thierry Moreau) Date: Fri, 14 Sep 2012 09:55:34 -0400 Subject: [Dnssec-deployment] Exponent 3 - was Re: Stop validation ... In-Reply-To: References: <5051F2DB.7090204@nlnetlabs.nl> <31406.1347572246@obiwan.sandelman.ca> Message-ID: <50533756.8050002@connotech.com> Edward Lewis wrote: > At 17:37 -0400 9/13/12, Michael Richardson wrote: > >> Yup. Also has exponent 3, I think. > > From what I understand, exponent 3 is no longer, um, "diseased." > (Saying this assuming the above comment is written as sort of an apology > for using 3). > Indeed. For the record, it was a signature verification software flaw (incomplete validation of prefix padding in the recovered cleartext) that allowed malignant party to attempt signature forgeries for principals signing with public exponent 3. Such attempts were unsuccessful with well-coded verification software (at relying parties). Presumably old flawed verification software is seldom in use today. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 From casey at deccio.net Fri Sep 14 12:05:51 2012 From: casey at deccio.net (Casey Deccio) Date: Fri, 14 Sep 2012 09:05:51 -0700 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 In-Reply-To: <748D5DB6-5B67-40E8-9FAC-0E29A3BC12C3@NLnetLabs.nl> References: <5051F2DB.7090204@nlnetlabs.nl> <748D5DB6-5B67-40E8-9FAC-0E29A3BC12C3@NLnetLabs.nl> Message-ID: On Fri, Sep 14, 2012 at 12:05 AM, Olaf Kolkman wrote: > > PS. Pedantic nit ;-) : 'look largely abandoned', if your assumption is > that the service offered is WWW. In this case the service offered is an > application on top of DNS. > > Poor choice of words on my part :) What I meant to say was that only two offered "current" (not expired) signatures, and only one had a DS in its parent, which led to a chain to the root. The "abandonment" referred to the lack of DNSSEC maintenance (of some), not the lack of use :) Anyway... Casey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20120914/fb0fceaa/attachment.html From mstjohns at comcast.net Sat Sep 15 00:34:39 2012 From: mstjohns at comcast.net (Michael StJohns) Date: Sat, 15 Sep 2012 00:34:39 -0400 Subject: [Dnssec-deployment] Exponent 3 - was Re: Stop validation ... In-Reply-To: References: <5051F2DB.7090204@nlnetlabs.nl> <31406.1347572246@obiwan.sandelman.ca> Message-ID: <20120915043543.68FB2140089@resources.rdi.tislabs.com> At 09:04 AM 9/14/2012, Edward Lewis wrote: >At 17:37 -0400 9/13/12, Michael Richardson wrote: > >>Yup. Also has exponent 3, I think. > > From what I understand, exponent 3 is no longer, um, "diseased." (Saying this assuming the above comment is written as sort of an apology for using 3). > >I mention this to elicit more crypto-competent people to comment. > >Where I get that notion is http://www.imperialviolet.org/2012/03/16/rsae.html and http://www.imperialviolet.org/2012/03/17/rsados.html. > >That exponent (3) is used in some high profile zones. NIST SP800-56B sets a minimum value of 65537 on the public exponent. Not saying that DNSSEC is required to follow that guidance, but in the US at least that guidance tends to be viewed as the minimum best commercial practice. Mike >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis >NeuStar You can leave a voice message at +1-571-434-5468 > >2012...time to reuse those 1984 calendars! From regnauld at nsrc.org Sun Sep 16 09:49:53 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Sun, 16 Sep 2012 15:49:53 +0200 Subject: [Dnssec-deployment] Possible .DK PMTU issues with b.nic.dk in v6 ? Message-ID: <20120916134953.GD61326@macbook.bluepipe.net> I've been experiencing some transient resolution problems here at home with native v6, on some of the DK domains, where BIND will return SERVFAIL, and a subsequent query will resolve correctly (sorry, have to turn on more dnssec debugging to see what BIND is complaining about). DNZviz complains that there are PMTU issues with one of the .DK servers, namely b.nic.dk (2a01:630:0:80::53 / 193.163.102.222). It also complains about an NSEC3 record missing for those domains. In fact, it will complain about NSEC3 for any domain with no DS in .DK. Could be an issue in the way DNSviz handles opt-out ? dnssec-trigger (unbound) on my Mac, on the same network, will return a SERVFAIL for those domains as well, as it's automatically using the BIND resolver on my network as a forwarder, but it doesn't recover. I have to unbound-control flush_zone [domain_name] followed by a killall mDNSresponder. [Yeah, it's more of a dnsops q, but since there may be a DNSSEC issue (or not) with .DK, I thought it was appropriate to post here...] Cheers, Phil From fw at deneb.enyo.de Sun Sep 16 14:54:43 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 16 Sep 2012 20:54:43 +0200 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 In-Reply-To: <20120913155623.GD89509@mx1.yitter.info> (Andrew Sullivan's message of "Thu, 13 Sep 2012 11:56:23 -0400") References: <5051F2DB.7090204@nlnetlabs.nl> <20120913155623.GD89509@mx1.yitter.info> Message-ID: <87d31lg5n0.fsf@mid.deneb.enyo.de> * Andrew Sullivan: > On Thu, Sep 13, 2012 at 04:51:07PM +0200, W.C.A. Wijngaards wrote: > >> With RFC6725 the DNSSEC algorithm RSAMD5 has gotten status DEPRECATED >> (it used to have status NOT RECOMMENDED from RFC4034 and before). > > You know, in all the back and forth over that document during the > incredible length of time it took to publish, as far as I recall > nobody ever asked what "deprecated" meant in the context. You'd think > one of our eagle-eyed observers would have asked whether "deprecated" > meant "don't use this for signing" or "don't use this for validating" > or both. Sigh. Ambiguity hides conflict. I'm pretty sure no document would have been published if it had clear language. From fw at deneb.enyo.de Sun Sep 16 15:07:05 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 16 Sep 2012 21:07:05 +0200 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 In-Reply-To: <5051F2DB.7090204@nlnetlabs.nl> (W. C. A. Wijngaards's message of "Thu, 13 Sep 2012 16:51:07 +0200") References: <5051F2DB.7090204@nlnetlabs.nl> Message-ID: <878vc9g52e.fsf@mid.deneb.enyo.de> * W. C. A. Wijngaards: > There is an argument that there is no evidence of weakness of MD5 for > DNSSEC (but there is for other MD5 usage), and we should keep md5 > support enabled, but perhaps have an option. I'm pretty sure the collision attack that tricked a commercial CA into signing a certificate with a meaningful twin could be adapted to a zone operator who just signs delegations, especially of the zone operator doesn't ask for DNSKEYs, only for DS RRs, and does not validate their contents. It seems to me that one particular challenge in the original collision attack (it took a non-trivial amount of time to compute the evil twins, and you had to decide on the serial number you want right from the start) wouldn't even come into play with DNSSEC. Or the short version: MD5 hashing is always insecure if you hash other people's data, unless you hash some non-predictable data you've generated yourself before you hash their data (that is, randomized hashing). DNSSEC uses MD5 in a non-randomized fashion, and signatures on delegations typically cross trust boundaries, so using MD5 for DNSSEC is insecure. From mysidia at gmail.com Sun Sep 16 15:15:59 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 16 Sep 2012 14:15:59 -0500 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 In-Reply-To: <5051F2DB.7090204@nlnetlabs.nl> References: <5051F2DB.7090204@nlnetlabs.nl> Message-ID: On 9/13/12, W.C.A. Wijngaards wrote: > Hi, > With RFC6725 the DNSSEC algorithm RSAMD5 has gotten status DEPRECATED > (it used to have status NOT RECOMMENDED from RFC4034 and before). So they changed the wording, from we recommend you use something other than RSAMD5, TO... a status indicating it has been superceded. There is no proven weakness in RSAMD5 RR signing, they are being cautious in preemptively recommending that organizations who start to sign their zones, should choose signing keys of a format using hashing algorithms that have no known weaknesses, they should pick from hash algorithms that are the current best ones available for strong security, those who are already using RSAMD5 signing may continue to use it, although DEPRECATED suggests they should be planning to transition away from it, within a few years. Specifically, they should move to RSA SHA-2. Because before too many years, SHA1 is likely to be in not recommended status as well. It sounds like a change from unusual wording to conventional wording to me, I see little/no difference between "NOT RECOMMENDED" and "DEPRECATED" in this context. [snip] > Are there still people using RSAMD5 for signing their zones? If so, > when do you plan to move away from it? Secspider saw 0 zones with RSAMD5. There might be... They should plan to move away from RSAMD5, because there are better choices of key types to sign your zones with. > There is an argument that there is no evidence of weakness of MD5 for > DNSSEC (but there is for other MD5 usage), and we should keep md5 > support enabled, but perhaps have an option. But this goes against > the RFC. It's the generation of RSA/MD5 SIG RRs that is not recommended. The recommendation is not that resolvers fail to accept or verify RSA/MD5 SIG RRs. There is no requirement to artificially reduce the security of SHAMD5, by ignoring the signature. > Are there considerations that we have missed? We want to deploy the > new RFC standards action, but we do not want unilateral actions. > Best regards, > Wouter -- -JH From mysidia at gmail.com Sun Sep 16 15:36:33 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 16 Sep 2012 14:36:33 -0500 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 In-Reply-To: <878vc9g52e.fsf@mid.deneb.enyo.de> References: <5051F2DB.7090204@nlnetlabs.nl> <878vc9g52e.fsf@mid.deneb.enyo.de> Message-ID: On 9/16/12, Florian Weimer wrote: [snip] > Or the short version: MD5 hashing is always insecure if you hash other > people's data, unless you hash some non-predictable data you've > generated yourself before you hash their data (that is, randomized "Always" has not been shown. MD5 is sometimes insecure if you hash other people's data. Specifically: there is a chance they could construct malicious data for you to sign, that they would be able to append to without changing the MD5 hash. However, the premise is that you have signed untrusted malicious data..... In the case of DNSSEC. You aren't supposed to sign a zone containing a RR that is not legitimate. Do you normally sign an untrusted record... And.... it would seem the risk of that particular exploit would be limited, to the possibility of appending data to the end of the malicious RR. You may very well be able to construct some theoretical attacks, that have no impliciations or concerns whatsoever that actually matter for real-world use of DNSSEC. > hashing). DNSSEC uses MD5 in a non-randomized fashion, and signatures > on delegations typically cross trust boundaries, so using MD5 for > DNSSEC is insecure. > -- -JH From dot at dotat.at Sun Sep 16 15:37:14 2012 From: dot at dotat.at (Tony Finch) Date: Sun, 16 Sep 2012 20:37:14 +0100 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 In-Reply-To: <878vc9g52e.fsf@mid.deneb.enyo.de> References: <5051F2DB.7090204@nlnetlabs.nl> <878vc9g52e.fsf@mid.deneb.enyo.de> Message-ID: Florian Weimer wrote: > > I'm pretty sure the collision attack that tricked a commercial CA into > signing a certificate with a meaningful twin could be adapted to a > zone operator who just signs delegations, especially of the zone > operator doesn't ask for DNSKEYs, only for DS RRs, and does not > validate their contents. But you can't use MD5 for DS RRs. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From fw at deneb.enyo.de Sun Sep 16 15:44:38 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 16 Sep 2012 21:44:38 +0200 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 In-Reply-To: (Tony Finch's message of "Sun, 16 Sep 2012 20:37:14 +0100") References: <5051F2DB.7090204@nlnetlabs.nl> <878vc9g52e.fsf@mid.deneb.enyo.de> Message-ID: <87y5k9eord.fsf@mid.deneb.enyo.de> * Tony Finch: > Florian Weimer wrote: >> >> I'm pretty sure the collision attack that tricked a commercial CA into >> signing a certificate with a meaningful twin could be adapted to a >> zone operator who just signs delegations, especially of the zone >> operator doesn't ask for DNSKEYs, only for DS RRs, and does not >> validate their contents. > > But you can't use MD5 for DS RRs. A collision in the DS hash wouldn't help you anyway because the RRSIG in the parent zone covers another instance of the zone name. The interesting target is the RRSIG RRset on the DS RRset in the parent zone. From fw at deneb.enyo.de Sun Sep 16 15:46:21 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 16 Sep 2012 21:46:21 +0200 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 In-Reply-To: (Jimmy Hess's message of "Sun, 16 Sep 2012 14:36:33 -0500") References: <5051F2DB.7090204@nlnetlabs.nl> <878vc9g52e.fsf@mid.deneb.enyo.de> Message-ID: <87r4q1eooi.fsf@mid.deneb.enyo.de> * Jimmy Hess: > However, the premise is that you have signed untrusted malicious data..... > In the case of DNSSEC. You aren't supposed to sign a zone > containing a RR that is not legitimate. > > Do you normally sign an untrusted record... TLD operators do this all the time (for "untrusted" in the sense that they don't know how the delegated domain is going to be used). From mysidia at gmail.com Sun Sep 16 16:20:18 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 16 Sep 2012 15:20:18 -0500 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 In-Reply-To: <87r4q1eooi.fsf@mid.deneb.enyo.de> References: <5051F2DB.7090204@nlnetlabs.nl> <878vc9g52e.fsf@mid.deneb.enyo.de> <87r4q1eooi.fsf@mid.deneb.enyo.de> Message-ID: On 9/16/12, Florian Weimer wrote: > TLD operators do this all the time (for "untrusted" in the sense that > they don't know how the delegated domain is going to be used). That's true, but NS, A, DS records signed by TLD operators have a specific format, arbitrary bits cannot be appended, and the TLD operator has to verify the data submitted to them is well formed and the submitter is authorized to submit these changes; E.g. A records contain a specified number of bits, and NS records contain nameserver names in a specified format, which have to already be registered; arbitrary data cannot be appended to RRs that have a specified length. In addition, if the trust relationship between the TLD and the legitimate domain holder is so compromised that attack data for the domain in the DS RRs submitted by an attacker can be signed, the security of the domain has been broken, regardless of what hashing algorithm is used. IN that case, There are much simpler attacks that can easily be imagined, attacks, which are a lot easier to execute, specifically: sending key material that is false. and nameserver A records or NS names that are just false, and point to servers controlled by the attacker. -- -JH From fw at deneb.enyo.de Sun Sep 16 16:33:03 2012 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 16 Sep 2012 22:33:03 +0200 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 In-Reply-To: (Jimmy Hess's message of "Sun, 16 Sep 2012 15:20:18 -0500") References: <5051F2DB.7090204@nlnetlabs.nl> <878vc9g52e.fsf@mid.deneb.enyo.de> <87r4q1eooi.fsf@mid.deneb.enyo.de> Message-ID: <87d31lemio.fsf@mid.deneb.enyo.de> * Jimmy Hess: > On 9/16/12, Florian Weimer wrote: > >> TLD operators do this all the time (for "untrusted" in the sense that >> they don't know how the delegated domain is going to be used). > > That's true, but NS, A, DS records signed by TLD operators have a > specific format, arbitrary bits cannot be appended, Most TLDs sign only DS RRsets. DS RRs contain binary blobs, and if the TLD doesn't restrict the list of DS algorithms, the blobs can be quite large, and the TLD will not always be able to interpret them and check them against DNSKEY RRs somewhere. From mysidia at gmail.com Sun Sep 16 17:48:56 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 16 Sep 2012 16:48:56 -0500 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 In-Reply-To: <87d31lemio.fsf@mid.deneb.enyo.de> References: <5051F2DB.7090204@nlnetlabs.nl> <878vc9g52e.fsf@mid.deneb.enyo.de> <87r4q1eooi.fsf@mid.deneb.enyo.de> <87d31lemio.fsf@mid.deneb.enyo.de> Message-ID: On 9/16/12, Florian Weimer wrote: > Most TLDs sign only DS RRsets. DS RRs contain binary blobs, and if > the TLD doesn't restrict the list of DS algorithms, the blobs can be > quite large, and the TLD will not always be able to interpret them and > check them against DNSKEY RRs somewhere. While that is true.. the contents of the DS RR that should be signed is trusted data; if the data was inauthentic, and the registrar cannot verify it was authentic, then security was already compromised, because the TLD was signing inauthentic data; based on the assumption it has to be inauthentic before it can be an attack... Which TLD is using a RSAMD5 key type to sign DS RRs, anyways? -- -JH From pk at ISOC.DE Mon Sep 17 07:46:22 2012 From: pk at ISOC.DE (Peter Koch) Date: Mon, 17 Sep 2012 13:46:22 +0200 Subject: [Dnssec-deployment] .HN Zone to go Invalid during Transition In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F34186BA37AD6A9@EXVPMBX100-1.exc.icann.org> References: <7C1BFAEB-138C-4269-84E5-9B17E2FB8FA6@afilias.info> <20120913140114.GG28513@macbook.bluepipe.net> <41F6C547EA49EC46B4EE1EB2BC2F34186BA37AD6A9@EXVPMBX100-1.exc.icann.org> Message-ID: <20120917114622.GZ7055@x28.adm.denic.de> On Thu, Sep 13, 2012 at 10:20:02AM -0700, Richard Lamb wrote: > I know there is most likely a way to interact with the parent less and it is too bad Peter's draft expired as I do think guidance on operator rollover with DNSSEC is needed. thanks, publishing an updated -05 with the implementation feedback folded in is indeed the plan. -Peter From Ed.Lewis at neustar.biz Mon Sep 17 09:34:46 2012 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 17 Sep 2012 09:34:46 -0400 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 In-Reply-To: References: <5051F2DB.7090204@nlnetlabs.nl> <878vc9g52e.fsf@mid.deneb.enyo.de> Message-ID: At 14:36 -0500 9/16/12, Jimmy Hess wrote: >Do you normally sign an untrusted record... The first sentence in RFC 4033's abstract: # The Domain Name System Security Extensions (DNSSEC) add data origin # authentication and data integrity to the Domain Name System. That means a cache can validate that received data arrived from an authoritative source unmolested - even if the delivery was indirect (via other caches, forwarders). Correctness and thus the "trustworthiness" of the data is not guaranteed. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From wouter at nlnetlabs.nl Mon Sep 17 09:56:49 2012 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Mon, 17 Sep 2012 15:56:49 +0200 Subject: [Dnssec-deployment] Stop validation support for RSAMD5 In-Reply-To: References: <5051F2DB.7090204@nlnetlabs.nl> <878vc9g52e.fsf@mid.deneb.enyo.de> Message-ID: <50572C21.6090708@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 09/17/2012 03:34 PM, Edward Lewis wrote: > At 14:36 -0500 9/16/12, Jimmy Hess wrote: >> Do you normally sign an untrusted record... > That means a cache can validate that received data arrived from an > authoritative source unmolested - even if the delivery was indirect > (via other caches, forwarders). > > Correctness and thus the "trustworthiness" of the data is not > guaranteed. I have decided to make it a source code patch. This is sufficiently difficult, but still reachable. The default is disabled, the patch enables MD5 usage (unconditionally, better not have FIPS mode). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQVywhAAoJEJ9vHC1+BF+NXusP/2GA73l9Tv2RA9I9sX0r1Yf5 NhrE+a2mSZqSwJat1exoZrwRXyyePdrX14y8RJ53mSiDgCGyvMk2VqwVuo0PaIVz ktuGnKYOqPZvc5vv5DIly3ajUplykKOikfMbh16R4AKGAqfz7mBppXKTf7WrmMcS U5VKOF0e9PtZstxPD25H9nGt+7k2otIxTxHqzaZ39OrNXiMyBNTpSckHSCVemINK sQD2dJ5snwdHT1T/p62szgHokC814LNwPbqnpIejNm89xVQI5Cv5xb8DCqpixNAv jt/Hcby+qnxMYQY5XPaf5g7ekL2VnuBoZMkSrS5A4+WadrSa5QxBYbCv8GnSO88B h0vKg7Lt/NFveDIJF4Fw6GDcPhDTRs0K/DZr9LZZ/P9QY0XEDK2aSAp5fTttqPd2 eJop8cCHN567rnuozLil/U7MWxSODDqYJd25ouotI2Go3Vl/WE32RhbkiH3+OkkR kMy1dwwBKYZV9OE6rwBe9OBd6XAzlGmkHEGru8vi15WHfoAzmrRVX6sMABMwL1yW D7KO0ChWZPlknTJDucT2yM1/uK4MVuvpI8j/LUPwE/VGrtpeaeqWLkhERsQ9Pd+O WvnFaLIs4IZcMNvnRTgpTO7yNHoSWSMYqDw8T6tvClP7kwrd1XEjXJnLGkHFjiwV qpRcZmOrXpq+gJf0dJc3 =hxcG -----END PGP SIGNATURE----- From casey at deccio.net Mon Sep 17 11:34:12 2012 From: casey at deccio.net (Casey Deccio) Date: Mon, 17 Sep 2012 08:34:12 -0700 Subject: [Dnssec-deployment] Possible .DK PMTU issues with b.nic.dk in v6 ? In-Reply-To: <20120916134953.GD61326@macbook.bluepipe.net> References: <20120916134953.GD61326@macbook.bluepipe.net> Message-ID: On Sun, Sep 16, 2012 at 6:49 AM, Phil Regnauld wrote: > DNZviz complains that there are PMTU issues with one of the .DK servers, > namely b.nic.dk (2a01:630:0:80::53 / 193.163.102.222). It also complains > about an NSEC3 record missing for those domains. In fact, it will complain > about NSEC3 for any domain with no DS in .DK. Could be an issue in the > way DNSviz handles opt-out ? > > This is the most recent DNSViz output for .dk which shows PMTU issues (max payload between 879 and 1458 bytes) for responses from 2a01:630:0:80::53. It also shows that servers 192.38.7.242 and 2001:7f8:1f::1835:242:0 aren't returning NSEC3 RRs with negative responses: http://dnsviz.net/d/dk/UFafmQ/dnssec/?rr=all&a=all&ds=all&doe=on&ta=.&ta=dlv.isc.org.&tk= The first I see of the NSEC3 issue is last month: http://dnsviz.net/d/dk/UCrXpg/dnssec/?rr=all&a=all&ds=all&doe=on&ta=.&ta=dlv.isc.org.&tk= It looks like this was introduced at the same time as the addition of the IPv6 interface to l.nic.dk: http://dnsviz.net/d/dk/UCrpMg/servers/ PMTU issues only show up on DNSViz when DNSKEY responses are large enough to be affected. With .dk they've appeared on and off, depending on DNSKEY RRset size, but I've seen them with 2a01:630:0:80::53 as early as Oct 2011, shortly after I added IPv6 support: http://dnsviz.net/d/dk/TptJyg/dnssec/ Regards, Casey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20120917/fe82f4b1/attachment.html From julie.hedlund at icann.org Wed Sep 19 11:41:52 2012 From: julie.hedlund at icann.org (Julie Hedlund) Date: Wed, 19 Sep 2012 08:41:52 -0700 Subject: [Dnssec-deployment] Invitation: Informal Gathering of DNSSEC Implementers in Toronto, 15 October 2012 Message-ID: Invitation to Informal Gathering of DNSSEC Implementers in Toronto, 15 October 2012 On behalf of the DNSSEC Deployment Initiative and CIRA, DNSSEC Implementers are invited to attend an informal gathering to discuss and exchange information on their DNSSEC implementation experiences during the ICANN meeting in Toronto, Canada. This is a unique opportunity to meet with and talk to key implementers, such as CIRA, CZNIC, Nominet UK, SIDN, IIS Sweden, and others. We do ask that in order to participate you should come prepared to say a few words about your experiences. This is a peer-to-peer event for implementers. When: Monday, October 15th, 7:00 to 9:00 pm Where: The Fox, 35 Bay Street, Toronto, ON M5J 3B2 http://www.foxonbay.ca/ Note that this event is in addition to the other DNSSEC events scheduled during the ICANN meeting. These are: Monday, 15 October, 5:15-6:30 pm, DNSSEC for Everybody Wednesday, 17 October: 8:30 am to 2:45 pm -- DNSSEC Workshop at ICANN Meeting ** Please RSVP to dnssec-toronto at shinkuro.com no later than Monday, 08 October if you would like to attend.** Best regards, Julie Hedlund On behalf of Jacques Latour, CIRA, and Steve Crocker and Russ Mundy for the DNSSEC Deployment Initiative -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20120919/0f8f7444/attachment.html From DOUGANLA at gru.com Fri Sep 21 10:00:32 2012 From: DOUGANLA at gru.com (Dougan, Linda A) Date: Fri, 21 Sep 2012 10:00:32 -0400 Subject: [Dnssec-deployment] DNSSEC Not Working for All Subdomains Message-ID: After setting up pdns for DNSSEC, it does not create the order name and auth in the records table for all of the subdomains, just some. I tried adding them myself but it still does not create the DNSSEC output as the others do. Any idea why it might be doing this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20120921/9c62e840/attachment.html From bert.hubert at netherlabs.nl Fri Sep 21 10:05:25 2012 From: bert.hubert at netherlabs.nl (bert hubert) Date: Fri, 21 Sep 2012 16:05:25 +0200 Subject: [Dnssec-deployment] DNSSEC Not Working for All Subdomains In-Reply-To: References: Message-ID: <20120921140525.GC2226@xs.powerdns.com> Hi Linda, Can I invite you to join the PowerDNS mailing list? They can be found through http://wiki.powerdns.com/trac/wiki/MailingLists and they have the highest concentration of PowerDNS & DNSSEC knowledgeable people. (in short, you'll need to run pdnssec rectify-zone on your new domain names) Thanks! -- PowerDNS Website: http://www.powerdns.com/ PowerDNS Community Website: http://wiki.powerdns.com/ PowerDNS is supported and developed by Netherlabs: http://www.netherlabs.nl On Fri, Sep 21, 2012 at 10:00:32AM -0400, Dougan, Linda A wrote: > After setting up pdns for DNSSEC, it does not create the order name and > auth in the records table for all of the subdomains, just some. I tried > adding them myself but it still does not create the DNSSEC output as the > others do. Any idea why it might be doing this? From regnauld at nsrc.org Fri Sep 21 11:49:46 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Fri, 21 Sep 2012 17:49:46 +0200 Subject: [Dnssec-deployment] Possible .DK PMTU issues with b.nic.dk in v6 ? In-Reply-To: References: <20120916134953.GD61326@macbook.bluepipe.net> Message-ID: <20120921154946.GV2013@macbook.bluepipe.net> Casey Deccio (casey) writes: > > The first I see of the NSEC3 issue is last month: > > http://dnsviz.net/d/dk/UCrXpg/dnssec/?rr=all&a=all&ds=all&doe=on&ta=.&ta=dlv.isc.org.&tk= I have notified some folks at DK-H. This issue should be now resolved, I have been told.