Future rollover planning opportunities
Colleagues, We are continuing to implement the final phases of the KSK-2017 rollover for the DNS Root Zone. While there are no plans to immediately schedule any subsequent planned rollover, we recognize this is a good opportunity to gather feedback while everyone’s experience with this rollover is still fresh in mind. Feedback from the community will inform our future strategy. We welcome feedback, particularly to this list, on what should be considered in designing the process for performing future rollovers. We are also planning to hold a number of outreach efforts in the coming months to capture further input. These sessions are being led by the ICANN’s Office of the Chief Technology Officer (OCTO) in coordination with IANA staff. These sessions will be at: * ICANN 64 in Kobe, as part of the DNSSEC workshop; * IETF 104 in Prague, as a proposed BOF; and * The 3rd ICANN DNS Symposium in Bangkok The feedback we receive will be used by the IANA team to develop a draft plan later in the year that we intend to share for public review. Thanks in advance. kim
ISC put about ten hours into the recent rollover - validating and testing, etc. To our way to thinking, the roll-over was far more of an event for the resolvers than it was for us. That probably says something about the frequency of roll-over events - if they were happening daily or weekly and we were putting ten hours into each event, we would begin to be concerned, but if they happened quarterly or annually we don't think we would be bothered - and might even think it was a good idea. The key consideration is that key rollovers are a "usual" event, and as such the key(s) should be something learned from the root and the root servers, not something configured or compiled into the resolver software.
On Feb 19, 2019, at 3:22 PM, Kim Davies <kim.davies@iana.org> wrote:
Colleagues,
We are continuing to implement the final phases of the KSK-2017 rollover for the DNS Root Zone.
While there are no plans to immediately schedule any subsequent planned rollover, we recognize this is a good opportunity to gather feedback while everyone’s experience with this rollover is still fresh in mind. Feedback from the community will inform our future strategy.
We welcome feedback, particularly to this list, on what should be considered in designing the process for performing future rollovers. We are also planning to hold a number of outreach efforts in the coming months to capture further input. These sessions are being led by the ICANN’s Office of the Chief Technology Officer (OCTO) in coordination with IANA staff. These sessions will be at:
• ICANN 64 in Kobe, as part of the DNSSEC workshop; • IETF 104 in Prague, as a proposed BOF; and • The 3rd ICANN DNS Symposium in Bangkok
The feedback we receive will be used by the IANA team to develop a draft plan later in the year that we intend to share for public review.
Thanks in advance.
kim _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
Fred Baker <fred@isc.org> wrote:
The key consideration is that key rollovers are a "usual" event, and as such the key(s) should be something learned from the root and the root servers, not something configured or compiled into the resolver software.
However there has to be a bootstrap mechanism, and the only one available is for the validator vendor to provide an initial key set. I agree that rollovers need to be routine (I think annual makes sense) but they have to be planned with software releases in mind. This might require keys to be generated and promulgated out of band a long time before they are published in the zone or used for signing. Then a vendor package can include root keys covering the next couple of years, say. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ promote human rights and open government
On 20 Feb 2019, at 4:29 am, Tony Finch <dot@dotat.at> wrote:
Fred Baker <fred@isc.org> wrote:
The key consideration is that key rollovers are a "usual" event, and as such the key(s) should be something learned from the root and the root servers, not something configured or compiled into the resolver software.
However there has to be a bootstrap mechanism, and the only one available is for the validator vendor to provide an initial key set.
I agree that rollovers need to be routine (I think annual makes sense) but they have to be planned with software releases in mind. This might require keys to be generated and promulgated out of band a long time before they are published in the zone or used for signing. Then a vendor package can include root keys covering the next couple of years, say.
There is something in your note Tony that I feel I should comment on. It gets to the heart of why the key gets rolled at all, in my view. I could offer the view that there is a prevalent feeling (perhaps irrationally - who knows) that a very long-held key will get compromised at some time. Either the tools to break the key will improve, or access to the key will no longer work, or some other mishap. It seems foolhardy not to have some exercised plan to roll the key to respond to such potential eventualities when or if the unplanned disaster happens and we need to roll the key. But then we enter into the next phase of the thinking - if we plan to roll the key at some time in response to some operational incident then we probably need to rehearse this plan. And so we have this extended exercise of using RFC5011 to transition the key. The plan has two parts - an extended ‘introduction’ of the new key and a key switch. The procedure we use at present is a planned introduction and a planned switch. If I were to guess at the thinking here, the plan is to allow us to decouple this slightly - i.e. to introduce a backup key in a planned fashion and to be able to switch keys either as planned process or in response to some situation that compromises the current working key in some manner. Your note seems to head down the path of planned switches, whereas I would offer the view that the overall object here is to carefully rehearse the introduction of backup keys, with the aim to be able to perform a key switch to a live backup with less notice than years or even months, if the need arises. While planning key switches well in advance sounds like a decent approach, we should not fall into the trap of thinking that the only way to perform a switch to a live backup is with such advance notice every time. my 2c anyway Geoff
Hi Geoff, Tony, At 09:58 AM 20-02-2019, Geoff Huston wrote:
There is something in your note Tony that I feel I should comment on. It gets to the heart of why the key gets rolled at all, in my view.
I could offer the view that there is a prevalent feeling (perhaps irrationally - who knows) that a very long-held key will get compromised at some time. Either the tools to break the key will improve, or access to the key will no longer work, or some other mishap. It seems foolhardy not to have some exercised plan to roll the key to respond to such potential eventualities when or if the unplanned disaster happens and we need to roll the key.
Please see Section 4.5 of the DPS. A "roll-over often" approach may have to take that into consideration. Regards, S. Moonesamy
Tony Finch <dot@dotat.at> wrote: > Fred Baker <fred@isc.org> wrote: >> >> The key consideration is that key rollovers are a "usual" event, and as >> such the key(s) should be something learned from the root and the root >> servers, not something configured or compiled into the resolver >> software. +1 > I agree that rollovers need to be routine (I think annual makes sense) but > they have to be planned with software releases in mind. This might require > keys to be generated and promulgated out of band a long time before they > are published in the zone or used for signing. Then a vendor package can > include root keys covering the next couple of years, say. I think that there is very little incremental cost to including a multitude of keys in a software release. i.e. rather than 1 or 3 for the next 3-4 years, I'd like to around a dozen. With a variety of algorithms, keysizes, and with the private keys escrowed in a variety of ways. Some will be expired without ever been used... they are just in case, or in support of as-yet-unknown contingencies. (including fire-drills for such switches) I'd like for this to include a hash-based signature system, but I'm not sure we have the standards specifications for this nailed down sufficiently. Yes, there is some non-trivial cost for the root-zone key holder to keep more private keys safe. It is my understanding that the ICANN software for this is being revised to be significantly more flexible, and so I also see this as a way to make sure it all really works. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
On Feb 20, 2019, at 1:39 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
Tony Finch <dot@dotat.at> wrote:
Fred Baker <fred@isc.org> wrote:
The key consideration is that key rollovers are a "usual" event, and as such the key(s) should be something learned from the root and the root servers, not something configured or compiled into the resolver software.
+1
I agree that rollovers need to be routine (I think annual makes sense) but they have to be planned with software releases in mind. This might require keys to be generated and promulgated out of band a long time before they are published in the zone or used for signing. Then a vendor package can include root keys covering the next couple of years, say.
I think that there is very little incremental cost to including a multitude of keys in a software release. i.e. rather than 1 or 3 for the next 3-4 years, I'd like to around a dozen. With a variety of algorithms, keysizes, and with the private keys escrowed in a variety of ways. Some will be expired without ever been used... they are just in case, or in support of as-yet-unknown contingencies. (including fire-drills for such switches) I'd like for this to include a hash-based signature system, but I'm not sure we have the standards specifications for this nailed down sufficiently.
There are two hash-based signature schemes that have been reviewed by the IRTF CFRG, one is already and RFC and the other is in the RFC Editor queue. Both of them have huge signature values, which would be an interesting challenge in the DNSSEC environment. I think we should be using hash-based signatures to sign software and firmware. They will give us authentication and integrity protection even if a large-scale quantum computer gets invented soon. That will allow us to deploy the next generation when we know what that looks like (see https://csrc.nist.gov/projects/post-quantum- <https://csrc.nist.gov/projects/post-quantum-cryptography>cryptography <https://csrc.nist.gov/projects/post-quantum-cryptography>). Russ
On Wed, 20 Feb 2019, Russ Housley wrote:
I think that there is very little incremental cost to including a multitude of keys in a software release. i.e. rather than 1 or 3 for the next 3-4 years, I'd like to around a dozen. With a variety of algorithms, keysizes, and with the private keys escrowed in a variety of ways.
That makes monitoring and transparency recoding of private key usage much harder. It also raises the possibly abuse of any DNSSEC key to the weakest key escrow method, and will surely raise lots of red flags with people who already don't trust this system. One of our arguments now is that if Verisign or ICANN abuses its key holding power, they will go down (commercially or non-commercially) and so they have a strong incentive not to blindly accept NSLs. When we have multiple escrow parties, its easy to sacrifice one. So this is detrimental to the security of the system as a whole.
I'd like for this to include a hash-based signature system, but I'm not sure we have the standards specifications for this nailed down sufficiently.
Please experiment locally, not globally. Kthanks :) Paul
Please note that the text Paul quotes is from Michael Richardson, not Russ Housley.
On Feb 20, 2019, at 2:09 PM, Paul Wouters <paul@nohats.ca> wrote:
On Wed, 20 Feb 2019, Russ Housley wrote:
I think that there is very little incremental cost to including a multitude of keys in a software release. i.e. rather than 1 or 3 for the next 3-4 years, I'd like to around a dozen. With a variety of algorithms, keysizes, and with the private keys escrowed in a variety of ways.
That makes monitoring and transparency recoding of private key usage much harder. It also raises the possibly abuse of any DNSSEC key to the weakest key escrow method, and will surely raise lots of red flags with people who already don't trust this system.
One of our arguments now is that if Verisign or ICANN abuses its key holding power, they will go down (commercially or non-commercially) and so they have a strong incentive not to blindly accept NSLs. When we have multiple escrow parties, its easy to sacrifice one. So this is detrimental to the security of the system as a whole.
I'd like for this to include a hash-based signature system, but I'm not sure we have the standards specifications for this nailed down sufficiently.
Please experiment locally, not globally. Kthanks :)
Paul _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On Wed, 20 Feb 2019, Matt Larson wrote:
Subject: Re: [ksk-rollover] Future rollover planning opportunities
Please note that the text Paul quotes is from Michael Richardson, not Russ Housley.
Indeed. It seems Russ's client quoting was incompatible with my client's ability to detect it was quoted, and it all appeared as written by him. A source check reveals Russ only included an HTML copy and not a ascii/text version in his reply. When I open the HTML manually, the quoting looks okay. Oh standards, they work so well :) Paul
mcr> I think that there is very little incremental cost to including a mcr> multitude of keys in a software release. i.e. rather than 1 or 3 mcr> for the next 3-4 years, I'd like to around a dozen. With a variety mcr> of algorithms, keysizes, and with the private keys escrowed in a mcr> variety of ways. Paul Wouters <paul@nohats.ca> wrote: > That makes monitoring and transparency recoding of private key usage > much harder. It also raises the possibly abuse of any DNSSEC key to the > weakest key escrow method, and will surely raise lots of red flags with > people who already don't trust this system. yeah, so the idea is not that it be a free-for-all, but that we might have many more keys maintained by perhaps just one additional entity. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
On Wed, 20 Feb 2019, Michael Richardson wrote:
Paul Wouters <paul@nohats.ca> wrote:
That makes monitoring and transparency recoding of private key usage much harder. It also raises the possibly abuse of any DNSSEC key to the weakest key escrow method, and will surely raise lots of red flags with people who already don't trust this system.
yeah, so the idea is not that it be a free-for-all, but that we might have many more keys maintained by perhaps just one additional entity.
That was discussed in the past too, eg by the Root Key rollover design team. The issue with that is that it most likely means that if one key cannot be used anymore for reason X, most likely the whole set cannot be used anymore for the same reason. Eg if there is an issue with a RNG, or with the HSM security, etc. Paul
On 20 Feb 2019, at 13:29, Tony Finch wrote:
However there has to be a bootstrap mechanism, and the only one available is for the validator vendor to provide an initial key set.
If it can provide an initial key set, it can also provide a current key set. See below :)
I agree that rollovers need to be routine (I think annual makes sense) but they have to be planned with software releases in mind.
I strongly disagree. Users have a trust relationship that everything is built on already - that with their software vendors. For most people, that is ‘Debian’ or ‘CentOS’ or perhaps ‘Microsoft’. Debian already ships a dns-root-data package that contains the current root trust anchors. This package is updated outside of any release schedules imposed by ISC, PowerDNS, NLnetlabs, etc. I understand that the RedHat/CentOS/Fedora side of things also has plans for this, or maybe has done this meanwhile. Please build on that relationship. It’s all we need. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/
participants (10)
-
Fred Baker -
Geoff Huston -
Kim Davies -
Matt Larson -
Michael Richardson -
Paul Wouters -
Peter van Dijk -
Russ Housley -
S Moonesamy -
Tony Finch