[ksk-change] Testing new keys added

[Paul Hoffman]

On Oct 10, 2014, at 9:49 AM, Michael StJohns <msj at nthpermutation.com> wrote:

> On 10/10/2014 2:05 AM, Jakob Schlyter wrote:
>> On 10 okt 2014, at 04:19, Paul Hoffman <paul.hoffman at 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