On Mar 28, 2019, at 2:45 PM, Geoff Huston <gih@apnic.net> wrote:

...

On 28 Mar 2019, at 12:08 pm, Kim Davies <kim.davies@iana.org> wrote:

Just confirming my mic comments:

Our current schedule has us remove the 2010 KSK from our HSMs in one of our two key management facilities in May, and from the HSMs in the other key management facility in August. While perhaps not a complete specification, we’d need a strong indicator we need to retain the KSK longer ideally by May, and certainly no later than August, in order to defer the deletion and retain the capability to use it (i.e. to create a signature via a new mechanism that would endorse the subsequent KSK).

Hi Kim,

I am happy to provide my strong indicator to retain the KSK until further notice. We have not given up yet on the dream of dusting off some dormant resolver that has a trusted key state of KSK 2010 and using some signed chain mechanism that would automate the installation of trust in the current key. If the old key is destroyed then the dream gets destroyed too.

How would this work? Such a dusty resolver doesn't yet have the "some signed chain mechanism" installed on it because it doesn't yet exist. If the resolver can have that mechanism installed when it starts up, it can have the current trust anchors installed too. I can see that maybe IANA should not delete keys once such a mechanism is defined and deployed, but not until then. Am I missing something here? --Paul Hoffman

Geoff Huston <gih@apnic.net> writes:

I have no idea Paul - but I do know that once the key is destroyed the entire conversation is kinda pointless, and I thought it was a little bit preemptory to slam the door shut on such musings..

I came to the same conclusion after hearing the discussion: there is no software or device today that can make use of a yet-undefined chain, and thus the need to anchor it to the single starting point in history is potentially not helpful. It may "look cleaner", but I can't think of a technical reason why it's necessary. Assuming a new protocol for doing history chaining of some kind, all on-the-shelf devices that suddenly have it implemented should simultaneously be chaining it back to only the current KSK, which is KSK-2017 not KSK-2010 (and should stop going backward once it hits the current trust anchor). -- Wes Hardaker USC/ISI

Hugo Salgado-Hernández <hsalgado@nic.cl> wrote:

Actually, I can see an use for the KSK-2010 yet. We can measure the "sunsetting" of this key from the resolvers by having a special record in somewhere signed only by KSK-2010, and by testing its validation status from a resolver we could know if it's revoked or if its still configured as a trust anchor.

That depends on some tricky assumptions about how the validator works. * The validator's trust anchor configuration might be in DS record form, rather than public key form, in which case it won't be able to validate unless the key appears in the DNSKEY record. * The validator might only use its trust anchor public keys for validating signatures on the DNSKEY RRset, and not allow the trust anchor to be used for validating any other records. I think the latter is true for BIND, for example. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Trafalgar: Easterly or northeasterly 4 or 5, but 6 to gale 8 in far southeast, becoming variable 4 later in north. Slight or moderate, but rough in southeast. Mainly fair. Good.

*sigh*  Sorry for top posting but... It is a _*monumentally bad idea*_ to retain revoked key material - especially when you don't actually have any way to use it.   There's a term for holding on to something when you think it *might* be useful in the future but have no idea whether it will be - it's called "hoarding" and can be a form of mental illness depending on how extreme it gets. Then there's the problem that as a "revoked" key, we really don't have a model for how the key material should be protected - e.g. it's not live, and it's not going to be live ever again but what happens if the worst case happens and the private key is compromised a year or so later?  Especially since as a "revoked" key it should be harmless and maybe we don't take enough care to protect it. As a general model, information can be created but not destroyed.  HSMs (and some uses of cryptography) allow us to finesse that a slight bit through a few different methods - e.g. never allowing the key material to leave the HSM, or if it does leave the HSM by never allowing the keys used to encrypt the backup to never leave the HSM (or the HSM smart cards).  The destruction of the key within the HSM used to encrypt the live signing key or its backup turns that information into nothing more than random bits.  The HSM substitutes programmed policy (i.e. we can use the key, but we can't see that key value) for information theory and allows for a semblance of destruction of information. At this point, two things should have happened:  The 2010 key should have been removed from the HSM(s), and the HSM(s) should have changed its backup keys to invalidate all the externally held backup material for the 2010 key.  If both of these haven't happened, then we're not quite done yet. Deciding on the fly that it might be a good idea to hold on to a key who for all of the 5011 resolvers is so many random bits, but for the non-5011 resolvers who may have not gotten a manual update of the revocation could still be used to sign the root DNSKEY RRSet doesn't seem to be to be either prudent or in keeping with the agreed upon key management plan. In fact it could be dangerous to keep that key around in any form. So to recap:  1) No current resolver should have any way to use this key except to validate its revocation, 2) any resolver that is still able to use this key is mis-configured and vulnerable to getting bad information, 3) it's way in the future where you might have a resolver which could use this key safely (e.g. in a way that doesn't end up with the installation of bad trust anchors), and 4) given that we don't need to start from the 2010 state of the root trust anchor set for things programmed in 2019 and later, then 5) ITS A REALLY BAD IDEA TO KEEP THIS KEY AROUND This is not a case where holding on to the past preserves the future. Later, Mike On 4/2/2019 8:09 AM, Joe Abley wrote:

