DNSSEC trust anchors for unsigned zones
Hi The current set of trust anchors distributed by RIPE NCC (<https://www.ripe.net/projects/disi/keys/ripe-ncc-dnssec-keys-new.txt>) 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 <https://www.ripe.net/projects/disi//keys/>). -- Alex
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.
On Wed, 30 Jan 2008 11:00:38 +0000, Jim Reid <jim@rfc1035.com> 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
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
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.
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
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
On Wed, 30 Jan 2008 13:10:56 +0100, Joao Damas <Joao_Damas@isc.org> 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
participants (5)
-
Alexander Gall -
bmanning＠vacation.karoshi.com -
Jim Reid -
Joao Damas -
Olivier Guillard / AFNIC