[ksk-change] Capabilities of validating systems we need to consider

Paul Hoffman paul.hoffman at vpnc.org
Sun Sep 21 19:34:47 UTC 2014


On Sep 21, 2014, at 10:17 AM, Michael StJohns <msj at nthpermutation.com> wrote:

> On 9/21/2014 11:27 AM, Paul Hoffman wrote:
>> Greetings again. In thinking about the question of "what would happen if we changed the KSK", but without thinking about why and when, it would be good to think about what kinds of systems are out there. My initial list came to three categories of capabilities:
>> 
>> 1) Able to automatically pull and correctly use a new KSK
> 5011 or something else.

Yes, as Joe has indicated, and noting that you did not agree with Joe's proposed "something elses".

>> 2) Cannot automatically pull a new KSK, or cannot correctly use an automatically-pulled KSK; however, it can correctly get and use a new KSK with operator intervention
> That sounds like just pulling down a file and restarting the resolver which should be the case for pretty much any normal resolver.  

My set of three does not presume "normal resolver". I don't think this group yet knows what we consider "normal", nor how much we care about the set of abnormal resolvers.

> Maybe an issue with middle boxes like home routers, but I'm not aware of any device that does validation OOB without configuration.

Me neither, but this group should not make its decisions based on what you and I are not aware of. It is worth consideration and, if at all possible, measurement.

>> 3) Even with operator intervention, cannot pull a new KSK or cannot correctly use an manually-pulled KSK
> 
> Is there an actual example of such a box.  

Yes. There are versions of some validating software whose documentation cannot be understood by all operators. (I'm purposely not naming them here.) The software works with the built-in KSK, but the operator will not be able to figure out how to get a new KSK to successfully replace the old KSK.

Further, I suspect there has been insufficient testing of systems that are otherwise considered "good" and "well-documented" when you add a second or third root KSK, as compared to replacing the KSK. Is the documentation sufficient? What happens after a reboot? What happens to the added keys after a software upgrade (and yes, I understand that I just opened the can labelled "Distro Hell", but we need to deal with it).

That is, are there systems in Class 1 and Class 2 that could become part of Class 3 if we add a second or third RSA key to the KSK pile? Or if we add a new EC key to the KSK pile? Or if there is an emergency rollover where we need to remove the original KSK?

> I'd basically call it bricked and replace it if I had one in this category.

Sure you would; so would I. However, you and I are not the primary targets for this effort.

> Last category is (4) doesn't know or care about DNSSEC.

I would not list them unless there was any way that a KSK change would be noticeable on them, and I don't see how that would be.

--Paul Hoffman


More information about the ksk-rollover mailing list