- ksk-rollover - lists.icann.org

new ksk and DNS software vendors
by manu tman March 30, 2019

March 30, 2019

Hi all, During the BoF session this morning, it was asked how long it would take vendors to incorporate the new KSK in their software. The few that spoke said it was a relatively short time. This is fine for people that get the latest versions and install it, but involves more communication between multiple parties when the goal is to update the keys and does not involve binary change. The main issue with going through that route is that the new key is only useful once it makes it into the distros that ship those softwares which involves DNS software vendors to work with upstream distros to get it in. One approach I would suggest is to rather work with DNS vendors to make sure they can all read the keys from a given format(s) (which I am sure is already the case) and then work with distros to make sure that all the DNS software they ship uses the same file. This file can then be distributed via a `trust-anchor` package à la `ca-certificates` for RedHat and Debian based distros. There is obviously an existing process for that, so I am hopeful it could be replicated for getting trust anchors from IANA. Automation on the distro side to pick up new trust anchors also seem rather trivial. I would love to hear from people closer to the distros realm if this is not, but it seems something that could be quite easily addressed and would be sustainable long term. The update will apply uniformly to all DNS softwares shipped by the distros, there is no need to rebuild/recompile anything which involves DNS softwares, the package is pretty trivial to update and assuming 4 major OSS DNS softwares, overhead drops by 3/4, or even close to 0 if some form of automation is put in place. Manu

5 6

KSK2017 Rollover was a success
by Ólafur Guðmundsson March 30, 2019

March 30, 2019

Repeat from what I said at the microphone today Main lesson from this roll is it worked better than we could have expected, given this was the first time, We expect that software/configuration has bugs/errors and this exposed some. There might have been some configurations that did not anticipate change in the key used ==> nothing beside rolling the KSK could have exposed that. There were some outages, there may have been some sites that turned off DNSSEC and we need to get some measurements of what that long term effect was i.e. did the validation get turned back on. The traffic increase reported was interesting but the big picture is it was in the NOISE range, i.e. all root servers should be able to deal with such small increase. I have no opinion at this point when next to roll or how fast to perform that roll. Ólafur

4 3

On the subject of timing
by Matthew Pounsett March 29, 2019

March 29, 2019

Repeating (with a little more care and hopefully clarity) my point from the mic the other morning.. Now that we've got a roll under our belts, I think it's time to move to a condition where the choice of how often to roll the root KSK is mostly a matter of an operational choice of the Root Zone Partners (noting the formal meaning of that term). I would suggest that, as one of the goals of regular rolls is operational practice, the rate of rotation should not be too slow; I think what that means, exactly, is up to the RZP, however. Also keeping in mind that there are, very likely, people in the community that disagree with me on that subject, the RZP should put the timing of the next roll out for public comment (as has been done in the past) but after some sort of rough consensus on the next roll date is reached, make it a matter of operational choice from that point forward. With that distraction out of the way of the community at large, we can get on with the business of figuring out how to do emergency key rolls, bootstrap old hardware, and solve other problems not covered by 5011. All things I shall surely comment on in other threads.

1 0

FYI - notes from KSK Future BoF at IETF 104
by Dan York March 29, 2019

March 29, 2019

FYI, I and others took some notes of the conversation in the KSK Future BOF this week at IETF 104 in Prague: https://etherpad.ietf.org/p/notes-ietf-104-ksk?useMonospaceFont=true Some of the people who commented have sent their own comments directly to this list (and I would suggest reading *those* comments versus the summaries that were made in the notes). Dan -- Dan York Director of Web Strategy, Internet Society york(a)isoc.org +1-603-439-0024 Jabber: york(a)jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/

1 0

Gathering operators' voice
by Yoshiro YONEYA March 28, 2019

March 28, 2019

Following is what I said during KSK Future BoF today. To gather operators' voice widely, conducting survey is a way. Operators are shy to express their experiences to the public mailing list, but they can answer anonymous survey, and then surveyer can proxy their answers anonymily. We can do it in our local community in local language, and bring it back to this mailing list. -- Yoshiro YONEYA

3 2

suggestions for deciding on key roll timing
by Wes Hardaker March 28, 2019

March 28, 2019

I just mentioned this at a mic, and I'm re-broadcasting it here: I believe we should consider two different elements separately for deciding future key-roll strategies: 1) When we should perform the next roll 2) What frequency we should use between future rolls after the next And for #1, I believe we shouldn't be thinking about time at all, but rather we should create two lists of MUSTs and MAYs for rolling next, and ensures all MUSTs are handled. The MUST and MAY list should include both "do this" type entries, as well as "think about this (again)" type entries. After thinking about the later "think about" items, they may, of course, turn into "do this" type entries. tl;dr: we need a list of blockers that must be dealt with before rolling. -- Wes Hardaker USC/ISI

4 3

Need to roll regularly to ensure operational stability.
by Lars-Johan Liman March 28, 2019

