(Un)planning future KSK replacements
At the BoF at IETF 104 I suggested the following. Make the next KSK rollover scheduled. After that, do not announce them. It is the only way to train the infrastructure to be ready to handle emergencies.
On 28 Mar 2019, at 10:14, Salz, Rich via ksk-rollover wrote:
At the BoF at IETF 104 I suggested the following.
Make the next KSK rollover scheduled. After that, do not announce them. It is the only way to train the infrastructure to be ready to handle emergencies.
May I propose we call these Stochastic Key rolls. ;-) —Olaf
On 28 Mar 2019, at 10:23, Olaf Kolkman wrote:
May I propose we call these Stochastic Key rolls. ;-)
Love it :-) Besides the joke, I do also support regular-ish rolls. I also agree that the main purpose for rolling the keys, at least for the next 4-5 years is to get a lot of the machinery out there oiled as Liman said. While it is true that IANA and the large operators should not need this poking from the top to have their procedures and machinery ready for emergency rolling, I do not believe that this is true for the wider DNS operator community. Should the rolls continue forever ? Maybe not, but I definitely see a need for them in the next 4-5 years. /Carlos
Carlos M. Martinez (carlosm3011) writes:
Should the rolls continue forever ? Maybe not, but I definitely see a need for them in the next 4-5 years.
Why shouldn't the rolls continue forever ? What's the argument for not doing so ? Exception situations that don't get tested are almost certain to fail in one way or another. By making the exception the normal course of operations, it's part of daily operations, and it stops being an issue.
I didn’t say they shouldn’t. I tried to convey that I’m not sure. via Newton Mail [https://cloudmagic.com/k/d/mailapp?ct=pi&cv=10.0.14&pv=12.1.4&source=email_f...] On Fri, Mar 29, 2019 at 9:58 AM, Phil Regnauld <regnauld@nsrc.org> wrote: Carlos M. Martinez (carlosm3011) writes:
Should the rolls continue forever ? Maybe not, but I definitely see a need for them in the next 4-5 years.
Why shouldn't the rolls continue forever ? What's the argument for not doing so ? Exception situations that don't get tested are almost certain to fail in one way or another. By making the exception the normal course of operations, it's part of daily operations, and it stops being an issue.
From my perspective, we need the rolls in order to counter potential compromises of the root key. One of the characteristics of a successful compromise of the root key is that we don't know it happened. Hence, waiting until we know it happened to roll it is a matter of waiting for the horses to leave the proverbial barn before closing the barn door. Apologies if that's an Americanism... If we follow that logic to its conclusion, if we roll the key at all, ever, we need to roll it periodically - and there is no last roll, because the threat never goes away. The issue is the interval, not the requirement for doing so. As to what period - I have previously said on this list that quarterly or annually seems reasonable from my perspective, based on the level of effort ISC put into the key roll. Again, the argument for more frequently than once per century is that the more frequently it rolls the greater the probability that (1) people will not be surprised that it does and (2) the process is automated to make it painless, or as painless as it can be. One comment that was made earlier is that care needed to be taken around some folks that compile the key into their software. From my perspective, it makes sense to compile a reference key that can be used to validate a new key downloaded in a DNSKEY record. Apart from that, I have a hard time imagining why one would compile a key into the software - because it makes rolling the key that much harder.
On Mar 29, 2019, at 9:58 AM, Phil Regnauld <regnauld@nsrc.org> wrote:
Carlos M. Martinez (carlosm3011) writes:
Should the rolls continue forever ? Maybe not, but I definitely see a need for them in the next 4-5 years.
Why shouldn't the rolls continue forever ? What's the argument for not doing so ? Exception situations that don't get tested are almost certain to fail in one way or another. By making the exception the normal course of operations, it's part of daily operations, and it stops being an issue. _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On 3/28/2019 5:14 AM, Salz, Rich via ksk-rollover wrote:
At the BoF at IETF 104 I suggested the following.
Make the next KSK rollover scheduled. After that, do not announce them. It is the only way to train the infrastructure to be ready to handle emergencies.
I mostly agree with this, and would totally agree if we were completely 5011 based, but that's not the case. I think there needs to be an "interested parties" announcement even if this isn't announced widely. E.g. ISPs that do manual configuration on roll-their-own DNS resolvers etc.
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
* I mostly agree with this, and would totally agree if we were completely 5011 based, but that's not the case. I think there needs to be an "interested parties" announcement even if this isn't announced widely. E.g. ISPs that do manual configuration on roll-their-own DNS resolvers etc. If you pre-announce to interested parties, then you are not helping those parties learn how to handle unannounced emergencies.
On 3/28/2019 6:19 AM, Salz, Rich wrote:
* I mostly agree with this, and would totally agree if we were completely 5011 based, but that's not the case. I think there needs to be an "interested parties" announcement even if this isn't announced widely. E.g. ISPs that do manual configuration on roll-their-own DNS resolvers etc.
If you pre-announce to interested parties, then you are not helping those parties learn how to handle unannounced emergencies.
So basically, the 5011 signalling would be the announcement? *shrug* WFM. Mike
msj> o I mostly agree with this, and would totally agree if we were msj> completely 5011 based, but that's not the case. I think there msj> needs to be an "interested parties" announcement even if this msj> isn't announced widely. E.g. ISPs that do manual configuration msj> on roll-their-own DNS resolvers etc. salz> If you pre-announce to interested parties, then you are not salz> helping those parties learn how to handle unannounced salz> emergencies. It is not the IETF's job to tell large ISP that they must do 5011. We need to consider that the world will never be all 5011 and that alternate automation methods are valid and how we'd address that in an emergency.
Paul Ebersman <list-ksk-rollover@dragon.net> wrote: msj> o I mostly agree with this, and would totally agree if we were msj> completely 5011 based, but that's not the case. I think there needs msj> to be an "interested parties" announcement even if this isn't msj> announced widely. E.g. ISPs that do manual configuration on msj> roll-their-own DNS resolvers etc. salz> If you pre-announce to interested parties, then you are not helping salz> those parties learn how to handle unannounced emergencies. > It is not the IETF's job to tell large ISP that they must do 5011. We > need to consider that the world will never be all 5011 and that > alternate automation methods are valid and how we'd address that in an > emergency. I don't really understand the long-term reasons for not doing 5011. Can you explain this further? I understand short-to-medium term "software not ready" issues, but not long-term resistence to 5011. [Can ISPs still use HOSTS.TXT ?] -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
ebersman> It is not the IETF's job to tell large ISP that they must do ebersman> 5011. We need to consider that the world will never be all ebersman> 5011 and that alternate automation methods are valid and how ebersman> we'd address that in an emergency. mcr> I don't really understand the long-term reasons for not doing 5011. mcr> Can you explain this further? Phased rollout and control of when things change.
ebersman> It is not the IETF's job to tell large ISP that they must do ebersman> 5011. We need to consider that the world will never be all ebersman> 5011 and that alternate automation methods are valid and how ebersman> we'd address that in an emergency. mcr> I don't really understand the long-term reasons for not doing 5011. mcr> Can you explain this further? list-ksk-rollover@dragon.net:
Phased rollout and control of when things change.
Aye. I agree that we shouldn't prescribe how people automate, or even that they do it at all. 5011 is _one_ way to do it, and I happen to like it, but that doesn't mean that it is good for $everybody. If $someone prefers to do it manually, be my guest, but $they should make d---ed sure to actually do it or be prepared to live with the consequences from not doing it. It will be an error-prone recurring pain that _I_ don't like to feel but $someone could have a pain addiction that I'm glad I don't have. :-) So: live and let live. Either automate (somehow!) or don't complain! :-) Cheers, /Liman
What is the purpose of doing a key rollover? I'll claim that it is to help make sure you're ready to handle an unplanned situation. If nothing goes wrong, then you don't need to change the key. If something does go wrong you do need to react; the speed required depends on the circumstances.
On 29/03/2019 12:28, Salz, Rich via ksk-rollover wrote:
What is the purpose of doing a key rollover? I'll claim that it is to help make sure you're ready to handle an unplanned situation. If nothing goes wrong, then you don't need to change the key. If something does go wrong you do need to react; the speed required depends on the circumstances.
Indeed - if you need to do it because the current key has been compromised then 5011 doesn't help at all because of the 30 day hold-time timer. Ray
*grumble* It’s not 5011s fault if the root zone does not currently include standby keys. Fortunately, that may be a shorter term issue. Mike On Fri, Mar 29, 2019 at 12:38 Ray Bellis <ray@isc.org> wrote:
On 29/03/2019 12:28, Salz, Rich via ksk-rollover wrote:
What is the purpose of doing a key rollover? I'll claim that it is to help make sure you're ready to handle an unplanned situation. If nothing goes wrong, then you don't need to change the key. If something does go wrong you do need to react; the speed required depends on the circumstances.
Indeed - if you need to do it because the current key has been compromised then 5011 doesn't help at all because of the 30 day hold-time timer.
Ray
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On 29/03/2019 13:26, StJohns, Michael wrote:
*grumble* It’s not 5011s fault if the root zone does not currently include standby keys.
No slight at you intended, Mike :)
Fortunately, that may be a shorter term issue. Mike
If standby keys become a thing, would it perhaps be useful if keys were pre-published as CDNSKEY / CDS records in the root so that they can be distributed without causing additional computational load on validators or bloating of the DNSKEY RR set? Ray
On Fri, Mar 29, 2019 at 01:44:06PM +0100, Ray Bellis wrote:
If standby keys become a thing, would it perhaps be useful if keys were pre-published as CDNSKEY / CDS records in the root so that they can be distributed without causing additional computational load on validators or bloating of the DNSKEY RR set?
I like this idea a lot. CDS seems like it's probably more doable than CDNSKEY. IIRC, the IANA powers-that-be have been resistant in the past to pre-publishing public keys but more open to pre-publishing hashes. So, CDS in a typical zone would be a signal to the parent to update the DS, and in the root zone it would be a signal to validators to update their trust anchors. (5011 holddown timing should probably apply, though...) -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc.
Evan Hunt <each@isc.org> wrote: > I like this idea a lot. ME TOO! > CDS seems like it's probably more doable than CDNSKEY. IIRC, the IANA > powers-that-be have been resistant in the past to pre-publishing public > keys but more open to pre-publishing hashes. pre-publishing hashes probably achieves all the results that those like me want in being able to build a software release that will live for 5-10 years on a shelf, while satisfying those who worry about brute force (or other?) attacks on the keys. -- ] 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 [
Won’t be useful for 5011 resolvers. They’re looking for a specific pattern of data publishing of dnskey and rrsigs. Publishing a cdnskey wouldn’t result in any new trust anchor being installed. Mike On Fri, Mar 29, 2019 at 13:44 Ray Bellis <ray@isc.org> wrote:
On 29/03/2019 13:26, StJohns, Michael wrote:
*grumble* It’s not 5011s fault if the root zone does not currently include standby keys.
No slight at you intended, Mike :)
Fortunately, that may be a shorter term issue. Mike
If standby keys become a thing, would it perhaps be useful if keys were pre-published as CDNSKEY / CDS records in the root so that they can be distributed without causing additional computational load on validators or bloating of the DNSKEY RR set?
Ray
Am 29.03.19 um 14:43 schrieb StJohns, Michael:
Won’t be useful for 5011 resolvers. They’re looking for a specific pattern of data publishing of dnskey and rrsigs. Publishing a cdnskey wouldn’t result in any new trust anchor being installed. sounds like 5011bis describing $to_be_defined and get that implemented by resolver vendors.
Andreas
On Fri, Mar 29, 2019 at 02:43:06PM +0100, StJohns, Michael wrote:
Won’t be useful for 5011 resolvers.
This would be a new approach, not 5011. As I said at the mic, since the operational effect of having a standby key was pretty manageable, we should do that routinely. But publishing CDS in the root also strikes me as a good idea. I could see it getting used in some environments where 5011 isn't. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc.
Ray Bellis <ray@isc.org> wrote:
If standby keys become a thing, would it perhaps be useful if keys were pre-published as CDNSKEY / CDS records in the root so that they can be distributed without causing additional computational load on validators or bloating of the DNSKEY RR set?
Cunning :-) Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Ardnamurchan Point to Cape Wrath: Southwesterly 5 or 6 at first in far south, otherwise variable 3 or 4, becoming westerly or northwesterly 5 or 6, occasionally 7 later in north. Rough or very rough. Occasional rain or drizzle, fair later. Good, occasionally poor until later.
Lars-Johan Liman <liman@netnod.se> wrote: ebersman> It is not the IETF's job to tell large ISP that they must do ebersman> 5011. We need to consider that the world will never be all 5011 ebersman> and that alternate automation methods are valid and how we'd ebersman> address that in an emergency. mcr> I don't really understand the long-term reasons for not doing 5011. mcr> Can you explain this further? > list-ksk-rollover@dragon.net: >> Phased rollout and control of when things change. > Aye. > I agree that we shouldn't prescribe how people automate, or even that > they do it at all. 5011 is _one_ way to do it, and I happen to like it, > but that doesn't mean that it is good for $everybody. In particular, it fails when the device is not on/connected during the period that the 5011 adds the new key, then it can not use 5011. I think that an alternative to straight 5011 is needed. As far as I understand 5011, the only reason we can't leave the entire chain of keys in at the trust point is because the RRset would get unreasonably large, causing other failures. It seems that the problem is solved if the history of the DNSkey can be placed at some other place. -- ] 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 [
Inline... On 3/29/2019 11:54 AM, Michael Richardson wrote:
Lars-Johan Liman <liman@netnod.se> wrote: ebersman> It is not the IETF's job to tell large ISP that they must do ebersman> 5011. We need to consider that the world will never be all 5011 ebersman> and that alternate automation methods are valid and how we'd ebersman> address that in an emergency.
mcr> I don't really understand the long-term reasons for not doing 5011. mcr> Can you explain this further?
> list-ksk-rollover@dragon.net: >> Phased rollout and control of when things change.
> Aye.
> I agree that we shouldn't prescribe how people automate, or even that > they do it at all. 5011 is _one_ way to do it, and I happen to like it, > but that doesn't mean that it is good for $everybody.
In particular, it fails when the device is not on/connected during the period that the 5011 adds the new key, then it can not use 5011.
No - that's not correct. It fails if it wasn't able to see the old key signing the new key for the add hold down period. If you're following my recommendations in 5011, then the new key C is going to be signed by A for a while, then B for a while, before it becomes the active key. E.g. 2 key steady state starts with A, B gets added and is signed by A for a year. Then C is added, and is signed by A (A signs the DNSKEY RRSET), then A is revoked and B signs the RRSet for another 6 months to a year. When its finally time for C to be the active key, its been signed by the other two keys for quite a long time. The "adds the key" is a resolver state change, NOT a publisher activity.
I think that an alternative to straight 5011 is needed.
As far as I understand 5011, the only reason we can't leave the entire chain of keys in at the trust point is because the RRset would get unreasonably large, causing other failures. No.
It seems that the problem is solved if the history of the DNSkey can be placed at some other place.
5011 was designed to cause resolvers to make state changes to their trust anchor set based on information gathered over a period of time. No resolver makes a "add anchor" state change based on seeing one signature - it makes it after it sees at least two signatures over the DNSKEY RRSet over a period of time. Once the state change is made, the "history" of the signature is irrelevant. This important because it causes the state changes to be tied to particular time ticks in a way that later lies can safely be ignored. As I said at the mike, you can't just trace the signatures, you need to trace the entire state of the trust anchor set - and that is vastly different than the contents of the DNSKEY RRSet and its associated signatures. I've spent a lot of time thinking about this and I don't think it can be done using just information from the DNS. Basically, a key compromised at any time can rewrite the state history for any point from the time the key was valid forward. Even revoking the key doesn't help. An attacker who is able to provide the client who is trying to verify the history the attacker's version of that history can cause that client to set up its trust anchor set state the way the attacker wants it to. Someone banned the use of the term "blockchain" in the discussion, but something like that is probably the right approach. BUT - blockchains like Bitcoin work because many entities write transactions to the global block chain, and repudiating the history to start from a previous point would be easily detected. Given that the contents of the root key set are being written by a single entity with a single chain of trust, I think we're going to need mix in some other non-DNS data to gain the same level of trust and prevent rewind of the root DNSKEY trust anchor state. Mike
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On Fri, 29 Mar 2019 at 22:14, Michael StJohns <msj@nthpermutation.com> wrote:
E.g. 2 key steady state starts with A, B gets added and is signed by A for a year. Then C is added, and is signed by A (A signs the DNSKEY RRSET), then A is revoked and B signs the RRSet for another 6 months to a year. When its finally time for C to be the active key, its been signed by the other two keys for quite a long time.
Given the operational experience we have with large response sizes, it seems like having three KSKs in the DNSKEY set (on top of one or more ZSKs, depending on the current status of a ZSK roll) plus RRSIGs from two different keys is probably not feasible.
On Mar 30, 2019, at 11:03, Matthew Pounsett <matt@conundrum.com> wrote:
Given the operational experience we have with large response sizes, it seems like having three KSKs in the DNSKEY set (on top of one or more ZSKs, depending on the current status of a ZSK roll) plus RRSIGs from two different keys is probably not feasible.
What negative operational experience with large dnskey sets are you talking about? I’ve seen 12 in TLDs without any noticeable impact. Paul
On Sat, 30 Mar 2019 at 11:42, Paul Wouters <paul@nohats.ca> wrote:
On Mar 30, 2019, at 11:03, Matthew Pounsett <matt@conundrum.com> wrote:
Given the operational experience we have with large response sizes, it seems like having three KSKs in the DNSKEY set (on top of one or more ZSKs, depending on the current status of a ZSK roll) plus RRSIGs from two different keys is probably not feasible.
What negative operational experience with large dnskey sets are you talking about? I’ve seen 12 in TLDs without any noticeable impact.
Perhaps I've misunderstood, but I was under the impression Geoff has significant evidence of issues when DNS messages are large enough to fragment in IPv6. Five RRs in a DNSKEY set plus two RRSIGs seems to me to be fairly likely to result in fragmentation.
Michael StJohns <msj@nthpermutation.com> wrote: >> list-ksk-rollover@dragon.net: >>> Phased rollout and control of when things change. >> Aye. >> I agree that we shouldn't prescribe how people automate, or even that >> they do it at all. 5011 is _one_ way to do it, and I happen to like >> it, but that doesn't mean that it is good for $everybody. mcr> In particular, it fails when the device is not on/connected during mcr> the period that the 5011 adds the new key, then it can not use 5011. > No - that's not correct. It fails if it wasn't able to see the old key > signing the new key for the add hold down period. If you're following > my recommendations in 5011, then the new key C is going to be signed by > A for a while, then B for a while, before it becomes the active key. Right. But, if the resolver has A as the trust anchor, and it's offline for the entire B-hold-down-period, then it never moves to B, and therefore does not trust B's signature on C. mcr> As far as I understand 5011, the only reason we can't leave the mcr> entire chain of keys in at the trust point is because the RRset would mcr> get unreasonably large, causing other failures. msj> No. *If* we can leave all the signatures in place, then we can use 5011 to roll forward? > Someone banned the use of the term "blockchain" in the discussion, but > something like that is probably the right approach. If by blockchain, you mean a merkle tree, then I agree... Perhaps the right answer is to sign the RSA/ECDSA/EDDSA keys with a hash-based signature scheme, which, while large, could be kept in a place that has enough space for such a thing. Would it have to reside, in a place reachable by numeric IP address only? I'm not sure. -- ] 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 [
On Sat, 30 Mar 2019 at 21:36, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> Someone banned the use of the term "blockchain" in the discussion, but > something like that is probably the right approach.
If by blockchain, you mean a merkle tree, then I agree... Perhaps the right answer is to sign the RSA/ECDSA/EDDSA keys with a hash-based signature scheme, which, while large, could be kept in a place that has enough space for such a thing.
Would it have to reside, in a place reachable by numeric IP address only? I'm not sure.
If you're trying to design some way to recover trust anchors after a key roll, might I suggest keeping it generalized to "trust anchors" and not "root zone trust anchors"? Someone suggested keeping a set of DNSKEYs with a chain of RRSIGs in an alternate zone, but that isn't scalable to multiple trust anchors unless you've also got some way to signal the name of the alternate zone at the apex. And then we're talking about adding a delegation to the root zone that is not a TLD registry, which has its own set of complexities. Not that whatever you're thinking was necessarily only applicable to the root zone, but I mention this in the hopes that people keep it in mind. If we want to try to add something like a chain of old keys signing each other, it probably needs to be at an off-apex special name (underscores! yay!) or use a new type that is DNSKEY-like, but for a special purpose.
Matthew Pounsett <matt@conundrum.com> wrote: > Someone suggested keeping a set of DNSKEYs with a chain of RRSIGs in an > alternate zone, but that isn't scalable to multiple trust anchors unless > you've also got some way to signal the name of the alternate zone at the > apex. And then we're talking about adding a delegation to the root zone that > is not a TLD registry, which has its own set of complexities. One thought is a set of files, copies of the root zone in AXFR or DNS presentation format. If available via TCP at a known IP address(es), then the client can replay the process and roll itself forward. It would be nice if we could use the root NS hints as the list of IPs, with some kind of redirect of the relevant port (80?) to another machine, but I don't think that's a load I want the anycast root name servers to support. > Not that whatever you're thinking was necessarily only applicable to the root > zone, but I mention this in the hopes that people keep it in mind. If we want > to try to add something like a chain of old keys signing each other, it > probably needs to be at an off-apex special name (underscores! yay!) or use a > new type that is DNSKEY-like, but for a special purpose. If you change the thing to non-DNSKEY, then the signatures have to change. There is an advantage to just leaving things literally (byte for byte) as they are/were. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
On Mon, 1 Apr 2019 at 11:54, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
Matthew Pounsett <matt@conundrum.com> wrote: > Someone suggested keeping a set of DNSKEYs with a chain of RRSIGs in an > alternate zone, but that isn't scalable to multiple trust anchors unless > you've also got some way to signal the name of the alternate zone at the > apex. And then we're talking about adding a delegation to the root zone that > is not a TLD registry, which has its own set of complexities.
One thought is a set of files, copies of the root zone in AXFR or DNS presentation format. If available via TCP at a known IP address(es), then the client can replay the process and roll itself forward.
That's still seems root-zone specific, though. They're not particularly common, but there are other trust anchors out there. As was done with 5011, it seems prudent to think about how anything we design could be applied to other zones.
Matthew Pounsett <matt@conundrum.com> wrote: >> Matthew Pounsett <matt@conundrum.com> wrote: > Someone suggested >> keeping a set of DNSKEYs with a chain of RRSIGs in an > alternate >> zone, but that isn't scalable to multiple trust anchors unless > >> you've also got some way to signal the name of the alternate zone at >> the > apex. And then we're talking about adding a delegation to the >> root zone that > is not a TLD registry, which has its own set of >> complexities. >> >> One thought is a set of files, copies of the root zone in AXFR or DNS >> presentation format. If available via TCP at a known IP address(es), >> then the client can replay the process and roll itself forward. > That's still seems root-zone specific, though. They're not > particularly common, but there are other trust anchors out there. As > was done with 5011, it seems prudent to think about how anything we > design could be applied to other zones. That seems a reasonable goal, but if other trust anchors can be updated through the normal software update process then they may be less of a problem. If you can't resolve the root (and don't want to turn off DNSSEC), then the rest of the Internet is gone... -- ] 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 [
Salz, Rich via ksk-rollover (ksk-rollover) writes:
* I mostly agree with this, and would totally agree if we were completely 5011 based, but that's not the case. I think there needs to be an "interested parties" announcement even if this isn't announced widely. E.g. ISPs that do manual configuration on roll-their-own DNS resolvers etc.
If you pre-announce to interested parties, then you are not helping those parties learn how to handle unannounced emergencies.
+1. The one thing that worries me most here is that if we don't make KSK rollovers part of something your software and/or distro deals with automatically, each pre-announced roll will result in huge amounts of of time and resources wasted on long threads on various mailing lists, with the risk of bringing the n+1 roll to a grinding halt if the least doubt arises. We are nearly 9 *years* into the signed root. Mission accomplished ? As Pieter wrote:
There are non-5011 ways to get the anchors (e.g. time fetches of the XML). But a list for announcements to interested parties, without the publication fanfare makes sense to not spring this on people.
... so yeah, work with the vendors/distros, make this as automatic and normal as possible, so we can use our time on other issues that haven't been solved yet ;) Cheers, Phil
Hi, On 3/28/19 11:01 AM, Michael StJohns wrote:
I mostly agree with this, and would totally agree if we were completely 5011 based, but that's not the case. I think there needs to be an "interested parties" announcement even if this isn't announced widely. E.g. ISPs that do manual configuration on roll-their-own DNS resolvers etc.
Correct. PowerDNS Recursor also does not do (and probably will never do) 5011. We ship the KSK TA's in the binary but are attempting to make the OS vendors (Debian, RedHat etc.) "responsible" for providing this data as they already do for the root server hints. Many (almost most) software users have a trust-relationship with their OS vendor to provide them with up-to-date data required for continued operation. Even if one does not _pay_ for this relationship, it simply exists by the choice made by the operator to run this software stack. There are non-5011 ways to get the anchors (e.g. time fetches of the XML). But a list for announcements to interested parties, without the publication fanfare makes sense to not spring this on people. Best regards, Pieter -- Pieter Lexis PowerDNS.COM BV -- https://www.powerdns.com
Pieter Lexis <pieter.lexis@powerdns.com> wrote: > On 3/28/19 11:01 AM, Michael StJohns wrote: >> >> I mostly agree with this, and would totally agree if we were >> completely 5011 based, but that's not the case. I think there needs >> to be an "interested parties" announcement even if this isn't >> announced widely. E.g. ISPs that do manual configuration on >> roll-their-own DNS resolvers etc. > Correct. PowerDNS Recursor also does not do (and probably will never > do) 5011. We ship the KSK TA's in the binary but are attempting to make > the OS vendors (Debian, RedHat etc.) "responsible" for providing this > data as they already do for the root server hints. So, one could have an rfc5011d that ran in parallel (or from cron) that updated the hints, and life would be okay for you? -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
Hi Michael, On 3/28/19 4:46 PM, Michael Richardson wrote:
So, one could have an rfc5011d that ran in parallel (or from cron) that updated the hints, and life would be okay for you?
Yes, however all of this is an operator choice. Many operators are not DNS-savvy enough to understand all ramifications but *do* understand that OS upgrades are important. This would make operating a validating resolver a bit more hands-off. Cheers, Pieter -- Pieter Lexis PowerDNS.COM BV -- https://www.powerdns.com
Like all good security discussions, things inevitably come back to the question about what are the threats one is trying to mitigate. Probably it's in a document that I didn't adequately read at some point, but given that we are having the discussion about why we should roll at all, it seems that we don't have a share understanding of the threats. As Fred says later in this thread:
From my perspective, we need the rolls in order to counter potential compromises of the root key. One of the characteristics of a successful compromise of the root key is that we don't know it happened. Hence, waiting until we know it happened to roll it is a matter of waiting for the horses to leave the proverbial barn before closing the barn door. Apologies if that's an Americanism...
If I understand the key signing ceremony proceedure correctly, there are multiple HSMs kept in multiple locations, but that each HSM has the same contents. We have many for redundancy/failure of HSM, not to split up the risk. It seems that having different iteration of the keys stored in different HSMs under control of different entities would help with dealing with the barn door being open. ==== {Personally, I still go back to: https://www.ssh.com/a/draft-ylonen-spki-binary-00.txt section 7.3.1: which was not AFAIK, published as an RFC: 7.3.1. One Possible Organization of DNS Name Delegation There is no single key for the domain name hierarchy. Instead, there are four keys, three of which are required to sign each top-level domain. The keys are each held by a trusted organization in the US, in EU, in Japan, and by some other suitable organization. ...} -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
participants (19)
-
A. Schulze -
Carlos M. Martinez -
Carlos Marcelo Martinez Cagnazzo
-
Evan Hunt -
Fred Baker -
Lars-Johan Liman -
Matthew Pounsett -
Michael Richardson -
Michael Richardson -
Michael StJohns -
Olaf Kolkman -
Paul Ebersman -
Paul Wouters -
Phil Regnauld -
Pieter Lexis -
Ray Bellis -
Salz, Rich -
StJohns, Michael
-
Tony Finch