thoughts to the list as requested
Hi all, The question of whether and how often to roll the KSK seems to me to be the least interesting of all the work to be done around KSK management, but since it also seems to block discussion of any of the more entertaining subjects, the following is my opinion. You'll note the justification for the proposed end-state is missing, as are detailed suggestions for how we get there. Both are available on demand :-) 1. We should move briskly towards a steady state where it is obvious and unremarkable to all stakeholders and relying parties that the KSK changes from time to time. Nobody should bake a particular KSK into software; the responsibilities for tracking trust anchors within any particular software ecosystem should be clear; client-side machinery should be exercised regularly. 2. The schedule and processes involved in rolling the KSK on the IANA side will become practiced, unremarkable and routine. 3. A regular schedule of data collection will become possible, instead of ad-hoc coordination for individual rollover events, reducing cost and promoting consistency in what is collected and how it is stored and made available for analysis. 4. An emergency key-roll due to key compromise (of any number of flavours) will be expected, easy to execute and easy to understand from the client side. Contributing oil on the wheels might be long-timebase pre-publication of standby keys and the processes for an emergency roll closely resembling (or being identical to) processes for a scheduled roll. 5. It should be unnecessary for ICANN to ever have to do an outreach programme around a scheduled KSK rollover. I imagine a future in which regularly-scheduled KSK rolls quickly become non-events. The degree of impact of each rollover can be expected always to be greater than zero because there's a lot of weird crap attached to the Internet, but by the regular and predictable cadence can be expected to help the measurable impact descend quickly into the noise floor. KSK rolls should become as unremarkable as the KSK ceremonies that happen now, almost 9 years after the first one. The overarching theme though all of this is that ICANN stops taking responsibility for each and every key roll decision, and the responsibility for minimising impact on particular end-user communities, devices, etc is clearly and deliberately shifted to their individual network providers and vendors. This is a necessary and important step, and will result in the system becoming more stable and more resilient, not just in stable operation but also in the event of emergency rollovers. Sticking a finger in the air, since Paul asked me to at the microphone in Prague, I would say that the schedule should be regular but not stressful, and should be possible with minimal change to the current periodicity of KSK management. To me that means we should roll every year, with the particular elements of the key roll process that happen in ceremonies (e.g. key generation, key import, secure destruction of retired keys) pinned to particular ceremonies within the year. Each ceremony's procedures always involves some element of a key rollover; key rollover is no longer exceptional, but normal. Having all of this agreed swiftly would accelerate our pace towards the day that work can begin on more interesting topics like algorithm rollover, new approaches to trust anchor distribution, HSM vendor diversity, deployment of key management facilities to new jurisdictions, etc. Joe
Joe Abley <jabley@hopcount.ca> wrote: > The question of whether and how often to roll the KSK seems to me to be > the least interesting of all the work to be done around KSK management, > but since it also seems to block discussion of any of the more > entertaining subjects, the following is my opinion. You'll note the > justification for the proposed end-state is missing, as are detailed > suggestions for how we get there. Both are available on demand :-) Let me start by saying that I concur with you completely. I think that some have asked why we are rolling at all, in order to more precisely understand what threats we are mitigating. > 4. An emergency key-roll due to key compromise (of any number of > flavours) will be expected, easy to execute and easy to understand from > the client side. Contributing oil on the wheels might be long-timebase > pre-publication of standby keys and the processes for an emergency roll > closely resembling (or being identical to) processes for a scheduled > roll. I think that may be situations which pre-publication of standby keys might not mitigate. I think that we won't be sure until we write down the reasons for an emergency key-roll. As a small detail; who would make that call, and how much time would they have to make the decision? -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
On 2 Apr 2019, at 10:59, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
I think that some have asked why we are rolling at all, in order to more precisely understand what threats we are mitigating.
It is possible that in the future it will be necessary to deal with a key compromise. (Broken chain of custody, cryptographic attack, non-availability of key materials due to disaster or hardware failure, etc.) It is prudent to plan for that eventuality. Rolling the key without being practiced at doing so is difficult (data point exists).
I think that may be situations which pre-publication of standby keys might not mitigate. I think that we won't be sure until we write down the reasons for an emergency key-roll. As a small detail; who would make that call, and how much time would they have to make the decision?
I suspect this is not the right list to conduct a design exercise. The question of who gets to declare a compromise, how they would decide to do so and how much time they would have to make the decision are (I think) IANA, unknown and unknown. This is a good example of interesting work that is much easier to contemplate once the KSK is rolling regularly and unremarkably. Joe
Joe Abley <jabley@hopcount.ca> wrote: >> I think that may be situations which pre-publication of standby keys might not >> mitigate. I think that we won't be sure until we write down the reasons for >> an emergency key-roll. As a small detail; who would make that call, and how >> much time would they have to make the decision? > I suspect this is not the right list to conduct a design exercise. > The question of who gets to declare a compromise, how they would decide > to do so and how much time they would have to make the decision are (I > think) IANA, unknown and unknown. This is a good example of interesting > work that is much easier to contemplate once the KSK is rolling > regularly and unremarkably. What if our current roll process (which we will have been rehearsing a lot), can not cope with the resulting answers? -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
On 2 Apr 2019, at 16:53, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
Joe Abley <jabley@hopcount.ca> wrote:
I think that may be situations which pre-publication of standby keys might not mitigate. I think that we won't be sure until we write down the reasons for an emergency key-roll. As a small detail; who would make that call, and how much time would they have to make the decision?
I suspect this is not the right list to conduct a design exercise.
The question of who gets to declare a compromise, how they would decide to do so and how much time they would have to make the decision are (I think) IANA, unknown and unknown. This is a good example of interesting work that is much easier to contemplate once the KSK is rolling regularly and unremarkably.
What if our current roll process (which we will have been rehearsing a lot), can not cope with the resulting answers?
Well, the opposite ordering involves designing a policy framework for a rollover that you don't know how to execute, which seems like more of a problem. Joe
On Tue, 2 Apr 2019 at 07:59, Joe Abley <jabley@hopcount.ca> wrote:
1. We should move briskly towards a steady state where it is obvious and unremarkable to all stakeholders and relying parties that the KSK changes from time to time. Nobody should bake a particular KSK into software; the responsibilities for tracking trust anchors within any particular software ecosystem should be clear; client-side machinery should be exercised regularly.
On the subject of "nobody should bake a particular key into software...", John Dickinson and I were entertaining the notion last week of writing up advice to the effect that implementers should deprecate the notion of non-5011 trust anchors; all configured trust anchors should be treated as potentially doing 5011 rolls, always. The reasoning being that if the authoritative operator isn't doing 5011 there's no harm (it's a no-op), and if they are then you don't want anyone accidentally hard-coding the trust anchor statically. I'm persuaded by the use case Paul Ebersman brought up, that some networks may prefer to control when and how trust anchor updates happen on their network, and so maybe this advice should be a statement about defaults, rather than advice to never have static keys. 3. A regular schedule of data collection will become possible, instead of
ad-hoc coordination for individual rollover events, reducing cost and promoting consistency in what is collected and how it is stored and made available for analysis.
DNS-OARC would be happy to continue coordinating data collection events around the major steps in KSK rolls.
4. An emergency key-roll due to key compromise (of any number of flavours) will be expected, easy to execute and easy to understand from the client side. Contributing oil on the wheels might be long-timebase pre-publication of standby keys and the processes for an emergency roll closely resembling (or being identical to) processes for a scheduled roll.
Pre-publishing keys for the purposes of emergency roll in the event of compromise sounds hard, and definitely expensive, given how they key material is handled today. I think a third signing party location would be required, with each key stored in only two locations. This is probably achievable, but I suspect it'll take a while for people to agree on costs and location, and then more time to get it set up. We will likely want to come up with an interim plan for emergency rolls until something like the above can be arranged.
5. It should be unnecessary for ICANN to ever have to do an outreach programme around a scheduled KSK rollover.
Hear hear!
On Tue, 2 Apr 2019, Matthew Pounsett wrote:
On the subject of "nobody should bake a particular key into software...", John Dickinson and I were entertaining the notion last week of writing up advice to the effect that implementers should deprecate the notion of non-5011 trust anchors;
Today this is simply impossible. All machines installed fresh within the last 29 days of a KSK roll would die.
I'm persuaded by the use case Paul Ebersman brought up, that some networks may prefer to control when and how trust anchor updates happen on their network, and so maybe this advice should be a statement about defaults, rather than advice to never have static keys.
We've had this discussion a number of times over the years. You won't get a different outcome now. 5011 is fundamentally broken and needs another mechanism to support it or a mechanism to replace it. Also, vendors already have static keys or OS updates. We update the system store for CA certificates and DNSSEC root keys with that. We don't see this as a big problem (granted, we don't look beyond EOL which you might want to) Paul
On Tue, 2 Apr 2019 at 12:40, Paul Wouters <paul@nohats.ca> wrote:
On Tue, 2 Apr 2019, Matthew Pounsett wrote:
On the subject of "nobody should bake a particular key into software...", John Dickinson and I were entertaining the notion last week of writing up advice to the effect that implementers should deprecate the notion of non-5011 trust anchors;
Today this is simply impossible. All machines installed fresh within the last 29 days of a KSK roll would die.
I believe that is just another case of a no-op. That would be solved in the same way that static keys deployed in that time are solved today, which is to say it's implementation (or distribution) specific.
I'm persuaded by the use case Paul Ebersman brought up, that some networks may prefer to control when and how trust anchor updates happen on their network, and so maybe this advice should be a statement about defaults, rather than advice to never have static keys.
We've had this discussion a number of times over the years. You won't get a different outcome now. 5011 is fundamentally broken and needs another mechanism to support it or a mechanism to replace it.
Broken, or just doesn't cover all use-cases? I don't think you'd find any disagreement that it doesn't cover all use cases. But, that's one of those discussions we still need to have about having multiple ways to distribute keys. I don't think this is an argument against treating all trust anchors as potential 5011 targets.
Also, vendors already have static keys or OS updates. We update the system store for CA certificates and DNSSEC root keys with that. We don't see this as a big problem (granted, we don't look beyond EOL which you might want to)
Again, I don't think this is an argument against treating all trust anchors as being potentially 5011-managed. Just because a trust anchor in DNS software is configured to be updated by 5011, nothing stops you from manually replacing it. In fact, your comment about EOL is, I think, another argument in favour of this.
On 2 Apr 2019, at 11:56, Matthew Pounsett <matt@conundrum.com> wrote:
4. An emergency key-roll due to key compromise (of any number of flavours) will be expected, easy to execute and easy to understand from the client side. Contributing oil on the wheels might be long-timebase pre-publication of standby keys and the processes for an emergency roll closely resembling (or being identical to) processes for a scheduled roll.
Pre-publishing keys for the purposes of emergency roll in the event of compromise sounds hard, and definitely expensive,
I'm not sure I agree that words like "hard" and "expensive" are useful before any design exercise has happened. You're presupposing a particular class of solutions, I think.
given how they key material is handled today. I think a third signing party location would be required, with each key stored in only two locations. This is probably achievable, but I suspect it'll take a while for people to agree on costs and location, and then more time to get it set up.
We will likely want to come up with an interim plan for emergency rolls until something like the above can be arranged.
We have an interim plan right now; it's documented in the DPS. It has never been tested. It may well not be complete. Joe
participants (4)
-
Joe Abley -
Matthew Pounsett -
Michael Richardson -
Paul Wouters