On 28 Mar 2019, at 09:45, Geoff Huston <gih@apnic.net> wrote:

...

On 28 Mar 2019, at 12:08 pm, Kim Davies <kim.davies@iana.org> wrote:

...

Just confirming my mic comments:

Our current schedule has us remove the 2010 KSK from our HSMs in one of our two key management facilities in May, and from the HSMs in the other key management facility in August. While perhaps not a complete specification, we’d need a strong indicator we need to retain the KSK longer ideally by May, and certainly no later than August, in order to defer the deletion and retain the capability to use it (i.e. to create a signature via a new mechanism that would endorse the subsequent KSK). I am happy to provide my strong indicator to retain the KSK until further notice. We have not given up yet on the dream of dusting off some dormant resolver that has a trusted key state of KSK 2010 and using some signed chain mechanism that would automate the installation of trust in the current key. If the old key is destroyed then the dream gets destroyed too. I agree.

It would be a low-cost exercise to at least retain the backup of KSK-2010 that already exists as key shares on smartcards in both facility and keep them there with the same chain of custody and physical security.

There is no active plan to use KSK-2010 for anything, and so having it available on an HSM (and having it transferred to future HSMs when they are replaced) seems unnecessary, but the ability to restore it from backup to an HSM for use in the future seems sensible. We are some distance away from KSK rolls being routine; while they continue to be science projects we should keep our options open.

Joe

_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover

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

On 4/2/2019 11:53 AM, Salz, Rich wrote:

* It is a *_monumentally bad idea_* to retain revoked key material

+1, +2, +1000!

If you want a chain of trust, when you generate key “N+1” sign it with key “N”.  Repeat for each generation.

The problem with this is that you need to know *when* N signed N+1, and you can't believe N about the time.  (E.g. in 2020, I use key 2010 to sign key 2017 well after 2010 was revoked, at the same time I sign Fake2017, and lead a chain of trust through Fake2017 for future signings).   This problem is at the root of why a simple chain of trust won't work.  I'm trying to figure out a way to mix-in something to tie each transaction to a point in time (or at least an order in time) in a manner that possession of a key (revoked or not) earlier in the chain doesn't allow you to lie about what comes after.    I don't know that its possible to do that automatically.  It may require a human making a trust decision based on other non-DNS information. [5011 works because each resolver updates its state as things happen, so twiddling with the signing chain a year or two after a key is revoked won't cause the resolver to update its state as the key is either not in trust anchor set, or is there in a revoked state.  Trying to replicate this behavior with a resolver that's been offline for two years just won't work].

* This is not a case where holding on to the past preserves the future.

Nice turn of phrase!

Thanks! Mike

On 4/2/2019 12:50 PM, Salz, Rich wrote:

* The problem with this is that you need to know *when* N signed N+1, and you can't believe N about the time.

Out of band verification. You make sure the chain you have connects properly up to the current KSK.

Then its "Turtles all the way down". https://en.wikipedia.org/wiki/Turtles_all_the_way_down At some point you've involved something outside of the DNS and you need a way to trust them, and a way to supercede the trust if they're compromised.  Or you need a crowd of them.  Etc. I thought of time stamp services - those might work but have the same problem of root management  for their chain of trust - e.g. the resolvers need to be able to get the most recent trust anchors before they can validate the DNS trust anchor set....   What I'm actually thinking about is some form of inserting a record into the blockchain ledger for one of the cryptocurrencies as a mechanism for time stamping the state of the trust anchor set at a given point in time.  See references 2 and 3 of https://en.wikipedia.org/wiki/Trusted_timestamping But that's complex and probably requires that the root key holders add another step to the process of managing the keys. It's not something that's a simple add on.

Or you tell folks turning on old computers to just reconfig first. :)

That gets my vote.  Or  - they just down load all the security patches that have been signed with the vendor of the devices private key to include the new starting trust anchor set. Later, Mike

Michael StJohns <msj@nthpermutation.com> writes:

This is more complex than "just sign the key", but it also probably works unlike "just sign the key".

