From galvin at elistx.com Tue Apr 1 09:23:50 2008 From: galvin at elistx.com (James M Galvin) Date: Tue, 01 Apr 2008 09:23:50 -0400 Subject: TIME CHANGE: meeting announcement: 2 April 2008 Message-ID: <758626BFF6061759E6244C70@[192.168.1.3]> [[ TIME CHANGE: Note that most of the world has been moving to or from Daylight Savings Time, so the meeting time may have changed in your region. ]] This meeting will be held at the usual time of: 0700 Los Angeles, San Francisco 0700 Phoenix 0800 Salt Lake City 1000 Washington 1400 UTC 1500 London 1600 Netherlands 1700 Israel 2300 Tokyo 0100 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 # Toll Free and Local Numbers from around the world will be distributed separately. 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 * Trust Anchor Repositories A Trust Anchor Repository (TAR) is a repository or set of repositories, temporary or permanent, used to store Secure Entry Points (SEPs) for a set of DNSSEC islands of trust. In this discussion we will consider some examples of TARs and the reasons why they should or should not exist. Several folks have been invited to give short presentations that will be followed by general discussion. For those that are using slides you will find them here: http://dnssec-deployment.org/wg/materials/20080402 Steve Crocker - Introduction Joao Damas - DLV Daniel Karrenberg - RIPE and Trust Anchors Eric Osterweil - SecSpider Suresh Krishnaswamy - DNSSEC Trust Anchor Repositories (TARs) From galvin at elistx.com Tue Apr 1 09:32:01 2008 From: galvin at elistx.com (James M Galvin) Date: Tue, 01 Apr 2008 09:32:01 -0400 Subject: meeting toll free and local numbers: 2 April 2008 Message-ID: There is a list of toll-free dial-in numbers followed by a list of local phone numbers included below. These numbers are subject to change and will be distributed just prior to each meeting. I will open the teleconference 5 minutes before the start time so that those dialing these numbers can make sure they can connect. Please do start early if you are using one of these numbers. If you have trouble you will find me in the Jabber room. International Toll-Free Dial-In Number(s): If a Service Access Code (SAC Code) is listed next to the Number, it must be entered after dialing the number in order for the call to be connected. Argentina Dial-In #: 08003330711 Australia Dial-In #: 1800635054 Austria Dial-In #: 0800296166 Bahamas Dial-In #: 18002054782 Belgium Dial-In #: 080074091 Bolivia Dial-In #: 800100103<(Code 5129)> Brazil Dial-In #: 08008916311 Bulgaria Dial-In #: 008001100203 Chile Dial-In #: 12300206931 China N (China Netcom) Dial-In #: 108007130776 China S (China Telecom) Dial-In #: 108001300744 Colombia Dial-In #: 018009134022 Costa Rica Dial-In #: 08000131036 Croatia (Hrvatska) Dial-In #: 0800222650 Cyprus Dial-In #: 80094945 Czech Republic Dial-In #: 800142297 Denmark Dial-In #: 80886120 Dominican Republic Dial-In #: 18887518389 Egypt Dial-In #: 3640083<(Code 5139)> El Salvador Dial-In #: 8006375 France Dial-In #: 0800905437 Germany Dial-In #: 08001821592 Greece Dial-In #: 0080018092024132 Hong Kong Dial-In #: 800901136 Hungary Dial-In #: 0680018610 Iceland Dial-In #: 8008083 India Dial-In #: 0008001006245 Indonesia Dial-In #: 0018030152021817 Ireland Dial-In #: 1800559980 Israel Dial-In #: 1809245950 Italy Dial-In #: 800870179 Jamaica Dial-In #: 18664255996 Japan Dial-In #: 00531160597 Kenya Dial-In #: 0800220115<(Code 5139)> Korea (South) Dial-In #: 00308131716 Latvia Dial-In #: 80002398 Lithuania Dial-In #: 880030328 Lithuania Dial-In #: 880030339 Luxembourg Dial-In #: 80025977 Malaysia Dial-In #: 1800812568 Mexico Dial-In #: 0018887579483 Monaco Dial-In #: 80093352 Netherlands Dial-In #: 08000226187 New Zealand Dial-In #: 0800446292 Nicaragua Dial-In #: 18000551<(Code 5105)> Norway Dial-In #: 80015566 Panama Dial-In #: 0018002024405 Peru Dial-In #: 080053332 Poland Dial-In #: 008001113741 Portugal Dial-In #: 800813478 Romania Dial-In #: 0218005030<(Code 5105)> Russian Federation Dial-In #: 81080025511012 Singapore Dial-In #: 8001011804 Slovak Republic Dial-In #: 0800042139 South Africa Dial-In #: 0800980259 Spain Dial-In #: 900941729 Sweden Dial-In #: 020797609 Switzerland Dial-In #: 0800561650 Taiwan Dial-In #: 00801148742 Thailand Dial-In #: 001800132024591 Trinidad and Tobago Dial-In #: 18002024620 United Kingdom Dial-In #: 08082348621 Uruguay Dial-In #: 00040190132 Venezuela Dial-In #: 8001627195 Local Dial-In Numbers Dial-In #: Vienna Dial-In #: 019281063 Antwerp Dial-In #: 034000310 Brussels Dial-In #: 024003531 Copenhagen Dial-In #: 032714405 Lyon Dial-In #: 0426031129 Marseille Dial-In #: 0486060057 Paris Dial-In #: 0176748990 Toulouse Dial-In #: 0567804153 Berlin Dial-In #: 030590024927 Frankfurt Dial-In #: 06922221674 Hamburg Dial-In #: 040809020734 Dublin Dial-In #: 012475629 Milan Dial-In #: 0236049233 Rome Dial-In #: 0645230543 Rotterdam Dial-In #: 0107114853 Lisbon Dial-In #: 01211201028 Singapore Dial-In #: 0282239877 Barcelona Dial-In #: 0934923275 Madrid Dial-In #: 914142527 Stockholm Dial-In #: 0850619596 Geneva Dial-In #: 0225803308 Zurich Dial-In #: 0445807165 London Dial-In #: 02031070236 Jim From eoster at cs.ucla.edu Wed Apr 2 10:03:58 2008 From: eoster at cs.ucla.edu (Eric Osterweil) Date: Wed, 2 Apr 2008 07:03:58 -0700 Subject: SecSpider Presentation Message-ID: Hey Everyone, Here are the slides from our presentation today: -------------- next part -------------- A non-text attachment was scrubbed... Name: SecSpider-final-2008-04-02.pdf Type: application/pdf Size: 183222 bytes Desc: not available Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20080402/c2c25d1e/attachment.pdf -------------- next part -------------- Sorry for the lateness of this email, Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20080402/c2c25d1e/attachment.bin From lutz at iks-jena.de Wed Apr 2 10:19:30 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 2 Apr 2008 16:19:30 +0200 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 11791 signed zones: 1482 -21 Entry Point 9621 +1 Test 17 +13 broken chain 585 +89 chained 0 new 86 -7 unreachable Top 10 autonomous systems injecting DNSSec zones: 697 -13 AS25537 462 -4 AS15725 137 +1 AS1280 86 +1 AS22548 78 AS3333 71 AS3245 70 +70 AS4230 42 AS24776 31 AS3265 28 AS39570 Top 10 TLD containing DNSSec zones: 697 -13 RU 291 ARPA 231 +91 BR 229 -2 DE 165 -5 COM 123 +1 ORG 91 +1 SE 71 BG 57 -1 NET 35 FR 33 (+2) weak keys: 55.129.in-addr.arpa, 124.32.198.in-addr.arpa, omnity.biz, jfce.jus.br sandelman.ottawa.on.ca, arakelian.com, intra-links.com, lecorvaisier.com nikomotos.com, agent-factory.de, the-agent-factory.de, bethelks.edu ll.mit.edu, aarechargement.fr, gigamax.fr, guiraudsa.fr, intra-links.fr john-nathan.fr, lbpdecoration.fr, lesbeauxpapiers.fr, vrai-decor.fr intra-links.net, kfuq.net, daedelys.org, rp.secret-wg.org, interlan.se keyserver.se, skabb.se, spam112.se, staver.se, umdac.se, vfqa.se, zkt.se 17 (+13) broken DS chains: 228.111.193.in-addr.arpa, sparta.dnsops.biz, jfac.jus.br, jfam.jus.br jfap.jus.br, jfba.jus.br, jfce.jus.br, jfdf.jus.br, jfma.jus.br jfmg.jus.br, jfpe.jus.br, jfro.jus.br, jfrr.jus.br, trf1.jus.br ornl.dnsops.gov, ipv4.stack.nl, bitstring.se 26 (+1) parent DS to unsigned zones: 0.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, lobbi.bg, niet.verweg.com, blopp.se hogskolaniboras.se, klan-csa.se, kristianstadpower.se, lyrek.se, mirall.se tshirttryck.se, xn--botsmarksdck-pcb.se 30 (-2) unnecessary islands: 8.4.e164.arpa, 9.9.6.2.2.8.4.e164.arpa, 8.0.6.4.1.4.6.3.9.4.e164.arpa 3.7.5.1.4.6.3.9.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, 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, 1.0.0.0.e.4.7.c.3.6.8.d.2.0.0.2.ip6.arpa e.8.1.c.8.0.3.0.1.0.a.2.ip6.arpa, metalplast.bg, cerebrohidroponico.blog.br digitaltv.blog.br, pixaco.com.br, eficacia.eng.br, bw.nist.gov rev.faelix.net, signed.dnssec-test.org, autonomica.se, skabb.se, staver.se xn--lda-ula.xn--ihrn-dpa.se, zkt.se 86 (-7) unreachable zones: Top 10 autonomous systems containing unreachable zones: 32 -5 AS25537 12 AS5537 8 +1 AS15725 5 -1 AS39570 3 AS1280 3 +3 AS18881 1 AS10466 1 AS24776 1 +1 AS3292 1 AS4436 -- Detailed list: https://www.iks-jena.de/leistungen/dnssec.php From lutz at iks-jena.de Wed Apr 2 10:25:29 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 2 Apr 2008 14:25:29 +0000 (UTC) Subject: [dnssec-deployment] Mal ein paar DNSSEC Statistiken / Some DNSSEC statistics References: Message-ID: * Lutz Donnerhacke wrote: > 17 (+13) broken DS chains: > ..., jfac.jus.br, jfam.jus.br, jfap.jus.br, jfba.jus.br, jfce.jus.br > jfdf.jus.br, jfma.jus.br, jfmg.jus.br, jfpe.jus.br, jfro.jus.br > jfrr.jus.br, trf1.jus.br, ... It's interesting, how quick operational errors occur when a larger deployment does happen. From thierry.moreau at connotech.com Sun Apr 6 20:18:15 2008 From: thierry.moreau at connotech.com (Thierry Moreau) Date: Sun, 06 Apr 2008 19:18:15 -0500 Subject: More about Trust Anchor Registries Message-ID: <47F96847.1000304@connotech.com> Dear dnssec deployment enthusiasts: A record of the current state of the DNSSEC TAR scene would be incomplete without a reference to some of my work. Given that some of you just "can't read" documents I authored because I did file patent applications, there is the following caveat notice to the reader: some otherwise knowledgeable experts in the field may suffer from an ill-defined inability to read, and perhaps even just ear about, the material presented here. Not all readers are in this situation. Moving to the topic of DNSSEC TAR (Trust Anchor Repository), there are two main rationales and two main challenge: (A) DNSSEC TAR operations are justified by the lack of DNSSEC support at the IANA root. (B) DNSSEC TAR operations are justified by the lack of DNSSEC support in large TLD zones. (C) A foremost challenge faced equally by an RFC-compliant DNSSEC deployment and any serious TAR operation is the "authentic" registration of secure delegations or TAR entries. (D) Preferably, a TAR deployment strategy needs the potential to increase market penetration rapidly. Here is the list of alternatives: (1) Actions that may be taken to overturn (A) and/or (B) through RFC-compliant DNSSEC deployment. Support of the fairly new NSEC3 Opt-Out option specifications (RFC5155) falls in this category for the purpose of my comment. (2) DLV, e.g. the DLV operation by ISC. (3) "Opt-in Secure Delegation Operations" as one of the roles - targeting rationale (B) above - in the document "Six Roles for Early Introduction of DNSSEC" available at http://www.connotech.com/six_roles_for_dnssec.pdf . This, the "MOPTIN proposal," works well in tandem with DNSSEC-enabled root nameservice, targeting rationale (A) above. (4) An alternative using PKI by Roy Arends, which I could trace to a mailing group message "dnssec automatic trust anchor configuration" on March 8th, 2007, at http://mail.shinkuro.com:8100/lists/dnssec-deployment/Message/585.html This message closes with "DLV is just another CA, no matter how you'd brand it," although the respective practical implementation are quite different. Here are a few observations: Contrary to DLV, the MOPTIN proposal requires no on-line presence for the purpose of rationale (B), but it does require alternate root nameservice for rationale (A). This suggests that the MOPTIN proposal works well for either communities of interest or enterprise/local environments. The SecSpider project addresses the challenge (C) with redundancy in the data collection process, and the level of trust in the resulting TAR is up to the resolver operator to decide (this is always the case anyway). The ISC DLV procedure takes the more classical approach to do something to ensure TAR registration authenticity at the individual registration granularity. This latter approach applies to the MOPTIN proposal because a specific DNSKEY RR in a zone apex (plus an RRSIG RR) conveys the information that the zone manager did enrol in the Opt-In program. The alternative using PKI appears to rely on the established X.509 security certificate issuance practice. Accordingly, the proposal (3) requires centralized institutional support for challenge (C), having no on-line presence for name resolution, and fragmented on-line presence for root nameservice targeting respective communities of interest or enterprise/local environments. This is based on the assumption that an alternate root of general applicability has virtually no chance of success. The separation of roles is further explained in the reference. The centralized institutional approach should appeal to those who fear the consequences of multiple TAR operations, e.g. for challenge (D). Moreover, centralization is actually facilitated by the patent pending status of the Opt-In process. So, the proposal (3) may be looked as an opportunity for early introduction of DNSSEC. In any event, maybe the foremost lesson in this post is that challenge (C) - operating a TAR with a formalized basis for ensuring TAR entry authenticity - is the single most important obstacle, and the technological approach is (almost) of secondary relevance. If I step back further from the details of the subject area, cryptography neither protects data (integrity in the case of DNSSEC) nor automates incident avoidance, it merely shifts (and concentrates when key management is properly worked out) IT controls. Now that the DNSSEC crypto is well defined in RFCs, the focus inevitably moves to institutional and economic aspects of IT controls. Thanks to those who read, I enjoyed the opportunity to clarify my thoughts. Regards to all, -- - 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 Olivier.Guillard at nic.fr Wed Apr 16 06:33:13 2008 From: Olivier.Guillard at nic.fr (Olivier Guillard / AFNIC) Date: Wed, 16 Apr 2008 12:33:13 +0200 Subject: No subject Message-ID: <20080416103313.GA562@james.nic.fr> FYI, this is the last communication from IANA to ccs about DNSSEC : http://www.aftld.org/SA2008/docs/presentations/Day3/kjd-johannesburg-dnssec-080410.pdf Comments ? Best regards, -- Olivier From lutz at iks-jena.de Wed Apr 16 07:11:22 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 16 Apr 2008 11:11:22 +0000 (UTC) Subject: End of Testbed? Message-ID: nsec3.jelte.nlnetlabs.nl seem to be dead or misconfigured. What happend? ; <<>> DiG 9.4.2 <<>> DNSKEY ok.nsec3.jelte.nlnetlabs.nl +trace nl. NS NS-NL.NIC.FR. nl. NS NS2.NIC.nl. nl. NS NS-EXT.ISC.ORG. nl. NS NS.DOMAIN-REGISTRY.nl. nl. NS NS3.NIC.nl. nl. NS NS4.NIC.nl. nl. NS NL1.DNSNODE.NET. nl. NSEC NO. NS RRSIG NSEC nl. RRSIG NSEC 5 1 86400 20080423190741 ( 20080324220042 64955 . JgG+S2Jqd3CqR05rU5bq/Ykh5gEn7Ohpcg== ) ;; Received 737 bytes from 2001:4bd8::53#53(a.dnssec-root.iks-jena.de) in 2 ms nlnetlabs.nl. NS open.nlnetlabs.nl. nlnetlabs.nl. NS omval.tednet.nl. nlnetlabs.nl. NS ns7.domain-registry.nl. ;; Received 168 bytes from 194.146.106.42#53(NL1.DNSNODE.NET) in 37 ms jelte.nlnetlabs.nl. NS ns.tjeb.nl. jelte.nlnetlabs.nl. DS 31560 5 1 ( 1CFED84787E6E19CCF9372C1187325972FE546CD ) jelte.nlnetlabs.nl. RRSIG DS 5 3 3600 20080429005004 ( 20080401005004 18182 nlnetlabs.nl. EO51dVdmjGTGa5UCYuVfLn2H3HR04Wj9+2niC+o= ) ;; Received 286 bytes from 62.4.86.230#53(ns7.domain-registry.nl) in 28 ms ok.nsec3.jelte.nlnetlabs.nl. NS jelte.nlnetlabs.nl.nsec3.jelte.nlnetlabs.nl. ok.nsec3.jelte.nlnetlabs.nl. RRSIG NS 5 5 600 20080227170230 ( 20080130170230 3105 nsec3.jelte.nlnetlabs.nl. DeMbzOQUmvDU3q8rv1GRpIO7hN1PKe3vXFrdw1k= ) ok.nsec3.jelte.nlnetlabs.nl. DS 12840 5 1 ( 0CDB215BCDB064AA7C7F620951C907634ABB7385 ) ok.nsec3.jelte.nlnetlabs.nl. RRSIG DS 5 5 3600 20080227170230 ( 20080130170230 3105 nsec3.jelte.nlnetlabs.nl. WsVaT42RVmPSJv0vags1ujxMVmQ+DVWkuk3uDvI= ) ;; Received 493 bytes from 195.169.221.157#53(ns.tjeb.nl) in 30 ms dig: couldn't get address for 'jelte.nlnetlabs.nl.nsec3.jelte.nlnetlabs.nl' From Shane_Kerr at isc.org Wed Apr 16 08:14:29 2008 From: Shane_Kerr at isc.org (Shane Kerr) Date: Wed, 16 Apr 2008 14:14:29 +0200 Subject: [dnssec-deployment] In-Reply-To: References: Message-ID: Olivier, On Apr 16, 2008, at 12:33 +0200, Olivier Guillard / AFNIC wrote: > FYI, > > this is the last communication from IANA to ccs > about DNSSEC : > > http://www.aftld.org/SA2008/docs/presentations/Day3/kjd-johannesburg-dnssec-080410.pdf > > Comments ? I was a bit daunted because there are so many slides, but each one only takes a second or two to look at. Seems like a very good overview and explanation of the current DNSSEC situation. Hard to know what the hell is going on with the ribbons if you only see the slides and not the corresponding talk. This is probably a side effect of slides being a suckful means of communicating data rather than a problem with the presentation though. :) -- Shane From jelte at NLnetLabs.nl Wed Apr 16 08:24:48 2008 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Wed, 16 Apr 2008 14:24:48 +0200 Subject: [dnssec-deployment] End of Testbed? In-Reply-To: References: Message-ID: <4805F010.5040105@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lutz Donnerhacke wrote: > nsec3.jelte.nlnetlabs.nl seem to be dead or misconfigured. > What happend? > just a misconfiguration, should be fixed now. (or better; fixed for now; since this tree and the surrounding ones are so experimental that if they had a logo, those would have 'beta' in the lower right corner) Thanks for noticing Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgF8BAACgkQ4nZCKsdOncVnMgCfYaNiz3Uu63vzwwYebSPvtlz1 0uYAn1wZal1O37cZupdqLk+5H9jXUm0b =Ainr -----END PGP SIGNATURE----- From Anne-Marie.Eklund-Lowinder at iis.se Wed Apr 16 11:15:38 2008 From: Anne-Marie.Eklund-Lowinder at iis.se (=?iso-8859-1?Q?Anne-Marie_Eklund-L=F6winder?=) Date: Wed, 16 Apr 2008 17:15:38 +0200 Subject: SV: [dnssec-deployment] In-Reply-To: References: Message-ID: <023E9DDFC555E3479AEBF917CE60A0B4019F375A@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Except from the fact that I think it is a brilliant, easy to understand, explanation of DNSSEC and signing the root? No, no comments.:) Anne-Marie 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 > -----Ursprungligt meddelande----- > Fr?n: DNSSEC deployment > [mailto:dnssec-deployment at shinkuro.com] F?r Olivier Guillard / > AFNIC Skickat: den 16 april 2008 12:33 > Till: DNSSEC deployment > ?mne: [dnssec-deployment] > > FYI, > > this is the last communication from IANA to ccs about DNSSEC : > > http://www.aftld.org/SA2008/docs/presentations/Day3/kjd-johann > esburg-dnssec-080410.pdf > > Comments ? > > Best regards, > > -- > Olivier > > ############################################################# > 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 > -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBSAYYGaXc8AFCsc+UEQIPwwCgllFMx5u4BB+nW7O33TiaEEuurCIAoMjo vYDwGBomeUiNd2jRcGPMdcbI =rxBi -----END PGP SIGNATURE----- From regnauld+dnssec at catpipe.net Wed Apr 16 16:32:44 2008 From: regnauld+dnssec at catpipe.net (Phil Regnauld) Date: Wed, 16 Apr 2008 22:32:44 +0200 Subject: IANA communication to ccs In-Reply-To: <20080416103313.GA562@james.nic.fr> References: <20080416103313.GA562@james.nic.fr> Message-ID: <20080416203244.GB9210@catpipe.net> Olivier Guillard / AFNIC (Olivier.Guillard) writes: > FYI, > > this is the last communication from IANA to ccs > about DNSSEC : > > http://www.aftld.org/SA2008/docs/presentations/Day3/kjd-johannesburg-dnssec-080410.pdf > > Comments ? No mention of DLV. Phil From pk at DENIC.DE Thu Apr 24 05:11:10 2008 From: pk at DENIC.DE (Peter Koch) Date: Thu, 24 Apr 2008 11:11:10 +0200 Subject: DNSSEC and registry data escrow Message-ID: <20080424091110.GA3091@unknown.office.denic.de> Colleagues, the DNSSEC related parts of the data escrow covered in Registry Agreements have been discussed here before, especially the value and risk of putting ZSK and/or KSK private keys under escrow. shows a proposal to change this obligation and essentially keep the private keys private. Lacking further detail of a handover/contingency scenario this raises the question of validity periods. Any thoughts? -Peter From thierry.moreau at connotech.com Thu Apr 24 05:52:04 2008 From: thierry.moreau at connotech.com (Thierry Moreau) Date: Thu, 24 Apr 2008 04:52:04 -0500 Subject: [dnssec-deployment] DNSSEC and registry data escrow In-Reply-To: References: Message-ID: <48105844.2080504@connotech.com> Peter Koch wrote: > Colleagues, > > the DNSSEC related parts of the data escrow covered in Registry Agreements > have been discussed here before, especially the value and risk of putting > ZSK and/or KSK private keys under escrow. > > shows a proposal to change this obligation and essentially keep the private > keys private. Lacking further detail of a handover/contingency scenario this > raises the question of validity periods. Any thoughts? > If the root is signed, the TLD KSK key loss (e.g. following a collapse of the TLD operator) is recovered through an update of the root zone secure delegation (with a DS record pointing to the KSK for the new TLD operator). No need of private key escrow. Private key distribution through the escrow mechanism would be detrimental to the TLD signing process security, as with any avoidable private key handling. Hence the abovementioned amendment seems justified. - Thierry Moreau From richard.lamb at icann.org Thu Apr 24 11:19:27 2008 From: richard.lamb at icann.org (Richard Lamb) Date: Thu, 24 Apr 2008 08:19:27 -0700 Subject: [dnssec-deployment] DNSSEC and registry data escrow In-Reply-To: References: Message-ID: <5751D739B8779944939698FBC816B7CE354F01F60B@EXVMBX016-2.exch016.msoutlookonline.net> Without my ICANN hat on - I agree with Thierry. Security and questions of such control make externally holding the private KSK a dangerous path to go down. -----Original Message----- From: DNSSEC deployment [mailto:dnssec-deployment at shinkuro.com] On Behalf Of Thierry Moreau Sent: Thursday, April 24, 2008 2:52 AM To: DNSSEC deployment Cc: Peter Koch Subject: Re: [dnssec-deployment] DNSSEC and registry data escrow Peter Koch wrote: > Colleagues, > > the DNSSEC related parts of the data escrow covered in Registry Agreements > have been discussed here before, especially the value and risk of putting > ZSK and/or KSK private keys under escrow. > > shows a proposal to change this obligation and essentially keep the private > keys private. Lacking further detail of a handover/contingency scenario this > raises the question of validity periods. Any thoughts? > If the root is signed, the TLD KSK key loss (e.g. following a collapse of the TLD operator) is recovered through an update of the root zone secure delegation (with a DS record pointing to the KSK for the new TLD operator). No need of private key escrow. Private key distribution through the escrow mechanism would be detrimental to the TLD signing process security, as with any avoidable private key handling. Hence the abovementioned amendment seems justified. - Thierry Moreau ############################################################# 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 richard.lamb at icann.org Thu Apr 24 11:58:18 2008 From: richard.lamb at icann.org (Richard Lamb) Date: Thu, 24 Apr 2008 08:58:18 -0700 Subject: [dnssec-deployment] DNSSEC and registry data escrow In-Reply-To: References: Message-ID: <5751D739B8779944939698FBC816B7CE354F01F64B@EXVMBX016-2.exch016.msoutlookonline.net> (no hats) I would expect the RSTEP process will consider in more detail the handover/contingency scenarios. Signature validity periods would be something to consider. Just thinking out loud here, it seems with a signed root (or other mechanism for distributing TLD DS records), the handover timeframe could be technically limited to the time it takes to put a new DS record (+NxTTL) in the root. However, organizational issues would take far longer. I am sure there are many more on this list that understand the handover problem far better than I but here is what I think. Pre-handover root: org. DS-old Transition to entity A: org. DS-old org. DS-A completed handover: org. DS-A A sudden or expected handover might require the introduction of DS-A before actual transition (and an alternate signed zone file with its own ZSKs) if we were to attempt to avoid a period of an unsigned zone so that the expiry of ZSK RRSIGs could be avoided. If this couldn't be done, simply removing DS-old might cause the least amount of damage until A could come on line. Anyway, I don't think the security tradeoff of an escrowed private key (actual and perceived) is worth it for such rare events. But that's just my own view. However from a purely legal/business view, where there is a chain of sufficiently financially responsible/insured parties involved in the process, key escrow would be fine with me. Lawyers scare me ;-) -Rick -----Original Message----- From: DNSSEC deployment [mailto:dnssec-deployment at shinkuro.com] On Behalf Of Peter Koch Sent: Thursday, April 24, 2008 2:11 AM To: DNSSEC deployment Subject: [dnssec-deployment] DNSSEC and registry data escrow Colleagues, the DNSSEC related parts of the data escrow covered in Registry Agreements have been discussed here before, especially the value and risk of putting ZSK and/or KSK private keys under escrow. shows a proposal to change this obligation and essentially keep the private keys private. Lacking further detail of a handover/contingency scenario this raises the question of validity periods. Any thoughts? -Peter ############################################################# 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 steve at shinkuro.com Thu Apr 24 12:01:01 2008 From: steve at shinkuro.com (Steve Crocker) Date: Thu, 24 Apr 2008 12:01:01 -0400 Subject: [dnssec-deployment] DNSSEC and registry data escrow In-Reply-To: References: Message-ID: I raised this same point in an internal review of the contractual language quite some ago. I am pressing this point again. The educational point is that escrow is good for protecting against loss of data, but the fundamental requirement for private keys is to protect against disclosure. Loss of private keys is perhaps annoying but tolerable, but disclosure is not tolerable. In contrast, disclosure of the rest of the data in a registry is perhaps undesirable, it's not as severe as if the data is lost. Steve On Apr 24, 2008, at 11:19 AM, Richard Lamb wrote: > Without my ICANN hat on - I agree with Thierry. Security and > questions of such control make externally holding the private KSK a > dangerous path to go down. > > -----Original Message----- > From: DNSSEC deployment [mailto:dnssec-deployment at shinkuro.com] On > Behalf Of Thierry Moreau > Sent: Thursday, April 24, 2008 2:52 AM > To: DNSSEC deployment > Cc: Peter Koch > Subject: Re: [dnssec-deployment] DNSSEC and registry data escrow > > > > Peter Koch wrote: > >> Colleagues, >> >> the DNSSEC related parts of the data escrow covered in Registry >> Agreements >> have been discussed here before, especially the value and risk of >> putting >> ZSK and/or KSK private keys under escrow. >> > amendment-23apr08.pdf> >> shows a proposal to change this obligation and essentially keep >> the private >> keys private. Lacking further detail of a handover/contingency >> scenario this >> raises the question of validity periods. Any thoughts? >> > > If the root is signed, the TLD KSK key loss (e.g. following a collapse > of the TLD operator) is recovered through an update of the root zone > secure delegation (with a DS record pointing to the KSK for the new > TLD > operator). No need of private key escrow. > > Private key distribution through the escrow mechanism would be > detrimental to the TLD signing process security, as with any avoidable > private key handling. > > Hence the abovementioned amendment seems justified. > > - Thierry Moreau > > > ############################################################# > 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 > > > ############################################################# > 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 roy at dnss.ec Thu Apr 24 12:16:38 2008 From: roy at dnss.ec (Roy Arends) Date: Thu, 24 Apr 2008 18:16:38 +0200 Subject: [dnssec-deployment] DNSSEC and registry data escrow In-Reply-To: References: Message-ID: <21B14ED2-C036-413A-84F1-1648048B49F0@dnss.ec> On Apr 24, 2008, at 11:11 AM, Peter Koch wrote: > Colleagues, > > the DNSSEC related parts of the data escrow covered in Registry > Agreements > have been discussed here before, especially the value and risk of > putting > ZSK and/or KSK private keys under escrow. > > > shows a proposal to change this obligation and essentially keep the > private > keys private. That looks promising. > Lacking further detail of a handover/contingency scenario this > raises the question of validity periods. Any thoughts? I am not sure what you mean by 'validity periods'. There is another issue to keep in mind though. Assume the fictional tld .PQR, which deploys dnssec, and is run by BadAttitude Inc. The .PQR have well known trust anchors and are configured at many secure resolvers. Now .PQR is being re-delegated to DomainLove, and BadAttitude acts in bad faith. Without the proper private key in DomainLove's hands, all these secure resolvers will need to reconfigure their trust anchor. Until then, secure resolver can not resolve .PQR domains. I totally agree that the private key should not be put in escrow. There is a solution to this paradox. A requirement that the private key signs a dummy key with a dummy dnssec algorithm. The signature over this dummy key is then given to ICANN. In case of bad faith by BadAttitude, the .PQR zone can be deployed by DomainLove, using a dummy key not understood by any secure-resolver, which now can continue to resolve .PQR unsecurely. This solve the key escrow issue while guaranteeing continued deployment of .PQR. Roy From thierry.moreau at connotech.com Thu Apr 24 14:47:31 2008 From: thierry.moreau at connotech.com (Thierry Moreau) Date: Thu, 24 Apr 2008 13:47:31 -0500 Subject: [dnssec-deployment] DNSSEC and registry data escrow In-Reply-To: References: Message-ID: <4810D5C3.7050704@connotech.com> Richard Lamb wrote: > (no hats) > > [...] will consider in more detail [...] > > [...] would be something to consider. [...] thinking out loud here, [...] > > [...] understand the handover problem [...] > > [...] A sudden or expected handover might [...] attempt to avoid a period of [...] might cause the least amount of damage [...] just my own view [...] a chain of sufficiently financially responsible/insured parties [...] and then: > Lawyers scare me ^^^^^^^^^^^^^^^^ With the above language, you, the expert, may well scare the lawyers. The lawyer question to the experts is fairly simple: does it make sense NOT TO ESCROW A gTLD KSK? Yes, or no? At one point, I thought the question needed not to be asked (assuming consensual engineering sense would provide the correct interpretation of generic contract language). Now that the PIR management decided to ask, the simple question deserves an answer. Preferably a simple one. -- - 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