On 4/2/2019 10:46 AM, Joe Abley wrote:
Hi Mike,
On 2 Apr 2019, at 09:33, Michael StJohns <msj@nthpermutation.com <mailto:msj@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