[DNSOP] DS vs DNSKEY trust anchors, was Re: Truncation...
At 8:19 +1100 3/11/09, Mark Andrews wrote: In message a06240804c5dc2ddef...@[10.31.200.116], Edward Lewis writes: record involves less typing than a DNSKEY, I'd want to work with a DS record. Has anyone on this list ever typed in a DNSKEY or DS as a trust anchor? I would presume that most (99.%) people work with != type in At 10:40 +1100 3/11/09, Mark Andrews wrote: I have a new key I want to introduce. I add the DS to the parent zone at least the ttl(ds) before I start using that key in the zone. After the DS has been published for ttl(ds) I can then replace the DNSKEY referred to by the old DS with that of the new DS and re-sign the DNSKEY RRset. Once the ttl(dnskey) has expired I can remove the old DS from the parent zone. I wish to be able to do something similar with trust anchors. Publishing DS prevents me from doing so. There is more than one way to do a key supersession. I'll describe one assuming DS records are installed as trust anchors. DS(KEY1) is in my validator. The owner of KEY1 distributes DS(KEY2) with a note that it should be installed by the 15th. On the 15th, DNSKEY(KEY2) is placed in the zone and KEY2 only is used to sign the keyset. With a 1 week TTL on the key set's RRSIG RR, a week later DNSKEY(KEY1) is removed from the set. At some point after that I can remove DS(KEY1) from my validator. Perhaps the special case here is that the keyset is unique in that the signatures for SEP/KSK's are tied to the where the key data is. I.e., if you have something signed by KEY1, then you have KEY1 because that something has to be the key set. If the zone is not run with a KSK/ZSK split, then the removal of KEY1 is triggered by signing the last RR set by KEY2 and then the TTL. The principle here is that there is no error if for a DS record there is no corresponding DNSKEY and vice versa. All that is needed for validation is one chain of trust. Accepting dangling references is not optimal but provides robustness. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DS vs DNSKEY trust anchors, was Re: Truncation...
In message a06240800c5dd7e5f2...@[10.31.200.116], Edward Lewis writes: At 8:19 +1100 3/11/09, Mark Andrews wrote: In message a06240804c5dc2ddef...@[10.31.200.116], Edward Lewis writes: record involves less typing than a DNSKEY, I'd want to work with a DS record. Has anyone on this list ever typed in a DNSKEY or DS as a trust anchor? I would presume that most (99.%) people work with != type in At 10:40 +1100 3/11/09, Mark Andrews wrote: I have a new key I want to introduce. I add the DS to the parent zone at least the ttl(ds) before I start using that key in the zone. After the DS has been published for ttl(ds) I can then replace the DNSKEY referred to by the old DS with that of the new DS and re-sign the DNSKEY RRset. Once the ttl(dnskey) has expired I can remove the old DS from the parent zone. I wish to be able to do something similar with trust anchors. Publishing DS prevents me from doing so. There is more than one way to do a key supersession. I'll describe one assuming DS records are installed as trust anchors. DS(KEY1) is in my validator. The owner of KEY1 distributes DS(KEY2) with a note that it should be installed by the 15th. On the 15th, DNSKEY(KEY2) is placed in the zone and KEY2 only is used to sign the keyset. With a 1 week TTL on the key set's RRSIG RR, a week later DNSKEY(KEY1) is removed from the set. At some point after that I can remove DS(KEY1) from my validator. Perhaps the special case here is that the keyset is unique in that the signatures for SEP/KSK's are tied to the where the key data is. I.e., if you have something signed by KEY1, then you have KEY1 because that something has to be the key set. If the zone is not run with a KSK/ZSK split, then the removal of KEY1 is triggered by signing the last RR set by KEY2 and then the TTL. The principle here is that there is no error if for a DS record there is no corresponding DNSKEY and vice versa. All that is needed for validation is one chain of trust. Accepting dangling references is not optimal but provides robustness. Ed, I'm aware there are multiple ways to do this. However publishing DS records only precludes some methods. Publishing DNSKEY records does not preclude any methods as one can *ALWAYS* generate a DS from a DNSKEY. The reverse requires you to look up a key which matches which means it must be available to be available to be looked up. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DS vs DNSKEY trust anchors, was Re: Truncation...
You poor souls. The DNSSEC monster is vast and complex. So much easier just to fix the problem instead of this endless gibberish. It's so complex it's funny when you consider a simple solution like DNSCURVE - http://dnscurve.org/ - and so much more secure. No man in the middle issues. Oh well - sorry for the interruption - and carry on. cheers joe baptista On Wed, Mar 11, 2009 at 10:57 AM, Edward Lewis ed.le...@neustar.biz wrote: At 8:19 +1100 3/11/09, Mark Andrews wrote: In message a06240804c5dc2ddef...@[10.31.200.116], Edward Lewis writes: record involves less typing than a DNSKEY, I'd want to work with a DS record. Has anyone on this list ever typed in a DNSKEY or DS as a trust anchor? I would presume that most (99.%) people work with != type in At 10:40 +1100 3/11/09, Mark Andrews wrote: I have a new key I want to introduce. I add the DS to the parent zone at least the ttl(ds) before I start using that key in the zone. After the DS has been published for ttl(ds) I can then replace the DNSKEY referred to by the old DS with that of the new DS and re-sign the DNSKEY RRset. Once the ttl(dnskey) has expired I can remove the old DS from the parent zone. I wish to be able to do something similar with trust anchors. Publishing DS prevents me from doing so. There is more than one way to do a key supersession. I'll describe one assuming DS records are installed as trust anchors. DS(KEY1) is in my validator. The owner of KEY1 distributes DS(KEY2) with a note that it should be installed by the 15th. On the 15th, DNSKEY(KEY2) is placed in the zone and KEY2 only is used to sign the keyset. With a 1 week TTL on the key set's RRSIG RR, a week later DNSKEY(KEY1) is removed from the set. At some point after that I can remove DS(KEY1) from my validator. Perhaps the special case here is that the keyset is unique in that the signatures for SEP/KSK's are tied to the where the key data is. I.e., if you have something signed by KEY1, then you have KEY1 because that something has to be the key set. If the zone is not run with a KSK/ZSK split, then the removal of KEY1 is triggered by signing the last RR set by KEY2 and then the TTL. The principle here is that there is no error if for a DS record there is no corresponding DNSKEY and vice versa. All that is needed for validation is one chain of trust. Accepting dangling references is not optimal but provides robustness. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DS vs DNSKEY trust anchors, was Re: Truncation...
Moin! On 12.03.2009, at 01:10, Joe Baptista wrote: You poor souls. The DNSSEC monster is vast and complex. So much easier just to fix the problem instead of this endless gibberish. It's so complex it's funny when you consider a simple solution like DNSCURVE -http://dnscurve.org/ - and so much more secure. No man in the middle issues. DNSCurve solves a different problem. It's about encryption of DNS data, while DNSSEC looks on authentication of DNS data. DNSSEC and DNSCurve are complementary solutions not contradicting solutions. Oh well - sorry for the interruption - and carry on. Ahem could I ask why you are carrying my companies logo on your webpage? If there is an contractual relationship please send me the details off list, otherwise please remove it. On the topic DNSKEY or DS keys as trust anchors I would opt for DNSKEYS as there may be publication of trust anchors that may have hash/digest algorithms that my resolver/validator doesn't understand. This already happened to me :-(. So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: r...@colt.net http://www.colt.net/ Data | Voice | Managed Services Schütze Deine Umwelt | Erst denken, dann drucken * COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 * Geschäftsführer: Dr. Jürgen Hernichel (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
