Subject: Null-key priority during key-clash.

From: Roy Arends <[email-masked]>
Date: Tue, 25 Jul 2000 15:35:01 +0200 (CEST)

Regarding: RFC 2535,
         : Handling of DNS Zone Signing Keys
           <draft-ietf-dnsop-keyhand-02.txt>

Hello,

Suppose the domains example.org and .org are secure. Now consider a
Real-key SIG for the zone example.org , which is issued for the period of
January 1st until April 1st. On March 1st the Real key for the example.org
zone gets compromised. This is noticed by the example.org owner and the
Real-Key is immediatly removed from the example.org zone. After TTL
expires, this key will not exist, and this zone will be considered BAD by
secure resolvers. Therefore, the .org domain issues a signature for a
Null-key for the example.org zone. Now the example.org zone can still be
resolved, though it is marked by secure resolvers as "Unsecure". All this
happens before April 1st.

But,

A malicious entity (for example, this could be the compromiser of the key)
can poison caches with the old Real-key and SIG for the example.org zone.
This Key's SIG is still valid until April 1st, and any secure resolver
which stumbles across this Real-Key & SIG will see these as valid.

Upon a query for the KEY & SIG of example.org. a (poisoned) cache will
return both KEYs and both SIGS. Should the secure resolve see this zone as
Secure (which, in this case it is obviously not) or as Unsecure. I think
the latter. In other words, should the Null-key be given a higher priority
during a Key-Clash ?

Note: This is not the same issue as what in rfc 2535 was noted as
"Experimentally secure." 

I haven't found this priority issue in rfc 2535, nor in any draft. Though
the draft "Handling of DNS Zone Signing Keys"
<draft-ietf-dnsop-keyhand-02.txt> has a section on Removing a Key From Use
(2.5) though this section does not suffice.

Any comments ?

Roy Arends
NLnet Labs.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Jerry Scharf <[email-masked]>
Date: Tue, 25 Jul 2000 09:41:43 -0700

Roy,

there are many DoS attacks that can be done with Secure DNS, nad that has been 
known since the original design. I think both of these, or variants, have been 
known since the beginning. I think everyone goes thought this at some point.

I think it has to be ackowledges that DNS as it exists today has many DoS 
attacks as well, so it's not like we're taking something that is hard to 
attack and then making it easy. I've always figured it was more work than 
needed to use subtle secure DNS attacks when it is so simple to just jam any 
answer back with the right source address and sequence.

Just return an NXDOM, it's much more effective with the exception of not 
wasting CPU cycles on the resolver/recursive system. If you want to burn their 
CPU you do want to use secure DNS, but what you really want to do is make the 
longest key possible to maximize checking cost.

jerry

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 25 Jul 2000 21:22:29 +0200

At 15:35 25/07/2000 +0200, Roy Arends wrote:
>This is noticed by the example.org owner and the
>Real-Key is immediatly removed from the example.org zone.

I thought this would read "is replaced by a NULL key" or "is replaced by a 
new key" - why would a security-aware admin
*remove* a KEY record rather than replacing it with a sensible one?

DNSSEC was designed without revocation lists; your scenario seems a 
consequence of that decision.

                  Harald

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: Roy Arends <[email-masked]>
Date: Wed, 26 Jul 2000 10:20:22 +0200 (CEST)

> *remove* a KEY record rather than replacing it with a sensible one?

For a secure resolver, there is no null-key without it's parents SIG
(regardless if example.org replaces the old key with a null-key in the
zone). Ofcourse, as soon as the parent issues a SIG for the null-key, the
child (or parent)  can put it in the child's apex.  

The issue here is that the old key is still very much alive regardless
its removal/replacement by the example.org zone. 

A possible solution is to give more priority to the NULL-key when there is
a KEY clash. 

> DNSSEC was designed without revocation lists; 

Yep, but time is the revocation method in DNSSEC.

> your scenario seems a consequence of that decision.

Not exactly, I'm suggesting a possible solution.

Thanks,

Regards,

Roy Arends,
NLnet Labs

---

From: Edward Lewis <[email-masked]>
Date: Wed, 26 Jul 2000 10:36:33 -0400

>Yep, but time is the revocation method in DNSSEC.

This email doesn't come to a point, but it explains other answers I may
give on the original thread...

Harald's point is correct.  Sorry not to answer sooner, but it took a lot
longer to get back home from the ICANN/INET meetings.

Revocation means "I no longer meant what I said."  To put a fine point on
it, time is not a revokation method in DNSSEC.

