Subject: [dnsext] Historical root keys: The Large Router Vendor Speaks

From: John Bashinski <[email-masked]>
Date: Thu, 27 Jan 2011 15:21:54 -0500

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

---

From: Joe Abley <[email-masked]>
Date: Thu, 27 Jan 2011 16:55:25 -0500

Hi John,

>     keep up with the Joneses...

Right now we publish trust anchors for the root zone as:

1. an XML file, which is signed separately using S/MIME and PGP. This file contains the current public key and also includes details of all previous public keys, annotated XMLishly to indicate over what periods of time they were intended to be used.

2. an X.509 certificate. One of the products of a key ceremony is an X.509 CSR, which we sign using an ICANN-maanged CA to produce the certificate.

It was our ambition with (2) to publish multiple certificates for each anchor, each one representing the same CSR signed by a different certificate authority. This would allow a software vendor who already runs a CA (e.g. for the purpose of signing software updates) to bootstrap trust in a published KSK public key using their own key, but it might also be useful with well-known and -used commercial CAs, too.

A client might then have a bootstrapping mechanism of

  - retrieve <http://data.iana.org/root-anchors/root-anchors.xml>;
  - retrieve the set of CRTs associated with the current KSK (as identified in the XML file, currently just <http://data.iana.org/root-anchors/Kjqmt7v.crt>, but potentially <http://data.iana.org/root-anchors/Kjqmt7v.crt.cisco>);

(both the above accomplished without using DNSSEC validation, or SSL, although those URLs are provided with HTTPS too)

  - use a local X.509 trust anchor (e.g. for a vendor CA, or the regular browser list of SysTrust-accredited commercial CAs, or something else) to verify that the trust anchor retrieved is correct and proper.

Don't interpret any of that as reluctance to discuss doing anything new at IANA to make this easier; I just want to make sure the existing mechanisms can't be made to work in a sensible way first.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 28 Jan 2011 00:34:20 -0500

On Thu, Jan 27, 2011 at 3:21 PM, John Bashinski <[email-masked]> wrote:

> Just to be clear, it was never proposed, except as a straw man by Paul
Wouters.

What I suggested was that we look at the possibilities of using X.509
standards and infrastructure that has been developed to meet similar
considerations in that space. I think it is abundantly clear that we do not
want the criteria for signing the root KSK to be  inclusion in some browser
root anchor list.

X.509 is designed to deal with persistent keys, DNS is not designed to
persist data.

I think that we should detach this problem from DNSSEC because we are going
to face the same problem for device keys. We have over the years created
quite a few consortiums that sign various CA certs for device keys and we
are in the process of creating more.

Ultimately these devices are going to have to tie into enterprise networks
and recognize the root of trust for the enterprise regardless of whether
their function requires them to also process DNSSEC or not.

So I would look to develop a scheme that addresses the problem of managing
the enterprise trust root first and then consider the IANA root key as being
a special case that would reuse the same code and management principles.

-- 
Website: http://hallambaker.com/

---

From: David Conrad <[email-masked]>
Date: Thu, 27 Jan 2011 22:06:13 -0800

John,

Very useful note, thanks!

On Jan 27, 2011, at 12:21 PM, John Bashinski wrote:
>    getting up to date starting from old trust roots.

If you only want to use DNS/DNSSEC, the implication of this is that the old trust roots would need to be forever (or at least the longest lifetime of all products) secure.  This would also sort of defeat the purpose of scheduled key rolls and would fail in the face of a key roll caused by known or suspected key compromise (you won't want to chain up through a known-compromised key).

> II. Provide our own key update service.

How would this be (conceptually) different than providing a (secure) software update service?

(Somewhat as an aside, in a world in which you can't trust admins, I'd argue that (by default) requiring user approval to install updates is demonstrably more risky to the Internet at large than otherwise.)

>    I got some indignant pushback for even suggesting it.

I'd agree relying on admins is unlikely to work.

> 	work. Which isn't every different from (a).

This doesn't seem that much different from III.  You'd have to rely on the admin to do something (in this case, ensure the initial connection used to fetch the root key is safe).

> Using the current public X.509 PKI is NOT under consideration.

Understandable.  However, this doesn't necessarily preclude the use of a private (not necessarily X.509, e.g., PGP/GPG) PKI.

Fundamentally, I don't see how this can be solved securely via DNS/DNSSEC. 

Regards,
-drc

---

From: Brian Dickson <[email-masked]>
Date: Fri, 28 Jan 2011 02:37:32 -0400

Thanks for the update, John.

Clarification and open question follows:

> Approaches

What if, rather than starting from "old trust roots", it was starting
from "privately-signed trust anchors"?

I.e. have IANA have private keys which are used ONLY for this service.
The vendors would include the public keys as trust anchors for
boot-strapping purposes. The key transfer might happen offline, or at
least out-of-band.

The same data could be signed with multiple such unpublished keys, as
needed (e.g. one per vendor, per year, use a new key every year, but
keep signing with all keys) and/or funded. Vendors might agree to pool
resources/keys, or not.

In the event of a key compromise of one of these keys, the presumed
impact would be finite, small, localized (to a vendor-pool + year
tuple), and decreasing over time (if a given public key is used only
for one-time bootstrap purposes).

And, most importantly, it would be off-axis from the root-key
chaining. The rolling of root keys (for whatever reason, especially
for compromise) would be orthogonal to this mechanism.

And now, consider the possibility when the public keys are never
actually published in this or any other zone....
The "public key" would be the trust anchor, used to validate the RRSIG directly.

Open question:
Does not publishing the key make it harder to compromise the key?

(Of course, the key needs to be distributed in the software and/or
configuration files, so it's just "less well known", I suppose...)

Brian

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 28 Jan 2011 08:55:50 +0100

> boot-strapping purposes. The key transfer might happen offline, or at

We designed the detached signature [1] over the XML file [2] to work almost like that, although the ICANN Root CA is used for other things as well.

> keep signing with all keys) and/or funded. Vendors might agree to pool

Anyone can grab the latest root key CSR [3], sign it and produce a their "own" DNSSEC root key certificate and distribute with their software.

> for compromise) would be orthogonal to this mechanism.

IMHO, any key signing the root key should protected with the same controls as the root key itself. Given how the root key itself is protected, I doubt that very few organizations can match that level of protection (although I know I'm biased when it comes to root key protection).

> Does not publishing the key make it harder to compromise the key?

No.

	jakob

[1] http://data.iana.org/root-anchors/root-anchors.p7s
[2] http://data.iana.org/root-anchors/root-anchors.xml
[3] http://data.iana.org/root-anchors/Kjqmt7v.csr

-- 
Jakob Schlyter
Kirei AB - www.kirei.se

---

From: Florian Weimer <[email-masked]>
Date: Fri, 28 Jan 2011 08:37:51 +0000

> doing, so that maybe some of the constraints are a little more clear.

Would it help you if there weren't any vanity key rollovers at all?

Then the remaining cases are, as far as I can see:

  (i) key is lost

  (ii) key is compromised

  (iii) cryptographic algorithms are compromised

  (iv) control of the root zone changes

In cases (i), (iv), you cannot expect that the new key material will
be signed by the old.

In case (ii), you cannot rely on the signature from the old key
material.

In case (iii), you'll likely need a firmware update to implement new
algorithms, and you can ship new key material with that.

What am I missing?

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: "George Barwood" <[email-masked]>
Date: Fri, 28 Jan 2011 09:49:54 -0000

----- Original Message ----- 
From: "Florian Weimer" <[email-masked]>

> Would it help you if there weren't any vanity key rollovers at all?

I think it's necessary to roll the key eventually because DNSSEC signature dates wrap,
(and signatures can therefore be replayed) but only after 136 years.

My feeling is that the roll process should be very slow.

e.g. the DS record for a new key is published say 60 years in advance,
with a new key being generated say every 20 years.

That allows a long (60 year) life for equipment that has a DS record for the root embedded.

George

---

From: Alex Bligh <[email-masked]>
Date: Fri, 28 Jan 2011 11:02:29 +0000

>      HTTP-based. It would provide either:
...
>      We are obviously capable of this. We also obviously think it's

I wonder if we're not overcomplicating this, or more accurately
looking at this as a problem unique to DNSSEC.

With plain old DNS, or DNSSEC, or SSL cert validation, or whatever,
there is a set of bootstrap data that need to be distributed with
any image. Under certain circumstances (all root servers move IP
address, lots of key rollover whilst disconnected from the internet,
new CAs, whatever), that data can become out of date in a manner
where the protocols themselves can't make things right.

There's also a pile of other bootstrap stuff distributed with
Large Router Vendor (for any value of LRV) devices, which is the
firmware it's designed to run on.

One presumes LRV's devices have at least some permanent storage
in even if their firmware is non-upgradable, else this problem
is near insoluble.

So, how about
 1. When 'things go wrong', 'periodically', or 'on UI interaction'
    (obviously the latter to be avoided), device makes a simple
    http request to a known URL at LRV.
 2. Device downloads new bootstrap data. At this stage, it could
    be bogus. No need to use anything more fancy than http.
 3. Device verifies it is genuine, e.g. by checking it is signed
    with a private key (held securely by the LRV), the public key-pair
    being in the firmware. If it is, genuine, it replaces the
    current bootstrap data.

DoS attacks, etc. could prevent this upgrade from happening, but
that would have to be for an entire key rollover period.

-- 
Alex Bligh

---

From: John Bashinski <[email-masked]>
Date: Fri, 28 Jan 2011 11:21:39 -0500

OK, now that I'm back on the Net, I'll respond to a few things:

Joe Abley wrote:

> 1. an XML file, which is signed separately using S/MIME and PGP. This
>    file contains the current public key and also includes details of all
>    previous public keys, annotated XMLishly to indicate over what periods
>    of time they were intended to be used.

Is there some particular S/MIME or PGP key that's guaranteed to be used
to sign every update in the future, and is that key reasonably well
controlled (it doesn't have to be perfect)?

> 2. an X.509 certificate. One of the products of a key ceremony is an
>    X.509 CSR, which we sign using an ICANN-maanged CA to produce the
>    certificate.

Same question... if I wake up several years from now, is the
root key for that CA going to be the same, or am I going to be
able to trace a path from the key I have to the current key?

The overriding requirement is that a device be able to choose its trust
anchor with no human intervention, based on information that may be
several years old.

We could work with that if we had a guarantee that:

o The ICANN CA was going to be around for the useful life of our products
o It wasn't going to change its root key unless there was some reason
  good enough to merit knocking hundreds of thousands of devices out
  of DNS.
o The current X.509 cert would always be available in some well-known place

Especially if that well-known place were in the DNS itself, actually, so
that we didn't have to rely on being able to get an HTTP request out of
who-knows-where in who-knows-what network. But HTTP could be OK, too.

I'd have to know more about how ICANN was managing the CA. I assume its
key isn't as well controlled as the DNSSEC root key itself, which could
be a bit of a problem. We need to have as much confidence in the root as
reasonably possible under the circumstances... and we need to be able to
give our customers a good reason for every risk we expose them to and
for every entity we make their equipment trust.

On the other hand, whatever we end up doing doesn't have to be the
absolute highest assurance way of learning the current valid root
key. I'm only talking about default behavior here. If an administrator
wants to manually configure the trust anchor (which will always be
possible even on consumer devices), then the administrator can get
additional assurance out of band, up to and including attending key
ceremonies. There are obvious limits on how certain you can ever
be with a years-old trust anchor.

>    It was our ambition with (2) to publish multiple certificates for each
>    anchor, each one representing the same CSR signed by a different
>    certificate authority. This would allow a software vendor who already
>    runs a CA (e.g. for the purpose of signing software updates) to
>    bootstrap trust in a published KSK public key using their own key, but
>    it might also be useful with well-known and -used commercial CAs, too.

We probably would NOT use our own CA to sign the CSR. Too much
complexity, too many chances for error or compromise, too much extension
of trust, requires an extra communication channel we'd prefer not to
have to assume was available, too expensive, and perhaps too much
liability assumed by us.

> [first part of suggested bootstrap procedure snipped for brevity]
>   - use a local X.509 trust anchor (e.g. for a vendor CA, or the
>   regular browser list of SysTrust-accredited commercial CAs, or
>   something else) to verify that the trust anchor retrieved is correct
>   and proper.

I don't think that's unreasonable. I'd prefer to retrieve the cert from
DNS rather than over HTTP, but that's not an absolute requirement. I do
think that trust anchor ought to be "something else", and that that
"something else" ought to be something well defined that everybody can
use and rely on.

Using a browser CA list is absolutely, unequivocally not acceptable.

Using a vendor CA is possible, but it seems to me it costs work and
money and complicates things and doesn't improve security... kind of a
bad combination.

Again, this ICANN CA of which you speak is intriguing, depending on how
it's managed.

I think the real weakness in DNSSEC is at the registration side.
Perhaps one way to look at this is that, so as long as we had enough
assurance on the key signing side to give the registration process some
headroom to improve into in the future, we'd have reasonably balanced
system exposures.

> Just to be clear, it was never proposed, except as a straw man by Paul

Point taken.

> considerations in that space. I think it is abundantly clear that we
> do not want the criteria for signing the root KSK to be inclusion in
> some browser root anchor list.
>

From my point of view, how you encapsulate the keys and represent the
signatures, DNS or X.509 or PGP or whatever, is an issue of
implementation convenience. Using DNS is appealing because it introduces
minimal extra code and relies on no extra communication paths, but it's
not required. I'm more interested in how the systems are actually
being administered and how the key are actually being handled.

I'm not familiar with the infrastructure you're talking about, or with
what about X.509's design makes it particularly superior for this
application. I don't see a big security difference among the formats, at
least if you avoid actually trying to use all the baroque X.500 stuff
that's buried under X.509 (that would surely trigger software bugs).

But I'm prepared to learn. Both you and David Conrad seem to think
there's a difference.

X.509 (PKIX-ized variant, with all the schema stuff torn out) as a
*technology* doesn't cause a lot of heartburn for us, because most Cisco
products already include it. It's not as appealing as *only* having to
include DNSSEC code, but it's not going to make product teams come after
me with pitchforks. The CA and trust management *practices* I've seen
associated with X.509 scare me, but I have no objection to adopting a
version of X.509 that doesn't bring those practices along with it.

One thing to remember that may bear on this, by the way: a lot of
these products won't have any security-quality assurance that they
know the date or time even *after* they come up, let alone when
they're first trying to get DNS working.

> I think that we should detach this problem from DNSSEC because we are
> going to face the same problem for device keys. We have over the years
> created quite a few consortiums that sign various CA certs for device
> keys and we are in the process of creating more.
>
> Ultimately these devices are going to have to tie into enterprise
> networks and recognize the root of trust for the enterprise regardless
> of whether their function requires them to also process DNSSEC or not.

I tend to think the opposite. I'd rather solve DNSSEC without making it
depend on much of anything else. The whole can of worms you're talking
about is turning into one of my daily obsessions... but it's a lot
harder to solve.

For one thing, in that context, I don't have the luxury of assuming that
there's an identifiable "enterprise" which deserves absolute trust...
not for every device, and sometimes not even for different parts of a
single device. I don't even get to assume taht there's a well-defined
name space. On the other hand, in the overwhelming majority of cases,
there really is a single trust root and a single agreed-upon name space
for the DNS, at least for the moment. And there's a really simple
well-defined delegation architecture.

Florian Weimer wrote:

> [analysis of cases]

If IANA/ICANN were to explicitly adopt a "no rollovers except for
compromise" policy, it would ease matters for us, but I don't think
we're in a position to ask for a fundamental change in the DNS key
management design, nor have I or anybody I know of really thought about
the implications of such a thing.

I'm not sure compromise is quite as black and white as you've presented
it, though. In a limited compromise, we might still get more assurance
from relying on the old key for a rollover than from relying on
*nothing* for a rollover. At the very least, a revocation of the old key
would put the device on notice that something was up. So that might
mean that we still needed to include rollover code in our products,
even if we didn't expect to use it. How well that code would work after
a decade or two of non-use, I can't really say...

Thierry Moreau wrote:

> Just do IV.b. [trust a query for an unvalidated key] as the default,
> and provide II.b. [use a new Cisco-signed root key] as an operator
> command for those customers who have IT security auditors.
>[...]

> Otherwise, you rely on some other long term signature key (public data
> integrity crypto material) and nobody wants to follow that route
> explicitly (IANA might follow that route merely be postponing root KSK
> rollover).

I do.

I've heard others here who seem to be willing to do it.

I think I can reasonably expect to get Cisco to do it.

In fact, (II)(b) also relies on a long-term key, just one held by Cisco
rather than one held by somebody else.

As far as I can tell, there are exactly three choices for default,
no-touch behavior:

1. Rely on a long-term key of some kind
2. Grab a totally unauthenticated root key and trust it.
3. Don't do DNSSEC at all.

Without human intervention, that's all that's available. Refusing to
use a long-term key because it might get compromised doesn't improve
security. It reduces security, because the only alternative is to use
a totally unvalidated trust anchor.

In practice, most admins probably do something very much like

   "dig -t dnskey . > trusted-key.dat"

but that's their choice and there's not much we can do about it. And, to
be honest, they'll do that because they don't necessarily have many
really better options than the software itself has. What I did for the
trust anchor in my own resolver wasn't too much better than that,
because I had no way to rely on the available PGP keys.

So, yes, a long-term key seems to be all that's possible. It's not
actually exactly *a* long-term key for every device, but whatever key is
wired into an individual device when it ships, or has its software
upgraded, is clearly trusted by that device until somebody configures it
otherwise or flashes new software on it. I think David Conrad
mischaracterizes it a bit with "old trust roots would need to be
forever"... they'd only need to be forever for devices that had nothing
newer to rely on.

> Neither the crypto nor protocol considerations have
> prevented this from occurring already. Something about liability, I
> guess. Liability is why the PKI operated by Cisco is "private," isn't
> it?

Er, no. In fact, IANAL, but it probably increases our liability slightly
to run that PKI ourselves. We do it because it improves security by not
spreading trust to entities that don't need to be trusted. On the
other hand, using it for DNSSEC seems as though it *would* spread
trust unnecessarily... and cost us money in the process.

> from "privately-signed trust anchors"?

Well, whoever signs it and however it's represented, that key is going
to be old. If the device software is 3 years old and the device has no
configuration, that key is, in my mind, an "old trust root".

> boot-strapping purposes. The key transfer might happen offline, or at

I imagine we could live with that. Smaller vendors might find it
onerous. I think that the administrative complexity of having per-vendor
or per-vendor-pool keys would probably actually lead to more exposures
than just having one big key, though. And I don't think we want to have
to decide which ones of our staff we're going to make into targets by
sending them to a key ceremony somewhere...

> Does not publishing the key make it harder to compromise the key?

If it does, I think we're all in deep doo-doo, because practically every
security system dreamed up in the last 20 years relies on the assumption
that public-key cryptography can be trusted. Usually in many places.

>    being in the firmware. If it is, genuine, it replaces the

The trick with schemes like that is that it tends to be really
hard to get them to interact cleanly with other security requirements.
We want the user to be able to restore the product to a known state.
The more exceptions and different sources of trust are in the device,
the harder that is to analyze, and we have to analyze it anew for
each class of products.

So it's not a non-starter, but it's probably not simple for us, either.

				   -- jbash

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 28 Jan 2011 11:36:56 -0500

No hat.

On Fri, Jan 28, 2011 at 11:21:39AM -0500, John Bashinski wrote:
> to sign every update in the future

> anchor with no human intervention, based on information that may be

That amounts to a requirement that someone guarantee a key is not
compromised.  Nobody can promise that.  This is why I am sceptical of
claims that some mechanism other than DNSSEC keys is the right way to
do this.  I don't see why it's more harmful to say, "Replay the 5011
rollovers as they happened through history," with the possible
exposure that one of those was compromised (the compromise being the
reason for the rollover, than it is to say, "Trust this key forever."
I see no reason to suppose one of those keys more likely to be
corrupted than the other, in the case where one is doing regular key
rolls.

If one is _not_ doing regular key rolls, then things are different.
In that case, of course the presence of a mismatch is either an attack
or a roll because of compromise.  But at that point, it seems to me,
one does not want anything automatic.  One wants analysis of the
situation, no?  (Why was the key compromised?  What evidence is there
that only that key was compromised?  &c.)

> they're first trying to get DNS working.

They're going to have a hard time with DNSSEC signatures if they don't
have accurate time.

> *nothing* for a rollover.

I don't want to put words in Wouter's mouth, but I believe this to be
one of the underlying assumptions of the trust-history draft.  Indeed,
it seems to me that if you have a real compromise, you can just not
publish that event in the trust history.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Joe Abley <[email-masked]>
Date: Fri, 28 Jan 2011 11:39:56 -0500

Hi John,

> controlled (it doesn't have to be perfect)?

The PGP key we're using is published on next to the trust anchors next on data.iana.org, as is a trust anchor for the IANA CA key we used to produce the CRT and generate the S/MIME signature. We don't currently publish practice statements for either key, and have made no assurances about how stable they will be (i.e. when anybody might expect them to roll).

I appreciate that this is not a good answer for you. We are listening, however, and the feedback you've provided in just a couple of e-mails is very useful.

> o The current X.509 cert would always be available in some well-known place

We are not yet ready to publish a Certificate Policy and Practice Statement for the IANA CA, principally due to (staff) resource constraints within the group at ICANN that is working on this stuff, but we expect to publish one at some point. That document will describe the details you're looking for.

Joe

---

From: John Bashinski <[email-masked]>
Date: Fri, 28 Jan 2011 11:49:57 -0500

On 2011-01-28 11:36, Andrew Sullivan wrote:
> compromised.

Actually, what it is is an *acceptance of the risk* that the key
will be compromised. Because that's the smallest available
risk to accept.

The alternative isn't to have better assurance. The alternative
is to have no assurance at all.

Obviously, if we're going to go down this road, we want to minimize the
risk that we accept, but we can't pretend it's not going to be zero.

>  Nobody can promise that.  This is why I am sceptical of

I'm happy with replaying 5011. I'm also happy with having some key
that will sign every new root, provided it's reasonably well controlled.

> that only that key was compromised?  &c.)

Well, yes... although it's kind of hard to ask Aunt Minnie to evaluate
that stuff. For some products, we're just going to have to hope that
there's never a compromise, because if there is we're going to take
a deluge of support calls.

> They're going to have a hard time with DNSSEC signatures if they don't

Some of them will rely on the time they have. Some of them probably
just won't check.

					-- jbash

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Jan 2011 08:57:59 -0800

Is there a reason that we are only focusing on one of the multiple 
proposals that this person proposed? Path II was:

It is not clear that it is inferior to (I) if doing (I) makes the entire 
system more fragile by adding another moving part.

I think (II)(b) looks quite sane, easy to do right now, and if this 
community ever agrees to a safe way to do (I) *and* implements it, doing 
a firmware update to switch over to it would not be hard. I would not 
hold my breath, though.

We're talking pre-loaded trust anchors here. They have the same power as 
pre-loaded software. If (II)(b) works for your software, it should work 
just fine for your trust anchors.

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 28 Jan 2011 09:12:30 -0800

It really seems to me that the only thing that works to bootstrap a device which may have missed arbitrary key rollovers is the following:

If the root KSK is due to 'once every 5 years/because we feel like it/we want to see what happens' rollover event (98% chance):

As long as all the historical data is available someplace that the device knows about (eg. http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-02 .  Or pick whatever...), there is no excuse for not using this style of mechanism.

Its not only secure, but MORE secure than any other automatic alternative because it doesn't add to the 'you need to trust' keyset.  

Anything else MUST either add additional keys to the trusted root, and/or becomes the trusted root instead.  In the former you're weakening the system (you now trust both the . KSK AND some 'random' PKI certificate, as a compromise of EITHER is sufficient to break your security), in the latter you're just replacing one key roll problem with a second (how do you roll the PKI certificate?).

And although the root SHOULD provide such a trust history, any vendor COULD provide its own trust history as a backup/until IANA decides formally it will provide such a mechanism.  It doesn't increase the trust in the vendor.

Thus the only question on a normal rollover is what to do if the update fails because the historic information is unavailable.

My thought would be a 'limited leap of faith': Just ask the root for its KSK, accept the result temporarily, but keep retrying to get the full chain once a minute for the first 10 minutes, once every 10 minutes for the first day, and once a day thereafter.

Yet this temporary result should ONLY be used for validating A records and the like, NOT be used for validating security records (eg, like the DANE working group is proposing).  

Fortunately, since using DNSSEC to validate security-relevenat records requires new API calls, this should be a reasonable to implement restriction.

Thus a denial-of-service from a MitM will be able to muck with A records fine, but can't muck with security records. 

Since such a MitM could just as easily muck with the final traffic in most cases, this is not a substantial increase in security risk, while gaining the ability to automatically role the root for a device that has been offline since who-knows-when, including being able to roll the device when the history service fails.

Instead, if the root KSK is rolled due to a key compromise:

Well, things are ugly.  But things have BEEN ugly for the whole period of time when the compromise was unknown (and someone who compromises the root key is going to have an incentive to keep it VERY quiet).  

And if this requires human intervention to fix, so be it, its going to be such a big mess that human-in-the-loop will be needed for so many other things that, hey, thats life.

Someone invents a practical quantum computer:

Well, DNSSEC is FUBARed then.  Back to the drawing board.

---

From: John Bashinski <[email-masked]>
Date: Fri, 28 Jan 2011 12:28:22 -0500

> It is not clear that it is inferior to (I) if doing (I) makes the
> entire system more fragile by adding another moving part.

I'm not sure I see how it does that. The new "moving part" isn't in
the main trust path. It's off to the side, and it doesn't affect
the basic system. It only affects devices that choose to validate
by default and choose to bootstrap from old keys.

If you do want to think of that as a new moving part, then if you have
every vendor do it separately,what you've really done is to add N
new moving parts instead of one.

> community ever agrees to a safe way to do (I) *and* implements it,
> doing a firmware update to switch over to it would not be hard. I
> would not hold my breath, though.

> We're talking pre-loaded trust anchors here. They have the same power
> as pre-loaded software. If (II)(b) works for your software, it should
> work just fine for your trust anchors.

Actually, it's not quite the preloaded trust anchors we're talking
about. It's the updated keys that get validated using those preloaded
anchors.

It's a given that you're going to start with some key to bootstrap your
trust in DNSSEC, and that key is going to be preloaded. Then you're
going to download some updated DNSSEC trust root, and validate it
against your preloaded key.

The question is how the downloaded key got signed.

From my point of view, some person or persons, inside or outside of
Cisco, is going to have the ability to cause a new DNSSEC root key to
get signed using that preloaded key.

That person or persons is NOT going to be the same person or persons
who generates the software loads. I'm adding a new trusted entity
to the system.

I think you're saying "well, let Cisco be trusted; it's trusted already
anyway". That's true if you look at Cisco as a monolith, but I don't
have that luxury. Something has to be set up inside Cisco to deal with
handling these keys. The complexity still exists; it's just been made
less visible from a certain point of view.

So, the question is whether it's better to have a single, publicly
visible process that may be able to break a very large number
of devices, or a large number of hidden processes each of which
can break a smaller number of devices.

I tend to prefer the former.

						-- jbash

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Jan 2011 12:32:15 -0500

> As long as all the historical data is available someplace that the device knows about (eg. http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-02 .  Or pick whatever...), there is no ex…

There's no way to validate this, so you might was well be trusting instructions written on a bathroom wall.

It's important to recognize two aspects of a key here: the value of the key, and the security of the key.   The root zone key is extraordinarily valuable; if you have it, you can do all kinds of fun bad things with it.   So the incentive to compromise this key is very high.

A corporate key for signing firmware is less valuable.   Of course, if it's used to sign firmware in millions of devices, it's not a *lot* less valuable, but it is less valuable.   The fewer devices it was used in, the less valuable it is.

This suggests another knob to tweak.  Firmware in self-updating devices should have a manufacturer-configured key, but the manufacturer should use that key in no more than N devices, for some TBD value of N.   This reduces the value of the firmware key, more substantially the smaller N is, to a limit of N=1.

> Anything else MUST either add additional keys to the trusted root, and/or becomes the trusted root instead.  In the former you're weakening the system (you now trust both the . KSK AND some 'random…

I think it's important to realize that any device that auto-updates already has one of these keys in it, and that key can be used to update the root zone key on the device, if the device even has a root zone key on it.   So it's not the case that this mechanism makes things less secure.

It's certainly possible to contemplate some regime in which the device key *couldn't* be used to update the root zone key, but I am skeptical that this would be practiced.   So in practice, this problem exists, and is not going away, so it would be better to describe a set of best practices for vendors who use this technique, rather than pretending the technique isn't being used.

We can certainly have a debate about which sort of compromise is more or less likely, but I find the idea of a "limited leap of faith" sort of like the idea of a "limited leap off a cliff."   Unless the cliff is only a few feet high, the absolute height of the cliff is immaterial.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 28 Jan 2011 17:34:45 +0000

> who generates the software loads. I'm adding a new trusted entity

Isn't the person who generates software loads already going to have
to put the (then current) root key / zone into the image? If so, isn't
this person already a trusted entity?

-- 
Alex Bligh

---

From: John Bashinski <[email-masked]>
Date: Fri, 28 Jan 2011 12:52:37 -0500

>> As long as all the historical data is available someplace that the
>> device knows about
>> (eg. http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-02
>> .  Or pick whatever...), there is no excuse for not using this style
>> of mechanism.

> instructions written on a bathroom wall.

You validate it by tracing the signature chain from whatever key you
start with through the first one. That does mean trusting the whole
chain, but it's definitely validation.

> This suggests another knob to tweak.  Firmware in self-updating
> devices should have a manufacturer-configured key, but the
> manufacturer should use that key in no more than N devices, for some
> TBD value of N.  This reduces the value of the firmware key, more
> substantially the smaller N is, to a limit of N=1.

There are tradeoffs there, and they're not just cost tradeoffs.  A
system for managing a whole bunch of keys is necessarily more complex
than a system for managing just one. It handles higher volumes of
data. It updates things more frequently (which means updates can't be
scrutinized as hard). It has more parts that have to be kept online or
near-line. Those all hurt the security.

>> Anything else MUST either add additional keys to the trusted root,
>> and/or becomes the trusted root instead.  In the former you're
>> weakening the system (you now trust both the . KSK AND some 'random'
>> PKI certificate, as a compromise of EITHER is sufficient to break
>> your security), in the latter you're just replacing one key roll
>> problem with a second (how do you roll the PKI certificate?).

> I think it's important to realize that any device that auto-updates
> already has one of these keys in it, and that key can be used to
> update the root zone key on the device, if the device even has a root
> zone key on it.  So it's not the case that this mechanism makes things
> less secure.

Not all devices auto-update. In Cisco's case, I don't think we have
ANY pro gear that auto-updates, and most of our consumer gear
doesn't auto-update, either. What you're talking about is one
of the reasons for that, and we probably won't have widespread
auto-update until we have better answers.

Of course, it's also true that it's probably pretty easy to trick most
people into manually installing bogus software (or DNSSEC roots) on
their devices, but we'd rather not make that an automated thing...

> We can certainly have a debate about which sort of compromise is more
> or less likely, but I find the idea of a "limited leap of faith" sort
> of like the idea of a "limited leap off a cliff."  Unless the cliff is
> only a few feet high, the absolute height of the cliff is immaterial.

That's a deeply misleading analogy, because the effects aren't
similar at all. Temporal extent of exposure matters.

You can:

1. Not validate at all. This makes you pretty easy to spoof,
   at any time anybody decides to spoof you.

2. Learn the root key by "pure faith" at initial installation. This
   is a very significant improvement; it means that anybody
   who wants to spoof you has to be prepared to do it at
   a specific time (which may be hard to predict). They have
   to plan in advance to target you specifically. And they have to get
   you on the first try.

3. Learn the root key by "limited faith". This is another siginificant
   improvement; it means that somebody has to keep a DoS or something
   running continuously from the moment you're installed up through
   the moment they want to feed you bad data. Which could be
   months. If they slip up at any time, you learn a good key and they
   lose the ability to hurt you. And they're very likely to be
   detected.

4. Learn the root key using a bootstrap key and never rely on "faith".
   Nobody can ever spoof you, although you still have exposures
   from key compromise or people leading the legitimate key holder
   to sign something it shouldn't.

Those aren't remotely equivalent exposures.

						-- jbash

---

From: John Bashinski <[email-masked]>
Date: Fri, 28 Jan 2011 12:57:49 -0500

> this person already a trusted entity?

Yes, but originally I had *just* the software person. Now I have the
software person *plus* the person who signs new DNSSEC keys for the
DNSSEC discovery process.

Also, the person generating software loads is only trusted at software
installation time. The person generating DNSSEC keys is trusted at
DNSSEC key learning time. So there's a temporal extension of trust
as well.

						-- jbash

---

From: Edward Lewis <[email-masked]>
Date: Fri, 28 Jan 2011 13:08:28 -0500

This question is mostly aimed at Paul Wouter and others that are 
pushing for a DNS-based mechanism to update keys.

Why is the updating of the DNSSEC root-zone KSK different than 
updating any other piece of data, configuration, or code (soft or 
firmware) in a dormant piece of equipment?

I ask this to see if there is some requirement that leads to a 
crafted solution for this problem.  I just don't see that this is a 
special case, we have other ways to update stuff already.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

With a week old newborn at home, I've discovered that the only 
difference between him and me is that I have to go to work daily. 
That's not fair!  Ma!

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Jan 2011 10:13:01 -0800

> by default and choose to bootstrap from old keys.

A moving part that is "off to the side" but becomes "quite central when 
something goes wrong" is not really "off to the side". It goes from 
unimportant to completely critical just like very other moving part does.

> new moving parts instead of one.

We fully disagree. Trust anchor loading (whether initial or while the 
system is running) is *always* unique to every vendor and, quite 
frankly, to every customer who actually cares about their trust anchors. 
You may not think this because 99.99% of users of trust anchor stores do 
this blindly, but many of Cisco's router customers (and folks like them 
that the DNSSEC community care about) do care about this.

Having each vendor "do this" with DNS security is exactly the same as 
having each vendor "do this" with software security. The fact that Cisco 
has a PKIX signing key that verifies software loads differentiates it 
from some of its competitors who don't do any software validation, and 
makes it similar to some of its competitors that do it in similar ways. 
Trust anchors are the same.

> about. It's the updated keys that get validated using those preloaded

Those have identical security properties to the users. If their vendor 
made it hard or impossible to get the latter when needed, the users will 
(rightly, IMHO) blame the vendor for the users' reduction in security.

> The question is how the downloaded key got signed.

Yep.

> who generates the software loads. I'm adding a new trusted entity

It could be / should be a person who is trusted within Cisco to the same 
level as the person who generated the software loads. She doesn't have 
to be the same person.

> handling these keys.

If you trusted Employee A to fetch the DNS root key at time X and 
include it in the initial firmware loads, you can trust Employee A at 
time Y to do it again for updates, or you can trust Employee B at time Y 
if you would have trusted Employee B to do the firmware loads.

> The complexity still exists; it's just been made

Fully agree.

> can break a smaller number of devices.

That's one way to phrase it. Another would be "whether it's better to 
have a single, publicly visible process that may be able to break a very 
large number of devices and is more complicated than the 
already-complicated process we have now, or a large number of hidden 
processes that have the same local security properties we have now where 
those hidden processes already can (and do!) break a smaller number of 
devices".

> I tend to prefer the former.

Understood. From a security and deployment standpoint, the latter is 
what we already have today, and it might be better to continue to do it 
(and maybe even document it) than to make the current DNSSEC 
infrastructure more fragile.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Jan 2011 13:21:50 -0500

>   lose the ability to hurt you. And they're very likely to be

I think the reason I disagree with you on this is that your threat model is narrower than mine.   I agree that for this threat model, and the others you describe, "limited faith" is an improvement.   But what I'm concerned about are situations where the network is "owned," as Nicholas likes to put it.   In these situations, a compromise that allows the attacker to present a consistent DNS using an old compromised root is a lot harder to detect than one that requires the attacker to know the specific key for your device that must be compromised.

I am not arguing that consistency checks are a bad idea.   If you can catch your attacker in a lie, that's good.   If your attacker can't reliably lie to you, that's also good.

But the particular leap of faith involved in tracing back history using an unauthenticated history list is useless in the face of a key compromise, because once you have that key, you can create a fake history that looks just as legitimate as the real history would; the fact that it validates does not mean that the later key is legitimate.

> near-line. Those all hurt the security.

This isn't strictly true.   DNSSEC is an example of a system that allows for the management of a large set of keys in a secure manner, with the sensitive secrets maintained offline, and yet with full validation possible online.

I don't mean to say that there would be no cost associated with a system like the one I'm talking about, but I think the per-unit cost would be reasonable for useful values of N.

I won't get into the question of auto-update; suffice it to say that no consensus exists that auto-update, done well, is *less* secure than manual-only updates.

---

From: John Bashinski <[email-masked]>
Date: Fri, 28 Jan 2011 13:26:30 -0500

> firmware) in a dormant piece of equipment?

Well, first of all, DNS is absolutely pervasive. Everything uses
it.

Second, you may need DNS as part of the network infrastructure
to let you get the other updates.

Third, DNS keys get updated on a schedule not under the vendor's
control, by an entity not under the vendor's control, and we're
only guaranteed 60 days' notice. And the users' trust for those
data is fundamentally in that entity, not in the vendor, so it's
*appropriate* that that entity get control over the keys.

Fourth, for much of the equipment we're dealing with, this may be the
*only* piece of information that ever gets updated during the entire
lifetime of the product.

Take the Linksys home routers. My guess is that maybe a couple of
percent of them *ever* get firmware updates. Most users don't even
change the factory default configuation. They plug the router in, plug
some computers into the other side, and forget about it.

At most they set up WiFi encryption, and that only reluctantly, because
we force it on them. And that's an entirely local process in which they
have to trust nothing. They definitely don't have to evaluate the
trustworthiness of some random string of hex digits downloaded from
some alphabet soup entity they've never heard of, in order to protect
from a threat they don't understand.

People install these things and forget them unless they break. The
standard operational model simply does not include software updates.

> I ask this to see if there is some requirement that leads to a crafted
> solution for this problem.  I just don't see that this is a special
> case, we have other ways to update stuff already.

Every device has its own specific way or ways to update its own
specific set of data. So we can either fix DNS once, or we can
rework every one of those thousands of update paths to support DNS.

					   -- jbash

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Jan 2011 13:31:56 -0500

On Jan 28, 2011, at 1:26 PM, John Bashinski wrote:
> percent of them *ever* get firmware updates.

Before you use this as a basis for argument, it might be worth your while to (not in this discussion) explore the question of *why* they don't get updates.   From my own personal experience, this is not because of a lack of demand.

---

From: John Bashinski <[email-masked]>
Date: Fri, 28 Jan 2011 13:54:14 -0500

> I think the reason I disagree with you on this is that your threat
> model is narrower than mine.  I agree that for this threat model, and
> the others you describe, "limited faith" is an improvement.  But what
> I'm concerned about are situations where the network is "owned," as
> Nicholas likes to put it.

I think that maintaining "ownership" of the network for that long
is roughly equivalent to "keeping a DoS or something going" for that
long. It's going to be very, very hard to do that without getting
busted.

>  In these situations, a compromise that
> allows the attacker to present a consistent DNS using an old
> compromised root is a lot harder to detect than one that requires the
> attacker to know the specific key for your device that must be
> compromised.

So, the threat you're suggesting is an adversary which can:

1. Compromise a DNS root key, however old that key may be.

2. Completely or nearly completely control all traffic I receive from
   the Net (and presumably the the traffic I send, as well).

I guess my answer is that enemies that powerful may indeed be out of
scope for default behavior. If you're worried about that, you may need
to do something out of band to validate your DNSSEC keys.  The current
plan requires every product to enable you to do that, by the way.

We just plain may not have what it takes to address that threat
by default. If it comes to a choice between not addressing that
threat and not addressing *any* threat, I think it's pretty obvious
that we'll shed that threat.

> But the particular leap of faith involved in tracing back history
> using an unauthenticated history list is useless in the face of a key
> compromise, because once you have that key, you can create a fake
> history that looks just as legitimate as the real history would; the
> fact that it validates does not mean that the later key is legitimate.

Well, yes, but "useless in the face of a key compromise" is "useless in
the face of what we hope is a very improbable event, which if it does
happen is probably going to be done by somebody who's going to make a
bigger splash than just hitting me personally".

All of DNSSEC is useless in the face of a compromise of the current
root key, but I still think it adds valuable security.

> This isn't strictly true.  DNSSEC is an example of a system that
> allows for the management of a large set of keys in a secure manner,
> with the sensitive secrets maintained offline, and yet with full
> validation possible online.

It does that with a single ultimately trusted key. I thought that
was what you wanted to avoid. Maybe I don't understand what you're
suggesting?

> I won't get into the question of auto-update; suffice it to say that
> no consensus exists that auto-update, done well, is *less* secure than
> manual-only updates.

This is a complicated subject and it's off-topic. Suffice it to say
that I do understand that. It's even more complicated than "no
consensus that it's less secure". There's not even a consensus
on how the security should be measured or which concerns matter.
As far as I can tell, whether auto-update is more secure for you
depends on who you are and what you care about.

Nonetheless, we don't have auto-update right now, and we probably
won't have widespread auto-update for quite a while, in part because
we don't know how to address those very issues.

					-- jbash

---

From: Paul Wouters <[email-masked]>
Date: Fri, 28 Jan 2011 14:12:15 -0500 (EST)

> Before you use this as a basis for argument, it might be worth your while to (not in this discussion) explore the question of *why* they don't get updates.   From my own personal experience, this i…

You can ask the firefox people. They have seen a massive increase in updates just
by sneakilly downloading the update in the background and telling the user "the update
is ready to be installed, proceed?". The users who tend not to be able to manually
update a product is exactly the class of users that will say "if it aint broken, don't
fix it".

I think the case of the consumer router is a good one. We all have a box of these old
routers. If our router, or a friends router breaks, we pull out a device and give it to
them. Where we might update it before giving it, non-geeks will just hand it over. It
worked two years ago, why would it not work now?

The receiver will likely factory default it (because they and/or you forgot the password).

Likely, at that moment they won't have an internet connection, because that's why they
needed the router. It has just to work without updates. If this device now has an old root
key and no automated way of updating it, your friend will not have a working internet
connection, and the device is considered "broken".

And there are many more scenarios. A more enterprise aimed product might require that
you know the vendor login/password before you can download the upgrade.

Paul

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Jan 2011 14:35:46 -0500

> plan requires every product to enable you to do that, by the way.

Your local ISP (or, indeed, the criminal with no arrest record who got a job at your local ISP) is perfectly capable of setting this up.   It's not even difficult.

---

From: John Bashinski <[email-masked]>
Date: Fri, 28 Jan 2011 14:57:08 -0500

On 2011-01-28 13:13, Paul Hoffman wrote:

> A moving part that is "off to the side" but becomes "quite central
> when something goes wrong" is not really "off to the side". It goes
> from unimportant to completely critical just like very other moving
> part does.

It doesn't become "quite central when something goes wrong".

It's "quite central" when you want to validate by default without any
operator intervention. It's not even part of the process if you maintain
your anchors manually (as everybody does now). And it doesn't become any
more central when anything goes wrong. It doesn't make any change
in, say, how the system responds to key compromise, nor have I asked
for any change in the key rollover schedule. All I've asked for is
a history of rollovers, or something equivalent.

If you want to have more assurance in your trust anchors, you can ALWAYS
install them manually, or check their fingerprints manually, exactly as
you would today. You can use whatever out of band methods you
want. Nobody's suggested taking that away. In fact, I'm expecting to
take heat for requiring some quite sophisticated trust anchor managment
to be available in products where it'll almost never get used. The
present draft requires:

1. User able to choose root keys (defaulting to whatever's learned
   from the system we're talking about now).

2. User able to override the root keys for any subzone:

   a. With a local anchor, or
   b. With DLV

3. User able to enable or disable RFC 5011 rollover for any anchor
   (on by default).

4. User able to choose trusted algorithms (although not presently
   per zone; maybe it should be).

That's all meant to be required in your pocket camera as well as your
backbone router. If there's something reasonable that I've missed, it
can be added in.

By the way, for further clarity, I'm not at present even asking devices
to *support* updating any manually installed root key with this whole
"historical key" thing, let alone to *force* it to to happen or even to
do it by default. This is only for devices that are starting from
scratch with no configuration.

> frankly, to every customer who actually cares about their trust
> anchors. You may not think this because 99.99% of users of trust
> anchor stores do this blindly, but many of Cisco's router customers
> (and folks like them that the DNSSEC community care about) do care
> about this.

Um, it sort of sounds to me as though you've just defined "many" as
"0.01 percent". But, in any case, all this stuff we're talking about is
for the *default* behavior for devices that have no other DNSSEC
information available.

By definition, it only applies your 99.99 percent who have chosen not to
take further control. They have delegated this matter to the defaults,
basically saying "OK, Cisco or whoever, I trust you tell me, using this
default key, what my DNSSEC root should be".

I'm sure some of them would prefer to trust "Cisco". I'm also sure
some of them would prefer to trust "whoever", if there were a good
reason to assume that "whoever" was less likely to introduce a new
risk than Cisco. It seems to me that the way that introduce the
absolute *least* new risk is to trust only the public root keys,
even the old ones. The second choice is to trust some new key managed
by the same people under the same procedures as part of the same
process.

> having each vendor "do this" with software security.

... except that the software part is unavoidable, so the question
doesn't arise. We create the software, and we're the only ones
in a position to certify it. The DNS part is a *choice*.

> Those have identical security properties to the users.

They have totally different temporal span, and temporal span is really
the whole thing causing us heartburn in the first place.

> If their vendor made it hard or impossible to get the latter when
> needed, the users will (rightly, IMHO) blame the vendor for the users'
> reduction in security.

I guess that's true, but nobody's suggested that.

> It could be / should be a person who is trusted within Cisco to the
> same level as the person who generated the software loads. She doesn't
> have to be the same person.

Um.

Let's suppose that I have two employees, A and B. I expect each of A and B
to behave properly with a probability of 99 percent (and thus expect
each to behave improperly with a probability 1 percent).

If I trust A with the ability to compromise my system, ignoring other
factors, I have a probability of compromise of 1 percent. Same if
I trust B. If I put trust in both A *and* B, such that either A *or* B
can compromise me, my probability of compromise is now 1.99 percent.
Very nearly doubled.

I mean, assuming that A and B have independent probabilities of
subversion, blah blah blah. You get the point.

> time Y to do it again for updates,

Not at all. Things may change between time X and time Y. Maybe A wasn't
mad at me at time X. Maybe A wasn't being bribed at time X.  Maybe A
wasn't having her family threatened at time X. Maybe A wasn't in an
extreme phase of her undiagnosed and uncontrolled bipolar disorder at
time X. Maybe A didn't happen to know how to patch the key in the
software, but does know how to change the key in the update blob.

All other things being equal, I'm much better off to trust A only
once than to trust A twice. And I'm somewhat better off to trust
N times than N+1 times, even for relatively large N.

> or you can trust Employee B at time
> Y if you would have trusted Employee B to do the firmware loads.

No, that's a new risk, just as it would be if I trusted A at time
Y. Actually, it's perhaps worse, because by implication B is now
carrying out a process with which B is less experienced than, say, A
might be, and B is more likely to make a mistake.

I can mitigate all these risks by bringing in employees C, D, E, and F,
and having lots of cross-checks and checklists and secret sharing and
whatnot, very much the way that IANA does for the root key.

Eventually, however, I'm going to have to explain to somebody why that
router I sold them costs more than the competitor's box. So I'd better
hope that person is among those of my customers who understand and care,
and I'd better be able to show a genuine risk reduction over a simpler,
cheaper system... like say trusting the people who already run the
DNSSEC root to do something that they were going to be doing anyway.

That may be kind of hard to do, since I haven't reduced trust in IANA or
its system or its people very much, but I *have* added my system into
the mix...  and I'd better be able to explain how employees A, B, C, D,
E, and F know they got the right root key from IANA...

> have a single, publicly visible process that may be able to break a
> very large number of devices and is more complicated than the
> processes that have the same local security properties we have now
> where those hidden processes already can (and do!) break a smaller
> number of devices".

I still don't agree that any additional complexity is added for
people who want to manage their own trust anchors.

For people who *don't* want to manage their own trust anchors,
there is *no* process now, so it can't get any more complicated.

I also don't agree that those hidden processes have the same
local security properties we have now. You've added complexity
and trust to each and every one of them, over and above what
exists for simply signing software.

... which, by the way, is something most vendors, including Cisco, still
don't have universally deployed and still aren't entirely comfortable
with.

> what we already have today, and it might be better to continue to do
> it (and maybe even document it) than to make the current DNSSEC

... but nobody's suggesting that you have to change anything you're
doing. This is completely optional default behavior, aimed at
people who wouldn't even turn on DNSSEC at all if it weren't there.

						-- jbash

---

From: Paul Wouters <[email-masked]>
Date: Fri, 28 Jan 2011 15:30:32 -0500 (EST)

>   a. With a local anchor, or

Note that this can be complicated. If you have a private.example.com
used internally only, then you have to "override" the DNSSEC signed data
that would "proof" that private.example.com does not exist at the parent
(used in the public view).

unbound has supported this for a long time, and bind started suporting
this only in 9.8.x. Be sure your validating stack can deal with this case.

Paul

---

From: Thierry Moreau <[email-masked]>
Date: Fri, 28 Jan 2011 16:56:45 -0500

John Bashinski wrote:
> 
> It's not even part of the process if you maintain

But once IANA (or whichever organization makes it "public") commits to 
"it" on a long term it becomes by definition more trustworthy than the 
root KSK. Then suddenly the trust foundation shifts from the root KSK to 
"it" and soon it becomes best practice to use it as the normal way to 
bootstrap DNSSEC resolution.

At one point you reach the end of the world (the Earth is flat with 
respect to system-wide crypto key management).

>    from the system we're talking about now).

Ah ah! Now "it" becomes the (default) new trust foundation. I knew it 
would come sooner than later.

Have a good week-end and best regards,

-- 
- Thierry Moreau

---

From: John Bashinski <[email-masked]>
Date: Fri, 28 Jan 2011 17:15:11 -0500

On 2011-01-28 16:56, Thierry Moreau wrote:

> root KSK.

How does that work? All validations are funneled through through the
root KSK. Furthermore, once you're bootstrapped, all your trust anchor
updates come as RFC 5011 signed by the root KSK. So there's no way to
have anything more trusted than the root KSK. This is in the technical
sense of "trusted", which is more or less equivalent to "able to spoil
your day".

The originally proposed form of "it" was for "it" to *be* the root
KSK. You'd start with a root KSK, and if that KSK were still in use,
you'd be done. If not, you'd get "it" in the form of a history of root
KSK rollovers, run through the chain, and thereafter anchor yourself at
the current root KSK.

I still prefer that approach, but other people seem to prefer
alternatives. Not even those the alternatives create anything that I can
see as "more trusted" than the root. "Equally trusted" at most.

> Then suddenly the trust foundation shifts from the root KSK
> to "it" and soon it becomes best practice to use it as the normal way
> to bootstrap DNSSEC resolution.

Well, it certainly wouldn't be the only available way, but, yes, it
probably would be the most common way.

What do you believe should be the "normal way"?

> would come sooner than later.

In order to enable DNSSEC by default, it MUST be possible to bootstrap
it without human intervention, using only the information available to
you when you first get turned on. That's what "default" means.

The current default is not to use DNSSEC at all. A tiny minority
enables DNSSEC. That tiny minority would still be able to do whatever
it wanted to set up trust anchors... including what it's doing today.

So what's the alternative?

					-- jbash

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 28 Jan 2011 20:22:19 -0500

On Fri, Jan 28, 2011 at 11:36 AM, Andrew Sullivan <[email-masked]> wrote:
> do this.

If you plan to roll the root KSK on a regular basis, you are going to create
a requirement to allow dependent applications to validate the current root.

You can deal with this issue without change to the DNSSEC specs of working
assumptions by committing to operate all KSKs for an extended period (20
years would be appropriate). In this model there might be an additional root
introduced every 5 years or so and there would thus be up to 4 roots in
operation simultaneously.

You can also deal with the issue by stating that the root KSK will never
roll. That is almost certainly what will happen in practice, but not
committing to do so means that people cannot plan.

Beyond that, I do not like the idea of a chain of historical roots. It means
that compromise of any root will poison the ones downstream. There are five
potential points of compromise in the following chain:

A -> B, B->C, C->D, D->E

This approach only ever has two at any given time:

A->B, A->C, A->D, A->E

A better approach is to have multiple signers and require multiple
signatures for the root KSK:

X1->A, X2->A, X3->A  [Quorum = 2]

In this scheme none of the signers has the ability to perform either a
fraudulent signature or a denial of service attack without collusion with
another signer.

I don't think that it makes any sense to try to express such semantics in
DNSSEC because the issues raised are not unique to DNSSEC. The hypothetical
NAT box with DNSSEC support would be expected to also require:

* Code signing to protect the integrity of firmware
* Device authentication via 802.1X or similar
* HTTP based configuration interface with TLS

So this is not a problem that I see value in extending DNSSEC to serve since
the same problems are raised in the other three cases, and those will affect
every device sold, not just ones with DNS recursive resolvers.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 28 Jan 2011 21:50:31 -0500 (EST)

On Fri, 28 Jan 2011, Phillip Hallam-Baker wrote:

> Beyond that, I do not like the idea of a chain of historical roots. It means that compromise of any root will poison the ones downstream. There are five

But that requires the key move somewhere trusted so it can make a NEW
signature for the A->C transition, after A has been retired for B. Or
rather, when you deploy E, you have 5 root keys to protect instead of
one. Unless you pregenerate all 5 root keys in advance (but then what
to do for the sixth role and further)

Wouter's draft has no such requirement - in fact the old private root
key could be destroyed, which seems a much safer approach, then requiring
ALL old private keys for 20 years.

Paul

---

From: Thierry Moreau <[email-masked]>
Date: Fri, 28 Jan 2011 21:55:55 -0500

Dear John,

Some definitions and background about trust and "liability" in the 
context of root public keys (DNSSEC root KSK, open PKI root CA -- in the 
original model --, and to a lesser extent a private CA like Cisco's for 
software revisions).

An organization stands behind a root public key because it controls the 
private key counterpart. The organization announces for which purposes 
the key pair is issued, along with some cryptoperiod expectation. 
Relying parties depend on the organization internal controls of the 
private key. Some factors make the organization's responsibilities more 
demanding: the value of surreptitious access to the private key, the 
expected computing power increase in the hands of "the enemy," the wear 
and tear of continuous internal controls, and, indirectly, the size of 
the relying party population.

The cryptoperiod announcement says: after such a date, don't expect our 
internal controls to be at par with the cumulative risk exposure. It 
also says "a digital signature verification is meaningless after the end 
of the cryptperiod." More precisely, it says "don't blame us if a bogus 
digital signature floats around after the end of the cryptoperiod, we 
would have told you that the key was expired."

What you are asking for is a long cryptoperiod, either because the 
history record relied upon in 2035 uses a KSK expired in 2021, or 
because a special-purpose signature key relied upon in 2035 has entered 
IANA internal controls before 2014, the manufacturing date for Cisco boxes.

I am sure IANA does not wish to let "the world" to so rely on a long 
expired KSK without having been served this little warning "no good 
after KSK rollover which we will announce in advance." I write this from 
discussions surrounding the KSK internal controls, a time during which I 
was advocating a longer term commitment (with slightly different 
procedures) from IANA. IANA did an excellent job at this project for 
which there was no precedent, at least with an equivalent level of 
transparency. Their stubbornness (?) in making this little warning is an 
indication that their KSK operations are trustworthy *before* rollover.

For the long-term commitment from IANA for (the internal controls 
required for) a special purpose signature key, I am less certain. But if 
they do make this commitment, then WOW! "The world" would have what you 
are looking for. Bootstrap from this super-WOW signature key whenever 
you feel you need more confidence in your DNS resolution.
   - You say *only*if* the current local KSK configuration is outdated. 
I would say it's up to any gear vendor, any security officer, or any sys 
admin, in any circumstances.
   - You say it's no better than the KSK, while in fact it is: it works 
across KSK rollovers. Suppose your unit goes back on-line in 2035 and 
sees the same KSK as was current in 2014, because a bogus root is being 
operated by a hacker in the network nearby. The super-WOW signature 
verification will prevent the bogus root attack.

It's about the IANA embarrassment if something goes wrong. Semantically 
it does not turn into "liability" but that is just because secure 
electronic payments are not directly secured by DNSSEC validated RRsets 
near the top of the DNS hierarchy.

I exposed the suggested course of action for Cisco in the first e-mail 
to you (it was off-list). It is a simple selection from what you already 
identified as operationally acceptable options.

I hope it clarifies the link between long term public key crypto 
material and "trust" as the term applies to your problem statement 
(which I find very good).

Hope it helps (I wish to abstain from further contributions to the IETF 
list on this issue).

Regards,

-- 
- Thierry Moreau

---

From: Paul Wouters <[email-masked]>
Date: Fri, 28 Jan 2011 22:13:59 -0500 (EST)

On Fri, 28 Jan 2011, Paul Wouters wrote:

>> Beyond that, I do not like the idea of a chain of historical roots. It 
>> means that compromise of any root will poison the ones downstream. There 
>> are five

Oops, as Phillip said, it is only two. I misunderstood. But it still requires
two private root keys to be available, instead of one.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 29 Jan 2011 11:43:26 -0500

On Fri, Jan 28, 2011 at 9:50 PM, Paul Wouters <[email-masked]> wrote:

>> means that compromise of any root will poison the ones downstream. There are
>> five

Neither would cause me the slightest concern in the context of offline root
key management.

HSMs used for this type of application are capable of storing hundreds of
private keys. For an application like DNSSEC the HSMs should be used for
DNSSEC and no other purpose whatsoever.

Offline root key management bears very little relationship to management of
application keys.

EVERY risk that has been identified should already be highly improbable. The
cumulative probability of any risk being realized should be negligible (much
less than 1%).

I think we need to start with a set of requirements and at the very least
involve people with first hand experience of the ICANN root key management
processes. The video suggests that there was something like thirty people in
the room when the keys were generated so they can hardly be trade secrets.

This issue was clearly understood at the time that the ICANN processes were
developed and it looks to me like the decision to not support a long term
validation root was quite deliberate, though the reasons for making that
choice are not.

Regardless of the reasons for the decision, it should be obvious that lack
of a technical proposal was not one of them.

So before discussing a technical proposal, I suggest we gather some
information. The ICANN people will be at RSA next month, so will Cisco
people who have responsibility for crypto and many others who might have
relevant ideas or experience.

If this is really an issue we should have a meeting and discuss the full set
of requirements and the issues involved.