This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[dns-wg] DNSSEC trust anchors for unsigned zones
- Previous message (by thread): [dns-wg] DNSSEC trust anchors for unsigned zones
- Next message (by thread): [dns-wg] DNSSEC trust anchors for unsigned zones
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Alexander Gall
gall at switch.ch
Wed Jan 30 16:24:34 CET 2008
On Wed, 30 Jan 2008 13:10:56 +0100, Joao Damas <Joao_Damas at 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
- Previous message (by thread): [dns-wg] DNSSEC trust anchors for unsigned zones
- Next message (by thread): [dns-wg] DNSSEC trust anchors for unsigned zones
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]