[dnsext] Historical root keys: The Large Router Vendor Speaks
John Bashinski <jbash@cisco.com> Thu, 27 January 2011 20:19 UTC
Return-Path: <jbash@cisco.com>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 205933A6A4A for <dnsext@core3.amsl.com>; Thu, 27 Jan 2011 12:19:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VksL9mYXQlUY for <dnsext@core3.amsl.com>; Thu, 27 Jan 2011 12:19:02 -0800 (PST)
Received: from vps1.velvet.com (vps1.velvet.com [66.249.7.50]) by core3.amsl.com (Postfix) with ESMTP id 4E0AB3A6A16 for <dnsext@ietf.org>; Thu, 27 Jan 2011 12:19:02 -0800 (PST)
Received: from candyfloss.jbash.velvet.com (206-248-144-221.dsl.teksavvy.com [206.248.144.221]) by vps1.velvet.com (Postfix) with ESMTPSA id 893231A52D4 for <dnsext@ietf.org>; Thu, 27 Jan 2011 15:22:03 -0500 (EST)
Received: from candyfloss.jbash.velvet.com (candyfloss.jbash.velvet.com [127.0.0.1]) by candyfloss.jbash.velvet.com (Postfix) with ESMTP id 675853061; Thu, 27 Jan 2011 15:22:02 -0500 (EST)
Message-ID: <4D41D3E2.6060107@cisco.com>
Date: Thu, 27 Jan 2011 15:21:54 -0500
From: John Bashinski <jbash@cisco.com>
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7
MIME-Version: 1.0
To: dnsext@ietf.org
X-Enigmail-Version: 1.1.2
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enigC8C727F6F6685A16808A8232"
Subject: [dnsext] Historical root keys: The Large Router Vendor Speaks
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jan 2011 21:04:59 -0000
Well, this has generated some interesting messages, and apparently some people think that the "large router vendor" in question should speak for itself. Of course, since this is the IETF, I don't actually represent the "large router vendor". We're all individuals here. I am, however, the person who's writing the internal standards in question for the "large router vendor", and I guess I've just authorized myself to disclose what the "large router vendor" is thinking about doing, so that maybe some of the constraints are a little more clear. Context ======= Presently under discussion (not finalized, with no commitment to do anything at all, subject to change or complete abandonment at any time even if we do adopt the plan, and undoubtedly to suffer exceptions in implementation if we execute on it): 1. Essentially every Cisco product will do DNSSEC validation, with RFC 5011 trust root rollover. I don't mean just routers, and definitely not not just professionally administered routers. That $50 Linksys home router/WiFi AP you buy down at Fry's will do DNSSEC when you plug it in. So will that Umi telepresence unit. So will the WebEx client, for that matter. And the network management software, and the management processor in your blade server, and whatever else you can think of. The present direction is to apply this to any and every Cisco product that uses DNS and has access to the necessary computing resources. Implication A: We can't assume very much about what resources a product has. We know it will have DNS and the necessary code and compute power to do DNSSEC validation. Most, but not all, products will have X.509 and TLS code, and the ability to retrieve stuff over HTTP. Beyond that, we don't know. If we force ourselves to put lots of code or hardware in products just for DNSSEC, we will price ourselves out of some markets... or, more realistically, our internal product teams will rightfully rebel and refuse to include validation at all. 2. Validation will be done *locally* in the vast majority of cases. We're not just talking about looking at the AD bit. 3. Validation will be done by default upon installation. If you don't want it, you'll be able to turn it off, but it's going to happen if you don't actively disable it. 4. This would be phased in, with the final phase at somewhere around the beginning of 2013. Realities ========= 5. Some of the people installing these products (frankly including some of the professional network gear) will have no clue what DNSSEC is or what cryptography is. 6. In the case of the consumer gear, the cost to us of helping the customer deal with any DNSSEC failure will be greater than the entire profit we make on the device. 7. Even for professional gear, customers don't want to pay their staff to mess with this, and we don't want to pay our staff to support them. 8. Lots of our products get drop-shipped to people's field offices, get plugged in by a wire-plugger-inner who basically just checks that the lights are on and goes on to the next task, and then have to fend for themselves, at least enough to be able to talk to the NOC and await further instructions. Implication B: As much as it possibly can, anything we do must work without human intervention, and especially without very skilled intervention. We know there will be problems, but we MUST minimize them and minimize the amount of "touch" required to fix them. Implication C: Social engineering is almost always a bigger risk than cryptographic failure, especially at the device end of the communication chain. 9. Devices of all kinds will get their configurations wiped now and then. They will get resold (at which point they SHOULD have their configurations wiped). They will get bought, left on a shelf for 2 or 3 years, and then installed. 10. We can't rely on any customer, let alone consumer products customers, to keep software up to date. I don't happen to like that, but it is a fact. In any case, it may sometimes be a pain to update the software in your device before you have the DNS working. Implication D: Whatever we do must work with a device that has software several years old, and no configuration data newer than the software. Implication E: We *will* be forced to rely on old trust roots, whether they be DNSSEC trust roots, public X.509 trust roots, or trust roots in some system we create for ourselves. Some devices just plain won't have newer information, and just plain won't have admins who can give them newer information, and that puts an absolute lower bound on some cryptoperiod. It's either trust old keys, or have no validation whatsoever. 11. Devices will get installed in corporate and government networks, behind all kinds of unpredictable firewalls administered by people who may not be very happy about opening any holes. Implication F: We have to minimize the number of things we assume to be reachable. Ideally, we'd like to keep it to just the DNS; we're already forced to assume the DNS is available, so that introduces no extra ways to fail. If we have to accept it, a well-known HTTP service or something might be OK, especially if it's something the customer can replicate internally. Weird proprietary protocols are a lot harder to sell to those firewall admins. 12. For most devices, there's a very significant logistical cost to us whenever we change the software... even if the change is just an embedded root key. In the same way, there's a logistical cost (and a new security exposure) if we change the manufacturing process to embed a key separately from the system software. Since our products have diverse manufacturing processes, we bear that cost separately for each product line. Principles ========== 13. We prefer to minimize trust in Cisco. Yes, obviously anybody using a Cisco product is trusting Cisco to deliver software that does what it says it does, and that's an enormous amount of trust. Nonetheless, we try to keep further trust to a minimum. If nothing else, that makes it easier for us to manage things internally, and to contain the effects of any internal failures. 14. We also try to reduce the temporal extent of trust; when possible, we avoid assuming that your trusting us when you install a box at time T implies you should have to trust us at every moment in time after T. For example, we usually require user approval for software updates. 15. We prefer to minimize the spread of trust to different entities. We're already trusting the process that maintains the DNS root, and we're already extending that trust over a long time without any real way to respond if it turns out to be unjustified. That is an unavoidable risk. We would prefer not to take on any avoidable risk. Implication G: We would like to avoid cryptographic trust in anything but DNSSEC root keys. Yes, we could use our PKI for this, but we'd prefer not to if we can easily avoid it. Further realities ================= 16. The public X.509 PKI (actually a loose confederation of rival PKIs, each of which everything is expected to trust) is completely broken. There's no sign that it will ever be fixed, we definitely can't wait around for it to get fixed, and making our DNSSEC dependent on it would greatly compromise the solution security, complicate the implementation, enlarge the attack surface beyond all sanity, *and* make the whole trust root maintenance problem worse (because we'd now have to maintain many, many roots). Implication H: "Fetch the key from IANA over HTTPS" won't do it. 17. As far as I can see, any other vendor who tried to do this would run into exactly the same problems. Implication I: It seems as though it makes sense to have a shared solution. Approaches ========== At the moment, the following are under consideration: I. Get IANA and the root zone to provide some kind of service for getting up to date starting from old trust roots. This is our preferred answer, because-- a. Every vendor could use it.. b. Every professional network admin would eventually be familiar with it c. Every firewall would probably eventually let it through. d. It would get a lot of scrutiny, and that would make it more trustworthy. e. We wouldn't have to commit to running a well-known service for ages and ages. To be honest, it's not that easy to get a big corporation to buy into something like that in a way that makes you feel as confident as I'd like to be in this. f. It could outlast any vendor. I do not have the authority to even *suggest* committing any Cisco funds to supporting this, but I could ask. Perhaps others on this list could think about asking their employers as well. It's always easier to get money if the boss feels the need to keep up with the Joneses... II. Provide our own key update service. This might be DNS-based or HTTP-based. It would provide either: a. The entire historical chain of DNS root KSKs, with older keys signing newer ones, so that the device could pick up from whatever key it had, OR b. Just the current root key, signed with a key validated by Cisco's private X.509 PKI (the same PKI we use to sign software), OR c. The chain of (a) further signed with a key from (b). We are obviously capable of this. We also obviously think it's inferior to (I). III. Try to ship devices with up-to-date keys, and rely on admins to update them when that fails. I think this would blow up on us, and I got some indignant pushback for even suggesting it. IV. Weaken the scheme in one of the following ways: a. Just query for the key record for the root zone at installation time, and believe whatever comes back. At least you're only exposed at one time instead of forever afterwards. b. Try a wired-in key, then fall back to (a) if it doesn't work. Which isn't every different from (a). Using the current public X.509 PKI is NOT under consideration. -- jbash
- Re: [dnsext] Historical root keys: The Large Rout… Phillip Hallam-Baker
- [dnsext] Historical root keys: The Large Router V… John Bashinski
- Re: [dnsext] Historical root keys: The Large Rout… Joe Abley
- Re: [dnsext] Historical root keys: The Large Rout… David Conrad
- Re: [dnsext] Historical root keys: The Large Rout… Brian Dickson
- Re: [dnsext] Historical root keys: The Large Rout… Jakob Schlyter
- Re: [dnsext] Historical root keys: The Large Rout… Florian Weimer
- Re: [dnsext] Historical root keys: The Large Rout… George Barwood
- Re: [dnsext] Historical root keys: The Large Rout… Alex Bligh
- Re: [dnsext] Historical root keys: The Large Rout… John Bashinski
- Re: [dnsext] Historical root keys: The Large Rout… Andrew Sullivan
- Re: [dnsext] Historical root keys: The Large Rout… Joe Abley
- Re: [dnsext] Historical root keys: The Large Rout… John Bashinski
- Re: [dnsext] Historical root keys: The Large Rout… Paul Hoffman
- Re: [dnsext] Historical root keys: The Large Rout… Nicholas Weaver
- Re: [dnsext] Historical root keys: The Large Rout… John Bashinski
- Re: [dnsext] Historical root keys: The Large Rout… Ted Lemon
- Re: [dnsext] Historical root keys: The Large Rout… Alex Bligh
- Re: [dnsext] Historical root keys: The Large Rout… John Bashinski
- Re: [dnsext] Historical root keys: The Large Rout… John Bashinski
- [dnsext] A question about the need for "historica… Edward Lewis
- Re: [dnsext] Historical root keys: The Large Rout… Paul Hoffman
- Re: [dnsext] Historical root keys: The Large Rout… Ted Lemon
- Re: [dnsext] A question about the need for "histo… John Bashinski
- Re: [dnsext] A question about the need for "histo… Ted Lemon
- Re: [dnsext] Historical root keys: The Large Rout… John Bashinski
- Re: [dnsext] A question about the need for "histo… Paul Wouters
- Re: [dnsext] Historical root keys: The Large Rout… Ted Lemon
- Re: [dnsext] Historical root keys: The Large Rout… John Bashinski
- Re: [dnsext] Historical root keys: The Large Rout… Paul Wouters
- Re: [dnsext] Historical root keys: The Large Rout… Thierry Moreau
- Re: [dnsext] Historical root keys: The Large Rout… John Bashinski
- Re: [dnsext] Historical root keys: The Large Rout… Phillip Hallam-Baker
- Re: [dnsext] Historical root keys: The Large Rout… Paul Wouters
- Re: [dnsext] Historical root keys: The Large Rout… Thierry Moreau
- Re: [dnsext] Historical root keys: The Large Rout… Paul Wouters
- Re: [dnsext] Historical root keys: The Large Rout… Phillip Hallam-Baker
- Re: [dnsext] Historical root keys: The Large Rout… Tony Finch
- Re: [dnsext] Historical root keys: The Large Rout… Chris Thompson
- Re: [dnsext] Historical root keys: The Large Rout… George Barwood
- Re: [dnsext] Historical root keys: The Large Rout… Tony Finch
- Re: [dnsext] Historical root keys: The Large Rout… Phillip Hallam-Baker
- Re: [dnsext] Historical root keys: The Large Rout… Olafur Gudmundsson