Subject: [DNSOP] draft-ietf-dnsop-dnssec-trust-history - discussion

From: Stephen Morris <[email-masked]>
Date: Fri, 10 Sep 2010 12:24:35 +0100

Colleagues

Although draft-ietf-dnsop-dnssec-trust-history (the DNSSEC Trust Anchor History Service) is a working group item and the editor has received a number of private comments on it, there has actually been relatively little discussion of the draft on the list, either pre- or post-adoption. If the draft is to go forward, it must represent the consensus of the working group.  To show that, we need people to comment on it and to support it.

So, to gauge feeling and to trigger discussion, could the chairs please have your views on the following issues: 

1. Is the situation addressed by the draft - that of a validator that has been offline or that has missed an (emergency) rollover needing to reconfigure itself - a problem that needs to be solved?

2. If the answer to (1) is yes, is the idea of using DNS the best way to do it?

Thanks,

Stephen

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 13 Sep 2010 16:36:29 +0200

Hi dnsop,

On 09/10/2010 01:24 PM, Stephen Morris wrote:
> Colleagues
> 
> Although draft-ietf-dnsop-dnssec-trust-history (the DNSSEC Trust
> Anchor History Service) is a working group item and the editor has
> received a number of private comments on it, there has actually been
> relatively little discussion of the draft on the list, either pre- or
> post-adoption. If the draft is to go forward, it must represent the
> consensus of the working group.  To show that, we need people to
> comment on it and to support it.
> 
> So, to gauge feeling and to trigger discussion, could the chairs
> please have your views on the following issues:
> 
> 1. Is the situation addressed by the draft - that of a validator that
> has been offline or that has missed an (emergency) rollover needing
> to reconfigure itself - a problem that needs to be solved?

Yes, I think that problems needs a solution.  If you miss the
couple-week KSK rollover, RFC5011 cannot catch up your root anchor.
Maybe not a problem in the ISP-space (who are always online), but for
widespread deployment.

> 2. If the answer to (1) is yes, is the idea of using DNS the best way

Well, one way is to have the OS update handle it somehow.  But then the
OS update has to handle it.  Perhaps the OS update requires domain names
to resolve (remember, the world is bogus when the root trust anchor no
longer works; port distributions and mirrors may not work).  Also such
an OS update, if it is secure, would rely on exactly another key that is
that old.

Another solution is a vendor-update solution, i.e. an ISC or an
NLnetLabs or other-vendor key which is used to fetch a new root key.
Such a key would need to be kept as safe as the private key for the root
to be useful.

Another solution is to fetch the root key fresh from the iana website.
And check that it is correct using another key (which is necessarily
just as old): the PGP key or the https certificate.

Trust history, then, does not require additional keys.  It could run
over TCP (i.e. fetch a text file), but recall that domain names are all
bogus.

So, without saying I really want to do one of them, I would like to
promote deployment of DNSSEC, and include a 'foolproof' root trust
anchor (or deployment-method description or handy shell-script to
reinitialise).

Initially, in IETF fashion, I went immediately to solution, and went for
an in-band (since no DNS service), not-rely-on-other-key and
safety-provided-by-root-team solution.  Maybe that was wrong, I would
like, however, to promote DNSSEC deployment towards the (more likely
down or offline) end-hosts, and something needs to be done to make it
possible to have a fluent KSK rollover for the root: I think it is very
important to make this as easy as possible, so that new algorithms or
updated key parameters can easily be introduced.

Best regards,
   Wouter

---

From: Joe Abley <[email-masked]>
Date: Tue, 14 Sep 2010 13:17:56 -0400

> Maybe not a problem in the ISP-space (who are always online), but for

For the root trust anchor, I think a better solution is to retrieve a fresh copy from the IANA. The format and location have been well-specified, albeit not in an RFC (yet), and I don't see why this could not be automated. There are several methods provided for the integrity of the retrieved key to be checked.

Perhaps I'm being overly optimistic about DNSSEC deployment in TLDs, but I think a realistic long-term solution for other trust anchors is not to use them (i.e. to use a single root trust anchor, and use DS records to publish trust anchors for other zones).

>> 2. If the answer to (1) is yes, is the idea of using DNS the best way

As I've mentioned before, the problem I have with trust-history is that it involves using old keys to make trust decisions about new keys. It is difficult to believe in the general case that old keys are entirely trustworthy. Presumably keys are rolled for a reason.

Doesn't trust-history impose a requirement high standards of operational security for key materials which have long since fallen out of production, and hence extend the possible window for a key compromise long after the key has stopped being used? From an operational perspective this worries me.

