On Mar 14, 2019, at 5:58 PM, Shane Kerr <shane@time-travellers.org> wrote:

Personally I would like to see rolls frequent enough that everything around a roll is automated.

I mostly agree. I think the key thing is that key rolls must be *normal* and the software therefore designed with that assumption. For developers to believe that it is normal, it must be "frequent enough", whatever that means. I personally might vote for "quarterly" or "annual" if the implication is only that operators needed to be aware that it was happening in case something breaks, and 2-3 years might actually be OK, but for sure not "every five years". -------------------------------------------------------------------------------- Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu

On 14. 03. 19 12:01, Warren Kumari wrote:

So, my original "gut feel" was approximately every year, and I still feel that that is roughly the right frequency -- but, I think that we first need to figure out what the cause of the increase in DNSKEY lookups is - it concerns me that we predicted no impact from the revocation, and we got... this. I think that, assuming we figure out the causes of the increase (and understand them well enough that we are fairly sure that they won't jump again!), my gut still says ~1year -- but, more research needed...

As a producer of a DNS validating CPE device/router, I must say, I am not very excited about frequent roll-overs. If your device stays at a retailer store for some time, you might be in a trouble. So I would prefer some longer periods. But it is more important how much in advance is the new key known/published. Ondrej

W

 

-------------------------------------------------------------------------------- Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win.      Sun Tzu

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

-- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.    ---maf

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

-- ( CZ.NIC z.s.p.o. ) ------------------------------------------------- Ondrej Filip - CEO Office : Milesovska 5, Praha 3, Czech Republic Email : ondrej.filip@nic.cz http://www.nic.cz Private: feela@network.cz -------------------------------------------------

Ondrej, On 14/03/2019 14.57, Ondrej Filip wrote:

On 14. 03. 19 12:01, Warren Kumari wrote:

...

So, my original "gut feel" was approximately every year, and I still feel that that is roughly the right frequency -- but, I think that we first need to figure out what the cause of the increase in DNSKEY lookups is - it concerns me that we predicted no impact from the revocation, and we got... this. I think that, assuming we figure out the causes of the increase (and understand them well enough that we are fairly sure that they won't jump again!), my gut still says ~1year -- but, more research needed...

As a producer of a DNS validating CPE device/router, I must say, I am not very excited about frequent roll-overs. If your device stays at a retailer store for some time, you might be in a trouble. So I would prefer some longer periods. But it is more important how much in advance is the new key known/published.

As far as I know, patching is still the only solution we have to securing software on the Internet. That means there must be some way to get software updates to the device. A device can detect a mismatch between the root KSK that it has and the one at the root servers. In that case, it can disable the root trust anchor until it updates the KSK, in whatever way it thinks is reliable enough - probably by updating the package that configured the KSK. My own suggestion would be to include a trust anchor for a zone that serves updated software, since that would minimize the risk of being sent to bogus servers looking for updates. This trust anchor can live forever if you want, because of the awesome decision that DNSKEY records have no lifetime. 😉 Presumably any software update mechanism has its own signatures as well, so the chances of actually getting invalid updates seems minimal. There is already a need to disable DNSSEC at certain times, for example before a device has synchronized its clock, so fiddling with trust anchors is probably something that the device has to do anyway. Maybe someone already has BCP in this area written down? If not, maybe it should be? Cheers, -- Shane

Tony Finch <dot@dotat.at> wrote: >> I also want regular rollover, and I'd like it to be frequent enough that it >> gets tested. I also want it infrequent enough to never be without an anchor. > Trust anchor lifetime can be decoupled from rollover frequency. > If keys are generated a few years in advance of going into active use, > there is plenty of time for them to be disseminated beforehand. They do > not have to be pre-published in the zone (although that is what RFC 5011 > was designed for); they can be distributed out of band by software updates > or other means. If there are annual rollovers with keys generated N years > in advance, at any time there will be N pre-published keys one of which > might be pre-published in the zone, one active KSK in production, and > maybe one in retirement. Yes, I'd like to do that. I'd like N=10, and the roll-over frequency to be yearly. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-

>>> If keys are generated a few years in advance of going into active >>> use, there is plenty of time for them to be disseminated >>> beforehand. They do not have to be pre-published in the zone >>> (although that is what RFC 5011 was designed for); they can be >>> distributed out of band by software updates or other means. If >>> there are annual rollovers with keys generated N years in advance, >>> at any time there will be N pre-published keys one of which might >>> be pre-published in the zone, one active KSK in production, and >>> maybe one in retirement. On 3/14/19 12:38 PM, Michael Richardson wrote: >> Yes, I'd like to do that. I'd like N=10, and the roll-over frequency >> to be yearly. Keith Mitchell <keith@dns-oarc.net> wrote: > The problem with generating that many keys out into the future is they > then become hostages to fortune should any issues arise during that > time-span with the integrity of those keys. e.g. a breach which causes > the private keys to be disclosed, flaws being discovered in the > algorithm in use, or the processes used to generate the keys, etc. > Which would likely mean a complete reset for new keys to be generated, > and a very large pile of baked-in pre-disseminated keys needing revoked. It seems that these issues exist if there are *any* keys generated before use, independantly of the number of keys. Based upon my reading of the spec sheet of the HSM that ICANN uses, it can store ~1K key pairs, so it's not like we need two devices for 10 vs 5 keys. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-

> On Mar 15, 2019, at 4:30 PM, Michael Richardson <mcr+ietf@sandelman.ca> > wrote: > It seems that these issues exist if there are *any* keys generated before > use, independently of the number of keys. Fred Baker <fred@isc.org> wrote: > To my mind, the argument has the issue backwards. The issue is that the > resolver needs to be able to resolve keys currently signed by the IANA, which > means that it needs to know "a" current public key to validate the DNSKEY > response. Rather than publish 2^12 keys that might or might not be used in > the future, it seems to me that it has to be able to identify *a* public key > that has been used in the past and use that to get the current public > key. I agree with you. (I think that there is a substantive difference between 2^12 keys, and 12 keys, and I think 2^12 was hyperbole... moving on) > It might be simplest to let resolver software bake whatever "current key"it > likes, I agree that having a path from the current key at time X to the current key at time Y is a good thing. I don't think it needs to be contained in . > perhaps among a set of candidates, into the software, and use > that > public key to sign the NS request to the root. If the decrypted request is > recognized by the root, it replies to the DNSKEY request with the current > key. While the math says you can encrypt/decrypt with either "public" or "private" keys, and the practice says otherwise. In particular, a) none of root name servers have the private keys online b) the root name servers are run by 13 different entities, and each has 50+ anycast nodes operating as root name servers. c) thanks to DNSSEC there is significant thinking to having recursive resolvers take a copy of the root zone by <someprotocol>, and not bothering the root name servers as often. > The attack on that would be to flood the root with requests using whatever > key might be randomly generated (or no real key), consuming the root's > resource to validate signatures. I'm not sure I have a response to that, but > it probably comes down to a cheap way to identify candidates for validation > and ignore the rest. The attackers know the real public key (it's public), so they don't have to fake it. They could put random garbage in, which I think is your point. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-

Hello, At 03:16 PM 16-03-2019, Dave Lawrence wrote:

It seems to me that what such a list gets you is lead time on cracking future keys, or more things that end up useless in the event some aspect of the whole process is found to have been faulty. This in exchange for the busywork of changing the current key more frequently without adding any real additional security in the process.

The first "trust anchor" was in use for around 10 years. Although it has not caused any security issue, it is better to have "key rotation". There have been discussions in DNSOP and in other venues about "cracking keys" but they were not about the KSK "private key". The current design was not driven by technical limitations of the HSMs used to store the cryptographic material. Having more "keys" might require changes to the design. That would open up an additional set of issues to consider. Regards, S. Moonesamy

Dave Lawrence <tale@dd.org> wrote: > Michael Richardson writes: >> It seems that these issues exist if there are *any* keys generated >> before use, independantly of the number of keys. > Yes, exactly, which makes me scratch my head every time someone > proposes a list of pre-generated keys as the solution to this > problem. Interesting that we agree on a core assumption and then come to opposite conclusions :-) > It seems to me that what such a list gets you is lead time on cracking > future keys, or more things that end up useless in the event some > aspect of the whole process is found to have been faulty. This in > exchange for the busywork of changing the current key more frequently > without adding any real additional security in the process. I could live with a KSK being in use for a long period of time. But, I don't buy the lead time argument. If any of the N keys are vulnerable to brute force attack in the planned use of period, then all the keys are vulnerable to an adversary with 1/N more resources. Do you agree with this? Brute force is not the only attack: there are possible "Mission Impossible"-like exfiltration attacks against the HSM(s). Do these attacks depend upon how many keys there are? I don't think so. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-