For example, let's say I issue a SIG with a validity period of August.  If
on August 15th, I (as a server) want to have the SIG invalidated I would
need to "revoke" it.  The SIG record is not revoked on September 1st, it is
"expired."

The difference between the two is that when I (as a resolver) receive data,
I can see its validity period and can use it within that constraint.  If
data is revoked, I probably won't know that when I receive the data - I
need to be told it is revoked when the decision is made.  Note that being
told could be a "push" from the source to me, or a "pull" when I ask the
source to refresh the revokation information.

Here is some long winded background material that may explain my point of view:

The facts that DNSSEC suffer from a lack of revokation and is suspect to
denial of service are known, and are artifacts of the design of the system.
I am pretty sure you can't completely solve these problems because of the
nature of DNS.

Recall that DNSSEC is designed to allow a resolver to be able to be sure
the answer the resolver gets is truely from an authoritative source.
DNSSEC does not protect the zone (server) and cannot guarantee that the
resolver will get the best answer.

Why is this?  The nature of DNSSEC is that it is a backwards compatible
extension to the DNS protocol, strengthening the DNS protocol in places
where the protocol is vulnerable to an attack.  DNSSEC has a couple of
weaknesses, but I think that most of these can be traced to fundamental
weaknesses in the DNS protocol.  Here are some of the major underlying
problems:

1) DNS is not real-time.  DNS data carries no sequence information, with
the exception of the SOA record.  I.e., if you were to get two A record
sets for a name from two sources, you can't tell which is more recent.

2) DNS is loosely coupled between servers and clients.  When a server
changes the data for a zone, it has no means to contact and update the
resolvers that have asked for information.

3) DNS provides no explicit (modular) authoritative data in a zone that it
has made a delegation.  I.e., the parent inserts the NS record, but is not
responsible for the data in it.

As far as point 1, DNSSEC adds validity periods to SIG records which verify
sets of data.  But this is done so that we can limit the damage done by a
key's exposure.   If you were to receive two validly signed sets of data
for a domain name/type/class, which would you trust?  The one with later
validity start period?  This isn't specified anywhere.

The way I deal with this is that a DNSSEC SIG record merely indicates that
the data you see came from someone with the private key generating the
signature.  This way you can pin-point the source, or at least who to ask
whether the data is valid (in case of a key exposure).

DNSSEC does not prevent bad data and attacks.  Don't rely too heavily on
the SIG record alone for protection.

