[ksk-change] Capabilities of validating systems we need to consider
Greetings again. In thinking about the question of "what would happen if we changed the KSK", but without thinking about why and when, it would be good to think about what kinds of systems are out there. My initial list came to three categories of capabilities: 1) Able to automatically pull and correctly use a new KSK 2) Cannot automatically pull a new KSK, or cannot correctly use an automatically-pulled KSK; however, it can correctly get and use a new KSK with operator intervention 3) Even with operator intervention, cannot pull a new KSK or cannot correctly use an manually-pulled KSK Are there other categories that would look operationally different to either customers of the system or to operators of signed zones? We will certainly later debate how many systems are in these categories and if those systems are "important", but it would be good to start with the smallest complete set to talk about. --Paul Hoffman
Hi Paul, Veering off at a slight tangent for the purpose of agenda-building: On 21 Sep 2014, at 11:27, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
Greetings again. In thinking about the question of "what would happen if we changed the KSK", but without thinking about why and when, it would be good to think about what kinds of systems are out there. My initial list came to three categories of capabilities:
1) Able to automatically pull and correctly use a new KSK
1.3) Able to retrieve a new KSK public key in-band through the DNS and verify its authenticity using an existing trust anchor and DNSSEC (e.g. RFC 5011) 1.6) Able to retrieve a new KSK public key out-of-band through other methods and verify its authenticity before using it (e.g. using draft-jabley-dnsop-validator-bootstrap 1.6.5) is the approach in draft-jabley-dnsop-validator-bootstrap a reasonable one? 1.6.7) do we need to consider other approaches to trust anchor publication by IANA?
2) Cannot automatically pull a new KSK, or cannot correctly use an automatically-pulled KSK; however, it can correctly get and use a new KSK with operator intervention
3) Even with operator intervention, cannot pull a new KSK or cannot correctly use an manually-pulled KSK
Are there other categories that would look operationally different to either customers of the system or to operators of signed zones?
We will certainly later debate how many systems are in these categories and if those systems are "important", but it would be good to start with the smallest complete set to talk about.
Joe
Veering off at a slight tangent for the purpose of agenda-building:
Fully agree with that idea, as well as triaging the other two categories as well. However, I want to be sure that those three are all the ones that we can think of that look different to the outside world. --Paul Hoffman
On 9/21/2014 11:37 AM, Joe Abley wrote:
Hi Paul,
Veering off at a slight tangent for the purpose of agenda-building:
On 21 Sep 2014, at 11:27, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
Greetings again. In thinking about the question of "what would happen if we changed the KSK", but without thinking about why and when, it would be good to think about what kinds of systems are out there. My initial list came to three categories of capabilities:
1) Able to automatically pull and correctly use a new KSK 1.3) Able to retrieve a new KSK public key in-band through the DNS and verify its authenticity using an existing trust anchor and DNSSEC (e.g. RFC 5011)
1.6) Able to retrieve a new KSK public key out-of-band through other methods and verify its authenticity before using it (e.g. using draft-jabley-dnsop-validator-bootstrap
1.6.5) is the approach in draft-jabley-dnsop-validator-bootstrap a reasonable one?
1.6.7) do we need to consider other approaches to trust anchor publication by IANA?
TANSTAAFL - basically, you still need to know which root you trust (X.509) before you can select a DNSSEC trust anchor. Which leads to the question of how do you recover if that X.509 root is compromised? The approach is interesting, but just recurses the problem over to somewhere else without actually figuring out what the worst case compromise approach needs to be. The main saving grace for the approach is that it moves data handling issues (e.g. size of the root DNSKEY RRSet) from DNS over to something else.
2) Cannot automatically pull a new KSK, or cannot correctly use an automatically-pulled KSK; however, it can correctly get and use a new KSK with operator intervention
3) Even with operator intervention, cannot pull a new KSK or cannot correctly use an manually-pulled KSK
Are there other categories that would look operationally different to either customers of the system or to operators of signed zones?
We will certainly later debate how many systems are in these categories and if those systems are "important", but it would be good to start with the smallest complete set to talk about.
Joe _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On 9/21/2014 11:27 AM, Paul Hoffman wrote:
Greetings again. In thinking about the question of "what would happen if we changed the KSK", but without thinking about why and when, it would be good to think about what kinds of systems are out there. My initial list came to three categories of capabilities:
1) Able to automatically pull and correctly use a new KSK 5011 or something else.
2) Cannot automatically pull a new KSK, or cannot correctly use an automatically-pulled KSK; however, it can correctly get and use a new KSK with operator intervention That sounds like just pulling down a file and restarting the resolver which should be the case for pretty much any normal resolver. Maybe an issue with middle boxes like home routers, but I'm not aware of any device that does validation OOB without configuration.
3) Even with operator intervention, cannot pull a new KSK or cannot correctly use an manually-pulled KSK
Is there an actual example of such a box. I'd basically call it bricked and replace it if I had one in this category. Last category is (4) doesn't know or care about DNSSEC.
Are there other categories that would look operationally different to either customers of the system or to operators of signed zones?
We will certainly later debate how many systems are in these categories and if those systems are "important", but it would be good to start with the smallest complete set to talk about.
--Paul Hoffman _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On Sep 21, 2014, at 10:17 AM, Michael StJohns <msj@nthpermutation.com> wrote:
On 9/21/2014 11:27 AM, Paul Hoffman wrote:
Greetings again. In thinking about the question of "what would happen if we changed the KSK", but without thinking about why and when, it would be good to think about what kinds of systems are out there. My initial list came to three categories of capabilities:
1) Able to automatically pull and correctly use a new KSK 5011 or something else.
Yes, as Joe has indicated, and noting that you did not agree with Joe's proposed "something elses".
2) Cannot automatically pull a new KSK, or cannot correctly use an automatically-pulled KSK; however, it can correctly get and use a new KSK with operator intervention That sounds like just pulling down a file and restarting the resolver which should be the case for pretty much any normal resolver.
My set of three does not presume "normal resolver". I don't think this group yet knows what we consider "normal", nor how much we care about the set of abnormal resolvers.
Maybe an issue with middle boxes like home routers, but I'm not aware of any device that does validation OOB without configuration.
Me neither, but this group should not make its decisions based on what you and I are not aware of. It is worth consideration and, if at all possible, measurement.
3) Even with operator intervention, cannot pull a new KSK or cannot correctly use an manually-pulled KSK
Is there an actual example of such a box.
Yes. There are versions of some validating software whose documentation cannot be understood by all operators. (I'm purposely not naming them here.) The software works with the built-in KSK, but the operator will not be able to figure out how to get a new KSK to successfully replace the old KSK. Further, I suspect there has been insufficient testing of systems that are otherwise considered "good" and "well-documented" when you add a second or third root KSK, as compared to replacing the KSK. Is the documentation sufficient? What happens after a reboot? What happens to the added keys after a software upgrade (and yes, I understand that I just opened the can labelled "Distro Hell", but we need to deal with it). That is, are there systems in Class 1 and Class 2 that could become part of Class 3 if we add a second or third RSA key to the KSK pile? Or if we add a new EC key to the KSK pile? Or if there is an emergency rollover where we need to remove the original KSK?
I'd basically call it bricked and replace it if I had one in this category.
Sure you would; so would I. However, you and I are not the primary targets for this effort.
Last category is (4) doesn't know or care about DNSSEC.
I would not list them unless there was any way that a KSK change would be noticeable on them, and I don't see how that would be. --Paul Hoffman
On 9/21/14 8:27 AM, Paul Hoffman wrote:
Greetings again. In thinking about the question of "what would happen if we changed the KSK", but without thinking about why and when, it would be good to think about what kinds of systems are out there. My initial list came to three categories of capabilities:
1) Able to automatically pull and correctly use a new KSK
2) Cannot automatically pull a new KSK, or cannot correctly use an automatically-pulled KSK; however, it can correctly get and use a new KSK with operator intervention
3) Even with operator intervention, cannot pull a new KSK or cannot correctly use an manually-pulled KSK
Are there other categories that would look operationally different to either customers of the system or to operators of signed zones?
We will certainly later debate how many systems are in these categories and if those systems are "important", but it would be good to start with the smallest complete set to talk about.
Is it worthwhile to also consider non-DNS hardware/software that is nevertheless part of the resolution/validation chain? Off hand I'm thinking specifically of a category of network devices that can handle DNS packets related to the root at their current size, but that may have "issues" if we add a new KSK, regardless of what "kind" of new KSK it is. I'm not sure how much of an issue this will turn out to be in practice, as theoretically every such device had its capacity tuned upwards to handle the size of the current packets. But we already know that both software users and vendors have problems with DNS packets that are !UDP and/or >512 bytes. To assume that just because things work now with packets of the current size means that they will continue to work if the packets get larger does not seem safe to me. Doug
On Sep 21, 2014, at 5:27 PM, Paul Hoffman <paul.hoffman@vpnc.org<mailto:paul.hoffman@vpnc.org>> wrote: Greetings again. In thinking about the question of "what would happen if we changed the KSK", but without thinking about why and when, it would be good to think about what kinds of systems are out there. My initial list came to three categories of capabilities: 1) Able to automatically pull and correctly use a new KSK 2) Cannot automatically pull a new KSK, or cannot correctly use an automatically-pulled KSK; however, it can correctly get and use a new KSK with operator intervention 3) Even with operator intervention, cannot pull a new KSK or cannot correctly use an manually-pulled KSK Are there other categories that would look operationally different to either customers of the system or to operators of signed zones? Perhaps there are instances that do leap-off fait type of configurations but I am not aware of them. Also the systems that have a to long off-line shelf life to be able to do a RFC5011 type rollover. They would be in (1) if they’d be on during the rollover but because of their off-lineness they might find themselves in cat. (2). I argue that we ignore category (3). If we allow ourselves to be ossified by that type of mistake we will never be able to roll. In fact the argument for roll early and often is to make sure to weed out all existence of (3) and make category (2) aware that they will need to pay attention. —Olaf —————————— Olaf Kolkman Internet Society Chief Internet Technology Officer kolkman@isoc.org<mailto:kolkman@isoc.org> www.isoc.org<http://www.isoc.org>
On Sep 22, 2014, at 12:27 AM, Olaf Kolkman <kolkman@isoc.org> wrote:
On Sep 21, 2014, at 5:27 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
Greetings again. In thinking about the question of "what would happen if we changed the KSK", but without thinking about why and when, it would be good to think about what kinds of systems are out there. My initial list came to three categories of capabilities:
1) Able to automatically pull and correctly use a new KSK
2) Cannot automatically pull a new KSK, or cannot correctly use an automatically-pulled KSK; however, it can correctly get and use a new KSK with operator intervention
3) Even with operator intervention, cannot pull a new KSK or cannot correctly use an manually-pulled KSK
Are there other categories that would look operationally different to either customers of the system or to operators of signed zones?
Perhaps there are instances that do leap-off fait type of configurations but I am not aware of them.
Also the systems that have a to long off-line shelf life to be able to do a RFC5011 type rollover. They would be in (1) if they’d be on during the rollover but because of their off-lineness they might find themselves in cat. (2).
Sounds right.
I argue that we ignore category (3). If we allow ourselves to be ossified by that type of mistake we will never be able to roll. In fact the argument for roll early and often is to make sure to weed out all existence of (3) and make category (2) aware that they will need to pay attention.
I agree that we should not cater at all to the systems in category 3, but we cannot ignore that they exist. By saying that they exist and that we do not intend to cater to them, we can possibly get them into category 2. If someone says "but my system's documentation on how to add a KSK is wrong!" we can say "yep, you're in category 3". That's better for the Internet than us saying "we don't know that you exist". --Paul Hoffman
On Sep 22, 2014, at 3:16 PM, Paul Hoffman <paul.hoffman@vpnc.org<mailto:paul.hoffman@vpnc.org>> wrote: I argue that we ignore category (3). If we allow ourselves to be ossified by that type of mistake we will never be able to roll. In fact the argument for roll early and often is to make sure to weed out all existence of (3) and make category (2) aware that they will need to pay attention. I agree that we should not cater at all to the systems in category 3, but we cannot ignore that they exist. By saying that they exist and that we do not intend to cater to them, we can possibly get them into category 2. If someone says "but my system's documentation on how to add a KSK is wrong!" we can say "yep, you're in category 3". That's better for the Internet than us saying "we don't know that you exist". yes, I agree with that. — — — — — — — — — — Olaf Kolkman (on personal title)
participants (5)
-
Doug Barton -
Joe Abley -
Michael StJohns -
Olaf Kolkman -
Paul Hoffman