March 28, 2019

All, As I stated at the mic in the BOF: We should look at _why_ we want to roll the key. My take is that we want to do this to make sure that rolling the key is a non-event. We need to make sure that all resolvers handle this in a smooth fashion, and that all operators remember what to do when it happens. Ideally it will be automated everywhere. My analogy was the diesel generators in a data centre. You don't wait for The Big Power Outage to run them, you do it every month, so that you discover potential problems, and so that all staff and equipment are "trained" to act appropriately. Repeating the event is the only way to train the world that this is a non-event. Make the "pain" is frequent enough, and people will make sure they handle it appropriately to avoid the pain. --> Automation. With a smooth machinery, we can roll at any time, should an emergency arise. And yes, there is a non-trivial cost associated with rolling, but again, we can only drive down the cost by going for "mass-production". The more often we do it, the lower the cost must be, and will eventually become. I suggest we roll on a yearly basis, but I can be convinced to agree to every two years. I also kind of like the idea to perform unannounced rolls in the future. It. Must. Be. A. Non-event! Cheers, /Liman -- #---------------------------------------------------------------------- # Lars-Johan Liman, M.Sc. ! E-mail: liman(a)netnod.se # Senior Systems Specialist ! Tel: +46 8 - 562 860 12 # Netnod Internet Exchange, Stockholm ! http://www.netnod.se/ #----------------------------------------------------------------------

2 1

Quantum Apocalypse
by Michael StJohns March 28, 2019

March 28, 2019

Retransmitting the points I made at the microphone at the IETF. 1) We don't have a quantum safe signature algorithm that we've selected for DNSSEC and AFAICT, while there are a lot of candidates, even the crypto folks aren't to the point of saying "use this" for any of the candidate algorithms. 2) Once (1) is done, there's at least a few years to agree and produce an RFC. 3) Once (2) is done, there's at least a 5 year uptake period to get the new algorithm support into the resolvers. (And there's the self-same problem that it's impossible for the root publisher to know whether or not a resolver actually supports the new algorithm. It may make sense to actually do a PERT style "what has to happen when and before what" diagram to document the moving pieces and to help figure out if there are any tasks we can complete early (e.g. figuring out how to serve *really big signatures* even if we don't know what the signature mechanism might be). Mike

2 1

Fate sharing
by Olaf Kolkman March 28, 2019

March 28, 2019

As I just mentioned at the #IETF104 BOF. I think there is a fate sharing requirement to be made: DNS infrastructure (authoritative, and recursive servers) that have not bought into the DNSSEC project should not be impacted by the roll. It would be good to understand if there where any resolvers that had resolution issues during the roll while they were not validating. I believe the examples that Geoff gave were about infrastructure that broke because validation was going on (and consequently turned off), but if it is the case that big ISPs lost connectivity while they were not doing DNSSEC validation, because of any stage in key rollover, that would be good to know. Frederico Neves just mentioned to me that 82%+ of queries towards .BR have the DO bit set (even though they may not do validation) which means that they are somewhat bought into any effects caused by transport issues. So maybe that the requirement above may not be realistically met. —Olaf

1 0

Re: [ksk-rollover] A lab test of Root Algorithm Rollover
by Medel Ramirez March 25, 2019

March 25, 2019

Davey, This is super Kool ! Best Medel ++++++++ Sent from my V6 Engine! メデルラミレズ On 25 Mar 2019, at 1:42 PM, Davey Song(宋林健) <ljsong(a)biigroup.cn> wrote: Hi folks, We have done a lab test against the root algorithm rollover last month. There is a preliminary result and supprise I would like to share with you if you are interested. I also would like to call for more participants (resolvers) and input for our second lab test. Comments are welcome. The Slides I presented in Yeti DNS workshop: https://yeti-dns.org/resource/Root-algorithm-rollover-lab-test.pdf The summary I quoted from the meeting note of my presentation: “Basically, we rolled the algorithm in four approaches with different configuration and time lines. The finding is interesting that four approaches successfully for BIND (9.11.5-P1) and UNBOUND(1.8.3) resolver. Note that there is an accidental mistake in configuring the ZSK's inactive time which results no active signing key in the middle of the rollover and causes validation failure(we recovered it with a new ZSK but it still had impact on resolver). As a response to this failure, it is observed BIND restarts the Add Hold-Down Time of new key/algorithm for another 30 days when new valid signing key is available but Unbound continue the timer and trusted the KSK/Algorithm after the rfc5011-timer expired. It is planned that more lab test for rollover should be done before roll the algorithm of Yeti. We will call for more resolvers to join this test.” Best regards, Davey _______________________________________________ ksk-rollover mailing list ksk-rollover(a)icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover -- This e-mail message (including attachments, if any) is intended for the use of the individual or the entity to whom it is addressed and may contain information that is privileged, proprietary, confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete this E-mail message immediately.

1 0