I think you're proposal seems like a viable one, and is interesting in its execution. I haven't decided if adding significant more complexity and requirements to entangle with something outside the sphere is worth the benefit... I'll have to think longer about that. -- Wes Hardaker USC/ISI

...

...

Just confirming my mic comments:

Our current schedule has us remove the 2010 KSK from our HSMs in one of our two key management facilities in May, and from the HSMs in the other key management facility in August. While perhaps not a complete specification, we’d need a strong indicator we need to retain the KSK longer ideally by May, and certainly no later than August, in order to defer the deletion and retain the capability to use it (i.e. to create a signature via a new mechanism that would endorse the subsequent KSK).

I am happy to provide my strong indicator to retain the KSK until further notice. We have not given up yet on the dream of dusting off some dormant resolver that has a trusted key state of KSK 2010 and using some signed chain mechanism that would automate the installation of trust in the current key. If the old key is destroyed then the dream gets destroyed too.

I agree.

It would be a low-cost exercise to at least retain the backup of KSK-2010 that already exists as key shares on smartcards in both facility and keep them there with the same chain of custody and physical security.

There is no active plan to use KSK-2010 for anything, and so having it available on an HSM (and having it transferred to future HSMs when they are replaced) seems unnecessary, but the ability to restore it from backup to an HSM for use in the future seems sensible. We are some distance away from KSK rolls being routine; while they continue to be science projects we should keep our options open.

I’m uncomfortable with a “keep it indefinitely” position. I would prefer to see the community reach some rough consensus on a key chain structure of new signing old that would allow a relying party that was configured with trust in some previous kSK to use a to-be-determined chain following tool that would allow it to trust the current KSK, or we conclude that this is a dud concept. At that point we should be destroying revoked KSKs. So perhaps we should give ourselves 24 months to either come up with something or conclude that its just not possible. At that point we can destroy KSK-2010. regards, Geoff

On 3 Apr 2019, at 0:37, Geoff Huston wrote:

I’m uncomfortable with a “keep it indefinitely” position. I would prefer to see the community reach some rough consensus on a key chain structure of new signing old that would allow a relying party that was configured with trust in some previous kSK to use a to-be-determined chain following tool that would allow it to trust the current KSK, or we conclude that this is a dud concept. At that point we should be destroying revoked KSKs. So perhaps we should give ourselves 24 months to either come up with something or conclude that its just not possible. At that point we can destroy KSK-2010.

Agree… Hold my beer… It occurs to me that the requirements are probably straight forward. Key N signs Key N+1 with a time of signature timestamp. Seems to me that writing down how the bits are stored is a short exercise. I do not see any reason to put an expiration date on the signature - since the signing key is revoked the signature is expired at the moment it is made. Any use of the chain of signatures during bootstrap is a big leap of fate anyhow - it be combined with a number of heuristics and used as a last resort mechanism in any case. Now, we do already have a chain of trust available, as long as we keep the old keysets and their signatures around (which we do, on those USB drives we copy around during the ceremony, not?). The only issue with those is that they carry a lot of extra baggage in the form of KSKs and expiration signatures. But if you want to you can construct a chain out of those. If you want to have a cruft-less chain of N->N+1 signatures then why not generate the signature with a time stamp. That seems pretty benign and doesn’t take years of engineering. Gimme that beer back so I can enjoy that tasty beverage, while I am being convince by all of you of the errors in my thinking. —Olaf

On 3 Apr 2019, at 16:09, Joe Abley wrote:

On 3 Apr 2019, at 05:10, Olaf Kolkman <kolkman@isoc.org> wrote:

...

It occurs to me that the requirements are probably straight forward.

This seems like a bad sign!

...

Key N signs Key N+1 with a time of signature timestamp. Seems to me that writing down how the bits are stored is a short exercise.

Back when Wouter proposed a similar mechanism, years ago (TALINK? something like that) my objection to it was that a compromise of any key along the chain breaks it in ways that are not trivial to signal to a relying party, remembering that the kind of relying party we're apparently trying to accommodate include those that have been sitting on a shelf for five years but still have aspirations about being secure.

I find Mike StJohn's cautionary shouting about key hoarding quite convincing.

I am not talking about keeping the private keys around. I am saying create a signature over the new key with a timestamp of signature and keep that around - a relatively clean variety of data that is already available anyway. That said I agree, all mechanisms to get from t(N) to t(N+i) (time when key N was in use to time when a future key is in use) by following a chain of signatures is not the best of ideas. But, if we ever want to go there, as methodology of last resort, having a clean blob of signed key material around may turn out to be useful. —Olaf