As far as point 2, if a zone changes it's mind, it has always and will
remain to be vigilant that old data maybe floating through DNS.  There's no
way for a server to alert users that it's data that data has been changed.
Since this is not possible, it is not possible to secure the action.  (I
can't secure nothing.)

As far as point 3, I threw this in for "completeness" - it's not germaine
here, but is the reason why delegation points are a pain in the DNSSEC.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"It takes years of training to know when to do nothing" - Dogbert

Opinions expressed are property of my evil twin, not my employer.

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 26 Jul 2000 19:51:24 -0400

Edward Lewis wrote:
> DNSSEC has a couple of weaknesses, but I think that most of these can be
> traced to fundamental weaknesses in the DNS protocol.  Here are some of
> the major underlying problems:
>

> [...]

Is it time, perhaps, to start thinking of extending NOTIFY as suggested in
RFC 1996, Section 1.2, i.e. to other purposes besides triggering zone
transfers?  >From what Ed says above, this may be useful from a DNSSEC
standpoint, but my more immediate concern is all of the load-balancing
and/or failover implementations these days which are setting TTL=0 on their
address records in order to defeat caching. If NOTIFY could be used to
"poke" caches to fetch changed versions of important RRsets, then maybe
those TTL's could return to more reasonable values...

(Obviously, some form of negotiation would be necessary -- probably using
EDNS -- to determine whether the querier wants to receive the NOTIFY or not;
there's no point in trying to poke a non-caching resolver).

- Kevin

---

From: Edward Lewis <[email-masked]>
Date: Thu, 27 Jul 2000 08:39:47 -0400

>> way for a server to alert users that it's data that data has been changed.

I used 'vigilant' in a message?  Man, was I out of it yesterday... ;)

>those TTL's could return to more reasonable values...

IMHO this would be a bad thing.  The problem is knowing what entities a
server would NOTIFY.  We don't want to introduce a requirement that a
server remembers all the resolvers that have queried it for information,
nor do we want to impose a requirement that if A learns from B information
that originated at C, A would register this learning with C.

Within DNS there are really three sub-protocols, all sharing the same wire
format but differentiated by processing and configuration information.
General DNS resovler-server is a open community protocol.  DNS
primary-secondary protocol and the DNS stub resolver-defaul server are
closed community protocols.

Open community protocols are built to scale, to so this you have to suffer
anonimity of actions.  Servers of this type cannot be expected to bear the
burden of maintaining state information about (all) individual clients -
clients who may never return for more information.

We can't have this in the general DNS resolver-server protocol and remain
within the spirit of the DNS architecture.

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 27 Jul 2000 18:29:28 -0400

> that originated at C, A would register this learning with C.

I wasn't thinking of this as a *mandatory* requirement. The client would request
the server to notify it of any future changes to the data it is fetching. The
server chooses to accept or decline this request. Even if the server accepts the
request, if it runs into some (hopefully configurable) resource limits, it would
still be allowed to "forget" that it gave a particular answer to a particular
client. Nothing would be mandatory. Everything would be on a "best efforts" basis,
and thus imperfect. But at least I think it would be better than all of the TTL=0
crap that's coming increasingly into vogue...

> within the spirit of the DNS architecture.

Reasonable people can disagree, of course, about what that "spirit" is or is not.
I think it's perfectly within the spirit of modern DNS for two nameservers to
participate in a mutually-agreed-upon optional extension to the protocol. Isn't
that what EDNS options were invented for, after all?

- Kevin

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 28 Jul 2000 16:11:56 +0200

>that what EDNS options were invented for, after all?

that's what EDNS0.5 features were invented for (among other things).
EDNS version numbers is a quite different kettle of fish.

               Harald

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 28 Jul 2000 11:03:37 -0400

Oh? I've read the EDNS0.5 draft quite thoroughly (I thought) and I think it's a
great idea. However,  my impression was that these "features" were only for
extensions which were expected to eventually be folded into the main protocol spec
for all clients and servers. Full-blown EDNS options, on the other hand, still
have a place when only _certain_ clients and _certain_ servers want to use
extensions between themselves.

Plus, I took EDNS0.5 features to be basically binary-valued, i.e. either you
request/support/comply with the feature or you don't. Options allow extra data to
be sent. I'm thinking that this "Change Notification" option, for instance, might
allow the requestor to optionally specify a key or some kind of token so that only
NOTIFY's "authenticated" with that key/token will be acted upon. This is to try
and ward off a certain kind of Denial-of-Service attack, e.g. bad guy X spoofs a
NOTIFY from Y, causing Z to resend a huge RRset or ANY query, thus amplifying the
attack.

- Kevin

---

From: Edward Lewis <[email-masked]>
Date: Fri, 28 Jul 2000 14:13:02 -0400

>that what EDNS options were invented for, after all?

I had interpreted your message to mean extending NOTIFY to be a means to
notify (stub) resolvers of updates to servers they had contacted.

Still, outside of grouping name servers into sets begin authoritative for a
zone, DNS is still an open community protocol.  Before attempting to define
an extension to NOTIFY as you are suggesting, we'd need to define a way to
group servers together in a more general set.  (E.g., all the servers
running in my network - regardless of zone.)

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 28 Jul 2000 19:52:37 -0400

> notify (stub) resolvers of updates to servers they had contacted.

Sorry, perhaps I wasn't clear. The NOTIFY would only be sent to a resolver that
had asked for it. And generally speaking there wouldn't be any incentive for a
non-caching resolver, like a stub resolver, to ask for the NOTIFY, since it has
no cache entries to refresh.

> running in my network - regardless of zone.)

Not to be glib, but isn't this an implementation detail? The implementation just
needs to know the set of who has requested to be NOTIFY'ed and then NOTIFY them
if the RRset changes. How it maintains that knowledge -- what data structures are
used, whether it is maintained in volatile or non-volatile storage, whether it is
purely dynamic or the administrator can also specify addresses which should
*always* receive NOTIFYs for a particular RRset, etc. -- seems to me not a part
of the protocol _per_se_.

Note that in terms of conserving capacity, the server can age out of the dynamic
NOTIFY set any targets that it knows will have already expired their entries
(based on when they last fetched the RRset and what its TTL value was at the
time); those targets will be fetching a new version of the RRset when they need
it anyway, so the NOTIFY is not necessary. This means that the administrator can
tune the amount of storage required for the NOTIFY set indirectly by manipulating
the TTL's on the records. For machines short on memory (or disk space, if that's
where it's storing the NOTIFY set), maybe the TTL's would be tuned down to an
hour, 30 minutes, 15 minutes, or whatever. That's not great, but it's still
better for the Internet DNS infrastructure as a whole than TTL=0, especially in
the case of popular RRset's.

- Kevin