Hi, thank you for the reply and context. S Moonesamy <sm+icann@elandsys.com> wrote: > At 01:24 PM 17-03-2019, Michael Richardson wrote: >> Brute force is not the only attack: there are possible "Mission >> Impossible"-like exfiltration attacks against the HSM(s). Do these >> attacks >> depend upon how many keys there are? I don't think so. > After the last KSK Ceremony, there was a discussion with the Root Zone > Manager (Public Technical Identifiers) about the physical controls for > the facility [1] where some of the HSMs are located. I took the > concerns raised on the different threads [2] into account for that > discussion. The issue, as I see it, is not whether an "exflitration > attack" could happen; it is whether > it will be detected and publicly disclosed. I am not addressing the absolute risk of exfiltration attacks, but rather asking if having more keys in the HSM causes a relative change to the risk of exfiltration attacks. More keys generated might mean that the HSM is unlocked more often, but I don't think this would be the case. My understanding is that the HSMs need to be acccessed on a regular basis by the Security Officers anyway in order to sign new ZSKs. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-

Michael Richardson writes:

But, I don't buy the lead time argument. If any of the N keys are vulnerable to brute force attack in the planned use of period, then all the keys are vulnerable to an adversary with 1/N more resources. Do you agree with this?

I completely agree with it. Of course, it does kind of gloss over the details, sidestepping just how high the resource bar is. I will of course also acknowledge that this applies equally well to the current key, both for and against my own position. What we're of course trying to find is the right balance. It is pretty straightforward to posit that if one key is crackable by an adversary of sufficient power in an amount of time that is not less than the defined rolling period, that multiplying the number of such keys extends the period of time that be spent cracking them. I'm a bit perplexed about how lead time can't possibly be relevant.

