[ksk-rollover] Retention of the 2010 KSK CONSIDERED HARMFUL

[Michael StJohns]

On 4/2/2019 10:46 AM, Joe Abley wrote:
> Hi Mike,
>
> On 2 Apr 2019, at 09:33, Michael StJohns <msj at nthpermutation.com 
> <mailto:msj at nthpermutation.com>> wrote:
>
>> It is a _*monumentally bad idea*_ to retain revoked key material - 
>> especially when you don't actually have any way to use it.
>
> My concern is that we don't know if we have any way to use it until 
> KSK rollovers stop being science projects.

Hoarding!  I have no way of knowing if that necktie hanging on my rack 
will ever come back into style, but it has a better chance of being 
useful than your revoked key.


>
> The topic that prompted the concern was Warren raising Wouter's old 
> trust anchor link proposal from the dead. I thought Wouter's proposal 
> was a bad idea, years ago and I'm not sure whether Warren's current 
> idea is best described as a recurring bad dream or a prodigal son 
> returning, but it seems silly to rush to a conclusion when we don't 
> need to.

Hoarding!   It's a bad idea mainly because of the way time works and 
that the keys are not policy bound to sign things bound in time.  (e.g. 
I can't tell the difference between an object with a timestamp of 1 jan 
2010 signed on 1 jan 2010 and the same object with the same time stamp 
signed in 2020).  Because of that I can use a revoked key to sign data 
that appears to have been signed before the key was revoked.


>
> What is the harm from keeping leaving the KSK-2010 smart cards that 
> are already in the safe there for as long as it takes to have a stable 
> plan in place for rolling the key? This is not a rhetorical question 
> -- you know more about this stuff than I do, and I'm interested in 
> your answer.

As long as the cards are around, the keys are usable.  If it were a 
perfect 5011 world, then that would be less of a problem as resolvers 
would mark them as revoked ore remove them from the trust anchor set.  
If you read 5011 you'll note that there's a housekeeping comment about 
removing information from the trustanchor set after its no longer 
useful.  E.g.  why hang on to the revoked key info for years on end when 
you know that the key holders have destroyed the private key.  What you 
say?  They didn't actually destroy the key??

In an ideal world, those keys should be no more useful than any randomly 
generated key pair - e.g. they exist in no DNS root DNSKEY RRSet trust 
anchor set in any resolver in the world.   But 5011 cannot (and no 
system can) result in perfect uptake by all resolvers of the fact of the 
revocation of the keys and their deletion from the trust anchor set for 
a given key - in this case 2010.  Think of it this way - we think we've 
defused the bomb, but it still contains explosives and can cause harm if 
mishandled.

At this point two things are true:  1) The 2010 key set still exists, 
and 2) there is at least one resolver out there that will still accept 
that key as a trust anchor.  Deleting the key set will make (2) a non-issue.

And given that there are humans involved, having yet another set of key 
material that is nominally out of service but must be protected at the 
same level of in-service key material increases the risk to all key 
material some small amount. (i.e., you're spreading your focus 
protecting things you really shouldn't have to be watching)

>
> Note that I'm not suggesting that old key materials be hoarded as a 
> general principle; rather that since we don't yet know what we are 
> doing, perhaps we shouldn't act as though we do.

Let's say it takes you 6 months (being generous, I think it will be a 
year or so) to figure out what to do and socialize it and publish the 
RFC.  Take another 6 months to get uptake from the resolver vendors and 
operators to actually implement it.  Take another 6-12 months to get 
sufficient coverage in the sales channel - call it 2 years for the sake 
of argument.  At that point I *really* hope that the 2017 key set has 
bit the dust and we're on to 2019 or later. Given that we're concerned 
with the state of the root trust anchor set, and as of today the 
publisher thinks that 2010 is a dead key why would you include it in any 
representation of the state of the set going forward from this point?   
Answer - you wouldn't.

Problem for the reader:  the original netscape browser contained lots of 
keys in its trust anchor set.  How many of those are still in modern 
browsers, and do any browsers contain a history of the supercession of 
those keys?  Argue that it would be a good idea to keep a history of 
those keys so that a browser that's been offline for two years can get 
to the current trust set without updating the software of the 1999 
version of Netscape.

Later, Mike



>
>
> Joe
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190402/4b5eb05a/attachment.html>