From lutz at iks-jena.de Wed Jan 2 05:36:42 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 2 Jan 2008 11:36:42 +0100 Subject: Mal ein paar DNSSEC Statistiken / Some DNSSEC statistics References: Message-ID: [This message has also been posted to de.comp.security.misc,de.org.ccc,comp.security.misc.] Overview of 11647 signed zones: 1495 -1 Entry Point 9618 Test 6 +1 broken chain 453 +13 chained 0 new 75 -22 unreachable Top 10 autonomous systems injecting DNSSec zones: 720 -13 AS25537 456 AS15725 136 +136 AS1280 81 AS22548 78 AS3333 71 -1 AS3245 46 +1 AS24776 32 AS3265 29 AS39570 21 AS36810 Top 10 TLD containing DNSSec zones: 720 -13 RU 288 +3 ARPA 234 +1 DE 161 +2 COM 121 -1 ORG 100 +1 BR 84 SE 70 -1 BG 53 NET 37 -1 FR 872 (+1) weak keys: Top 10 autonomous systems injecting weak keys: 690 +1 AS25537 42 -3 AS24776 18 AS3216 15 AS8228 10 +1 AS29632 8 AS20943 4 AS1103 4 AS29344 4 AS12859 3 AS2119 6 (+1) broken DS chains: 228.111.193.in-addr.arpa, sparta.dnsops.biz, llnl.dnsops.gov, bitstring.se dyn.niconet.se, tgfslp.dalmany.co.uk 27 (-4) parent DS to unsigned zones: 0.20.149.in-addr.arpa, 64.20.149.in-addr.arpa, 157.110.193.in-addr.arpa 178.170.195.in-addr.arpa, 128.111.89.in-addr.arpa, 129.111.89.in-addr.arpa 130.111.89.in-addr.arpa, 131.111.89.in-addr.arpa, 132.111.89.in-addr.arpa 133.111.89.in-addr.arpa, 134.111.89.in-addr.arpa, 135.111.89.in-addr.arpa 136.111.89.in-addr.arpa, 137.111.89.in-addr.arpa, 138.111.89.in-addr.arpa 139.111.89.in-addr.arpa, 140.111.89.in-addr.arpa, blopp.se hogskolaniboras.se, klan-csa.se, kristianstadpower.se, lyrek.se, mirall.se nl-dnssectest.se, tshirttryck.se, webro.se, xn--botsmarksdck-pcb.se 33 (+2) unnecessary islands: 8.4.e164.arpa, 2.2.0.2.4.6.3.3.6.6.9.4.e164.arpa, 1.2.0.0.1.8.e164.arpa 64-26.0.149.193.in-addr.arpa, 0.68.193.in-addr.arpa, 42.32.198.in-addr.arpa 178.25.217.in-addr.arpa, 241.75.217.in-addr.arpa 4.2.0.0.1.6.0.1.0.0.2.ip6.arpa, 5.2.0.0.1.6.0.1.0.0.2.ip6.arpa 6.2.0.0.1.6.0.1.0.0.2.ip6.arpa, 7.2.0.0.1.6.0.1.0.0.2.ip6.arpa 7.f.3.0.8.3.8.0.1.0.0.2.ip6.arpa, e.8.1.c.8.0.3.0.1.0.a.2.ip6.arpa cerebrohidroponico.blog.br, digitaltv.blog.br, pixaco.com.br eficacia.eng.br, antd.nist.gov, rev.faelix.net, broken.jelte.nlnetlabs.nl sub.jelte.nlnetlabs.nl, ipv6.stack.nl, signed.dnssec-test.org dyn.johani.org, ddns.klubkev.org, autonomica.se, echo-lan.se, shinkuro.se skabb.se, staver.se, xn--lda-ula.xn--ihrn-dpa.se, zkt.se 75 (-22) unreachable zones: Top 10 autonomous systems containing unreachable zones: 30 -14 AS25537 12 AS5537 6 AS39570 4 +3 AS24776 2 +1 AS15725 1 AS22894 1 +1 AS9700 1 AS3265 1 AS39858 1 AS7132 -- Detailed list: https://www.iks-jena.de/leistungen/dnssec.php From lutz at iks-jena.de Wed Jan 2 05:38:18 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 2 Jan 2008 11:38:18 +0100 Subject: Mal ein paar DNSSEC Statistiken / Some DNSSEC statistics References: Message-ID: [This message has also been posted to de.comp.security.misc,de.org.ccc,comp.security.misc.] * Lutz Donnerhacke wrote: 10 autonomous systems injecting DNSSec zones: > 136 +136 AS1280 Simple reason: ISC changed their AS. From scottr at nist.gov Wed Jan 2 07:23:46 2008 From: scottr at nist.gov (Scott Rose) Date: Wed, 02 Jan 2008 07:23:46 -0500 Subject: [dnssec-deployment] Mal ein paar DNSSEC Statistiken / Some DNSSEC statistics In-Reply-To: References: Message-ID: <477B8252.4080204@nist.gov> Lutz Donnerhacke wrote: > > 6 (+1) broken DS chains: > 228.111.193.in-addr.arpa, sparta.dnsops.biz, llnl.dnsops.gov, bitstring.se > dyn.niconet.se, tgfslp.dalmany.co.uk > I think the sparta.dnsops.biz and llnl.dnsops.gov errors may be because I'm using SHA-256 DS RRs. Or else I didn't generate them correctly. I'll double check. > > 33 (+2) unnecessary islands: > antd.nist.gov, What a round about way of learning my parent zone is signed :) I think the nist.gov deployment is still a "test" deployment. No word on how subzones will link and upload DS/DNSKEY RRs yet. Normally we are in the loop more. Scott From jeroen at unfix.org Wed Jan 2 07:38:11 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 02 Jan 2008 13:38:11 +0100 Subject: [dnssec-deployment] Mal ein paar DNSSEC Statistiken / Some DNSSEC statistics In-Reply-To: References: Message-ID: <477B85B3.9000803@spaghetti.zurich.ibm.com> Lutz Donnerhacke wrote: [..] > Top 10 TLD containing DNSSec zones: > 720 -13 RU > 288 +3 ARPA > 234 +1 DE > 161 +2 COM > 121 -1 ORG > 100 +1 BR > 84 SE > 70 -1 BG > 53 NET > 37 -1 FR Why is .nl not listed here? Or do they only get listed when the tld itself is also signed? > 33 (+2) unnecessary islands: How do zones come into this category? And more importantly, how do they get out as they are 'unnecessary', it seems there should be a simple way. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20080102/e0075c6d/attachment.bin From lutz at iks-jena.de Wed Jan 2 07:53:12 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 2 Jan 2008 12:53:12 +0000 (UTC) Subject: [dnssec-deployment] Mal ein paar DNSSEC Statistiken / Some DNSSEC statistics References: Message-ID: * Scott Rose wrote: > Lutz Donnerhacke wrote: >> 6 (+1) broken DS chains: >> 228.111.193.in-addr.arpa, sparta.dnsops.biz, llnl.dnsops.gov, bitstring.se >> dyn.niconet.se, tgfslp.dalmany.co.uk > > I think the sparta.dnsops.biz and llnl.dnsops.gov errors may be because > I'm using SHA-256 DS RRs. Or else I didn't generate them correctly. > I'll double check. My fault. Sorry. I do not check for SHA-256, because I assumed a SHA fingerprint in parallel. I've to fix my script. >> 33 (+2) unnecessary islands: >> antd.nist.gov, > > What a round about way of learning my parent zone is signed :) Indeed. ;-) Happy new year. From lutz at iks-jena.de Wed Jan 2 08:03:59 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 2 Jan 2008 13:03:59 +0000 (UTC) Subject: [dnssec-deployment] Mal ein paar DNSSEC Statistiken / Some DNSSEC statistics References: Message-ID: * Jeroen Massar wrote: > Lutz Donnerhacke wrote: >> Top 10 TLD containing DNSSec zones: [...] >> 37 -1 FR > > Why is .nl not listed here? Because I found only the following 13 signed domains. This is not enough to be listed in the TOP 10. nlnetlabs.nl jelte.nlnetlabs.nl broken.jelte.nlnetlabs.nl sub.jelte.nlnetlabs.nl matje.nlnetlabs.nl openswan.nl pixaco.nl rodecker.nl stack.nl ipv6.stack.nl signed.telin.nl subsigned.signed.telin.nl xelerance.nl And I found 9590 signed domains for testing purposes only. >> 33 (+2) unnecessary islands: > > How do zones come into this category? And more importantly, how do they > get out as they are 'unnecessary', it seems there should be a simple way. All listed domain hostmasters got an email today: ------------------------------------------------------------- Hi, I'd like to inform you, that your DNSSEC setup seems to be improvable. The following domains are not linked from their parent zones. That means: The parent zone does not contains a DS entry, indicating a unsigned zone, but your zone is really signed. There is not an error! Your signed zone will just not checked on most validating resolvers. But you can enhance the DNSSEC benefits, by linking your signed zone from your parent zone. To link your signed zone, please add a DS entry to your parent zone. If your zone is not linked by purpose, please accept my excuse for sending this email. List of unlinked zones: $domains$ Lutz Donnerhacke ------------------------------------------------------------- From andrei at ripe.net Wed Jan 2 09:13:18 2008 From: andrei at ripe.net (Andrei Robachevsky) Date: Wed, 02 Jan 2008 15:13:18 +0100 Subject: [dnssec-deployment] Mal ein paar DNSSEC Statistiken / Some DNSSEC statistics In-Reply-To: References: Message-ID: <477B9BFE.1020800@ripe.net> Lutz Donnerhacke wrote on 02-01-2008 14:03: [...] >>> 33 (+2) unnecessary islands: >> How do zones come into this category? And more importantly, how do they >> get out as they are 'unnecessary', it seems there should be a simple way. > > All listed domain hostmasters got an email today: > ------------------------------------------------------------- > Hi, > > I'd like to inform you, that your DNSSEC setup seems to be improvable. The > following domains are not linked from their parent zones. That means: The > parent zone does not contains a DS entry, indicating a unsigned zone, but > your zone is really signed. > I'd like to note that while e164.arpa is indeed signed, we don't support secure delegations yet. That will happen on 25 March. But I guess the admins know that anyway. Andrei > There is not an error! Your signed zone will just not checked on most > validating resolvers. But you can enhance the DNSSEC benefits, by linking > your signed zone from your parent zone. > > To link your signed zone, please add a DS entry to your parent zone. > If your zone is not linked by purpose, please accept my excuse for sending > this email. > > List of unlinked zones: > $domains$ > > Lutz Donnerhacke > ------------------------------------------------------------- > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: > and older material is at > From jeroen at unfix.org Wed Jan 2 09:35:34 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 02 Jan 2008 15:35:34 +0100 Subject: [dnssec-deployment] Mal ein paar DNSSEC Statistiken / Some DNSSEC statistics In-Reply-To: References: Message-ID: <477BA136.1080005@spaghetti.zurich.ibm.com> Lutz Donnerhacke wrote: [..] > There is not an error! Your signed zone will just not checked on most > validating resolvers. But you can enhance the DNSSEC benefits, by linking > your signed zone from your parent zone. Which would require the parent zone to actually be able to do signing and also to link up to their parents and their parents, which in some cases is not possible.... Okay lets put in my new years resolution for this year: DNSSec sign&enable SixXS subnet (/48) delegations Note that I mention subnets, as signing the tunnel spaces is, due to the amount of space, nearly impossible. The above would at least a DLV to be inserted for a few zones and allow a lot of folks to have dnssec enabled reverses. First finish up some work though and the list gets longer and longer and longer for cool stuff to do :( Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20080102/6532e80c/attachment.bin From paul at xelerance.com Wed Jan 2 09:49:52 2008 From: paul at xelerance.com (Paul Wouters) Date: Wed, 2 Jan 2008 09:49:52 -0500 (EST) Subject: [dnssec-deployment] Mal ein paar DNSSEC Statistiken / Some DNSSEC statistics In-Reply-To: References: Message-ID: On Wed, 2 Jan 2008, Lutz Donnerhacke wrote: > >> 37 -1 FR > > > > Why is .nl not listed here? > > Because I found only the following 13 signed domains. This is not enough to > be listed in the TOP 10. > nlnetlabs.nl jelte.nlnetlabs.nl broken.jelte.nlnetlabs.nl > sub.jelte.nlnetlabs.nl matje.nlnetlabs.nl openswan.nl pixaco.nl > rodecker.nl stack.nl ipv6.stack.nl signed.telin.nl > subsigned.signed.telin.nl xelerance.nl Brining up all our .nl domains has been delayed a bit. They will come online soon. Paul From Mark_Andrews at isc.org Wed Jan 2 10:01:42 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Thu, 03 Jan 2008 02:01:42 +1100 Subject: [dnssec-deployment] Mal ein paar DNSSEC Statistiken / Some DNSSEC statistics In-Reply-To: Your message of "Wed, 02 Jan 2008 15:35:34 BST." Message-ID: <200801021501.m02F1gwn004735@drugs.dv.isc.org> > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > --------------enig1096F1487FD4D310223DE532 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > Lutz Donnerhacke wrote: > [..] > > There is not an error! Your signed zone will just not checked on most > > validating resolvers. But you can enhance the DNSSEC benefits, by linki= > ng > > your signed zone from your parent zone. > > Which would require the parent zone to actually be able to do signing > and also to link up to their parents and their parents, which in some > cases is not possible.... > > Okay lets put in my new years resolution for this year: > > DNSSec sign&enable SixXS subnet (/48) delegations > > Note that I mention subnets, as signing the tunnel spaces is, due to the > amount of space, nearly impossible. The above would at least a DLV to be > inserted for a few zones and allow a lot of folks to have dnssec enabled > reverses. Or just be slightly more imaginative with how you organise the zones. Assuming a /32, create zones for each of the /36's and only sign those that have signed childen. Similarly for the /40's and /44's in turn. To reduce the number of DS/DNSKEY pairs in the validation chain you could just delegate away the unsigned space at each level and leave the signed content in the /32's zone. Mark > First finish up some work though and the list gets longer and longer and > longer for cool stuff to do :( > > Greets, > Jeroen > > > --------------enig1096F1487FD4D310223DE532 > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: OpenPGP digital signature > Content-Disposition: attachment; filename="signature.asc" > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (MingW32) > > iD8DBQFHe6E2KaooUjM+fCMRAonyAJ48krK2Ga2INSv8nMflqh6ou1hCoACgq+aU > dzFEdPwqJA0z7aMtLmBzCw8= > =AYAq > -----END PGP SIGNATURE----- > > --------------enig1096F1487FD4D310223DE532-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From lutz at iks-jena.de Wed Jan 2 10:03:40 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 2 Jan 2008 15:03:40 +0000 (UTC) Subject: [dnssec-deployment] Mal ein paar DNSSEC Statistiken / Some DNSSEC statistics References: Message-ID: * Jeroen Massar wrote: > Which would require the parent zone to actually be able to do signing > and also to link up to their parents and their parents, which in some > cases is not possible.... Of course, RIPE and SiXXS suffers from this problem. I do not really check for this case and forgot to remove the zones from the mailing script. Sorry. > Okay lets put in my new years resolution for this year: > DNSSec sign&enable SixXS subnet (/48) delegations No! You are doing enough for the bleeding edge development. > Note that I mention subnets, as signing the tunnel spaces is, due to the > amount of space, nearly impossible. That's in interesting question for the technicans here. Somebody must have to found a solution ... > The above would at least a DLV to be inserted for a few zones and allow a > lot of folks to have dnssec enabled reverses. You might delegate that job to already existing DLVs. Thank you for your work. From lutz at iks-jena.de Wed Jan 2 10:09:42 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 2 Jan 2008 15:09:42 +0000 (UTC) Subject: [dnssec-deployment] Mal ein paar DNSSEC Statistiken / Some DNSSEC statistics References: Message-ID: * Paul Wouters wrote: > Brining up all our .nl domains has been delayed a bit. They will come online > soon. This would add about 300 domains and boost NL to the second place behind RU. From jeroen at unfix.org Wed Jan 2 10:33:25 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 02 Jan 2008 16:33:25 +0100 Subject: [dnssec-deployment] Mal ein paar DNSSEC Statistiken / Some DNSSEC statistics In-Reply-To: <200801021501.m02F1gwn004735@drugs.dv.isc.org> References: <200801021501.m02F1gwn004735@drugs.dv.isc.org> Message-ID: <477BAEC5.5090204@spaghetti.zurich.ibm.com> Mark Andrews wrote: [..] >> Note that I mention subnets, as signing the tunnel spaces is, due to the >> amount of space, nearly impossible. The above would at least a DLV to be >> inserted for a few zones and allow a lot of folks to have dnssec enabled >> reverses. > > Or just be slightly more imaginative with how you organise > the zones. Assuming a /32, create zones for each of the > /36's and only sign those that have signed childen. Similarly > for the /40's and /44's in turn. Well, in the case of the tunnel space everything contains data and thus can be signed as it is in our control fully. The issue with the tunnel spaces though is that those are /48's containing /64's, with every /64 ::1 + ::2 being the local and remote endpoint. That is a 65k * 2 = 128k record zone with fairly long record names, eg cl-42.dub-01.ie.sixxs.net. I've did a test sign for one such zone and found out that it would need quite a bit of extra memory to load the signed zone, an amount which would be a bit too high for our setup. Note that we have 25 of such zones and I recall the amount of mem to be used per zone was something like 100mb extra, thus 2.5Gb extra, which really is way too much for our setup. Thus, only signing the subnets which get delegated to users is a good start and allows them to start playing with it. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20080102/28a6efeb/attachment.bin From Mark_Andrews at isc.org Wed Jan 2 17:43:52 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Thu, 03 Jan 2008 09:43:52 +1100 Subject: [dnssec-deployment] Mal ein paar DNSSEC Statistiken / Some DNSSEC statistics In-Reply-To: Your message of "Wed, 02 Jan 2008 16:33:25 BST." Message-ID: <200801022243.m02Mhqd2049414@drugs.dv.isc.org> > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > --------------enig392B4843CB798F1C780C48DD > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > Mark Andrews wrote: > [..] > >> Note that I mention subnets, as signing the tunnel spaces is, due to t= > he > >> amount of space, nearly impossible. The above would at least a DLV to = > be > >> inserted for a few zones and allow a lot of folks to have dnssec enabl= > ed > >> reverses. > >=20 > > Or just be slightly more imaginative with how you organise > > the zones. Assuming a /32, create zones for each of the > > /36's and only sign those that have signed childen. Similarly > > for the /40's and /44's in turn. > > Well, in the case of the tunnel space everything contains data and thus > can be signed as it is in our control fully. The issue with the tunnel > spaces though is that those are /48's containing /64's, with every /64 > ::1 + ::2 being the local and remote endpoint. That is a 65k * 2 =3D 128k= > record zone with fairly long record names, eg cl-42.dub-01.ie.sixxs.net. You can play the same tricks in the /48 - /64 space and just sign the tunnels where you clients request a signed reverse or they sign the /48 (/64) allocated to them for internal use. Eventually you need bigger iron or more nameservers. This applies to a deep zone or a flat zone though the later does require something to distribute the queries across the nameservers. > I've did a test sign for one such zone and found out that it would need > quite a bit of extra memory to load the signed zone, an amount which > would be a bit too high for our setup. Note that we have 25 of such > zones and I recall the amount of mem to be used per zone was something > like 100mb extra, thus 2.5Gb extra, which really is way too much for our > setup. Thus, only signing the subnets which get delegated to users is a > good start and allows them to start playing with it. > > Greets, > Jeroen > > > --------------enig392B4843CB798F1C780C48DD > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: OpenPGP digital signature > Content-Disposition: attachment; filename="signature.asc" > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (MingW32) > iD8DBQFHe67FKaooUjM+fCMRArs1AJ9m13w7W1bXyXiWT3pWFNHv9XBW1ACgqU93 > wS6iBGHcqSJum2D17msbWXQ= > =hg6a > -----END PGP SIGNATURE----- > > --------------enig392B4843CB798F1C780C48DD-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From don at aptld.org Thu Jan 3 01:13:07 2008 From: don at aptld.org (Don Hollander) Date: Thu, 3 Jan 2008 19:13:07 +1300 Subject: DNSSEC Expertise in Taiwain in Februrary for APRICTO 2008 In-Reply-To: References: Message-ID: <6B2D760E69D3439292A842AA991DA400@DonPC> I am looking for someone to speak about the revisions to the DNSSEC protocols that are being introduced to the APTLD (www.aptld.org) meeting in Taiwan on the 25th of February, which is being held in conjunction with APRICOT 2008. And, it would be paticularly grand if there's anyone who has direct experience with its introduction who will be there too. Please let me know. Thanks. Don Don Hollander APTLD General Manager don at aptld.org www.aptld.org +64 21 24 24 215 From bmanning at vacation.karoshi.com Thu Jan 3 01:20:09 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 3 Jan 2008 06:20:09 +0000 Subject: [dnssec-deployment] DNSSEC Expertise in Taiwain in Februrary for APRICTO 2008 In-Reply-To: References: Message-ID: <20080103062009.GA3057@vacation.karoshi.com.> I'll be there and can talk, unless there are others who would prefer to do so. --bill On Thu, Jan 03, 2008 at 07:13:07PM +1300, Don Hollander wrote: > I am looking for someone to speak about the revisions to the DNSSEC > protocols that are being introduced to the APTLD (www.aptld.org) meeting in > Taiwan on the 25th of February, which is being held in conjunction with > APRICOT 2008. > > And, it would be paticularly grand if there's anyone who has direct > experience with its introduction who will be there too. > > Please let me know. > > Thanks. > > Don > > Don Hollander > APTLD General Manager > don at aptld.org > www.aptld.org > +64 21 24 24 215 > > > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: > > and older material is at > From Anne-Marie.Eklund-Lowinder at iis.se Thu Jan 3 08:31:52 2008 From: Anne-Marie.Eklund-Lowinder at iis.se (=?iso-8859-1?Q?Anne-Marie_Eklund-L=F6winder?=) Date: Thu, 3 Jan 2008 14:31:52 +0100 Subject: =?iso-8859-1?Q?Ny_nyckelsigneringsnyckel_=28KSK=29_f=F6r_=2ESE_-_New_key_?= =?iso-8859-1?Q?signing_key_=28KSK=29_for_=2ESE_?= Message-ID: <023E9DDFC555E3479AEBF917CE60A0B401723861@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Information in English follow Ny nyckelsigneringsnyckel (KSK) f?r .SE Fr?n och med idag, 2008-01-03, publicerar och anv?nder .SE en ny KSK f?r signering av .SE zonfilen. Nyckeln fr?n 2006 med key id = 17686 ?r ogiltig sedan 2008-01-01 och kommer att tas bort 2008-02-01. Ni b?r ha konfigurerat nyckeln f?r 2007 (Key id = 6166) i er resolver och vi rekommenderar er starkt att ers?tta den med den nya nyckeln (Key id = 49678) senast 2008-12-31. F?ljande publika nycklar ?r f?r n?rvarande giltiga f?r .SE: se. IN DNSKEY 257 3 5 ( AwEAAb6xRZHEf+PyF5dxEvz0BHEHbziu6iZaiNW/yjSa ZcmrmZiRMF8FPppD+XuKSau0rgu4eBwYdpkEoMVR4FhI 8frkuPHIue2LP1ETo+2hCrdr60K1538yLvzbOhMxXt6k njPN+OlalMmCknadaofKga5FLKOPQs2C3nw6AH4WUNGr chmDMVBwRwfZdQXYZTXesqULmGMK7mwjQGOxerRDQWrF v8NhNnVV31PihaYBdQ1TJjvfGS/FYZJwv/BddiELiLeU nNWu3AOsRAshgOcDBOAPUvKJNEq6RHELFmvXOOe2d8H2 yzv02EMQik6GwUm16DrSdmX+SWfelQs+9ELFN6k= ) ; key id = 6166 se. IN DNSKEY 257 3 5 ( AwEAAdKc1sGsbv5jjeJ141IxNSTdR+nbtFn+JKQpvFZE TaY5iMutoyWHa+jCp0TBBAzB2trGHzdi7E55FFzbeG0r +G6SJbJ4DXYSpiiELPiu0i+jPp3C3kNwiqpPpQHWaYDS 9MTQMu/QZHR/sFPbUnsK30fuQbKKkKgnADms0aXalYUu CgDyVMjdxRLz5yzLoaSO9m5ii5cI0dQNCjexvj9M4ec6 woi6+N8v1pOmQAQ9at5Fd8A6tAxZI8tdlEUnXYgNwb8e VZEWsgXtBhoyAru7Tzw+F6ToYq6hmKhfsT+fIhFXsYso 7L4nYUqTnM4VOZgNhcTv+qVQkHfOOeJKUkNB8Qc= ); key id = 49678 Nycklarna finns ?ven p? http://www.iis.se/domains/sednssec/publickey. DNS-anv?ndare som ?nnu inte har satt upp sin DNS att fr?ga efter DNSSEC-svar men har f?r avsikt att g?ra det b?r endast anv?nda de aktuella nycklarna. F?r DNS-anv?ndare som inte explicit har satt upp sin DNS att fr?ga efter DNSSEC-svar kommer det inte att inneb?ra n?gon f?r?ndring. Vi r?der er att prenumerera p? meddelanden fr?n dnssec-announce at lists.nic.se f?r att f? information om nyckelbyten och andra viktiga f?r?ndringar. Fr?gor kan st?llas till dnssec-info at iis.se. New key signing key (KSK) for .SE As from today, 2008-01-03 .SE publish and take into use a new KSK for signing the .SE zone file. The key published with start 2006 with key id = 17686 is unvalid since 2008-01-01 and will be removed 2008-02-01. You should have configured the key published with start 2007 (Key id = 6166) into your resolver and we strongly recommend you to replace it with the new key published today (Key id = 49678) no later than 2008-12-31. se. IN DNSKEY 257 3 5 ( AwEAAb6xRZHEf+PyF5dxEvz0BHEHbziu6iZaiNW/yjSa ZcmrmZiRMF8FPppD+XuKSau0rgu4eBwYdpkEoMVR4FhI 8frkuPHIue2LP1ETo+2hCrdr60K1538yLvzbOhMxXt6k njPN+OlalMmCknadaofKga5FLKOPQs2C3nw6AH4WUNGr chmDMVBwRwfZdQXYZTXesqULmGMK7mwjQGOxerRDQWrF v8NhNnVV31PihaYBdQ1TJjvfGS/FYZJwv/BddiELiLeU nNWu3AOsRAshgOcDBOAPUvKJNEq6RHELFmvXOOe2d8H2 yzv02EMQik6GwUm16DrSdmX+SWfelQs+9ELFN6k= ) ; key id = 6166 se. IN DNSKEY 257 3 5 ( AwEAAdKc1sGsbv5jjeJ141IxNSTdR+nbtFn+JKQpvFZE TaY5iMutoyWHa+jCp0TBBAzB2trGHzdi7E55FFzbeG0r +G6SJbJ4DXYSpiiELPiu0i+jPp3C3kNwiqpPpQHWaYDS 9MTQMu/QZHR/sFPbUnsK30fuQbKKkKgnADms0aXalYUu CgDyVMjdxRLz5yzLoaSO9m5ii5cI0dQNCjexvj9M4ec6 woi6+N8v1pOmQAQ9at5Fd8A6tAxZI8tdlEUnXYgNwb8e VZEWsgXtBhoyAru7Tzw+F6ToYq6hmKhfsT+fIhFXsYso 7L4nYUqTnM4VOZgNhcTv+qVQkHfOOeJKUkNB8Qc= ); key id = 49678 The keys are also available at http://www.iis.se/domains/sednssec/publickey. DNS users that haven't earlier but are going to configure their DNS to ask for DNSSEC answers should only use the new key. DNS users that haven't explicitly configured their DNS to ask for DNSSEC answers this will not involve any changes at all. We do advice you to subscribe to the dnssec-announce at lists.nic.se mailing list to get notified about key rollovers and any other important changes. Questions may be addressed to dnssec-info at iis.se. Anne-Marie Eklund L?winder Quality & Security Manager .SE (The Internet Infrastructure Foundation) PO Box 7399, SE-103 91 Stockholm, Sweden Phone: +46 (0)8-452 35 00/17 Mobile: +46 (0)734 315 310 E-mail: anne-marie.eklund-lowinder at iis.se Web: www.iis.se -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBR3zjyKXc8AFCsc+UEQK3+QCgnWuy26bScsFvafkp+Hu46RwFI8YAmgPN e2ACZlMLpzvnqIfWYnonZbpZ =EZWM -----END PGP SIGNATURE----- From Holger.Zuleger at hznet.de Thu Jan 3 10:54:19 2008 From: Holger.Zuleger at hznet.de (Holger Zuleger) Date: Thu, 03 Jan 2008 16:54:19 +0100 Subject: =?ISO-8859-1?Q?Re=3A_=5Bdnssec-deployment=5D_Ny_nyckelsign?= =?ISO-8859-1?Q?eringsnyckel_=28KSK=29_f=F6r_=2ESE_-_New_key_?= =?ISO-8859-1?Q?signing_key_=28KSK=29_for_=2ESE?= In-Reply-To: References: Message-ID: <477D052B.1090503@hznet.de> > New key signing key (KSK) for .SE > > As from today, 2008-01-03 .SE publish and take into use a new KSK for > signing the .SE zone file. The key published with start 2006 with key > id = 17686 is unvalid since 2008-01-01 and will be removed > 2008-02-01. You should have configured the key published with start Would it be possible to set the REVOKE Bit on that key, and announce it for another 30 days? Doing so enables a rfc5011 aware validator to discard the key automatically from the list of possible trust anchor. Without it, the key ends up in state missing on the validator side. Missing This is an abnormal state. The key remains a valid trust- point key, but was not seen at the resolver in the last validated DNSKEY RRSet. This is an abnormal state because the zone operator should be using the REVOKE bit prior to removal. So setting the revoke bit, would be one step to make the zone more compatible to RFC5011 (Automated Updates of DNS Security Trust Anchors) which is a way forward in implementing and using DNSSEC even without a signed root (and in absence of an elsewere trustable TAR). BTW: The same is true for all other signed TLDs and the signed zones managed by RIPE as well. Greets Holger -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4870 bytes Desc: S/MIME Cryptographic Signature Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20080103/6509c367/attachment.bin From pawal at blipp.com Thu Jan 3 11:16:21 2008 From: pawal at blipp.com (Patrik Wallstrom) Date: Thu, 3 Jan 2008 17:16:21 +0100 Subject: [dnssec-deployment] Ny =?utf-8?Q?nycke?= =?utf-8?Q?lsigneringsnyckel_=28KSK=29_f=C3=B6?= =?utf-8?Q?r?= .SE - New key signing key (KSK) for .SE In-Reply-To: References: Message-ID: <20080103161621.GF16456@vic20.blipp.com> On Thu, 03 Jan 2008, Holger Zuleger wrote: >> New key signing key (KSK) for .SE >> As from today, 2008-01-03 .SE publish and take into use a new KSK for >> signing the .SE zone file. The key published with start 2006 with key >> id = 17686 is unvalid since 2008-01-01 and will be removed >> 2008-02-01. You should have configured the key published with start > Would it be possible to set the REVOKE Bit on that key, and announce it for > another 30 days? There was no time to fix this for this rollover. Next time. > Doing so enables a rfc5011 aware validator to discard the key automatically > from the list of possible trust anchor. Which resolvers honors the revocation bit? To my knowledge, no swedish resolver operators are using such software yet. -- patrik_wallstrom->foodfight->pawal at blipp.com->+46-733173956 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20080103/7ce26ea2/attachment.bin From lutz at iks-jena.de Thu Jan 3 11:29:24 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Thu, 3 Jan 2008 16:29:24 +0000 (UTC) Subject: [dnssec-deployment] Mal ein paar DNSSEC Statistiken / Some DNSSEC statistics References: Message-ID: * Lutz Donnerhacke wrote: > 872 (+1) weak keys: I was informed, that this classification is not correct anymore. The Bleichenbacher's attack requires an obsolete software version. The fix in the resolver code was not soley to prevent this specific attack, but caused by "lazy developers". The choosen exponent in the keygen tool was bad from the cryptographic point of view, too. So there is no specific relationship to this attack even in this subject. Therefore I remove the "exponent 3" indicator for "weak". Now weak keys are keys with an unusual small modulus. From Holger.Zuleger at hznet.de Fri Jan 4 04:11:28 2008 From: Holger.Zuleger at hznet.de (Holger Zuleger) Date: Fri, 04 Jan 2008 10:11:28 +0100 Subject: =?ISO-8859-1?Q?Re=3A_=5Bdnssec-deployment=5D_Ny_nyckelsign?= =?ISO-8859-1?Q?eringsnyckel_=28KSK=29_f=F6r_=2ESE_-_New_key_?= =?ISO-8859-1?Q?signing_key_=28KSK=29_for_=2ESE?= In-Reply-To: <20080103161621.GF16456@vic20.blipp.com> References: <20080103161621.GF16456@vic20.blipp.com> Message-ID: <477DF840.3000905@hznet.de> Patrik Wallstrom wrote: > On Thu, 03 Jan 2008, Holger Zuleger wrote: > >>> New key signing key (KSK) for .SE >>> As from today, 2008-01-03 .SE publish and take into use a new KSK for >>> signing the .SE zone file. The key published with start 2006 with key >>> id = 17686 is unvalid since 2008-01-01 and will be removed >>> 2008-02-01. You should have configured the key published with start >> Would it be possible to set the REVOKE Bit on that key, and announce it for >> another 30 days? > > There was no time to fix this for this rollover. Next time. Oh, sure, it's clear that no one want's to add a new functionality on a productive service without testing, even if it is just to set one bit. But I thought that it was a good time to bring rfc5011 in mind... >> Doing so enables a rfc5011 aware validator to discard the key automatically >> from the list of possible trust anchor. > > Which resolvers honors the revocation bit? To my knowledge, no swedish > resolver operators are using such software yet. I think you are right. I guess that actually no one use it. Small question to all the dnssec operators: Please raise your hand if I'm wrong. ;-) And to the bind guys: Honors bind, used as an dnssec validator, the revoke bit? Holger -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4870 bytes Desc: S/MIME Cryptographic Signature Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20080104/3d7f2624/attachment.bin From lutz at iks-jena.de Fri Jan 4 11:39:06 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri, 4 Jan 2008 16:39:06 +0000 (UTC) Subject: Results of an DNSSEC AT survey Message-ID: Report of DNSSEC deploymnet in AT, CO.AT, OR.AT NIC.AT thankworthy offered me access to the AT zone in order to keep an eye on the DNSSEC distribution in their zone. This survey used a list of 721965 zones from 2008-1-1. First question was for DNSKEY using a validating resolver: 7 OK 680919 No such data 1507 No such domain 39532 Nameserver reports failure The seven signed zones stay on the same primary name server: asclepion.at epages.co.at epages.or.at meinfotoservice.at online-fotos.at onlinefotos.at pixaco.at The huge majority (680919) of zones are not signed and working fine with the validating resolver. For 1507 zones, the nameserver reports NXDOMAIN for DNSKEY queries. That's sometimes wrong, the domain exists! See the example below. The 39532 zones, causing temporary failures for DNSKEY queries are rechecked with a non-validating resolver and A/NS queries. Most of them do not respond to EDNS0 queries at all. So the "ordinary" queries result in: 16934 "No such data" oder "OK" 354 No such domain 21459 Nameserver reports failure About 40% of the DNSSEC problematic zones are reachable without any problems for the non-validating resolver. Here an example: ; <<>> DiG 9.4.2 <<>> DNSKEY 0038.at @ns3.domaindiscount24.net +norec ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 65298 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ; <<>> DiG 9.4.2 <<>> A 0038.at @ns3.domaindiscount24.net +norec ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47454 ;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 3, ADDITIONAL: 0 More than a half of all those zone is served by the name servers of domaindiscount24.net. The remaining 21459 tempfailed zones are caused by resolvers which does not know about the delegated zone but recursivly refer to other servers. -- I'm interested in other TLDs to do the same checks. From richard.lamb at icann.org Fri Jan 4 14:30:19 2008 From: richard.lamb at icann.org (richard.lamb) Date: Fri, 4 Jan 2008 11:30:19 -0800 Subject: =?iso-8859-1?Q?RE:_=5Bdnssec-deployment=5D_Ny_nyckelsigneringsnyckel_?= =?iso-8859-1?Q?=28KSK=29_f=F6r_.SE_-_New_key_signing_key_=28KSK=29_for_.SE?= In-Reply-To: References: <20080103161621.GF16456@vic20.blipp.com> Message-ID: <001501c84f08$3e644330$9700a8c0@ICANNBBFBFAB85> I agree it would be unrealistic to set it for a production zone like .se yet. However, I like the idea of "exercising" the REVOKE bit so that potential developers see it. Would it break anything in BIND resolvers to do so? If not, id like to set it every time I change KSKs in our demo. -----Original Message----- From: DNSSEC deployment [mailto:dnssec-deployment at shinkuro.com] On Behalf Of Holger Zuleger Sent: Friday, January 04, 2008 1:11 AM To: DNSSEC deployment Cc: Patrik Wallstrom; Anne-Marie.Eklund-Lowinder at iis.se; dns-wg at ripe.net Subject: Re: [dnssec-deployment] Ny nyckelsigneringsnyckel (KSK) f?r .SE - New key signing key (KSK) for .SE Patrik Wallstrom wrote: > On Thu, 03 Jan 2008, Holger Zuleger wrote: > >>> New key signing key (KSK) for .SE >>> As from today, 2008-01-03 .SE publish and take into use a new KSK for >>> signing the .SE zone file. The key published with start 2006 with key >>> id = 17686 is unvalid since 2008-01-01 and will be removed >>> 2008-02-01. You should have configured the key published with start >> Would it be possible to set the REVOKE Bit on that key, and announce it for >> another 30 days? > > There was no time to fix this for this rollover. Next time. Oh, sure, it's clear that no one want's to add a new functionality on a productive service without testing, even if it is just to set one bit. But I thought that it was a good time to bring rfc5011 in mind... >> Doing so enables a rfc5011 aware validator to discard the key automatically >> from the list of possible trust anchor. > > Which resolvers honors the revocation bit? To my knowledge, no swedish > resolver operators are using such software yet. I think you are right. I guess that actually no one use it. Small question to all the dnssec operators: Please raise your hand if I'm wrong. ;-) And to the bind guys: Honors bind, used as an dnssec validator, the revoke bit? Holger From Mark_Andrews at isc.org Fri Jan 4 17:52:24 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Sat, 05 Jan 2008 09:52:24 +1100 Subject: [dnssec-deployment] Results of an DNSSEC AT survey In-Reply-To: Your message of "Fri, 04 Jan 2008 16:39:06 -0000." Message-ID: <200801042252.m04MqOtO091053@drugs.dv.isc.org> > Report of DNSSEC deploymnet in AT, CO.AT, OR.AT > > NIC.AT thankworthy offered me access to the AT zone in order to keep an eye > on the DNSSEC distribution in their zone. > > This survey used a list of 721965 zones from 2008-1-1. > > First question was for DNSKEY using a validating resolver: > 7 OK > 680919 No such data > 1507 No such domain > 39532 Nameserver reports failure > > > The seven signed zones stay on the same primary name server: > asclepion.at epages.co.at epages.or.at meinfotoservice.at online-fotos.at > onlinefotos.at pixaco.at > > The huge majority (680919) of zones are not signed and working fine with the > validating resolver. > > For 1507 zones, the nameserver reports NXDOMAIN for DNSKEY queries. That's > sometimes wrong, the domain exists! See the example below. > > The 39532 zones, causing temporary failures for DNSKEY queries are rechecked > with a non-validating resolver and A/NS queries. Most of them do not respond > to EDNS0 queries at all. So the "ordinary" queries result in: > 16934 "No such data" oder "OK" > 354 No such domain > 21459 Nameserver reports failure > > About 40% of the DNSSEC problematic zones are reachable without any problems > for the non-validating resolver. Here an example: > > ; <<>> DiG 9.4.2 <<>> DNSKEY 0038.at @ns3.domaindiscount24.net +norec > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 65298 > ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ; <<>> DiG 9.4.2 <<>> A 0038.at @ns3.domaindiscount24.net +norec > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47454 > ;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 3, ADDITIONAL: 0 > > More than a half of all those zone is served by the name servers of > domaindiscount24.net. > > The remaining 21459 tempfailed zones are caused by resolvers which does not > know about the delegated zone but recursivly refer to other servers. > > -- > I'm interested in other TLDs to do the same checks. Similar checks should be done at delegation time and the delegation should be refused if NXDOMAIN is returned or the nameserver fails to respond to EDNS queries. Both of these conditions cause operational problems. It's time people took the DNS seriously. The one time when they can be forced to ensure things are correct is at initial delegation time. Similarly nameservers should accept queries from port 53. Mark > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: -deployment/> > and older material is at > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From ol at bofh.priv.at Sat Jan 5 04:33:06 2008 From: ol at bofh.priv.at (Otmar Lendl) Date: Sat, 5 Jan 2008 10:33:06 +0100 Subject: [dnssec-deployment] Results of an DNSSEC AT survey In-Reply-To: References: Message-ID: <20080105093306.GA18864@bofh.priv.at> On 2008/01/04 23:01, Mark Andrews wrote: > > Similar checks should be done at delegation time and the > delegation should be refused if NXDOMAIN is returned or > the nameserver fails to respond to EDNS queries. Both > of these conditions cause operational problems. nic.at does check basic nameserver configuration at delegation time. (IIRC, as a hardcore requirement for requests coming by email, but only post-hoc in the case of EPP.) That doesn't guarantee that people screw up their setup over time. But yes, it's a good idea to add a check whether the nameservers for a domain can cope with validating servers or not. /ol -- -=- Otmar Lendl -- ol at bofh.priv.at -=- From wouter at NLnetLabs.nl Mon Jan 7 06:08:46 2008 From: wouter at NLnetLabs.nl (Wouter Wijngaards) Date: Mon, 07 Jan 2008 12:08:46 +0100 Subject: =?ISO-8859-1?Q?Re=3A_=5Bdns-wg=5D_RE=3A_=5Bdnssec-deployme?= =?ISO-8859-1?Q?nt=5D_Ny_nyckelsigneringsnyckel_=28KSK=29_f=F6r_?= =?ISO-8859-1?Q?=2ESE_-_New_key_signing_key_=28KSK=29_for_?= =?ISO-8859-1?Q?=2ESE?= In-Reply-To: <001501c84f08$3e644330$9700a8c0@ICANNBBFBFAB85> References: <20080103161621.GF16456@vic20.blipp.com> <001501c84f08$3e644330$9700a8c0@ICANNBBFBFAB85> Message-ID: <4782083E.4050807@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As a developer I have a question about revoke bits. In a DNSKEY RRset that revokes A and also has keys B and C. Does A sign (A+B+C) or does the signature from A only sign A? Signing more than simply A is nonsense, since the key is revoked. And aids storing a presigned-self-revocation for emergency use. However, that is not standard for RRset signatures. Do signatures from B and C sign (A+B+C) or (B+C) ? How do revoke bit signatures work? Best regards, ~ Wouter richard.lamb wrote: | I agree it would be unrealistic to set it for a production zone like .se | yet. | However, I like the idea of "exercising" the REVOKE bit so that potential | developers see it. | Would it break anything in BIND resolvers to do so? | If not, id like to set it every time I change KSKs in our demo. | | | -----Original Message----- | From: DNSSEC deployment [mailto:dnssec-deployment at shinkuro.com] On Behalf Of | Holger Zuleger | Sent: Friday, January 04, 2008 1:11 AM | To: DNSSEC deployment | Cc: Patrik Wallstrom; Anne-Marie.Eklund-Lowinder at iis.se; dns-wg at ripe.net | Subject: Re: [dnssec-deployment] Ny nyckelsigneringsnyckel (KSK) f?r .SE - | New key signing key (KSK) for .SE | | | | Patrik Wallstrom wrote: |> On Thu, 03 Jan 2008, Holger Zuleger wrote: |> |>>> New key signing key (KSK) for .SE |>>> As from today, 2008-01-03 .SE publish and take into use a new KSK for |>>> signing the .SE zone file. The key published with start 2006 with key |>>> id = 17686 is unvalid since 2008-01-01 and will be removed |>>> 2008-02-01. You should have configured the key published with start |>> Would it be possible to set the REVOKE Bit on that key, and announce it | for |>> another 30 days? |> There was no time to fix this for this rollover. Next time. | Oh, sure, it's clear that no one want's to add a new functionality on a | productive service without testing, even if it is just to set one bit. | But I thought that it was a good time to bring rfc5011 in mind... | |>> Doing so enables a rfc5011 aware validator to discard the key | automatically |>> from the list of possible trust anchor. |> Which resolvers honors the revocation bit? To my knowledge, no swedish |> resolver operators are using such software yet. | I think you are right. I guess that actually no one use it. | Small question to all the dnssec operators: Please raise your hand if | I'm wrong. ;-) | And to the bind guys: Honors bind, used as an dnssec validator, the | revoke bit? | | Holger | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHggg+kDLqNwOhpPgRAuHwAJ4ow2e4qwnt7Yb/eDk03VyHBS3ELQCfeciD UJgy2s63Chz9Jw9YQGgYSRs= =62zO -----END PGP SIGNATURE----- From ogud at ogud.com Mon Jan 7 07:48:11 2008 From: ogud at ogud.com (Olafur Gudmundsson) Date: Mon, 07 Jan 2008 07:48:11 -0500 Subject: Revocation bit interpretation Was Re: [dnssec-deployment] [dns-wg] RE: [dnssec-deployment] Ny nyckelsigneringsnyckel .... In-Reply-To: References: <20080103161621.GF16456@vic20.blipp.com> <001501c84f08$3e644330$9700a8c0@ICANNBBFBFAB85> Message-ID: <200801071248.m07CmJUe010084@ogud.com> Notation A = the original key A' = is the same key after setting the revocation bit. the key id of A' = (A + 128) mod 64K The Revoked Key signs the whole set, it makes no sense to change what/how it signs it is a normal key with special meaning :-) My interpretation for TA A is: Set signed by A can be used to learn about new trust anchors and zone signing keys. Signature by A' can be used to assert (securely) that key A should not be trusted anymore The implication is if A was the only TA then the zone just revoked its Trusted status. B & C sign (A' + B + C) confirming that key A' has been revoked and in the case that A was a zone signing key blinding all validator's to the signatures generated by A. Olafur At 06:08 07/01/2008, Wouter Wijngaards wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >As a developer I have a question about revoke bits. > >In a DNSKEY RRset that revokes A and also has keys B and C. Does A sign >(A+B+C) or does the signature from A only sign A? >Signing more than simply A is nonsense, since the key is revoked. >And aids storing a presigned-self-revocation for emergency use. >However, that is not standard for RRset signatures. > >Do signatures from B and C sign (A+B+C) or (B+C) ? > >How do revoke bit signatures work? > >Best regards, >~ Wouter > >richard.lamb wrote: >| I agree it would be unrealistic to set it for a production zone like .se >| yet. >| However, I like the idea of "exercising" the REVOKE bit so that potential >| developers see it. >| Would it break anything in BIND resolvers to do so? >| If not, id like to set it every time I change KSKs in our demo. >| >| >| -----Original Message----- >| From: DNSSEC deployment [mailto:dnssec-deployment at shinkuro.com] On >Behalf Of >| Holger Zuleger >| Sent: Friday, January 04, 2008 1:11 AM >| To: DNSSEC deployment >| Cc: Patrik Wallstrom; Anne-Marie.Eklund-Lowinder at iis.se; dns-wg at ripe.net >| Subject: Re: [dnssec-deployment] Ny nyckelsigneringsnyckel (KSK) f?r .SE - >| New key signing key (KSK) for .SE >| >| >| >| Patrik Wallstrom wrote: >|> On Thu, 03 Jan 2008, Holger Zuleger wrote: >|> >|>>> New key signing key (KSK) for .SE >|>>> As from today, 2008-01-03 .SE publish and take into use a new KSK for >|>>> signing the .SE zone file. The key published with start 2006 with key >|>>> id = 17686 is unvalid since 2008-01-01 and will be removed >|>>> 2008-02-01. You should have configured the key published with start >|>> Would it be possible to set the REVOKE Bit on that key, and announce it >| for >|>> another 30 days? >|> There was no time to fix this for this rollover. Next time. >| Oh, sure, it's clear that no one want's to add a new functionality on a >| productive service without testing, even if it is just to set one bit. >| But I thought that it was a good time to bring rfc5011 in mind... >| >|>> Doing so enables a rfc5011 aware validator to discard the key >| automatically >|>> from the list of possible trust anchor. >|> Which resolvers honors the revocation bit? To my knowledge, no swedish >|> resolver operators are using such software yet. >| I think you are right. I guess that actually no one use it. >| Small question to all the dnssec operators: Please raise your hand if >| I'm wrong. ;-) >| And to the bind guys: Honors bind, used as an dnssec validator, the >| revoke bit? >| >| Holger >| > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.7 (GNU/Linux) >Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > >iD8DBQFHggg+kDLqNwOhpPgRAuHwAJ4ow2e4qwnt7Yb/eDk03VyHBS3ELQCfeciD >UJgy2s63Chz9Jw9YQGgYSRs= >=62zO >-----END PGP SIGNATURE----- > >############################################################# >This message is sent to you because you are subscribed to > the mailing list . >To unsubscribe, E-mail to: >A public archive is available here: > >and older material is at > From Holger.Zuleger at hznet.de Mon Jan 7 08:24:22 2008 From: Holger.Zuleger at hznet.de (Holger Zuleger) Date: Mon, 07 Jan 2008 14:24:22 +0100 Subject: =?ISO-8859-1?Q?Re=3A_=5Bdnssec-deployment=5D_=5Bdns-wg=5D_?= =?ISO-8859-1?Q?RE=3A_=5Bdnssec-deployment=5D_Ny_nyckelsigneringsny?= =?ISO-8859-1?Q?ckel_=28KSK=29_f=F6r_=2ESE_-_New_key_signin?= =?ISO-8859-1?Q?g_key_=28KSK=29_for_=2ESE?= In-Reply-To: References: <20080103161621.GF16456@vic20.blipp.com> <001501c84f08$3e644330$9700a8c0@ICANNBBFBFAB85> Message-ID: <47822806.7050900@hznet.de> > As a developer I have a question about revoke bits. > > In a DNSKEY RRset that revokes A and also has keys B and C. Does A sign > (A+B+C) or does the signature from A only sign A? In theory, only the signing of A is required, but don't care about the additional signing of B+C. > Signing more than simply A is nonsense, since the key is revoked. > And aids storing a presigned-self-revocation for emergency use. > However, that is not standard for RRset signatures. > > Do signatures from B and C sign (A+B+C) or (B+C) ? They have to sign (A+B+C) BTW, be aware of key tag changing if you set the revoke bit. Holger -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5006 bytes Desc: S/MIME Cryptographic Signature Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20080107/bc4244bf/attachment.bin From galvin at elistx.com Tue Jan 8 21:24:05 2008 From: galvin at elistx.com (James M Galvin) Date: Tue, 08 Jan 2008 21:24:05 -0500 Subject: meeting announcement: 16 January 2008 Message-ID: The next meeting of the DNSSEC deployment working group will be Wednesday, 16 January 2008, at the usual time of 1500 UTC. The agenda will be "holes in the hierarchy". We are setting up speakers and I'll have an agenda in another day or so. Thanks, Jim From andrew.ruthven at catalyst.net.nz Sun Jan 13 21:04:02 2008 From: andrew.ruthven at catalyst.net.nz (Andrew Ruthven) Date: Mon, 14 Jan 2008 15:04:02 +1300 Subject: Future applications? Message-ID: <1200276242.16773.5.camel@dirk.catalyst.net.nz> Hi guys, I'm going to be giving a talk at linux.conf.au[0] early next month talking about DNSSEC, mostly just a very high level view of what it is and why it is and what some of the current issues are (from .nz's point of view). But I thought it might be interesting to include something about future applications, if any. The ones that I've thought of so far are (I know there are arguements for and against, I'm going to over look those for now): * SSL cert deployment * GPG public key deployment * ENUM Does anyone have any other suggestions? Cheers! [0] http://linux.conf.au (registered back in the days that .au let almost anything go) -- Andrew Ruthven, Wellington, New Zealand At work: andrew.ruthven at catalyst.net.nz At home: andrew at etc.gen.nz GPG fpr: 34CA 12A3 C6F8 B156 72C2 D0D7 D286 CE0C 0C62 B791 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20080114/f33fecf5/attachment.bin From jakob at rfc.se Mon Jan 14 03:51:33 2008 From: jakob at rfc.se (Jakob Schlyter) Date: Mon, 14 Jan 2008 09:51:33 +0100 Subject: [dnssec-deployment] Future applications? In-Reply-To: References: Message-ID: <83E98639-3BC5-4D59-B129-53F572EA7429@rfc.se> On 14 jan 2008, at 03.04, Andrew Ruthven wrote: > But I thought it might be interesting to include something about > future > applications, if any. The ones that I've thought of so far are (I > know > there are arguements for and against, I'm going to over look those for > now): > > * SSL cert deployment http://stupid.domain.name/ietf/draft-schlyter-pkix-dns-02.txt might be interesting to read. IMHO, this is still a good idea. jakob From regnauld+dnssec at catpipe.net Mon Jan 14 04:35:27 2008 From: regnauld+dnssec at catpipe.net (Phil Regnauld) Date: Mon, 14 Jan 2008 10:35:27 +0100 Subject: [dnssec-deployment] Future applications? In-Reply-To: References: Message-ID: <20080114093527.GA68464@catpipe.net> Andrew Ruthven (andrew.ruthven) writes: > > * SSL cert deployment > * GPG public key deployment > * ENUM SSH keys in DNS (not very new, and actually already used some places): http://www.ietf.org/rfc/rfc4255.txt Phil From olaf at NLnetLabs.nl Mon Jan 14 07:10:47 2008 From: olaf at NLnetLabs.nl (Olaf M. Kolkman) Date: Mon, 14 Jan 2008 13:10:47 +0100 Subject: [dnssec-deployment] Future applications? In-Reply-To: References: Message-ID: ` > SSH keys in DNS (not very new, and actually already used some > places): > > http://www.ietf.org/rfc/rfc4255.txt > And along the same lines of opportunistic key exchange, there is the IPSECKEY RR. RFC4025. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 227 bytes Desc: This is a digitally signed message part Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20080114/b06650d0/attachment.bin From pk at DENIC.DE Mon Jan 14 07:37:53 2008 From: pk at DENIC.DE (Peter Koch) Date: Mon, 14 Jan 2008 13:37:53 +0100 Subject: [dnssec-deployment] Future applications? In-Reply-To: References: Message-ID: <20080114123753.GA22060@denics7.denic.de> On Mon, Jan 14, 2008 at 01:10:47PM +0100, Olaf M. Kolkman wrote: > And along the same lines of opportunistic key exchange, there is the > IPSECKEY RR. RFC4025. yes. And sice we're in repeat mode already, I'd like to remind everyone that DNSSEC provides data origin authentication only. There's nothing in DNSSEC that stricitly binds the RDATA (keying or fingerprint information) to the owner name. RRSIGs are not certificates, so there is no implicit or explicit liability of the zone maintainer (or worse, one of the [TLD] registries involved) for the correctness of the data. If this isn't kept in mind, we're just about to hit the next road block. -Peter From olaf at NLnetLabs.nl Mon Jan 14 07:53:44 2008 From: olaf at NLnetLabs.nl (Olaf M. Kolkman) Date: Mon, 14 Jan 2008 13:53:44 +0100 Subject: [dnssec-deployment] Future applications? In-Reply-To: References: Message-ID: <53E941CD-352F-4E52-8B49-A615F36C9847@NLnetLabs.nl> On Jan 14, 2008, at 1:37 PM, Peter Koch wrote: > On Mon, Jan 14, 2008 at 01:10:47PM +0100, Olaf M. Kolkman wrote: > >> And along the same lines of opportunistic key exchange, there is the >> IPSECKEY RR. RFC4025. > > yes. And sice we're in repeat mode already, I'd like to remind > everyone that > DNSSEC provides data origin authentication only. There's nothing in > DNSSEC > that stricitly binds the RDATA (keying or fingerprint information) > to the > owner name. > RRSIGs are not certificates, so there is no implicit or explicit > liability > of the zone maintainer (or worse, one of the [TLD] registries > involved) > for the correctness of the data. If this isn't kept in mind, we're > just > about to hit the next road block. The word _opportunistic_ was used deliberately because of the point you make. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 227 bytes Desc: This is a digitally signed message part Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20080114/ec1269b2/attachment.bin From bmanning at vacation.karoshi.com Mon Jan 14 07:53:20 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 14 Jan 2008 12:53:20 +0000 Subject: [dnssec-deployment] Future applications? In-Reply-To: References: Message-ID: <20080114125320.GA5781@vacation.karoshi.com.> On Mon, Jan 14, 2008 at 01:37:53PM +0100, Peter Koch wrote: > On Mon, Jan 14, 2008 at 01:10:47PM +0100, Olaf M. Kolkman wrote: > > > And along the same lines of opportunistic key exchange, there is the > > IPSECKEY RR. RFC4025. > > yes. And sice we're in repeat mode already, I'd like to remind everyone that > DNSSEC provides data origin authentication only. There's nothing in DNSSEC > that stricitly binds the RDATA (keying or fingerprint information) to the > owner name. > RRSIGs are not certificates, so there is no implicit or explicit liability > of the zone maintainer (or worse, one of the [TLD] registries involved) > for the correctness of the data. If this isn't kept in mind, we're just > about to hit the next road block. > > -Peter > true enough - but having a user supplied CERT as part of an RRSIG that is in a validated chain just might be useful. the CERT, presuming non-self-signed, is another channel for verification of the bindings. for my edification, who else, besides Simon Josefsson and myself are using CERT rrs or IPSECKEY rrs in regular use? --bill From paul at xelerance.com Mon Jan 14 08:20:20 2008 From: paul at xelerance.com (Paul Wouters) Date: Mon, 14 Jan 2008 08:20:20 -0500 (EST) Subject: [dnssec-deployment] Future applications? In-Reply-To: References: Message-ID: On Mon, 14 Jan 2008, bmanning at vacation.karoshi.com wrote: > for my edification, who else, besides Simon Josefsson and myself are > using CERT rrs or IPSECKEY rrs in regular use? I don't think Openswan has been fully updated yet to use IPSECKEY (instead of KEY) yet, though we do still have deployments using a TXT record for this. Paul From suresh at sparta.com Mon Jan 14 09:22:27 2008 From: suresh at sparta.com (Suresh Krishnaswamy) Date: Mon, 14 Jan 2008 09:22:27 -0500 Subject: [dnssec-deployment] Future applications? In-Reply-To: References: Message-ID: <73DEAE9F-FBD2-401F-9987-F18108B75720@sparta.com> On Jan 14, 2008, at 4:35 AM, Phil Regnauld wrote: > Andrew Ruthven (andrew.ruthven) writes: >> >> * SSL cert deployment >> * GPG public key deployment >> * ENUM > > SSH keys in DNS (not very new, and actually already used some > places): > > http://www.ietf.org/rfc/rfc4255.txt > > Phil > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: Lists/dnssec-deployment/> > and older material is at > From dave at corecom.com Mon Jan 14 09:28:08 2008 From: dave at corecom.com (Dave Piscitello) Date: Mon, 14 Jan 2008 09:28:08 -0500 Subject: [dnssec-deployment] Future applications? In-Reply-To: References: Message-ID: <478B7178.8070303@corecom.com> I would be very interested in seeing your presentation. I think this is an important issue for DNSSEC advocates. I don't want to appear negative or alarmist and I am certain many of you hear the same chatter I've been hearing, especially lately: "DNSSEC doesn't solve enough problems and the ones it solves can be mitigated using other methods" and "DNSSEC doesn't bring enough to the table to justify the implementation and deployment costs". I'm not saying these are true claims, but they are made loudly and frequently. An article that identifies the kinds of applications DNSSEC can support and why those applications are important would be *extremely* valuable. BUT... it must be written in language that average people and executives can understand. I am certain I could get an editor at a quality publication like ENISA Journal, USENIX, or BCR to publish something like this and would be happy to lend my pen to the task. Andrew Ruthven wrote: > Hi guys, > > I'm going to be giving a talk at linux.conf.au[0] early next month > talking about DNSSEC, mostly just a very high level view of what it is > and why it is and what some of the current issues are (from .nz's point > of view). > > But I thought it might be interesting to include something about future > applications, if any. The ones that I've thought of so far are (I know > there are arguements for and against, I'm going to over look those for > now): > > * SSL cert deployment > * GPG public key deployment > * ENUM > > Does anyone have any other suggestions? > > Cheers! > > [0] http://linux.conf.au (registered back in the days that .au let > almost anything go) > -------------- next part -------------- A non-text attachment was scrubbed... Name: dave.vcf Type: text/x-vcard Size: 220 bytes Desc: not available Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20080114/d3856014/attachment.vcf From thierry.moreau at connotech.com Mon Jan 14 09:33:49 2008 From: thierry.moreau at connotech.com (Thierry Moreau) Date: Mon, 14 Jan 2008 09:33:49 -0500 Subject: [dnssec-deployment] Data origin authentication *only*? (Was: Future applications?) In-Reply-To: References: Message-ID: <478B72CD.6010903@connotech.com> Olaf M. Kolkman wrote: > > On Jan 14, 2008, at 1:37 PM, Peter Koch wrote: > >> On Mon, Jan 14, 2008 at 01:10:47PM +0100, Olaf M. Kolkman wrote: >> >> [...], I'd like to remind >> everyone that >> DNSSEC provides data origin authentication only. There's nothing in >> DNSSEC >> that stricitly binds the RDATA (keying or fingerprint information) to >> the >> owner name. >> RRSIGs are not certificates, so there is no implicit or explicit >> liability >> of the zone maintainer (or worse, one of the [TLD] registries involved) >> for the correctness of the data. If this isn't kept in mind, we're just >> about to hit the next road block. > > > > > The word _opportunistic_ was used deliberately because of the point you > make. > I would like to agree with Peter. However, you may consider the following quote for another perspective: [quote] For some time, the consequences of the DNSSEC digital signatures ?aura of accountability? was an outstanding issue. Some well respected experts repeatedly asserted the specification limitation to ?data origin authentication,? which allegedly excluded zone file contents authentication, and excludes ?non-repudiation? as well. These subtleties are carried from IT security framework documents from the OSI era and are used to disclaim any implied accountability for the DNSSEC root zone file signatory. But now that operatinal deployment decisions are being made, the perceptions about the social impact of the technology can no longer be reversed per RFC language, i.e. such perceptions will become the social norm. Hence the following questions become relevant: Q1. Is the DNSSEC root zone file signature a legally binding signature? Q2. Can you convince a judge that the DNSSEC root zone file signature is not binding? Q3. Who can convince the ICANN counsel that if the question is raised in Court you can predictably convince the judge? Now that the retiring ICANN chairman Vince Cerf clearly described DNSSEC functionality as ?digitally authenticated responses to DNS queries? in the ICANN 2007 annual report, the obvious answer to question Q3 is nobody. Those who argued that DNSSEC is merely a technical feature should take good note that DNSSEC operations at the root does come with liability issues. Ignoring this conclusion and further arguments against it is counterproductive. [end-quote] Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau at connotech.com From suresh at sparta.com Mon Jan 14 09:28:00 2008 From: suresh at sparta.com (Suresh Krishnaswamy) Date: Mon, 14 Jan 2008 09:28:00 -0500 Subject: [dnssec-deployment] Future applications? In-Reply-To: References: Message-ID: > SSH keys in DNS (not very new, and actually already used some > places): > > > And along the same lines of opportunistic key exchange, there is > the IPSECKEY RR. RFC4025. > > And I should also point out that we already have patches in www.dnssec-tools.org for doing the validation of the above records in openssh and openswan respectively. Suresh From rdroms at cisco.com Mon Jan 14 09:32:09 2008 From: rdroms at cisco.com (Ralph Droms) Date: Mon, 14 Jan 2008 09:32:09 -0500 Subject: [dnssec-deployment] Future applications? In-Reply-To: References: Message-ID: <333BB0F8-BC68-4261-A004-03E52D51005B@cisco.com> Dave - I agree 100% that this is an important issue. What would really help me make the point about the importance of DNSSEC with customers and other folks inside Cisco is specific examples of actual attacks that have been detected and that would be mitigated through DNSSEC and not through other methods... - Ralph On Jan 14, 2008, at Jan 14, 2008,9:28 AM, Dave Piscitello wrote: > I would be very interested in seeing your presentation. > > I think this is an important issue for DNSSEC advocates. I don't > want to appear negative or alarmist and I am certain many of you > hear the same chatter I've been hearing, especially lately: "DNSSEC > doesn't solve enough problems and the ones it solves can be > mitigated using other methods" and "DNSSEC doesn't bring enough to > the table to justify the implementation and deployment costs". I'm > not saying these are true claims, but they are made loudly and > frequently. > > An article that identifies the kinds of applications DNSSEC can > support and why those applications are important would be > *extremely* valuable. BUT... it must be written in language that > average people and executives can understand. I am certain I could > get an editor at a quality publication like ENISA Journal, USENIX, > or BCR to publish something like this and would be happy to lend my > pen to the task. > > Andrew Ruthven wrote: >> Hi guys, >> I'm going to be giving a talk at linux.conf.au[0] early next month >> talking about DNSSEC, mostly just a very high level view of what it >> is >> and why it is and what some of the current issues are (from .nz's >> point >> of view). >> But I thought it might be interesting to include something about >> future >> applications, if any. The ones that I've thought of so far are (I >> know >> there are arguements for and against, I'm going to over look those >> for >> now): >> * SSL cert deployment >> * GPG public key deployment >> * ENUM >> Does anyone have any other suggestions? >> Cheers! >> [0] http://linux.conf.au (registered back in the days that .au let >> almost anything go) > < > dave.vcf>############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: > > and older material is at > From paul at xelerance.com Mon Jan 14 09:56:46 2008 From: paul at xelerance.com (Paul Wouters) Date: Mon, 14 Jan 2008 09:56:46 -0500 (EST) Subject: [dnssec-deployment] Future applications? In-Reply-To: References: Message-ID: On Mon, 14 Jan 2008, Suresh Krishnaswamy wrote: > >And along the same lines of opportunistic key exchange, there is the IPSECKEY > >RR. RFC4025. > > And I should also point out that we already have patches in > www.dnssec-tools.org for doing the validation of the above records in openssh > and openswan respectively. Were the openswan patches updated to use lwres? Last I remember, you patched the old DNS API of the openswan pluto daemon. Paul From paul at xelerance.com Mon Jan 14 10:00:24 2008 From: paul at xelerance.com (Paul Wouters) Date: Mon, 14 Jan 2008 10:00:24 -0500 (EST) Subject: [dnssec-deployment] Future applications? In-Reply-To: References: Message-ID: On Mon, 14 Jan 2008, Ralph Droms wrote: > What would really help me make the point about the importance of DNSSEC with > customers and other folks inside Cisco is specific examples of actual attacks > that have been detected and that would be mitigated through DNSSEC and not > through other methods... ISP-wide cache poisoning of bank sites comes to mind. I've heard this happened to Rogers and Bell Canada, somewhere early 2007 (or 2006?) for the major Canadian banks. The reason we don't see more of these, is that there are still enough people clicking on dfjgkdglgsgflsfglsdfsdf.com/ing/ to go to a fake bank site. With increased protection in browsers and email clients, we'll see an increase in DNS cache poisoning. Paul From suresh at sparta.com Mon Jan 14 10:05:12 2008 From: suresh at sparta.com (Suresh Krishnaswamy) Date: Mon, 14 Jan 2008 10:05:12 -0500 Subject: [dnssec-deployment] Future applications? In-Reply-To: References: Message-ID: <5F85B630-5D2A-4586-A5F0-F36B27B44215@sparta.com> Paul, The patches use libval for validation (not lwres). The code still use the old adns API for now although we're in the process of moving to the lwdnsq API. Suresh On Jan 14, 2008, at 9:56 AM, Paul Wouters wrote: > On Mon, 14 Jan 2008, Suresh Krishnaswamy wrote: > >>> And along the same lines of opportunistic key exchange, there is >>> the IPSECKEY >>> RR. RFC4025. >> >> And I should also point out that we already have patches in >> www.dnssec-tools.org for doing the validation of the above records >> in openssh >> and openswan respectively. > > Were the openswan patches updated to use lwres? Last I remember, you > patched the old DNS API of the openswan pluto daemon. > > Paul > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: Lists/dnssec-deployment/> > and older material is at > From dave at corecom.com Mon Jan 14 10:40:16 2008 From: dave at corecom.com (Dave Piscitello) Date: Mon, 14 Jan 2008 10:40:16 -0500 Subject: [dnssec-deployment] Future applications? In-Reply-To: References: Message-ID: <478B8260.3070801@corecom.com> Paul, You make quite an assertion here (that browsers will defeat social engineering). I think this an area where skeptics abound. There are fools and geniuses within the phishing and e-crime communities. The fools buy phishing kits, rent flux networks, and generate the easily detected bogus links and they apparently make money in spite of themselves. The geniuses adjust their attacks based on the countermeasures they encounter. They make *lots* of money and are very unlikely to stop trying to do so. Social engineering is as old a practice as prostitution. We've already begun to see IDNs used in phishing attacks. These are perhaps probes and indicators of the how phishing will evolve. I don't have faith that browsers will force attackers to fall back to cache poisoning, especially if the geniuses know there's a countermeasure available to defeat that tack. At best, they will be no more effective than antispam measures in mail clients. Paul Wouters wrote: > On Mon, 14 Jan 2008, Ralph Droms wrote: > >> What would really help me make the point about the importance of DNSSEC with >> customers and other folks inside Cisco is specific examples of actual attacks >> that have been detected and that would be mitigated through DNSSEC and not >> through other methods... > > ISP-wide cache poisoning of bank sites comes to mind. I've heard this > happened to Rogers and Bell Canada, somewhere early 2007 (or 2006?) for > the major Canadian banks. > > The reason we don't see more of these, is that there are still enough > people clicking on dfjgkdglgsgflsfglsdfsdf.com/ing/ to go to a fake bank > site. With increased protection in browsers and email clients, we'll see > an increase in DNS cache poisoning. > > Paul > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: > and older material is at > > -------------- next part -------------- A non-text attachment was scrubbed... Name: dave.vcf Type: text/x-vcard Size: 220 bytes Desc: not available Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20080114/174fb835/attachment.vcf From ol at bofh.priv.at Mon Jan 14 11:24:48 2008 From: ol at bofh.priv.at (Otmar Lendl) Date: Mon, 14 Jan 2008 17:24:48 +0100 Subject: [dnssec-deployment] Future applications? In-Reply-To: References: Message-ID: <20080114162448.GG18864@bofh.priv.at> On 2008/01/14 16:01, Dave Piscitello wrote: > > Social engineering is as old a practice as prostitution. We've already > begun to see IDNs used in phishing attacks. These are perhaps probes and > indicators of the how phishing will evolve. > > I don't have faith that browsers will force attackers to fall back to > cache poisoning, especially if the geniuses know there's a > countermeasure available to defeat that tack. At best, they will be no > more effective than antispam measures in mail clients. Listing to talks at conferences like FIRST gave me the impression that the next generation of phishing uses a completely different approach: The phishers try to infect the victim's pc with malware which hooks itself into the browser (BHO for IE, extensions like greasemonkey for Firefox). This malware transparently changes what is sent to the bank and what's received from the bank. No messing with domains needed at all. Just on the fly rewriting your request to transfer 10 $ to the local charity into a 10000 $ transfer to a money-mule's account + changing the "are you sure" and "transfer history" pages back to the harmless information. [1] Given the fact that SSL certificates confuses the heck out of most people (just for laughs: build a webpage with the SSL lock symbol as the favicon.ico, and then ask joe random user whether this is a secure site or not), I doubt that any cryptography will ever be the solution to the phishing problem. /ol [1] Austrian banks counter this by sending a summary of the transaction plus a TAN code by SMS to the customer. This way, the attacker needs to corrupt two different communication channels to be successful. -- -=- Otmar Lendl -- ol at bofh.priv.at -=- From paul at xelerance.com Mon Jan 14 13:48:25 2008 From: paul at xelerance.com (Paul Wouters) Date: Mon, 14 Jan 2008 13:48:25 -0500 (EST) Subject: [dnssec-deployment] Future applications? In-Reply-To: References: Message-ID: On Mon, 14 Jan 2008, Otmar Lendl wrote: > No messing with domains needed at all. Just on the fly rewriting your > request to transfer 10 $ to the local charity into a 10000 $ transfer > to a money-mule's account + changing the "are you sure" and "transfer > history" pages back to the harmless information. [1] My bank has a different verification procedure for small and large amounts. Small amounts require one number out of my magic blackbox, and two numbers for larger transactions, so you cannot just change the amount arbitrarilly. > Given the fact that SSL certificates confuses the heck out of most > people And companies are actively MITM'ing these to protect their users.... > [1] Austrian banks counter this by sending a summary of the transaction > plus a TAN code by SMS to the customer. This way, the attacker needs > to corrupt two different communication channels to be successful. But soon, the phone is no longer an out of bound device, as you will be baking and using the internet on the same device. Paul From richard.lamb at icann.org Mon Jan 14 15:29:09 2008 From: richard.lamb at icann.org (Richard Lamb) Date: Mon, 14 Jan 2008 12:29:09 -0800 Subject: [dnssec-deployment] Data origin authentication *only*? (Was: Future applications?) In-Reply-To: References: Message-ID: <002401c856ec$1e910430$9700a8c0@ICANNBBFBFAB85> Thierry- I don't think it is new news to anyone on this list but ICANN has contracted with an outside Risk Assessment firm to study these sorts of questions. I agree about perceptions versus truth. However, setting the correct expectations from the start can often be a useful tool against the former does not run amok. DNSSEC provides a way for software to validate DNS data has not been modified in flight. I think we have been doing a reasonable job here but from your comments we can clearly do better. Thank you for your analysis. -Rick -----Original Message----- From: DNSSEC deployment [mailto:dnssec-deployment at shinkuro.com] On Behalf Of Thierry Moreau Sent: Monday, January 14, 2008 6:34 AM To: DNSSEC deployment Cc: Olaf M. Kolkman; Phil Regnauld; Andrew Ruthven; Peter Koch Subject: Re: [dnssec-deployment] Data origin authentication *only*? (Was: Future applications?) Olaf M. Kolkman wrote: > > On Jan 14, 2008, at 1:37 PM, Peter Koch wrote: > >> On Mon, Jan 14, 2008 at 01:10:47PM +0100, Olaf M. Kolkman wrote: >> >> [...], I'd like to remind >> everyone that >> DNSSEC provides data origin authentication only. There's nothing in >> DNSSEC >> that stricitly binds the RDATA (keying or fingerprint information) to >> the >> owner name. >> RRSIGs are not certificates, so there is no implicit or explicit >> liability >> of the zone maintainer (or worse, one of the [TLD] registries involved) >> for the correctness of the data. If this isn't kept in mind, we're just >> about to hit the next road block. > > > > > The word _opportunistic_ was used deliberately because of the point you > make. > I would like to agree with Peter. However, you may consider the following quote for another perspective: [quote] For some time, the consequences of the DNSSEC digital signatures "aura of accountability" was an outstanding issue. Some well respected experts repeatedly asserted the specification limitation to "data origin authentication," which allegedly excluded zone file contents authentication, and excludes "non-repudiation" as well. These subtleties are carried from IT security framework documents from the OSI era and are used to disclaim any implied accountability for the DNSSEC root zone file signatory. But now that operatinal deployment decisions are being made, the perceptions about the social impact of the technology can no longer be reversed per RFC language, i.e. such perceptions will become the social norm. Hence the following questions become relevant: Q1. Is the DNSSEC root zone file signature a legally binding signature? Q2. Can you convince a judge that the DNSSEC root zone file signature is not binding? Q3. Who can convince the ICANN counsel that if the question is raised in Court you can predictably convince the judge? Now that the retiring ICANN chairman Vince Cerf clearly described DNSSEC functionality as "digitally authenticated responses to DNS queries" in the ICANN 2007 annual report, the obvious answer to question Q3 is nobody. Those who argued that DNSSEC is merely a technical feature should take good note that DNSSEC operations at the root does come with liability issues. Ignoring this conclusion and further arguments against it is counterproductive. [end-quote] Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau at connotech.com ############################################################# This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: A public archive is available here: and older material is at From dave at corecom.com Mon Jan 14 16:03:59 2008 From: dave at corecom.com (Dave Piscitello) Date: Mon, 14 Jan 2008 16:03:59 -0500 Subject: [dnssec-deployment] Future applications? In-Reply-To: <20080114162448.GG18864@bofh.priv.at> References: <20080114162448.GG18864@bofh.priv.at> Message-ID: <478BCE3F.1050208@corecom.com> This is one of several tactics, but it's not social engineering. I don't think you'll see phishing disappear, just evolve. It's much simpler to push email and host a bogus site than to write and deliver stealthy, clever code. History amply illustrates that people do silly things even when taught to not do them. Social engineering will always be the "low hanging fruit" path for crime and prudence alone should make us wary when we suggest technology will intervene. Otmar Lendl wrote: > On 2008/01/14 16:01, Dave Piscitello wrote: >> Social engineering is as old a practice as prostitution. We've already >> begun to see IDNs used in phishing attacks. These are perhaps probes and >> indicators of the how phishing will evolve. >> >> I don't have faith that browsers will force attackers to fall back to >> cache poisoning, especially if the geniuses know there's a >> countermeasure available to defeat that tack. At best, they will be no >> more effective than antispam measures in mail clients. > > Listing to talks at conferences like FIRST gave me the impression that > the next generation of phishing uses a completely different approach: > > The phishers try to infect the victim's pc with malware which hooks itself > into the browser (BHO for IE, extensions like greasemonkey for Firefox). > This malware transparently changes what is sent to the bank and what's > received from the bank. > > No messing with domains needed at all. Just on the fly rewriting your > request to transfer 10 $ to the local charity into a 10000 $ transfer > to a money-mule's account + changing the "are you sure" and "transfer > history" pages back to the harmless information. [1] > > Given the fact that SSL certificates confuses the heck out of most > people (just for laughs: build a webpage with the SSL lock symbol as > the favicon.ico, and then ask joe random user whether this is a > secure site or not), I doubt that any cryptography will ever be the > solution to the phishing problem. > > /ol > > [1] Austrian banks counter this by sending a summary of the transaction > plus a TAN code by SMS to the customer. This way, the attacker needs > to corrupt two different communication channels to be successful. -------------- next part -------------- A non-text attachment was scrubbed... Name: dave.vcf Type: text/x-vcard Size: 220 bytes Desc: not available Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20080114/d3107cdf/attachment.vcf From galvin at elistx.com Mon Jan 14 16:20:46 2008 From: galvin at elistx.com (James M Galvin) Date: Mon, 14 Jan 2008 16:20:46 -0500 Subject: [dnssec-deployment] meeting announcement: 16 January 2008 In-Reply-To: References: Message-ID: This meeting will be held at the usual time of: 0700 Los Angeles, San Francisco 0800 Phoenix 0800 Salt Lake City 1000 Washington 1500 UTC 1500 London 1600 Netherlands 1700 Israel 0000 Tokyo (the next day) 0200 Melbourne (the next day) The usual teleconference logistics are as follows. These do not change. You will hear music until the moderator joins. USA Toll Free Number: +1 888-221-7341 USA Toll Number: +1 973-935-2305 Conference Code: 599 786 # Leader: James Galvin employed by ICANN if speaking to an operator Jabber: dnssec-deployment at conference.jabber.org This is a public room. If your phone does not have a mute capability you can use "*6" to mute and "#6" to unmute your connection. DIAL OUT: 1. ISC SIP Bridge - contact me for SIP identifiers DRAFT AGENDA * Holes in the hiararchy There are two interrelated topics to consider. The first is counting the number of signed zones, with particular attention to counting the number of secure entry points, i.e., signed zones without a signed parent. The second topic is how to get the keying information for the secure entry points into a trust anchor repository. With respect to counting signed zones, there are at least two regular surveys. However, these surveys do not result in the same numbers. We are interested in understanding how these surveys relate to each other and how to interpret the numbers. It is interesting to note that the surveys provide one view of the number of secure entry points and, for example, ISC's DLV registry operation provides a different view. As is obvious, the process for being included in the ISC's DLV registry is considerably different and stricter than simply being counted in a survey. Do we know if every secure entry point in the ISC DLV is included in the surveys? More generally, the focus of the second topic is on the provisioning of trust anchor repositories but not on the serving side. As a rough guess, the expected number of secure entry points with unsigned parents will grow to be somewhere in the broad range of 10,000 to 1,000,000. Enterprises will sign their zones, or registrars and other service providers will sign zones on behalf of the customers, and their keys will need to be published. Whenever a TLD is ready to accept the keys from its registrants, the number of secure entry points with unsigned parents will drop. The largest component in this equation is, of course, .COM, but it is not the only one. Other gTLDs and probably many ccTLDs will have children who sign their zones in advance of the parent. What will it take to accommodate this number of secure entry points? Will registrars be able to pass along the keying information of their children in the same fashion they pass along the other components of their customers' configuration? What relationships and operational arrangements are required? Three speakers have agreed to join us and start the discussion. Lutz Donnerhacke, IKS-Jena Eric Osterweil, SecSpider Joao Damas, DLV From thierry.moreau at connotech.com Mon Jan 14 17:24:56 2008 From: thierry.moreau at connotech.com (Thierry Moreau) Date: Mon, 14 Jan 2008 17:24:56 -0500 Subject: [dnssec-deployment] meeting announcement: 16 January 2008 In-Reply-To: References: Message-ID: <478BE138.9060001@connotech.com> James M Galvin wrote: > [...] > > > DRAFT AGENDA > > * Holes in the hiararchy > > [...] > > More generally, the focus of the second topic is on the > provisioning of trust anchor repositories but not on the serving > side. > > What will it take to accommodate this number of secure entry > points? 1) DLV 2) NSEC3 opt-out feature 3) An interim root operator with opt-in signature delegations as described in http://www.connotech.com/six_roles_for_dnssec.pdf. On the provisioning side, I guess there are few contributions to IETF activities (and other open standards activities) mainly because the Verisign revenues are tied to proprietary technologies in this area. When I get blame for filing a patent application, I sometimes feel like the wrong duck being shot. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau at connotech.com From lutz at iks-jena.de Mon Jan 14 18:12:09 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Mon, 14 Jan 2008 23:12:09 +0000 (UTC) Subject: [dnssec-deployment] meeting announcement: 16 January 2008 References: Message-ID: * Thierry Moreau wrote: > 1) DLV > 3) An interim root operator with opt-in signature delegations Both are up an running. The latter in a production environment. > 2) NSEC3 opt-out feature That's for COM, NET and some ccTLDs. From thierry.moreau at connotech.com Tue Jan 15 10:01:34 2008 From: thierry.moreau at connotech.com (Thierry Moreau) Date: Tue, 15 Jan 2008 10:01:34 -0500 Subject: [dnssec-deployment] meeting announcement: 16 January 2008 In-Reply-To: References: Message-ID: <478CCACE.9050904@connotech.com> Lutz Donnerhacke wrote: > * Thierry Moreau wrote: > >>1) DLV >>3) An interim root operator with opt-in signature delegations > > > Both are up an running. The latter in a production environment. > What type of opt-in signature delegation are you referring to? Perhaps I missed something, or there is a misunderstanding. I was specifically referring to this type of opt-in operation: In reference to the DNSSEC protocol terminology, an opt-in secure delegation occurs when a SLD domain manager prepares a revision of SLD zone keyset, i.e. the DNSKEY RRset at the zone apex. The opt-in service provider has a direct delegation signature key pair, and the SLD domain manager includes this direct delegation public key in the SLD zone keyset, i.e. a DNSKEY resource record for a signature key that is exceptionally not controlled by the zone manager. The SLD domain manager sends the revised keyset to the opt-in service provider. The latter authenticates and checks the authorization status of the SLD before digitally signing the DNSKEY RRset with its direct delegation signature private key, and returns the signature to the SLD domain manager, i.e. the service provider sends an RRSIG resource record. The SLD manager includes the received direct delegation signature in the zone file and serves the DNS zone through the authoritative nameservers as usual. > >>2) NSEC3 opt-out feature > > > That's for COM, NET and some ccTLDs. > Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau at connotech.com From lutz at iks-jena.de Tue Jan 15 10:23:39 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 15 Jan 2008 15:23:39 +0000 (UTC) Subject: [dnssec-deployment] meeting announcement: 16 January 2008 References: Message-ID: * Thierry Moreau wrote: > Lutz Donnerhacke wrote: >> * Thierry Moreau wrote: >>>1) DLV >>>3) An interim root operator with opt-in signature delegations >> Both are up an running. The latter in a production environment. > > What type of opt-in signature delegation are you referring to? Sorry, I kept too much text in the quote. I refer to an alternate root operator. From Olivier.Guillard at nic.fr Wed Jan 16 06:46:42 2008 From: Olivier.Guillard at nic.fr (Olivier Guillard / AFNIC) Date: Wed, 16 Jan 2008 12:46:42 +0100 Subject: DNS islands cooperation Message-ID: <20080116114642.GA27126@james.nic.fr> Question may seem naive to many of you, but I'm not sure that I see everything with this one. Suppose: .fr is not signed .foo.fr is not signed .foo.fr is served by ns.cleaver.se. suppose that [cleaver.[se]]. was signed (: would this change anything for .foo.fr if [some or all of] the authoritative name server names for this domain were within signed zones ? I would say no (aka: practically, it does not bring anything to .foo.fr to have authoritative NS signed, and it doesn't change much from a resolution point of view, even for security aware resolvers). And the reverse question. suppose: dnssec.se is signed primary.se. is authoritative for dnssec.se but not signed. Does it change anything for dnssec.se if [some or all of] the authoritative name server names for this domain are or not within signed zones ? I would say again no (since dnssec.se records stay signed and can be verified in the same way independently on where they have been collected from). Any comment on that ? To be clear, I try to identify if there are not any potential side effect of "DNSSEC island" on others, and vice versa. Thanks, -- Olivier From weiler at tislabs.com Wed Jan 16 06:47:05 2008 From: weiler at tislabs.com (Sam Weiler) Date: Wed, 16 Jan 2008 06:47:05 -0500 (EST) Subject: [dnssec-deployment] DNS islands cooperation Message-ID: I agree with your interpretation in both cases: it doesn't matter whether the glue records are signed or not. -- Sam From Ed.Lewis at neustar.biz Wed Jan 16 09:11:42 2008 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 16 Jan 2008 09:11:42 -0500 Subject: [dnssec-deployment] DNS islands cooperation In-Reply-To: References: Message-ID: At 12:46 +0100 1/16/08, Olivier Guillard / AFNIC wrote: >Question may seem naive to many of you, but I'm not >sure that I see everything with this one. > >Suppose: > >.fr is not signed >.foo.fr is not signed >.foo.fr is served by ns.cleaver.se. > >suppose that [cleaver.[se]]. was signed (: > >would this change anything for .foo.fr if [some or >all of] the authoritative name server names for this >domain were within signed zones ? A fundamental rule of DNSSEC is that zones are signed, servers are just annoying things that answer questions. If you go to an unauthorized source of information (DNS or otherwise), but the answer is verifiable is the answer any less valuable? >I would say no That's right. >And the reverse question. > >suppose: > >dnssec.se is signed >primary.se. is authoritative for dnssec.se but not signed. You're mixing units (inches, meters) here. I presume that dnssec.se is a zone and primary.se is a) a zone therefore can be signed but can't be authoritative for another zone, b) a server name therefore it individually isn't signed but is able to be authoritative, or c) a zone apex with an A record. Case c) is rare, so I don't assume that's what you wanted to say. >Does it change anything for dnssec.se if [some or >all of] the authoritative name server names for this >domain are or not within signed zones ? Signing is strictly a characteristic of the zone. But if the slaves are serving without the DNSSEC records then validators may get confused (that is, invalidate some data, validate others - the result of alternating getting data from different servers). >I would say again no (since dnssec.se records stay signed >and can be verified in the same way independently on where >they have been collected from). Again, right, but consider what happens if the servers in the unsigned zones are also unable to provide the DNSSEC data in the response. >Any comment on that ? > >To be clear, I try to identify if there are not any potential >side effect of "DNSSEC island" on others, and vice versa. If others have no knowledge of the keys, it doesn't matter. If the others mean those providing slave service to a zone that is signed, they have to be capable (new DNS code) and able to withstand any other capacity impact. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. From Olivier.Guillard at nic.fr Wed Jan 16 10:03:15 2008 From: Olivier.Guillard at nic.fr (Olivier Guillard) Date: Wed, 16 Jan 2008 16:03:15 +0100 Subject: [dnssec-deployment] DNS islands cooperation In-Reply-To: References: Message-ID: <20080116150315.GA32024@james.nic.fr> Thanks Edward, > You're mixing units (inches, meters) here. I presume that dnssec.se > is a zone and primary.se is a) a zone therefore can be signed but > can't be authoritative for another zone, b) a server name therefore > it individually isn't signed but is able to be authoritative, or c) > a zone apex with an A record. Case c) is rare, so I don't assume > that's what you wanted to say. Consistantly with the previous question, response /b/ $ dig dnssec.se ns ;; QUESTION SECTION: ;dnssec.se. IN NS ;; ANSWER SECTION: dnssec.se. 300 IN NS ns.dnssec.se. dnssec.se. 300 IN NS primary.se. dnssec.se. 300 IN NS secondary.se. Thanks for your input, --- Olivier le mercredi 16 janvier ? 09 H 11 , Edward Lewis a ecrit : > At 12:46 +0100 1/16/08, Olivier Guillard / AFNIC wrote: > >Question may seem naive to many of you, but I'm not > >sure that I see everything with this one. > > > >Suppose: > > > >.fr is not signed > >.foo.fr is not signed > >.foo.fr is served by ns.cleaver.se. > > > >suppose that [cleaver.[se]]. was signed (: > > > >would this change anything for .foo.fr if [some or > >all of] the authoritative name server names for this > >domain were within signed zones ? > > A fundamental rule of DNSSEC is that zones are signed, servers are > just annoying things that answer questions. > > If you go to an unauthorized source of information (DNS or > otherwise), but the answer is verifiable is the answer any less > valuable? > > >I would say no > > That's right. > > >And the reverse question. > > > >suppose: > > > >dnssec.se is signed > >primary.se. is authoritative for dnssec.se but not signed. > > You're mixing units (inches, meters) here. I presume that dnssec.se > is a zone and primary.se is a) a zone therefore can be signed but > can't be authoritative for another zone, b) a server name therefore > it individually isn't signed but is able to be authoritative, or c) a > zone apex with an A record. Case c) is rare, so I don't assume > that's what you wanted to say. > > >Does it change anything for dnssec.se if [some or > >all of] the authoritative name server names for this > >domain are or not within signed zones ? > > Signing is strictly a characteristic of the zone. But if the slaves > are serving without the DNSSEC records then validators may get > confused (that is, invalidate some data, validate others - the result > of alternating getting data from different servers). > > >I would say again no (since dnssec.se records stay signed > >and can be verified in the same way independently on where > >they have been collected from). > > Again, right, but consider what happens if the servers in the > unsigned zones are also unable to provide the DNSSEC data in the > response. > > >Any comment on that ? > > > >To be clear, I try to identify if there are not any potential > >side effect of "DNSSEC island" on others, and vice versa. > > If others have no knowledge of the keys, it doesn't matter. If the > others mean those providing slave service to a zone that is signed, > they have to be capable (new DNS code) and able to withstand any > other capacity impact. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > Think glocally. Act confused. -- Olivier Guillard --- || AFNIC - Immeuble International || 2 rue Stephenson - Montigny-le-Bretonneux || 78181, Saint-Quentin-en-Yvelines CEDEX, France || http://www.nic.fr/ || mailto:Olivier.Guillard at nic.fr || tel: +33 1 39 30 83 31 From steve at shinkuro.com Wed Jan 16 10:06:17 2008 From: steve at shinkuro.com (Steve Crocker) Date: Wed, 16 Jan 2008 10:06:17 -0500 Subject: Fwd: DNSSEC plenary conference re counting signed zones and adding secure entry points to a trust anchor repository References: <73F371EC-D956-429F-9979-0A1EC7C93101@CS.UCLA.EDU> Message-ID: <3A3F7376-584F-486E-8493-FFB535948C78@shinkuro.com> Eric, Thanks! In the interest of time, I am forwarding these to the mailing list directly. Steve Begin forwarded message: > From: Eric Osterweil > Date: January 16, 2008 9:57:38 AM EST > To: Steve Crocker > Cc: Lixia Zhang , Michael Ryan > , Daniel Massey , > James Galvin > Subject: Re: DNSSEC plenary conference re counting signed zones and > adding secure entry points to a trust anchor repository > > Hi again Mr. Crocker, > > I don't know if slides need to be posted. If not, feel free to > disregard this. If so, however, here's an updated deck. I updated > a couple of figures and trimmed some slides (though I still have > way too many), but in case you happen to be posting these there is > also an authorship correction. Anyway, I'll likely not speak to a > number of these (to be sure to stay on-time), but if people found > them interesting then they could comment I thought. > > Thanks a lot, > > Eric > ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20080116/651d7fc8/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: SecSpider-2008-01-16.pdf Type: application/pdf Size: 317091 bytes Desc: not available Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20080116/651d7fc8/attachment.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20080116/651d7fc8/attachment-0001.html From lutz at iks-jena.de Wed Jan 16 10:59:55 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 16 Jan 2008 15:59:55 +0000 (UTC) Subject: [dnssec-deployment] meeting announcement: 16 January 2008 References: Message-ID: * James M Galvin wrote: > Three speakers have agreed to join us and start the discussion. > Lutz Donnerhacke, IKS-Jena Slides: http://www.iks-jena.de/mitarb/lutz/vortrag/Survey-of-DNSSEC.pdf From Mats.Dufberg at teliasonera.com Wed Jan 16 11:08:30 2008 From: Mats.Dufberg at teliasonera.com (Mats.Dufberg at teliasonera.com) Date: Wed, 16 Jan 2008 17:08:30 +0100 Subject: Any implementation of RFC 5011 Message-ID: Does anyone know of any implementation of client side of RFC 5011 ("Automated Updates of DNS Security (DNSSEC) Trust Anchors")? Or start of such work? http://www.ietf.org/rfc/rfc5011.txt Mats ------------------------------------------ Mats Dufberg TeliaSonera BBS P&P S IPS Broadband Applications +46-70-2582588 mats.dufberg at teliasonera.com ------------------------------------------ From suresh at sparta.com Wed Jan 16 11:22:06 2008 From: suresh at sparta.com (Suresh Krishnaswamy) Date: Wed, 16 Jan 2008 11:22:06 -0500 Subject: [dnssec-deployment] Any implementation of RFC 5011 In-Reply-To: References: Message-ID: Mats, We've implemented this in our 'trustman' tool (found in the dnssec- tools package): http://www.dnssec-tools.org/docs/tool-description/trustman.html Suresh On Jan 16, 2008, at 11:08 AM, wrote: > Does anyone know of any implementation of client side of RFC 5011 > ("Automated Updates of DNS Security (DNSSEC) Trust Anchors")? Or start > of such work? > > http://www.ietf.org/rfc/rfc5011.txt > > > > Mats > > ------------------------------------------ > Mats Dufberg > TeliaSonera > BBS P&P S IPS Broadband Applications > +46-70-2582588 > mats.dufberg at teliasonera.com > ------------------------------------------ > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: Lists/dnssec-deployment/> > and older material is at > From Mark_Andrews at isc.org Wed Jan 16 17:36:22 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Thu, 17 Jan 2008 09:36:22 +1100 Subject: [dnssec-deployment] DNS islands cooperation In-Reply-To: Your message of "Wed, 16 Jan 2008 06:47:05 CDT." Message-ID: <200801162236.m0GMaMPW034425@drugs.dv.isc.org> > I agree with your interpretation in both cases: it doesn't matter > whether the glue records are signed or not. > > -- Sam Actually there are senarios where signed glue, that is tagged as glue, is beneficial. With the current DNSSEC we can spend a lot of time chasing down dead ends. If glue was signed we could avoid this waste of time. We could also go back to arbitary glue as we would now be able to chase back to its source bad glue. Mark > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: ec-deployment/> > and older material is at > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From lutz at iks-jena.de Wed Jan 16 17:39:44 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 16 Jan 2008 22:39:44 +0000 (UTC) Subject: [dnssec-deployment] DNS islands cooperation References: Message-ID: * Sam Weiler wrote: > I agree with your interpretation in both cases: it doesn't matter > whether the glue records are signed or not. Glue records are never signed. But the case here does not involve glue records at all. From regnauld+dnssec at catpipe.net Wed Jan 16 18:14:47 2008 From: regnauld+dnssec at catpipe.net (Phil Regnauld) Date: Thu, 17 Jan 2008 00:14:47 +0100 Subject: [dnssec-deployment] Future applications? In-Reply-To: <478B7178.8070303@corecom.com> References: <478B7178.8070303@corecom.com> Message-ID: <20080116231446.GC694@catpipe.net> Dave Piscitello (dave) writes: > I would be very interested in seeing your presentation. So would I in fact. > I think this is an important issue for DNSSEC advocates. I don't want to > appear negative or alarmist and I am certain many of you hear the same > chatter I've been hearing, especially lately: "DNSSEC doesn't solve enough > problems and the ones it solves can be mitigated using other methods" and > "DNSSEC doesn't bring enough to the table to justify the implementation and > deployment costs". I'm not saying these are true claims, but they are made > loudly and frequently. ... The only way you can counter that is by doing relentless promotion of DNSSEC at conferences, NOG meetings and workshops. For instance at the most recent ccTLD workshop organized by NSRC/ISOC/ ICANN (http://ws.edu.isoc.org/workshops/2007/cctld-amman/agenda.html), we had almost a day of DNSSEC (intro + basic hands-on signing), to get administrators from the Region familiarized with the concepts, and show that it wasn't as complicated (from a technical point of view) as it seemed. There's been entire workshops on the topic: http://www.interlab.ait.ac.th/training/2006/dnssec.html ... and some of the materials have been translated to other languages: http://ws.edu.isoc.org/workshops/2006/dnssec-dakar/ So what's missing now is to give people a good argument why they should go through with the extra work and administrative overhead that signing zones and delegations implies. I'm a bit stumped on that one :) > An article that identifies the kinds of applications DNSSEC can support and > why those applications are important would be *extremely* valuable. A point was made that DNSSEC doesn't function as some kind of PKI that you can build on (it's not a signature framework for the rdata), so it's not easy to "sell" DNSSEC as an enabler of new applications/features. Even the added validation is not visible: if we take the case of typical end-users (read: web surfers :), failure to validate the origin of DNS answers (and the ensuing failure of resolution, as seen by the client) does not automatically generate a warning in the application, since there's no vertical mechanism to push a qualified error condition back to the application, unless the application actively checks DNS data (and that's not its job). See http://www.dnssec-tools.org/ and http://www.dnssec-tools.org/whybad.html for a good example). > BUT... > it must be written in language that average people and executives can > understand. I am certain I could get an editor at a quality publication > like ENISA Journal, USENIX, or BCR to publish something like this and would > be happy to lend my pen to the task. Same here, but we've got a silver bullet looking for a werewolf, is the perceived attitude. Phil -- _ _ |_ | (_(_||_ | regnauld at catpipe.net - www.catpipe.net | From Mats.Dufberg at teliasonera.com Fri Jan 18 04:58:38 2008 From: Mats.Dufberg at teliasonera.com (Mats.Dufberg at teliasonera.com) Date: Fri, 18 Jan 2008 10:58:38 +0100 Subject: [dnssec-deployment] Any implementation of RFC 5011 In-Reply-To: References: Message-ID: It seems to be the tool I'm looking for. I will start a test of that together with the .SE registry. The documentation does not refer to RFC 5011 anywhere. Do you know if trustman is completely RFC 5011 compliant? Do you know if it is used in production anywhere? Mats ------------------------------------------ Mats Dufberg TeliaSonera BBS P&P S IPS Broadband Applications +46-70-2582588 mats.dufberg at teliasonera.com ------------------------------------------ > -----Original Message----- > From: Suresh Krishnaswamy [mailto:suresh at sparta.com] > Sent: den 16 januari 2008 17:22 > To: Dufberg, Mats O. > Cc: DNSSEC deployment > Subject: Re: [dnssec-deployment] Any implementation of RFC 5011 > > > Mats, > > We've implemented this in our 'trustman' tool (found in the dnssec- > tools package): > http://www.dnssec-tools.org/docs/tool-description/trustman.html > > Suresh > > On Jan 16, 2008, at 11:08 AM, > wrote: > > > Does anyone know of any implementation of client side of RFC 5011 > > ("Automated Updates of DNS Security (DNSSEC) Trust > Anchors")? Or start > > of such work? > > > > http://www.ietf.org/rfc/rfc5011.txt > > > > > > > > Mats > > > > ------------------------------------------ > > Mats Dufberg > > TeliaSonera > > BBS P&P S IPS Broadband Applications > > +46-70-2582588 > > mats.dufberg at teliasonera.com > > ------------------------------------------ > > > > ############################################################# > > This message is sent to you because you are subscribed to > > the mailing list . > > To unsubscribe, E-mail to: > > A public archive is available here: > Lists/dnssec-deployment/> > > and older material is at > > > > From suresh at sparta.com Fri Jan 18 10:06:02 2008 From: suresh at sparta.com (Suresh Krishnaswamy) Date: Fri, 18 Jan 2008 10:06:02 -0500 Subject: [dnssec-deployment] Any implementation of RFC 5011 In-Reply-To: References: Message-ID: <1C6AB8A9-3FFB-458A-A4B6-A588C0A035B9@sparta.com> > It seems to be the tool I'm looking for. I will start a test of that > together with the .SE registry. > Sounds good! > The documentation does not refer to RFC 5011 anywhere. Do you know if > trustman is completely RFC 5011 compliant? Do you know if it is > used in > production anywhere? > The documentation needs to be updated to say this, but trustman was specifically written with RFC 5011 (then draft-ietf-dnext-trustupdate- timers) in mind. We're continuing to tinker with some of the finer details in the tool, but the implementation should be fairly complete in its current form. As of now we've mainly been using trustman in our test environment; I'm not sure if someone else is using it on a production basis. Feel free to send in your comments and feedback to the dnssec-tools-users mailing list. Thanks! Suresh From lutz at iks-jena.de Mon Jan 21 04:49:43 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Mon, 21 Jan 2008 09:49:43 +0000 (UTC) Subject: DNSSEC for ENUM Message-ID: I'd like to inform you, that I try to get DNSSEC as a requirement for an upcoming ENUM seal. The risk of modified data (by hotels which want to prohibit VoIP or gouvernmental intercepting dreams) is too high for unverified information. OTOH ENUM is an area where DNSSEC drawbacks (bogus zones caused by mismaintainance) does not harm that much due to the POTS fallback. From regnauld+dnssec at catpipe.net Mon Jan 21 04:53:11 2008 From: regnauld+dnssec at catpipe.net (Phil Regnauld) Date: Mon, 21 Jan 2008 10:53:11 +0100 Subject: [dnssec-deployment] DNSSEC for ENUM In-Reply-To: References: Message-ID: <20080121095311.GC6037@catpipe.net> Lutz Donnerhacke (lutz) writes: > I'd like to inform you, that I try to get DNSSEC as a requirement for an > upcoming ENUM seal. The risk of modified data (by hotels which want to > prohibit VoIP or gouvernmental intercepting dreams) is too high for > unverified information. OTOH ENUM is an area where DNSSEC drawbacks > (bogus zones caused by mismaintainance) does not harm that much due to the > POTS fallback. Interesting, do you have anything that outlines the advantages of DNSSEC in this respect, besides what you've just mentioned ? From lutz at iks-jena.de Mon Jan 21 05:58:36 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Mon, 21 Jan 2008 10:58:36 +0000 (UTC) Subject: [dnssec-deployment] DNSSEC for ENUM References: Message-ID: * Phil Regnauld wrote: > Lutz Donnerhacke (lutz) writes: >> I'd like to inform you, that I try to get DNSSEC as a requirement for an >> upcoming ENUM seal. The risk of modified data (by hotels which want to >> prohibit VoIP or gouvernmental intercepting dreams) is too high for >> unverified information. OTOH ENUM is an area where DNSSEC drawbacks >> (bogus zones caused by mismaintainance) does not harm that much due to the >> POTS fallback. > > Interesting, do you have anything that outlines the advantages > of DNSSEC in this respect, besides what you've just mentioned ? No, it's initial thinking ;-) From mcr at sandelman.ottawa.on.ca Mon Jan 21 07:52:07 2008 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Mon, 21 Jan 2008 07:52:07 -0500 Subject: [dnssec-deployment] DNSSEC for ENUM In-Reply-To: References: Message-ID: <15516.1200919927@marajade.sandelman.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Lutz" == Lutz Donnerhacke writes: Lutz> I'd like to inform you, that I try to get DNSSEC as a Lutz> requirement for an upcoming ENUM seal. The risk of modified Lutz> data (by hotels which want to prohibit VoIP or gouvernmental Lutz> intercepting dreams) is too high for unverified Lutz> information. OTOH ENUM is an area where DNSSEC drawbacks Lutz> (bogus zones caused by mismaintainance) does not harm that Lutz> much due to the POTS fallback. I'm a bit confused by this threat analysis as it relates to hotels. A hotel wants to prohibit VoIP/ENUM can just break the zone by breaking DNSSEC, and that will cause a fallback to the hotels metered PSTN. Or do you think that breaking DNSSEC will cause sufficient complaints that the hotel will get no money for the internet connection? In the case of ENUM, you don't have to break all the zones either, just one or two. Government interception, I see the point. - -- ] Bear: "Me, I'm just the shape of a bear." | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ]mcr at xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ]panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Finger me for keys iQEVAwUBR5SVcoCLcPvd0N1lAQKYUQf9GAfhs9brEiIZTAjGFVi5tapJmu9M6VLM DT/hvO8oHvJc3pIgZlDHnFw6Rsw/nPJ6Jmy32bbEy2rUHJEUCGx7D1nhJD0NNz2t /MIoaYHyd5yOYh+ig47TfTf6n7AdJraRu7VOMOABy6icRLE1NGDdBY9r+nPJzF3Q 45NnIw78ItDK2kBcAYgHTC7jGZBUCB1GXPLqxDSNcGlJvZzboBRbcpi1qurEMcY1 g/TjNJ+uQx2ZjU5MZW2ok6dZ1PGq7ghRexEQLMa9e98hNQUGCEicamXXDgFcj7fU gu4aYay1VJ8AUveCxq1NcFQZWzcPKXRnFx1UZVyBNr1t/oTtjBZLFw== =K0lG -----END PGP SIGNATURE----- From lutz at iks-jena.de Mon Jan 21 08:49:01 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Mon, 21 Jan 2008 13:49:01 +0000 (UTC) Subject: [dnssec-deployment] DNSSEC for ENUM References: Message-ID: * Michael Richardson wrote: > A hotel wants to prohibit VoIP/ENUM can just break the zone by > breaking DNSSEC, and that will cause a fallback to the hotels metered > PSTN. You are right. > Or do you think that breaking DNSSEC will cause sufficient > complaints that the hotel will get no money for the internet connection? *grin* That would be great. I might argue, that the green LED on the customers phone will be off. ;-)