Brute force is not the only attack: there are possible "Mission Impossible"-like exfiltration attacks against the HSM(s). Do these attacks depend upon how many keys there are? I don't think so.

Right, but that was the other part of my point. So great, you generated 20 keys for the future, and Tom Cruise just stole the Rootsday Device that controls them all. Or Quantum Computerman finally had his breakthrough and *poof* cracking time plummets. What good has having made that list gotten you? We don't want those baked-in products using the list then either. The only thing pre-generating a bunch of keys seems to buy you is a known schedule that you can bake into products. While I won't say that's valueless, for my tastes it doesn't have enough value to be seen as a useful solution for this problem.

On 3/14/19, 08:58, "ksk-rollover on behalf of Michael Richardson" <ksk-rollover-bounces@icann.org on behalf of mcr+ietf@sandelman.ca> wrote:

I think it's reasonable that a live boot/install device do RFC5011 to update itself before reaching out to update software, but I don't think that we leave the chain of keys in place long enough for a 3-5 year LTS to be able to catch up.

(I altered the RFC number in the included text assuming Automated Updates is meant. [...Why I try to refrain from using document numbers as identifiers...] ;) )

(Why would a paranoid person one use such an old release? There are a number of reasons I can think about, some of them involving investigation of potential other compromised software tool chains. Is this enough justification? Maybe.)

The use case of having a device re-establish a secure state after an extended period of being disconnected is one of those "classic problems." I've heard this applied to devices in submarines go radio-silent while the keys are rolled. And, for instance, from 10 years back, "DNSSEC Trust Anchor History Service" https://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-02 That has resulted in an resource record type reservation but the draft hasn't made it into a RFC document. https://www.iana.org/assignments/dns-parameters/TALINK/talink-completed-temp... There were considerable mail threads around that draft in the IETF. My suggestion is to measure the incidence of the use-case. Now would be the time to do so. The key is rolled, how many re-connected devices will try to catch up? It isn't clear how to measure this, but it would be good to measure the volume of this use case. (Who has the data? What should be measured? Is there an objective measure of the need?) Anyone want to take this on? If the impact is high enough, intent (Michael's use of 'paranoia') doesn't matter. In the sense that there have been attempts to address this in the past that have not come to fruition, if the impact is seen, we ought to redouble our efforts. With use cases quantified, the parameters ('3-5 years' from Michael's mail) would be based on what's real, which may precipitate a workable solution.

