Outdated RIPE NCC Trust Anchors in Fedora Linux Repositories
[Apologies for duplicates] Dear Colleagues, We have discovered that recent versions of the Fedora Linux distribution are shipping with a package called "dnssec-conf", which contains the RIPE NCC's DNSSEC trust anchors. This package is installed by default as a dependency of BIND, and it configures BIND to do DNSSEC validation. Unfortunately, the current version of this package (1.21) is outdated and contains old trust anchors. On 16 December 2009, we had a key roll-over event, where we removed the old Key-Signing Keys (KSKs). From that time, BIND resolvers running on Fedora Linux distributions could not validate any signed responses in the RIPE NCC's reverse zones. If you are running Fedora Linux with the standard BIND package, please edit the file "/etc/pki/dnssec-keys//named.dnssec.keys", and comment out all the lines in it containing the directory path "production/reverse". Then restart BIND. This will stop BIND from using the outdated trust anchors. If you do want to use the RIPE NCC's trust anchors to validate our signed zones, we recommend that you fetch the latest trust anchor file from our website and reconfigure BIND to use it instead of the ones distributed in the dnssec-conf package: https://www.ripe.net/projects/disi/keys/index.html Please remember to check frequently for updates to our trust anchor file, as we introduce new Key-Signing Keys (KSKs) every 6 months. Regards, Anand Buddhdev, DNS Services Manager, RIPE NCC
Moin! On 05.02.2010, at 14:23, Anand Buddhdev wrote:
Please remember to check frequently for updates to our trust anchor file, as we introduce new Key-Signing Keys (KSKs) every 6 months. With the root planning for much longer time frames on KSK rollovers maybe RIPE NCC should think about increasing it's KSK life times.
SO long -Ralf --- Ralf Weber (Internet Citizen) e: dns@fl1ger.de
On 5 Feb 2010, at 14:18, Ralf Weber wrote:
With the root planning for much longer time frames on KSK rollovers maybe RIPE NCC should think about increasing it's KSK life times.
Ralf, I don't follow you. Could you please explain why the NCC should increase the lifetime of its KSKs? Just because "the root's going to have long KSK lifetimes" isn't an answer. :-) As I'm sure you know, there are all sorts of trade-offs that have to be made when choosing key sizes and rollover intervals. And every zone has its own set of requirements and operational criteria. So what's good for one zone may not be so suitable for another. I'd like to hear the reasoning why key management by the NCC should be the same as that for the root, particularly if it goes beyond the usual "if it's good enough for the root, it's good enough for me". FWIW, I regularly make that case when people ask me what DNS software they should run. What I do think would be helpful is a document explaining how the eventual parameters were chosen and the trade-offs/thinking that went into those choices. This is needed for DNSSEC generally as well as for the root zone and the NCC's bits of the .arpa tree.
Moin! On 05.02.2010, at 15:58, Jim Reid wrote:
On 5 Feb 2010, at 14:18, Ralf Weber wrote:
With the root planning for much longer time frames on KSK rollovers maybe RIPE NCC should think about increasing it's KSK life times.
Ralf, I don't follow you. Could you please explain why the NCC should increase the lifetime of its KSKs? Just because "the root's going to have long KSK lifetimes" isn't an answer. :-) As I'm sure you know, there are all sorts of trade-offs that have to be made when choosing key sizes and rollover intervals. And every zone has its own set of requirements and operational criteria. So what's good for one zone may not be so suitable for another. Well the original reason was Anands mail that Fedora delivered an old ripe key. This would not be the case with a key life time of say two years. I always thought that RIPEs schedule was to aggressive wrt to key rollovers. As even in this industry it takes time with people/OS vendors to act.
I'd like to hear the reasoning why key management by the NCC should be the same as that for the root, particularly if it goes beyond the usual "if it's good enough for the root, it's good enough for me". FWIW, I regularly make that case when people ask me what DNS software they should run. I didn't say that and there are good reasons for not having it the same especially not rolling all the keys at the same time. I however think that long term with more zones (think millions) signed there probably will be a best practices for leaf zones.
What I do think would be helpful is a document explaining how the eventual parameters were chosen and the trade-offs/thinking that went into those choices. This is needed for DNSSEC generally as well as for the root zone and the NCC's bits of the .arpa tree. Agreed it would be great to have that.
So long -Ralf --- Ralf Weber (Internet Citizen) e: dns@fl1ger.de
On 5 Feb 2010, at 15:39, Ralf Weber wrote:
Well the original reason was Anands mail that Fedora delivered an old ripe key. This would not be the case with a key life time of say two years.
It would always be a problem if Fedora shipped something with the old keys, no matter what their lifetime was. Stale keys are still stale keys. This sort of problem is always a nuisance on for an OS that depends on informal, volunteer efforts. If the guys working on some tool/project drag their feet or give up, stale code and obsolete configuration data can end up in the distros and repositories. In any case, these alternate trust anchors should hopefully be dead and buried soon. Assuming we have a signed root this summer.... So, given that we should have a signed root Real Soon Now (=> alternate trust anchor schemes fade into oblivion), what impact does that have on the NCC's KSK rollover policy? Will the current schedule be too aggressive or unreasonable when this happens? [And .arpa gets signed of course...] Why? I'd welcome some discussion about this.
On Feb 5 2010, Jim Reid wrote: [...]
In any case, these alternate trust anchors should hopefully be dead and buried soon. Assuming we have a signed root this summer....
And a signed arpa, and a signed in-addr.arpa ... ? No announced time scale for *those* yet :-( [I suggested on the dnssec-deployment list a few months ago that removing one or both of the zone cuts between the root and in-addr.arpa might not be a bad thing, but ID draft-jabley-reverse-servers-01 is veering off in a quite different direction...] -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom.
At 14:58 +0000 2/5/10, Jim Reid wrote:
On 5 Feb 2010, at 14:18, Ralf Weber wrote:
With the root planning for much longer time frames on KSK rollovers maybe RIPE NCC should think about increasing it's KSK life times.
Ralf, I don't follow you. Could you please explain why the NCC should increase the lifetime of its KSKs?
I do not read the message as suggesting that the RIPE NCC match the root zone key management parameters. Instead I read that "there's a new data point available on what the parameters for key management should be, so maybe it is a good time to rethink the RIPE NCC parameters."
Just because "the root's going to have long KSK lifetimes" isn't an answer. :-) Maybe it is. Odds are that the work being done to sign the root is being carried out by a top-notch staff of individuals - if they emerge with some surprising results, it's worth looking into why. But you are also right, there's no need to match the results.
I'd like to hear the reasoning why key management by the NCC should be the same as that for the root, particularly if it goes beyond the usual "if it's good enough for the root, it's good enough for me". FWIW, I regularly make that case when people ask me what DNS software they should run.
Frankly, it's far easier to make the case why not.
What I do think would be helpful is a document explaining how the eventual parameters were chosen and the trade-offs/thinking that went into those choices. This is needed for DNSSEC generally as well as for the root zone and the NCC's bits of the .arpa tree.
The reason I jumped in with this reply is that in the last month or so there was an interesting thread in the IETF about the relationship of key size and key effectivity periods. (I.e., is a key of 1024 bits good for a year, a key of 2048 good for 2?) The outcome of the thread was that, if left up to the cryptographic issues, there would be no need to change keys until a key was detected as being broken. This is because the effective lifetime of a key is not determined by the key itself but rather by the determination of the attackers. The moral - you only need to change the key in an emergency. But, as a good operator you know that you never do anything in an emergency you don't do on a regular basis - whether that means regularly exercise the plan in production, in practice, or in drills. So, the parameters for key change fall under the domain of operational cycles and not cryptographic considerations. And, for operators in large organizations, "regularly" means on a strict periodic schedule (such as monthly) - something that can be easily programmed into cron. The realization that it isn't the cryptography limiting the usefulness of the key to me is "new thinking." All along I thought that the limitation on the effectivity of a key was the cryptography - but for "good enough keys" the limitation is how comfortable I am going without changing it and how much does it cost to change it. Based on that discussion, and the fact that root zone is willing to use longer term keys, I'd rethink the 6 month changes of the KSK. Or maybe just because the root will be signed soon and the RIPE NCC DNSSEC keys will ultimately be chained from there (modulo the reverse map's intermediate zones). Further, when we automate all of the registration interfaces, the cost/pain of rolling the KSK goes to almost 0 - maybe frequently change it. OTOH, if we only have to worry about attacks and abuse, maybe we hardly ever change it. As we progress operationally with DNSSEC, we will be learning a lot more. There's no shame in being the first out the door and then learning you can or should adjust your parameters based on the follower's experiences. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction.
On Fri, 5 Feb 2010, Edward Lewis wrote:
The outcome of the thread was that, if left up to the cryptographic issues, there would be no need to change keys until a key was detected as being broken. This is because the effective lifetime of a key is not determined by the key itself but rather by the determination of the attackers. The moral - you only need to change the key in an emergency.
I don't think that was the outcome at all. As I read it, the outcome was "cryptographers are even more conservative then DNS operators, because key strength is a function of math & money, but the IETF suggested lifetimes were very safe".
The realization that it isn't the cryptography limiting the usefulness of the key to me is "new thinking." All along I thought that the limitation on the effectivity of a key was the cryptography - but for "good enough keys" the limitation is how comfortable I am going without changing it and how much does it cost to change it.
To that I agree. Paul
On 05/02/2010 15:58, Jim Reid wrote:
What I do think would be helpful is a document explaining how the eventual parameters were chosen and the trade-offs/thinking that went into those choices. This is needed for DNSSEC generally as well as for the root zone and the NCC's bits of the .arpa tree.
The RIPE NCC was an early adopter of DNSSEC way back in 2005, and at the time, there was very little operational experience. It was important to exercise the various processes, including key roll-overs. A relatively short roll-over period of 6 months allowed us to invoke our roll-over procedures more frequently. This is especially important as some of our processes are still manual. Things are a bit different now. DNSSEC toolsets have improved, and there are both commercial and open-source products available to handle a lot of the heavy-lifting needed to maintain DNSSEC-signed zones. It would probably be okay to have longer key lifetimes now. Regards, Anand Buddhdev, DNS Services Manager, RIPE NCC
On Fri, 5 Feb 2010, Anand Buddhdev wrote:
Things are a bit different now. DNSSEC toolsets have improved, and there are both commercial and open-source products available to handle a lot of the heavy-lifting needed to maintain DNSSEC-signed zones. It would probably be okay to have longer key lifetimes now.
I think the suggestion was to extend the current keys until July, so that the next rollover would be "covered" by the signed root. Paul
On Fri, Feb 05, 2010 at 03:18:46PM +0100, Ralf Weber wrote:
With the root planning for much longer time frames on KSK rollovers maybe RIPE NCC should think about increasing it's KSK life times.
... or emphasize the point that the NCC's repository of the NCC's trust anchors is the true one and only authoritative repository for the NCC's trust anchors. -Peter
On Fri, Feb 05, 2010 at 08:38:56PM +0100, Peter Koch <pk@DENIC.DE> wrote a message of 10 lines which said:
... or emphasize the point that the NCC's repository of the NCC's trust anchors is the true one and only authoritative repository for the NCC's trust anchors.
Very bad idea because it does not scale: I, sysadmin of a validating resolver, certainly cannot go to 42 different https Web pages to extract the one and only authoritative information.
On Mon, Feb 08, 2010 at 09:01:23AM +0100, Stephane Bortzmeyer wrote:
Very bad idea because it does not scale: I, sysadmin of a validating resolver, certainly cannot go to 42 different https Web pages to extract the one and only authoritative information.
well, this may not lead anywhere useful. If you "cannot" make the conscious decision to configure and maintain a set of trust anchors, then there's a variety of options, including "do nothing". This WG has made a statement regarding the unsolicited inclusion of trust anchors in "some" distribution mechanisms in the past and there was also the list of requirements for TARs, which included prior consent of the party responsible for the KSK/TA. Unfortunately, helpful deployment initiatives have turned into obstacles more than once. -Peter
At 15:12 +0100 2/8/10, Peter Koch wrote:
well, this may not lead anywhere useful.
Regretfully I agree with Peter on this point and in that way. ;) No matter how long the Secure Entry Points (aka KSK) are in use, there will be a on-the-shelf piece of equipment that is turned on after the keys are history. Bill Manning made attempts to characterize that problem years ago - the most recent San Diego IETF if I recall correctly. Every time someone has a case that solves for up to N, there's a case for N+1. (Months, zones, servers, years, you name it.) Remember that DNSSEC is there to protect the resolver. I don't think there is any (or going to be any) one way that is manageable, scale-able, non-commercial (and/or open-source), quick, cheap, in-line, dynamic and convenient for zone operators to use to inform all recursive servers that there are new SEPs - whether just for the root zone or for all the zones, or even just for the roots of DNSSEC-ized subtrees. Well, no "one way" known in advance of deployment. Perhaps in two or three years we'll have an answer. Or in two or three years network administrators will just put up with "the jungle out there." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction.
The I-D draft-wijngaards-dnsop-trust-history-02.txt by Wijngaards & Kolkman is addressing these type of problems. jaap
morning Ed - thanks for reminding me. in that vein, there is a pending proposal to provide a proof of concept implementation of Internet-based "over the air" re-keying to facilitate un-scheduled key rollover. We've not (yet) augmented it to inculde an MofN set of hooks - but that would go a -long- way toward the "on the shelf" problem that RFC 5011 does not address well. Once we get it working, it is possible that we might bring it to the IETF for consideration. --bill On Mon, Feb 08, 2010 at 09:33:36AM -0500, Edward Lewis wrote:
At 15:12 +0100 2/8/10, Peter Koch wrote:
well, this may not lead anywhere useful.
Regretfully I agree with Peter on this point and in that way.
;)
No matter how long the Secure Entry Points (aka KSK) are in use, there will be a on-the-shelf piece of equipment that is turned on after the keys are history.
Bill Manning made attempts to characterize that problem years ago - the most recent San Diego IETF if I recall correctly. Every time someone has a case that solves for up to N, there's a case for N+1. (Months, zones, servers, years, you name it.)
Remember that DNSSEC is there to protect the resolver. I don't think there is any (or going to be any) one way that is manageable, scale-able, non-commercial (and/or open-source), quick, cheap, in-line, dynamic and convenient for zone operators to use to inform all recursive servers that there are new SEPs - whether just for the root zone or for all the zones, or even just for the roots of DNSSEC-ized subtrees.
Well, no "one way" known in advance of deployment.
Perhaps in two or three years we'll have an answer. Or in two or three years network administrators will just put up with "the jungle out there." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468
As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction.
participants (10)
-
Anand Buddhdev -
bmanning＠vacation.karoshi.com -
Chris Thompson -
Edward Lewis -
Jaap Akkerhuis -
Jim Reid -
Paul Wouters -
Peter Koch -
Ralf Weber -
Stephane Bortzmeyer