[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 []) 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-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (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 []) 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 []) 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 []) 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: 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.

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.

 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

 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

Implication D: Whatever we do must work with a device that has software
    several years old, and no configuration data newer than the

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.


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

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

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.


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

     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