Thanks again for a yet another great DNSSEC workshop in Kobe! Let me chime in and recap what I said at the meeting. I’m for regular rolling of the root KSK. Less than 5 years, which is too long to keep institutional and operational memory, but no more than every year, which would just be too much churn. Since we’re not in any hurry, I would use some time to look more into the strange increases we’ve seen, but it is not something that keeps me up at night. With regards to online standby keys, it needs to be seen in a holistic way. What threats or scenarios are those keys trying to mitigate? Do they actually provide the security we think they do? E.g. if the active and standby keys are generated in the same HSM, it is no protection from an HSM compromise. What new vulnerabilities do published standby keys pose? With all the lessons learned since 2010, let’s go back to defining the problem we’re trying to solve, rather than having standby keys as a solution looking for a problem. Med venlig hilsen / Best regards Erwin Lansing Head of Security & Chief Technologist [cid:image001.png@01D407D6.ABC8B400][cid:image008.png@01D407D6.CD80C0B0]<https://www.facebook.com/dkhostmaster><https://www.facebook.com/dkhostmaster><https://www.facebook.com/dkhostmaster><https://www.facebook.com/dkhostmaster><https://www.facebook.com/dkhostmaster><https://www.facebook.com/dkhostmaster> <https://www.facebook.com/dkhostmaster> [cid:image009.png@01D407D6.CD80C0B0] <https://www.linkedin.com/company/dk-hostmaster-as> <https://www.linkedin.com/company/dk-hostmaster-as> <https://www.linkedin.com/company/dk-hostmaster-as> <https://www.linkedin.com/company/dk-hostmaster-as> <https://www.linkedin.com/company/dk-hostmaster-as> <https://www.linkedin.com/company/dk-hostmaster-as> <https://www.linkedin.com/company/dk-hostmaster-as> <http://www.internetdagen.dk/>DK Hostmaster A/S • Ørestads Boulevard 108, 11. sal • 2300 København S +45 2980 9214 • erwin@dk-hostmaster.dk • www.dk<http://www.dk>-hostmaster.dk<http://hostmaster.dk> [cid:image007.png@01D407D6.ABC8B400] This is an email from DK Hostmaster A/S. This message may contain confidential information and is intended solely for the use of the intended addressee. If you are not the intended addressee, please notify the sender immediately and delete this e-mail from your system. On 21 Mar 2019, at 14.42, Jacques Latour <Jacques.Latour@cira.ca<mailto:Jacques.Latour@cira.ca>> wrote: As I also stated in the DNSSEC workshop, I support a regular root KSK rollover, annually but not longer than two years, we need to develop muscle memory to rollover the key. Also, if the removal of the old key tomorrow is non eventful then I think it would be worthwhile to roll the key in 6 months while our memory is still fresh, this may force the one who manually update to use automated mechanisms. As for the unexpected increased DNSKEY query results, as I said, it looks very interesting but if there were real users or applications problems behind it then they would be been fix by now, and in my view the increase is probably not end-user / application impacting. Just plain old hardcoding ;-) Jacques -----Original Message----- From: ksk-rollover <ksk-rollover-bounces@icann.org<mailto:ksk-rollover-bounces@icann.org>> On Behalf Of Yoshiro YONEYA Sent: March 13, 2019 5:33 PM To: ksk-rollover@icann.org<mailto:ksk-rollover@icann.org> Subject: [ksk-rollover] followup of DNSSEC Workshop at ICANN64 Hi all, During DNSSEC Workshop at ICANN64, there were discussion regarding future KSK rollover. https://64.schedule.icann.org/meetings/961939 This is followup what I said. I support regular Root Zone KSK Rollover for operational maturity and DNS software matulity. The importance is doing regulary. Frequency may be once per 2-3 years, less than 5 years. -- Yoshiro YONEYA _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org<mailto:ksk-rollover@icann.org> https://mm.icann.org/mailman/listinfo/ksk-rollover