[ksk-change] Testing new keys added
Greetings again. Pure conjecture below. Assuming that a rollover uses the Double-KSK method described previously, is there an intention to test systems for the new SEP key before removing the old one? That is, if A is the current KSK and IANA adds B, after the 30-day hold-down time, either key could be used to sign zones in the root. One thought is to sign a test TLD "dywnagrebo" with just B, have an IANA-supported server that is authoritative for dywnagrebo, and include URLs such as www.test.dywnagrebo in some environments where they might be resolved. I'm not sure how one might be able to see when a lookup fails due to validation (as compared to failing due to it being a new TLD), so this could be a useless idea. However, more creative people here might be able to design a way to actually test that the B KSK is widely loaded before A is removed. --Paul Hoffman
On 10 okt 2014, at 04:19, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
Assuming that a rollover uses the Double-KSK method described previously, is there an intention to test systems for the new SEP key before removing the old one? That is, if A is the current KSK and IANA adds B, after the 30-day hold-down time, either key could be used to sign zones in the root.
No, both keys needs to sign the ZSK that signs the DS records in the root zone. And that invalidates the rest of your (otherwise interesting) proposal. Sorry :-/ jakob
On Fri, Oct 10, 2014 at 08:05:50AM +0200, Jakob Schlyter wrote:
No, both keys needs to sign the ZSK that signs the DS records in the root zone. And that invalidates the rest of your (otherwise interesting) proposal. Sorry :-/
the "-v" is that since the old KSK (at least) needs to sign the ZSK and thus the DNSKEY RRSet, the new KSK will always be signed by the old one and therefore its SEP properties cannot be tested? -Peter
On 10/10/2014 2:05 AM, Jakob Schlyter wrote:
On 10 okt 2014, at 04:19, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
Assuming that a rollover uses the Double-KSK method described previously, is there an intention to test systems for the new SEP key before removing the old one? That is, if A is the current KSK and IANA adds B, after the 30-day hold-down time, either key could be used to sign zones in the root. No, both keys needs to sign the ZSK that signs the DS records in the root zone. And that invalidates the rest of your (otherwise interesting) proposal. Sorry :-/
Not exactly. By convention we split ZSK and KSK duties, but that's not actually enforced by the resolver. So 1. A and B sign (A B Z) 2. Z signs most of the zone. 3. B signs the DS record for the test zone. Should work. But that doesn't prove anything about B's "trust anchor"ness because the chain can go A -> (A B Z) -> B(DS) rather than B -> (A B Z) -> B(DS). If I'd been smarter, I would have provided a convention to query a caching validating resolver for its trust anchors. Mike
jakob
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On Oct 10, 2014, at 9:49 AM, Michael StJohns <msj@nthpermutation.com> wrote:
On 10/10/2014 2:05 AM, Jakob Schlyter wrote:
On 10 okt 2014, at 04:19, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
Assuming that a rollover uses the Double-KSK method described previously, is there an intention to test systems for the new SEP key before removing the old one? That is, if A is the current KSK and IANA adds B, after the 30-day hold-down time, either key could be used to sign zones in the root.
No, both keys needs to sign the ZSK that signs the DS records in the root zone. And that invalidates the rest of your (otherwise interesting) proposal. Sorry :-/
Not exactly. By convention we split ZSK and KSK duties, but that's not actually enforced by the resolver.
So • A and B sign (A B Z) • Z signs most of the zone. • B signs the DS record for the test zone.
Yes, that's what I was proposing.
Should work. But that doesn't prove anything about B's "trust anchor"ness because the chain can go A -> (A B Z) -> B(DS) rather than B -> (A B Z) -> B(DS).
Yes, that's what I figured. Also, I'm not sure how to get relying parties to actually test the signature on the test zone, much less to be able to understand validation failures.
If I'd been smarter, I would have provided a convention to query a caching validating resolver for its trust anchors.
That can still be done, but will take long to be rolled out. And, really, what we want to know is how many systems *don't* update their trust anchors and software often enough to trust the new KSK. At best, this proposal is to test a negative. Having said that, ICANN's implementation of the controlled interruption for collision with recent new TLDs has generated some positive results. If IANA can devise something similar for a root key rollover, that might help assure people of the value. --Paul Hoffman
On 10 okt 2014, at 18:49, Michael StJohns <msj@nthpermutation.com> wrote:
Not exactly. By convention we split ZSK and KSK duties, but that's not actually enforced by the resolver.
Sure, but it is enforced by the current RZ key management process. ICANN can not sign an arbitrary RRset unless several key components are modified, including the DPS and the software used for signing. jakob
On Oct 12, 2014, at 11:49 AM, Jakob Schlyter <jakob@kirei.se> wrote:
On 10 okt 2014, at 18:49, Michael StJohns <msj@nthpermutation.com> wrote:
Not exactly. By convention we split ZSK and KSK duties, but that's not actually enforced by the resolver.
Sure, but it is enforced by the current RZ key management process. ICANN can not sign an arbitrary RRset unless several key components are modified, including the DPS and the software used for signing.
The latter part seems interesting to me. Is this written down anywhere where the rest of us can view it? There may be other things in such a document that might help this discussion. --Paul Hoffman
On 13 okt 2014, at 07:24, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
The latter part seems interesting to me. Is this written down anywhere where the rest of us can view it? There may be other things in such a document that might help this discussion.
There are still some material published at www.root-dnssec.org, including http://www.root-dnssec.org/wp-content/uploads/2010/05/draft-icann-dnssec-key... that documents most of these aspects. I'm a bit surprised that these documents wasn't made "final" after the root was signed, but maybe they are still in the pipeline to be published at https://www.iana.org/dnssec. Kim? jakob
Jakob's right. If I understand question correctly, you always need two KSK RRSIGs to be able to simultaneously validate with either TA. I learned that when I was testing ksrsigner.c for key rolls. -Rick -----Original Message----- From: ksk-rollover-bounces@icann.org [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Jakob Schlyter Sent: Thursday, October 09, 2014 11:06 PM To: Paul Hoffman Cc: ksk-rollover@icann.org Subject: Re: [ksk-change] Testing new keys added On 10 okt 2014, at 04:19, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
Assuming that a rollover uses the Double-KSK method described previously, is there an intention to test systems for the new SEP key before removing the old one? That is, if A is the current KSK and IANA adds B, after the 30-day hold-down time, either key could be used to sign zones in the root.
No, both keys needs to sign the ZSK that signs the DS records in the root zone. And that invalidates the rest of your (otherwise interesting) proposal. Sorry :-/ jakob _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On 10/10/2014 3:08 PM, Richard Lamb wrote:
Jakob's right. If I understand question correctly, you always need two KSK RRSIGs to be able to simultaneously validate with either TA. I learned that when I was testing ksrsigner.c for key rolls. -Rick
That's not what the stuff below was about exactly. The issue is actually that the trust chains from A and B can't ever be independent because both chains must pass through the monolithic signed root DNSKEY RRSet. So its impossible to set up a zone that can *only* be verified if you've installed "B" as a trust anchor. (*sigh* That's not exactly the right way to say it but close enough for government work....) Mike
-----Original Message----- From: ksk-rollover-bounces@icann.org [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Jakob Schlyter Sent: Thursday, October 09, 2014 11:06 PM To: Paul Hoffman Cc: ksk-rollover@icann.org Subject: Re: [ksk-change] Testing new keys added
On 10 okt 2014, at 04:19, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
Assuming that a rollover uses the Double-KSK method described previously, is there an intention to test systems for the new SEP key before removing the old one? That is, if A is the current KSK and IANA adds B, after the 30-day hold-down time, either key could be used to sign zones in the root.
No, both keys needs to sign the ZSK that signs the DS records in the root zone. And that invalidates the rest of your (otherwise interesting) proposal. Sorry :-/
jakob
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
Ahh.. Got it. Thank you. I was on the wrong plane of thought. Engineering is not the hard part here. Sent from my iPhone On Oct 10, 2014, at 12:56, Michael StJohns <msj@nthpermutation.com<mailto:msj@nthpermutation.com>> wrote: On 10/10/2014 3:08 PM, Richard Lamb wrote: Jakob's right. If I understand question correctly, you always need two KSK RRSIGs to be able to simultaneously validate with either TA. I learned that when I was testing ksrsigner.c for key rolls. -Rick That's not what the stuff below was about exactly. The issue is actually that the trust chains from A and B can't ever be independent because both chains must pass through the monolithic signed root DNSKEY RRSet. So its impossible to set up a zone that can *only* be verified if you've installed "B" as a trust anchor. (*sigh* That's not exactly the right way to say it but close enough for government work....) Mike -----Original Message----- From: ksk-rollover-bounces@icann.org<mailto:ksk-rollover-bounces@icann.org> [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Jakob Schlyter Sent: Thursday, October 09, 2014 11:06 PM To: Paul Hoffman Cc: ksk-rollover@icann.org<mailto:ksk-rollover@icann.org> Subject: Re: [ksk-change] Testing new keys added On 10 okt 2014, at 04:19, Paul Hoffman <paul.hoffman@vpnc.org><mailto:paul.hoffman@vpnc.org> wrote: Assuming that a rollover uses the Double-KSK method described previously, is there an intention to test systems for the new SEP key before removing the old one? That is, if A is the current KSK and IANA adds B, after the 30-day hold-down time, either key could be used to sign zones in the root. No, both keys needs to sign the ZSK that signs the DS records in the root zone. And that invalidates the rest of your (otherwise interesting) proposal. Sorry :-/ jakob _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org<mailto:ksk-rollover@icann.org> https://mm.icann.org/mailman/listinfo/ksk-rollover _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org<mailto:ksk-rollover@icann.org> https://mm.icann.org/mailman/listinfo/ksk-rollover _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org<mailto:ksk-rollover@icann.org> https://mm.icann.org/mailman/listinfo/ksk-rollover
participants (5)
-
Jakob Schlyter -
Michael StJohns -
Paul Hoffman -
Peter Koch -
Richard Lamb