new ksk and DNS software vendors
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
Hi all, Thank you Manu. On 28/03/2019 15:39, manu tman wrote:
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.
Indeed, this is correct. We do have contact persons with the well known Linux and *BSD distributions, and there are procedures to get the new DNSSEC key incorporated in stable distributions. For us it takes a relative small effort and a short time, but puts some burden at the packagers and distributions to update the software in their repos.
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.
I would support such an approach to update/distribute trust-anchors with distributions. Debian already has a package 'dns-root-data' that includes the TA (amongst other things) and installs the files in /usr/share/dns/ (credits to Ondrej, Robert and dkg). Speaking for Unbound, it is not using this package right now in Debian---its default config is with unbound-anchor and TA in software as fallback---but can be configured & packaged to make use of a system-wide installed TA. --Benno -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/
Hi, On Mar 28, 2019, at 7:39 AM, manu tman <chantr4@gmail.com> wrote:
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.
I suspect the most common resolvers on the Internet today are either Microsoft DNS or some version of DNSMasq. Have those vendors weighed in on the triviality of update of their installed base? Regards, -drc
On Thu, Mar 28, 2019 at 4:58 PM David Conrad <david.conrad@icann.org> wrote:
Hi,
On Mar 28, 2019, at 7:39 AM, manu tman <chantr4@gmail.com> wrote:
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.
I suspect the most common resolvers on the Internet today are either Microsoft DNS or some version of DNSMasq. Have those vendors weighed in on the triviality of update of their installed base?
Thanks David,
Fair point. I suppose Microsoft can handle software updates, for DNSMasq within common distros I don't think it could not be handled the same way, or at least does not seem impossible. Same for systemd-resolved. There will definitely be other cases, like the year-on-a-shelf devices, but I guess this is a different problem. On the assumption that there is software continuity, this mechanism could be a way to relatively quickly push security updates. There were also some discussions around how to deal with the devices that spent a year on a shelf. I suppose one way out is that if such machine could not update resolve dns because the keys are outdated, it would need to perform a non-validating query and get it off IANA website or other pre-set vendor websites that mirrors the keys and rely on SSL cert. But that could open a window to install the wrong keys. Update continuity and bootstrapping outdated software will most likely end up having different solutions. Manu
manu tman <chantr4@gmail.com> wrote: > I suspect the most common resolvers on the Internet today are > either Microsoft DNS or some version of DNSMasq. Have those vendors > weighed in on the triviality of update of their installed base? Definitely dnsmasq. > There will definitely be other cases, like the year-on-a-shelf devices, > but I guess this is a different problem. I don't think it's really a different problem. Resolvers that are turned on all the time could use 5011 if they wanted. A "rfc5011d" could dpkg-divert the TAs and update them at the right time. > There were also some discussions around how to deal with the devices > that spent a year on a shelf. I suppose one way out is that if such > machine could not update resolve dns because the keys are outdated, it > would need to perform a non-validating query and get it off IANA > website or other pre-set vendor websites that mirrors the keys and rely > on SSL cert. But that could open a window to install the wrong keys. > Update continuity and bootstrapping outdated software will most likely > end up having different solutions. Yes, it does open up windows of vulnerability, and it seems like forcing someone to open that window would be relatively easy. "Did you try turning it off and on?"-type support often then becomes "factory reset it"... Factory resetting a home router might also wipe out rfc5011 updates too. So I'd really like to solve this problem, and if we do, then it makes the distro-update-package way of getting TAs much less critical. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
manu tman <chantr4@gmail.com> wrote:
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.
I think this will depend a lot on whether the patch is distributed as a routine change or as a security-critical fix. I think it won't look particularly good if the whole DNS gets a CVE every year just to roll the keys in a timely fashion :-) Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ South Utsire, Forties: Southwesterly 5 or 6. Moderate or rough, occasionally slight. Fair. Good.
On Thu, Mar 28, 2019 at 5:16 PM Tony Finch <dot@dotat.at> wrote:
manu tman <chantr4@gmail.com> wrote:
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.
I think this will depend a lot on whether the patch is distributed as a routine change or as a security-critical fix. I think it won't look particularly good if the whole DNS gets a CVE every year just to roll the keys in a timely fashion :-)
:) yeah. This is a discussion that is worth having with the distributions and see what their take on this is. As mentioned in my original email, I would love to hear from people closer to the distros. There is already connection between software vendors and distros, so they could maybe initiate this discussion. Manu
Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ South Utsire, Forties: Southwesterly 5 or 6. Moderate or rough, occasionally slight. Fair. Good.
participants (5)
-
Benno Overeinder -
David Conrad -
manu tman -
Michael Richardson -
Tony Finch