From Holger.Zuleger at hznet.de Thu Jan 3 16:54:19 2008 From: Holger.Zuleger at hznet.de (Holger Zuleger) Date: Thu, 03 Jan 2008 16:54:19 +0100 Subject: [dns-wg] =?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: From pawal at blipp.com Thu Jan 3 17:16:21 2008 From: pawal at blipp.com (Patrik Wallstrom) Date: Thu, 3 Jan 2008 17:16:21 +0100 Subject: [dns-wg] Re: [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: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From Holger.Zuleger at hznet.de Fri Jan 4 10:11:28 2008 From: Holger.Zuleger at hznet.de (Holger Zuleger) Date: Fri, 04 Jan 2008 10:11:28 +0100 Subject: [dns-wg] =?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: From richard.lamb at icann.org Fri Jan 4 20:30:19 2008 From: richard.lamb at icann.org (richard.lamb) Date: Fri, 4 Jan 2008 11:30:19 -0800 Subject: [dns-wg] =?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 jwkckid1 at ix.netcom.com Mon Jan 7 06:18:41 2008 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Sun, 06 Jan 2008 21:18:41 -0800 Subject: [dns-wg] Re: [apnic-talk] AAAA records to be added for root servers References: <49878589-D2C2-485F-98D2-4A57127CFDFB@icann.org> Message-ID: <4781B631.4957CE7F@ix.netcom.com> Barbara and all, Why only 4 root servers? Regards, Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1 at ix.netcom.com My Phone: 214-244-4827 Barbara Roseman wrote: > apologies for cross-posting... > > On 4 February 2008, IANA will add AAAA records for the IPv6 addresses > of the four root servers whose operators have requested it. A > technical analysis of inserting IPv6 records into the root has been > done by a joint working group of ICANN's Root Server System Advisory > Committee and Security and Stability Advisory Committee, a report of > which can be found at http://www.icann.org/committees/security/ > sac018.pdf. Network operators should take whatever steps they feel > appropriate to prepare for the inclusion of AAAA records in response > to root queries. > > More information will be posted to the IANA web site during January. > > Regards, > > Barbara Roseman > IANA General OperationsManager > ICANN > _______________________________________________ > apnic-talk mailing list > apnic-talk at lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/apnic-talk From wouter at NLnetLabs.nl Mon Jan 7 12:08:46 2008 From: wouter at NLnetLabs.nl (Wouter Wijngaards) Date: Mon, 07 Jan 2008 12:08:46 +0100 Subject: [dns-wg] =?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 Holger.Zuleger at hznet.de Mon Jan 7 14:24:22 2008 From: Holger.Zuleger at hznet.de (Holger Zuleger) Date: Mon, 07 Jan 2008 14:24:22 +0100 Subject: [dns-wg] =?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: From bmanning at vacation.karoshi.com Mon Jan 7 16:44:35 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 7 Jan 2008 15:44:35 +0000 Subject: [dns-wg] Re: [apnic-talk] AAAA records to be added for root servers In-Reply-To: <4781B631.4957CE7F@ix.netcom.com> References: <49878589-D2C2-485F-98D2-4A57127CFDFB@icann.org> <4781B631.4957CE7F@ix.netcom.com> Message-ID: <20080107154435.GA24769@vacation.karoshi.com.> perhaps your answer can be found in the first line of Barbaras message. let me quote it: "> On 4 February 2008, IANA will add AAAA records for the IPv6 addresses > of the four root servers whose operators have requested it. " .... for the four root servers whose operators have REQUESTED it. (emphasis added) e.g. the other operators have not requested AAAA records be added for their servers. --bill On Sun, Jan 06, 2008 at 09:18:41PM -0800, Jeffrey A. Williams wrote: > Barbara and all, > > Why only 4 root servers? > > Regards, > > Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) > "Obedience of the law is the greatest freedom" - > Abraham Lincoln > > "Credit should go with the performance of duty and not with what is > very often the accident of glory" - Theodore Roosevelt > > "If the probability be called P; the injury, L; and the burden, B; > liability depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. > div. of Information Network Eng. INEG. INC. > ABA member in good standing member ID 01257402 E-Mail > jwkckid1 at ix.netcom.com > My Phone: 214-244-4827 > > Barbara Roseman wrote: > > > apologies for cross-posting... > > > > On 4 February 2008, IANA will add AAAA records for the IPv6 addresses > > of the four root servers whose operators have requested it. A > > technical analysis of inserting IPv6 records into the root has been > > done by a joint working group of ICANN's Root Server System Advisory > > Committee and Security and Stability Advisory Committee, a report of > > which can be found at http://www.icann.org/committees/security/ > > sac018.pdf. Network operators should take whatever steps they feel > > appropriate to prepare for the inclusion of AAAA records in response > > to root queries. > > > > More information will be posted to the IANA web site during January. > > > > Regards, > > > > Barbara Roseman > > IANA General OperationsManager > > ICANN > > _______________________________________________ > > apnic-talk mailing list > > apnic-talk at lists.apnic.net > > http://mailman.apnic.net/mailman/listinfo/apnic-talk From gall at switch.ch Wed Jan 30 11:34:33 2008 From: gall at switch.ch (Alexander Gall) Date: Wed, 30 Jan 2008 11:34:33 +0100 Subject: [dns-wg] DNSSEC trust anchors for unsigned zones Message-ID: <18336.21177.386482.197736@hadron.switch.ch> Hi The current set of trust anchors distributed by RIPE NCC () includes the domains disi.nl example.net pwei.net None of these currently have any DNSSEC resource records (i.e. they are insecure), which effectively brakes those zones for everybody who uses that particular set of trust anchors. I guess this shows one of the operational problems with trust anchor management. These zones are not maintained by RIPE NCC itself and the administrators probably didn't bother to tell them that they've disabled DNSSEC (if they know or remember at all that their keys are distributed by a third party). I guess it would be more prudent for RIPE NCC to only distribute the keys for their own zones (those listed on ). -- Alex From jim at rfc1035.com Wed Jan 30 12:00:38 2008 From: jim at rfc1035.com (Jim Reid) Date: Wed, 30 Jan 2008 11:00:38 +0000 Subject: [dns-wg] DNSSEC trust anchors for unsigned zones In-Reply-To: <18336.21177.386482.197736@hadron.switch.ch> References: <18336.21177.386482.197736@hadron.switch.ch> Message-ID: <1E913564-F1A6-4944-B5A1-83267F23D23B@rfc1035.com> On Jan 30, 2008, at 10:34, Alexander Gall wrote: > The current set of trust anchors distributed by RIPE NCC includes > the domains > > disi.nl example.net pwei.net > > None of these currently have any DNSSEC resource records (i.e. they > are insecure), which effectively brakes those zones for everybody who > uses that particular set of trust anchors. Doesn't everyone check any third party's trust anchors before configuring them into their secure resolvers? > I guess it would be more prudent for RIPE NCC to only distribute > the keys for their own zones Indeed. Can someone from the NCC please explain why these keys (which appear to have nothing to do with the NCC) are present? I think it's also regrettable that this file seems to mix keys that are presumably for experimental purposes -- testing in the likes of example.net (say) -- with operational ones. Thanks for catching this Alex. You've given an extra requirement for the Trust Anchor Repository Task Force to consider. From gall at switch.ch Wed Jan 30 12:48:26 2008 From: gall at switch.ch (Alexander Gall) Date: Wed, 30 Jan 2008 12:48:26 +0100 Subject: [dns-wg] DNSSEC trust anchors for unsigned zones In-Reply-To: <1E913564-F1A6-4944-B5A1-83267F23D23B@rfc1035.com> References: <18336.21177.386482.197736@hadron.switch.ch> <1E913564-F1A6-4944-B5A1-83267F23D23B@rfc1035.com> Message-ID: <18336.25610.281641.626990@hadron.switch.ch> On Wed, 30 Jan 2008 11:00:38 +0000, Jim Reid said: > On Jan 30, 2008, at 10:34, Alexander Gall wrote: >> The current set of trust anchors distributed by RIPE NCC includes >> the domains >> >> disi.nl example.net pwei.net >> >> None of these currently have any DNSSEC resource records (i.e. they >> are insecure), which effectively brakes those zones for everybody who >> uses that particular set of trust anchors. > Doesn't everyone check any third party's trust anchors before > configuring them into their secure resolvers? Actually, I think this is an interesting but tricky question. Of course, everybody can eventually decide for themselves, which trust anchors they want to accept. However, if somebody you trust (the RIPE NCC in this case) gives you a list of domains which are supposed to be secure (which is really what this is all about), you're susceptible to a downgrade attack when you're willing to drop a trust anchor because you conclude that DNSSEC is not enabled for a zone from unsigned query responses that might all be spoofed. If you want to be really serious about this, you need to check with the distributor of the trust anchor and accept the zones to be bogus until things get fixed one way or the other. That would be pretty much what would happen if the parent zone was signed (and trusted) and had a DS record for the zone. -- Alex From jim at rfc1035.com Wed Jan 30 13:37:16 2008 From: jim at rfc1035.com (Jim Reid) Date: Wed, 30 Jan 2008 12:37:16 +0000 Subject: [dns-wg] DNSSEC trust anchors for unsigned zones In-Reply-To: <36D1B32E-8CC3-478F-8F23-469E29385794@isc.org> References: <18336.21177.386482.197736@hadron.switch.ch> <1E913564-F1A6-4944-B5A1-83267F23D23B@rfc1035.com> <36D1B32E-8CC3-478F-8F23-469E29385794@isc.org> Message-ID: On Jan 30, 2008, at 12:10, Joao Damas wrote: >> Doesn't everyone check any third party's trust anchors before >> configuring them into their secure resolvers? > > Sometimes. At other times I place trust in registries that do this > for me (eg a DLV registry that I find I can trust). IMO Joao a DLV is a trust anchor. Sort of. :-) What I really meant by trust anchor was "something you stick in a config file to tell a resolver what keys to use for DNSSEC validation". In BIND9, that would be a trusted-keys{} statement or a dnssec-lookaside clause. From Joao_Damas at isc.org Wed Jan 30 13:10:56 2008 From: Joao_Damas at isc.org (Joao Damas) Date: Wed, 30 Jan 2008 13:10:56 +0100 Subject: [dns-wg] DNSSEC trust anchors for unsigned zones In-Reply-To: <1E913564-F1A6-4944-B5A1-83267F23D23B@rfc1035.com> References: <18336.21177.386482.197736@hadron.switch.ch> <1E913564-F1A6-4944-B5A1-83267F23D23B@rfc1035.com> Message-ID: <36D1B32E-8CC3-478F-8F23-469E29385794@isc.org> On 30 Jan 2008, at 12:00, Jim Reid wrote: > On Jan 30, 2008, at 10:34, Alexander Gall wrote: > >> The current set of trust anchors distributed by RIPE NCC includes >> the domains >> >> disi.nl example.net pwei.net >> >> None of these currently have any DNSSEC resource records (i.e. they >> are insecure), which effectively brakes those zones for everybody who >> uses that particular set of trust anchors. > > Doesn't everyone check any third party's trust anchors before > configuring them into their secure resolvers? Sometimes. At other times I place trust in registries that do this for me (eg a DLV registry that I find I can trust). It's the same with SSL certificates, I have to trust the CA to do its job Joao From bmanning at vacation.karoshi.com Wed Jan 30 13:53:05 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 30 Jan 2008 12:53:05 +0000 Subject: [dns-wg] DNSSEC trust anchors for unsigned zones In-Reply-To: <36D1B32E-8CC3-478F-8F23-469E29385794@isc.org> References: <18336.21177.386482.197736@hadron.switch.ch> <1E913564-F1A6-4944-B5A1-83267F23D23B@rfc1035.com> <36D1B32E-8CC3-478F-8F23-469E29385794@isc.org> Message-ID: <20080130125305.GA16785@vacation.karoshi.com.> On Wed, Jan 30, 2008 at 01:10:56PM +0100, Joao Damas wrote: > > On 30 Jan 2008, at 12:00, Jim Reid wrote: > > >On Jan 30, 2008, at 10:34, Alexander Gall wrote: > > > >>The current set of trust anchors distributed by RIPE NCC includes > >>the domains > >> > >>disi.nl example.net pwei.net > >> > >>None of these currently have any DNSSEC resource records (i.e. they > >>are insecure), which effectively brakes those zones for everybody who > >>uses that particular set of trust anchors. > > > >Doesn't everyone check any third party's trust anchors before > >configuring them into their secure resolvers? > > Sometimes. At other times I place trust in registries that do this for > me (eg a DLV registry that I find I can trust). It's the same with SSL > certificates, I have to trust the CA to do its job > > Joao so... the thing one trusts == the trust anchor where one gets the thing trusted == the anchor source or some random third party, e.g. RIPE-NCC, Joao/ISC, Verisign, etc.. how one gets there == a config stmnt people refer to these three things as "trust anchors"... which is it folks? --bill From Olivier.Guillard at nic.fr Wed Jan 30 16:02:48 2008 From: Olivier.Guillard at nic.fr (Olivier Guillard / AFNIC) Date: Wed, 30 Jan 2008 16:02:48 +0100 Subject: [dns-wg] DNSSEC trust anchors for unsigned zones In-Reply-To: <20080130125305.GA16785@vacation.karoshi.com.> References: <18336.21177.386482.197736@hadron.switch.ch> <1E913564-F1A6-4944-B5A1-83267F23D23B@rfc1035.com> <36D1B32E-8CC3-478F-8F23-469E29385794@isc.org> <20080130125305.GA16785@vacation.karoshi.com.> Message-ID: <20080130150248.GA30731@james.nic.fr> Hi Bill, My comments, [in your text]: [one of] the thing[s] one trusts == the trust anchor [for a specific zone] where one gets [each of] the thing[s] trusted == the [known] anchor source[s] how one gets there == config stmnt[s] + As long as there is no recongized place[s] hard coded in DNS softwares. -- Olivier From gall at switch.ch Wed Jan 30 16:24:34 2008 From: gall at switch.ch (Alexander Gall) Date: Wed, 30 Jan 2008 16:24:34 +0100 Subject: [dns-wg] DNSSEC trust anchors for unsigned zones In-Reply-To: <36D1B32E-8CC3-478F-8F23-469E29385794@isc.org> References: <18336.21177.386482.197736@hadron.switch.ch> <1E913564-F1A6-4944-B5A1-83267F23D23B@rfc1035.com> <36D1B32E-8CC3-478F-8F23-469E29385794@isc.org> Message-ID: <18336.38578.600716.410325@hadron.switch.ch> On Wed, 30 Jan 2008 13:10:56 +0100, Joao Damas said: > On 30 Jan 2008, at 12:00, Jim Reid wrote: >> On Jan 30, 2008, at 10:34, Alexander Gall wrote: >> >>> The current set of trust anchors distributed by RIPE NCC includes >>> the domains >>> >>> disi.nl example.net pwei.net >>> >>> None of these currently have any DNSSEC resource records (i.e. they >>> are insecure), which effectively brakes those zones for everybody who >>> uses that particular set of trust anchors. >> >> Doesn't everyone check any third party's trust anchors before >> configuring them into their secure resolvers? > Sometimes. At other times I place trust in registries that do this for > me (eg a DLV registry that I find I can trust). It's the same with SSL > certificates, I have to trust the CA to do its job Yes. The subtle point I was trying to make was that once you've decided to trust a particular source of DNSSEC keys, you shouldn't throw away any of them based on your perceived status of a zone through plain DNS queries. If RIPE NCC would have chosen to use DLV, it would have put all keys that are now in the text file into the DLV zone and only hand out the public key of that zone. In that case, my validator would mark the three zones above as bogus - there would be no other choice except not to use this DLV registry at all. The way it is done now, I *technically* have the choice to exclude the keys for these zones from the set of trusted keys in my validator (this is what Jim suggests). The result would be that the zones are marked as insecure, which is a big difference. The question I'm rising is how I should handle this situation. I believe the answer (at least for the paranoid :-) is that I must install *all* keys and attribute the fact that, say, disi.nl is now bogus to malicious activity until either the zone gets properly signed or someone I trust tells me that the zone really is insecure. Before this happens, all I know is that someone I trust tells me the zone is secure but I can't verify it with the key this person is giving me. This ain't easy, I know. Security never is. Of course, people tend to be very pragmatic in a time where the root is not signed and everybody has to rely on some sort of out-of-band validation (we're all happy DNSSEC works on the protocol level, right?), but then I find the value of DNSSEC rather questionable. What a surprise ;-) -- Alex