Joe

---

From: Tony Finch <[email-masked]>
Date: Tue, 14 Sep 2010 18:55:27 +0100

On Tue, 14 Sep 2010, Joe Abley wrote:
>
> Doesn't trust-history impose a requirement high standards of operational
> security for key materials which have long since fallen out of
> production, and hence extend the possible window for a key compromise
> long after the key has stopped being used? From an operational
> perspective this worries me.

I haven't checked the draft, but it should be possible to throw away a
private key after it has signed its successor and been decommissioned.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 14 Sep 2010 14:22:19 -0400

At 13:17 -0400 9/14/10, Joe Abley wrote:

>As I've mentioned before, the problem I have with trust-history is that
>it involves using old keys to make trust decisions about new keys. It
>is difficult to believe in the general case that old keys are entirely
>trustworthy. Presumably keys are rolled for a reason.

Double ditto.  (The "I've mentioned before" part as well as "old keys 
to make trust decisions about new keys.")

I discourage anyone caching any information that appears in any of my 
managed zones for longer than it's TTL.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh.

---

From: Joe Abley <[email-masked]>
Date: Tue, 14 Sep 2010 16:01:37 -0400

> private key after it has signed its successor and been decommissioned.

Right. I'm concerned about the scenario where

 - KSK goes out of production
 - KSK is supposed to be destroyed following some suitable emergency roll-back window
 - KSK is not actually destroyed due to operational error
 - KSK is compromised by someone (hard disk found in dumpster)
 - KSK is used to create an apparently-legitimate branch of the trust-history chain, legitimising a bogus key

In normal operation this would not be a concern because the retired KSK is of no practical use. By inventing a practical use for the retired KSK, the requirements for secure handling are extended until the end of time.

I agree that in an ideal world the KSK would be securely destroyed. I don't often feel like I live in that world, however, hence my worry.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Sep 2010 18:12:56 -0700

>1. Is the situation addressed by the draft - that of a validator that has been offline or that has missed an (emergency) rollover needing to reconfigure itself - a problem that needs to be solved?

Yes, mostly for the former case. A subset of the "has been offline" problem is distros that come with trust anchors that are installed after one of the trust anchors has expired. That's like being offline since the distro was burned into an ISO.

>2. If the answer to (1) is yes, is the idea of using DNS the best way to do it?

Maybe, but I agree with the folks who said "but not by using keys that should have been discarded". A possibly better (and much simpler) way to do this is to somehow associate a long-lived secure URL (such as using the https: scheme) that leads to the repository of current trust anchors. This requires that the DNS server have a separate pile of trust anchors for the non-DNS scheme, and those keys need to be valid for longer than the DNS trust anchors that are expiring, of course.

--Paul Hoffman, Director
--VPN Consortium

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 17 Sep 2010 12:28:17 +0200

Hi dnsop,

The sentiment over the last week is that retired keys should not be
abused, and trust-history is then gone, with such opposition by WG.

I do have to renew the root anchor when it changes.  Let's look at the
'fetch from iana again' method in detail.  Obviously I assume the
machine is also performing 5011, but this has not been sufficient and
thus a refetch has become necessary.  But I do not like to make too many
assumptions, so I am going to try to call out all of the (hidden)
assumptions that 'fetch from a URL' means.  So that you can choose
explicitly the ones that are ok.

* The URL that iana published in their description is:
  https://data.iana.org/root-anchors/root-anchors.xml
* 'widely available trust certificates' to verify the https

Are you sure that we want to create a cross-dependency on the https
security for the DNS security?  This means the DNS and cert paths are no
longer different trust paths.  And we should look at the attack vectors
here.  If the root-key-prime fails, it is likely the machine will
initiate this update machinery right away.  Assume a full MitM; say on a
middlebox; it can make the root-key-prime fail and intercept traffic to
that URL.

If you know 5011 is on, you can have a 30-day delay.  (described in more
detail in that trust-history draft).  But then someone faking NTP might
subvert this mechanism if that makes the client reset its date.

Also, there is no trustworthy DNS resolver while this https fetch is
executed.  Should I hardcode the IP address?  (192.0.32.25?)  An
alternative is to resolve the (bogus) name and use that, but it means
having a special-purpose https implementation that has the ability to
call the resolver to lookup (bogus) names without DNSSEC validation
while the root anchor is updated.  (and that might also need to lookup
certificate revocation lists and so on).

The certificates, well we could use the current public key that IANA
uses, and hardcode that in the resolver.  It is currently signed until
8/29/2011.  Or insert root certificates, or use the
system-certificate-list (if such a thing exists).  I notice the one used
by IANA is valid until 2038.  Is 28 years sufficient?  What do I do when
the root certificate(s) have expired?  (or, when the local clock seems
to indicate they have; that clock may be off).

I could perform a blind leap of faith, and simply accept the new root
key, or fetch the root key using a http session to a bogus IP-address.
This would likely work and give users an experience.

The file is in XML.  It is described in
http://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.txt
I would like to fix its format, as XML string operations are (in my
opinion) dangerous - especially for a file someone can force me to parse
by triggering a validation failure for the root.  It is also in UTF-8,
that needs unicode conversion?  I really have to have a full XML parser?
 I would assume the file uses the ascii set and no change in linebreaks
from today.

Also, if I make a special-purpose https. what version of http is
assumed?  I would assume plain GET, no http stuff, no sslv2.

Does the user have to be informed?  You can decide that automatic update
is forbidden and users must be active.  I would like automatic.
The PGP key route is nice if you get it; it precludes automation.

Is all this worth it, if compared with the trust-history proposal?

Best regards,
   Wouter

---

From: Jim Reid <[email-masked]>
Date: Fri, 17 Sep 2010 12:01:27 +0100

On 17 Sep 2010, at 11:28, W.C.A. Wijngaards wrote:

> security for the DNS security?

Depends...

> This means the DNS and cert paths are no longer different trust paths.

That might or might not be a bad thing. If the One True TA is lost and  
needs to be re-instantiated, some sort of out of band mechanism is  
going to be needed. That may have to be a manual intervention. What  
mechanism is used will depend on local policy. I'm not sure it's wise  
to limit our options to HTTPS.

---

From: Joe Abley <[email-masked]>
Date: Fri, 17 Sep 2010 09:10:09 -0400

> * 'widely available trust certificates' to verify the https

We also specified

 - http:// URLs (no "s")
 - detached OpenPGP signatures
 - detached S/MIME signatures

> security for the DNS security?

Per above, there are multiple alternatives.

> This means the DNS and cert paths are no

Let's also assume that a trust anchor for the ICANN CA which is used to create the detached S/MIME signature, or the PGP public key which is used to create the OpenPGP signature has been incorporated in some sensible way into operating system and/or DNS software distribution. This ought to represent a usefully-different path of trust to allow the authenticity of trust anchors received from the repository to be verified.

ICANN continues to offer to work directly with key software vendors to facilitate secure distribution of these trust points. We'll fly to your offices and hand them to you with signed attestations, if you want.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 17 Sep 2010 08:31:12 -0700

>security for the DNS security?

No, I am sure we don't want to create a forced cross-dependency on https. But that is far from the only choice.

We are talking about two different scenarios mixed as one, and I think we should differentiate them:

- The IANA trust anchor for the root

- All other trust anchors, both "alternate roots" and lower-in-the-tree fixed points

In the first case, we can rely on out-of-band fingerprints and so on being widely distributed in a reliable fashion. In the second case, we can make suggestions but we can't really rely on it.

I am only interested in the first case. I could care less about alternate DNSSEC roots, and the people I know who care about distribution of lower-in-the-tree trust anchors have enough control of the affected systems to deal with missed rollovers.

--Paul Hoffman, Director
--VPN Consortium

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 21 Sep 2010 11:20:22 +0200

Hi,

Thanks for your comments and suggestions, and I'll go and make my
(software-vendor-specific-)pick from them.

Best regards,
   Wouter

On 09/17/2010 05:31 PM, Paul Hoffman wrote:
> No, I am sure we don't want to create a forced cross-dependency on
> https. But that is far from the only choice. I am only interested in
> the first case. I could care less about alternate DNSSEC roots, and
> the people I know who care about distribution of lower-in-the-tree
> trust anchors have enough control of the affected systems to deal
> with missed rollovers.

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 21 Sep 2010 16:57:25 +0200

> I would assume the file uses the ascii set and no change in linebreaks

The file is in XML format and follows the schema from the draft. You should parse this file as XML and not depend on the specific current format/encoding, i.e. new tags and attributes may be added in the future. There are plenty of light-weight XML parsers available and I suggest you try to use one of them instead of rolling your own.

> assumed?  I would assume plain GET, no http stuff, no sslv2.

According to the draft, HTTPS as specified in RFC 2818 (HTTP Over TLS) is used. Checking data.iana.org as of onw gives that it will offer TLSv1/SSLv3 with RC4-SHA.

	jakob

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