On 2011-01-31 14:32, Joe Abley wrote: > Per below, Dave and I scribbled some thoughts down about how we might > recommend validators obtain a useful root zone trust anchor on > startup.
Wow, that's fast service. :-) > Individual trust anchors are also packaged as X.509 identity > certificates, signed by various Certificate Authorities (CAs). How firmly are you attached to your approach? Would you be prepared to consider supporting alternatives, if consensus could be gathered behind them? If so, what would be your concerns? We've heard a lot about my/our requirements. What are *your* requirements? What would an alternative bootstrap scheme have to do before you could support it? What procedural guarantees can you provide, and what guarantees can't you provide? From what I'm seeing, I kind of doubt we'll get consensus on anything else quickly enough to be useful on our timetable, so I *suspect* we're going to have to do what you suggest, at least until something better comes along, and maybe forever. For the longer term, maybe we could think about other things. Given our own constraints, under your draft we (Cisco) would need to maintain our own bootstrapping service. Specifically, we'd need to play the role of the X.509 CA signing the root KSKs in your section 5.3: > Individual trust anchors are also packaged as X.509 identity > certificates, signed by various Certificate Authorities (CAs). If we do have to roll our own as you suggest, we may want to give customers more assurance than your draft specifies, by augmenting your procedure. Specifically, we might do as you suggest, but *additionally* retrieve from Cisco a signed 5011 rollover list. The idea there would be that somebody would have to compromise *both* Cisco and at least one historical root KSK. Of course, the downside would be that any non-5011 key roll would break the devices. We'll probably have to think about that. Of course, it's even less likely that you'd want to suggest it to others than that we'd do it ourselves. Prodedural details ================== I assume you *are* saying that the http://data.iana.org/root-anchors/root-anchors.xml URL is guaranteed good for a long time? I'm not sure what procedure we're meant to use to get the validated CSRs to create the X.509 certificates for new KSKs. Can you say anything about that? I assume that the "ultimate" way to do it is to send some people to a key ceremony. To be honest, I'm not sure that I could convince management (or even myself) that that gave enough extra assurance to be worth it. I suspect what we'd end up doing, absent other guidance, would be just grabbing the CSR from wherever, and looking at the root KSK in use on our own internal systems to see if it was right... then signing it. Some comments on the draft itself: Finding CAs =========== You say: > URLs > to allow those certificates to be retrieved are included as optional > elements in the XML document. I don't actually see any CA URLs in the XML at the moment. Obviously you can't just grab a root cert from such a URL and trust it, anyway... you have to have either a wired-in copy of the cert itself, or at least a wired-in copy of its public key. So I'm not sure I see what having the URLs in the XML would do for anybody. > alternatively a vendor may instantiate its own CA and make > arrangements with the root zone KSK manager to have the corresponding > identity certificate locations published in root-anchors.xml. Our devices already have copies of our own CA's root cert for other reasons, so we'd just let them rely on that. I'd assume others would do similarly. Time ==== > 3.1 Initial State > [...] > A validator must confirm that its local clock is sufficiently > accurate before trust anchors can be established, and before > processing of DNSSEC signatures can proceed. Discussion of timing > considerations can be found in Section 4. How? I know I brought it up, but I'm getting a little nervous about using the home router as the only reference point. Nonetheless, it's a good paradigmatic case, and I'll go with it for now. You're a home router. You've just been plugged in, either new from the box or after being in a closet for a long time. Do you: 1. Rely on your local real-time clock? I'm not saying this is impossible, but: a. Much existing hardware (not just Linksys; many home routers) doesn't have RTCs. Putting one in would significantly increase the build cost of the hardware, I'm guessing by several percent. And it would reduce the reliability and shelf life. b. If you've been in a closet for a while, your RTC may have drifted enough to matter. Perhaps more likely, the battery for your RTC may have died... an event you may or may not be able to detect and usually can't report. c. The user may have set the RTC wrong before you went into that closet. This is perhaps more likely for a PC than for a router, but it could happen... and PCs are also in scope. 2. Rely on NTP? If so, then: a. How do you know which NTP sources to trust? b. How do you set up authentication with them? Public NTP is unauthenticated, and if I remember correctly it's not *possible* to authenticate NTP in a public network. The public-key stuff is used to distribute shared keys. I could be wrong; it's been a while. But that's how I remember it. Anyway, you'd need some kind of NTP trust anchor... which puts us back where we started. 3. GPS? WWVB (or non-US equivalent)? Can't receive either one where my router is, even if it had the hardware. And both are jammable. WWVB, at least, is easily falsified, as are the similar but incompatible systems in use in various places outside North America... those where such systems exists, that is. I haven't looked into GPS, but I suspect it's spoofable too. 4. Make the user enter the time? How does the user know she needs to do that? For us, another question is how we keep the user from buying the competitor's box that doesn't do DNSSEC and doesn't ask for the time. Users see all this stuff as a hassle. I was told today that even entering a PIN to get WiFi up causes a noticeable number of products to go back to the store. The state of the art in enterprise networks is *unauthenticated* NTP with internal hosts. The state of the art in consumer is unauthenticated NTP with a pool on the public Internet. This is a huge problem for us with bootstrapping all kinds of crypto protocols, actually, not just DNSSEC. There's this pervasive assumption that the time of day is not only known, but known with such certainty that it can be trusted to ensure the security of systems that are otherwise engineered to take CPU-aeons to compromise. The problem is that it's just not an assumption we know how to meet. In a lot of cases, we just end up having to assume that keys are valid from the beginning of time to the end of time. I'd very much like to not have that be true, but I don't know how to fix it. I could imagine a distributed system of digital notaries and time stampers that at least let you establish that it was "no earlier than" some particular time, and that also gave you some assurance that some set of past events had happened in a particular sequence and within particular time parameters. You could build that with mutually distrustful "authorities", and use a quorum or something to prevent any one of them from messing it up. I think that sort of thing is (part of) what Phillip Hallam-Baker is getting at. But I'm not sure we can deploy it sanely in time to be useful for this application... and I don't think you can build *anything* that lets you detect lies about the time if an attacker controls *all* your communications. Trust ===== I'm not sure I understand the phrase "trust anchor" the same way you do. > 5.1 Retrieval of Trust Anchors from Local Sources > > A trust anchor which is packaged with validator software can never be > trusted, [...] > > Validators should never use local trust anchors for bootstrapping. I think that by "trust anchor" here, you really mean "DNSSEC root KSK", because below you say: > 5.3 Retrieval of Trust Anchors from the Root Zone KSK Manager > [...] > > 3. Retrieve the corresponding X.509 identity certificates for the > key identified in the previous step, for use in establishing > trust in the retrieved trust anchor (see Section 6). > [...] > 6. Establishing Trust in Candidate Trust Anchors > > Once a candidate trust anchor has been retrieved, the validator must > establish that it is authentic before it can be used. This document > recommends that this be carried out by checking the signatures on > each of the X.509 identity certificates retrieved in the previous > step until a certificate is found which matches a CA trust anchor > > This verification phase requires that validators ship with a useful > set of CA trust anchors, and that corresponding identity certificates > are published by the root zone KSK manager. Either way, it's a local trust anchor... and I don't see why X.509 keys are any less compromisable than DNS keys... -- jbash
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop