Subject: draft-ietf-dnsext-delegation-signer-01

From: Jakob Schlyter <[email-masked]>
Date: Sun, 05 Aug 2001 22:39:00 -0700

section 2.1, protocol change, says:

  DS record MUST only appear at secure delegations in the parent zone.
  The record lists the child's keys that SHOULD sign the child's key
  set.  Insecure delegation MUST NOT have a DS record, the presence of
  DS record SHOULD be considered a hint that the child might be secure.
  Resolver MUST only trust KEY records that match a DS record.

I think is to vague as it does allow you to get into a situation where the
parent says the child might be secure but it is not. perhaps this is a
better wording:

  DS record MUST only appear at secure delegations in the parent zone.
  Secure delegations MUST have a DS record. Insecure delegations MUST NOT
  have a DS record. Therefore the presence of a DS record should be
  an indication that the child is secure. The child MUST sign its key set
  with at least one of the keys listed in the DS record at the parent.

Regarding NULL DS, I believe we don't need them as could use NXT/NO
instead if desired (as explained in the draft).

	jakob

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

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 7 Aug 2001 17:35:41 +0200 (MEST)

>   Resolver MUST only trust KEY records that match a DS record.

as olafur pointed out personally to me, you may not write should in
lowercase. updated text below:

DS record MUST only appear at secure delegations in the parent zone.
Secure delegations MUST have a DS record. Insecure delegations MUST NOT
have a DS record. Therefore the presence of a DS record is an indication
that the child is secure. The child MUST sign its key set with at least
one of the keys listed in the DS record at the parent.

	jakob

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 08 Aug 2001 12:27:41 +0200

Jakob Schlyter <[email-masked]> writes:
 * On Sun, 5 Aug 2001, Jakob Schlyter wrote:
 * 
 * > section 2.1, protocol change, says:
 * >
 * >   DS record MUST only appear at secure delegations in the parent zone.
 * >   The record lists the child's keys that SHOULD sign the child's key
 * >   set.  Insecure delegation MUST NOT have a DS record, the presence of
 * >   DS record SHOULD be considered a hint that the child might be secure.
 * >   Resolver MUST only trust KEY records that match a DS record.
 * 
 * as olafur pointed out personally to me, you may not write should in
 * lowercase. updated text below:
 * 
 * DS record MUST only appear at secure delegations in the parent zone.
 * Secure delegations MUST have a DS record. Insecure delegations MUST NOT
 * have a DS record. Therefore the presence of a DS record is an indication
 * that the child is secure. The child MUST sign its key set with at least
 * one of the keys listed in the DS record at the parent.

After a little chat with Ed, Lars, Johan and Jakob I think we want to
word this even more carefully.

The problem is in:

'The child MUST sign its key set with at least one of the keys listed'

In the case of key compromise the zone administrator of a child zone
might want to resign the zones with a completely new key even
before the parent has had a change to update their DS record.

The 'MUST' in the line quoted above indicates that this operational
procedure is illegal.

On the other hand it must be clear to a resolver that if the DS record
indicates a child zone is secure. The original sentence:

'  Insecure delegation MUST NOT have a DS record, the presence of
   DS record SHOULD be considered a hint that the child might be secure.
   Resolver MUST only trust KEY records that match a DS record. '

will allow spoofing of unsecured child zone data. I think if the
resolver cannot validate the child zone's data using any of the keys
that the DS records are pointing to, the child zone MUST be
considered bad. 

I propose the following wording:

   DS records MUST only appear at secure delegations in the parent zone.
   The records list the child's keys that SHOULD sign the child's key
   set.  Insecure delegation MUST NOT have a DS record. Secure delegations 
   MUST have at least one DS record. 
   The presence of one or more DS records MUST be considered an indication
   that the child zone is secure. 

   Resolvers that are not able to find or verify at least one of the 
   child's keys pointed to by the DS records, MUST consider the child zone 
   non-authentic.

--Olaf

-----------------------------------------------------
  Olaf M. Kolkman      |  RIPE NCC DISI Project
     -----------       |      ---------------	   
  RIPE NCC             |  Phone:   +31 20 535 4444
  Singel 258           |  Fax:     +31 20 535 4445
  1016 AB Amsterdam    |  http://www.ripe.net/disi
  The Netherlands      |  [email-masked]

---

From: Dan Massey <[email-masked]>
Date: Wed, 8 Aug 2001 11:23:14 -0400

On Wednesday, August 08, 2001 at 12:27PM, Olaf Kolkman wrote:
| 
| The problem is in:
| 
| 'The child MUST sign its key set with at least one of the keys listed'
| 
| In the case of key compromise the zone administrator of a child zone
| might want to resign the zones with a completely new key even
| before the parent has had a change to update their DS record.
| 
| The 'MUST' in the line quoted above indicates that this operational
| procedure is illegal.
| 

But shouldn't this be illegal since it would cause the zone to black-hole 
itself?

The isi.edu KEY is compromised and isi.edu wants to resign its zone
with a new KEY.  Suppose it does resign its zone with this new KEY 
before the DS record is updated at the parent.  This is allowed
under the above wording, but the isi.edu zone MUST not remove the 
compromised KEY and SIGs yet... 

If the isi.zone does removed the compromised KEY/SIGs before the
parent has updated its DS, then isi.edu has just blackholed itself.
Resolvers know that isi.edu is signed because of the (now outdated) DS 
record at the parent and the resolver expects signed data.  The
resolver will get signed data, but the data is signed using the new 
KEY.  The resolver has no reason to trust this new key and should disregard
the data.  (otherwise, what stops an attacker from simply pretending
there is a key compromise anytime its want to forge data for a secure zone?)

I will be very happy if I'm missing something here...  

| 
| On the other hand it must be clear to a resolver that if the DS record
| indicates a child zone is secure. The original sentence:
| 
| '  Insecure delegation MUST NOT have a DS record, the presence of
|    DS record SHOULD be considered a hint that the child might be secure.
|    Resolver MUST only trust KEY records that match a DS record. '
| 
| will allow spoofing of unsecured child zone data. I think if the
| resolver cannot validate the child zone's data using any of the keys
| that the DS records are pointing to, the child zone MUST be
| considered bad. 
| 

This sounds like what I'm saying above so doesn't that imply the
original sentence was really what you wanted:

| I propose the following wording:
| 
|    DS records MUST only appear at secure delegations in the parent zone.
|    The records list the child's keys that SHOULD sign the child's key
|    set.  Insecure delegation MUST NOT have a DS record. Secure delegations 
|    MUST have at least one DS record. 
|    The presence of one or more DS records MUST be considered an indication
|    that the child zone is secure. 
| 
|    Resolvers that are not able to find or verify at least one of the 
|    child's keys pointed to by the DS records, MUST consider the child zone 
|    non-authentic.
| 

Could you replace the second sentence with:

The records list the child's keys and at least one of these keys MUST sign
the child's key set.

Dan

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 8 Aug 2001 21:26:17 +0200 (MEST)

> compromised KEY and SIGs yet...

if my key is compromised, why should someone - by specification - prevent
me from removing it from my zone if I like to? it may be stupid, but it is
really my call.

I'm not saying I would do that (I would probably wait for my parent zone
to put in the new key first), but some people may choose to actually break
their zone rather than have someone spoof it.

	jakob

---

From: Dan Massey <[email-masked]>
Date: Wed, 8 Aug 2001 18:26:11 -0400

On Wednesday, August 08, 2001 at 09:26PM, Jakob Schlyter wrote:
| 
| if my key is compromised, why should someone - by specification - prevent
| me from removing it from my zone if I like to? it may be stupid, but it is
| really my call.
| 
| I'm not saying I would do that (I would probably wait for my parent zone
| to put in the new key first), but some people may choose to actually break
| their zone rather than have someone spoof it.
| 

But how does breaking your zone prevent anyone from spoofing it?  
If it does help prevent spoofing, then I agree you should be allowed 
to do it.  I claim removing the KEY/SIGs  actually makes your zone 
more vulnerable to spoofing, not less vulnerable.

Assume your key has been compromised and your parent is still reporting
this KEY as valid.  Three things can happen when a resolver asks for 
your data:

1) the resolver gets only a non-forged response 
      - remove the KEY/SIGs from your zone and you make any response 
        from the real namesevers invalid.
      - keep the KEY/SIGs and the resolver will still declare the 
        response valid.

2) the resolver gets only a forged response (using the compromised key)
      - remove the KEY/SIGs from your zone and it still does not help 
        since the forged response is signed by a key and the parent 
        declares the key valid.
      - keep the KEY/SIGs and it also does not help and the forged
        response is still declared valid.

3) the resolver gets both a forged and real response
      - remove the KEY/SIGs and you make the real response appear to
        be forged and the forged response will be believed.
      - keep the the KEY/SIGs and you get two conflicting responses,
        both signed by the same KEY and both appearing to be valid.  
        the resolver can't tell which response is right but at least 
        the resolver could realize something is wrong.

So in my view you always lose by removing the KEY/SIGs.  

In general, the compromised key MUST remain in the DNS until the
parent updates its zone to prevent black holes.  It is bad to have
compromised keys in the DNS but creating black holes doesn't help.   
The compromised key remains a threat until the parent's SIG expires. 

Or am I missing something?

Dan

---

From: Edward Lewis <[email-masked]>
Date: Mon, 20 Aug 2001 16:32:27 -0400

There are two arguements here.

>But how does breaking your zone prevent anyone from spoofing it?

There may be value in causing confusion.  If the parent indicates that key
#1 is signing the child, but I can only see key #2, I can conclude that
something is amiss.  In this state, I could try contacting the admin, delay
my current attempt to access data, etc.

>Or am I missing something?

Part of the problem is the definition of "MUST."  I think the text being
offered is mixing protocol definition and operational procedure, a mix
which leads to confusion.

Perhaps I'll try to restate the specification under discussion:

"In a properly secured parent zone, at a delegation point there MUST be a
DS RR set present if the child zone is to be considered secure.  In the
case of an unsecured child zone, there MUST NOT be a DS RR set present.

"The intent of the DS RR set is to list the child zone keys that are
recognized to sign the zone.  The parent signing of this set of data
indicates that the child has indicated that these are the proper zone
key(s).

"For any set of data in the child zone, if there is no SIG RR generated by
one of the recognized keys for an RR set that is supposed to be signed
(<text weakened in advance of an opt-in like proposal>), a resolver could
conclude that something is broken with respect to the child zone.  The
behavior of the resolver at this point is not specificed here.  (Begging
the question: where to we specify the behavior.)"

A specification cannot "MUST" that two entities have the same value for
something.  A specification can suggest this and should indicate what to do
when the entities differ.

To push the limits of sane conversation - because of the special theory of
relativity - it is impossible for two entities to change a value
simultaneously to all observers, ergo, you can't MUST that the set at the
parent agree with the child's set.

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

You fly too often when ... the airport taxi is on speed-dial.

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

---

From: Dan Massey <[email-masked]>
Date: Mon, 20 Aug 2001 19:01:01 -0400

On Monday, August 20, 2001 at 04:32PM, Ed Lewis wrote:
| There are two arguements here.
| 
| At 6:26 PM -0400 8/8/01, Dan Massey wrote:
| >But how does breaking your zone prevent anyone from spoofing it?
| 
| There may be value in causing confusion.  If the parent indicates that key
| #1 is signing the child, but I can only see key #2, I can conclude that
| something is amiss.  In this state, I could try contacting the admin, delay
| my current attempt to access data, etc.
| 

I also initially thought it would be okay to remove the compromised
key, but it turns out to be a very bad idea.  Doing what you suggest 
will either:

  blackhole your zone if you aren't under attack
  make it easier to spoof your data if you are under attack

Consider the example you describe above.  In your example, the parent 
has indicated (via a DS record) that key #1 should be used to sign the 
child zone (or at least the child zone's key set).  In your example,
the child has removed key #1 and is now using key #2 to sign it zone.  
Here is what happens when a resolver tries to get data from the child 
zone.

A resolver knows the zone is secure and is getting data signed by key #2.  
This key #2 is not signed by any trusted entity and differs from the 
expected zone key.  The resolver will ignore this data.  If the resolver 
does not ignore this data, nothing stops me from creating random keys and 
using them to spoof the zone's data.  So the child zone has just blackholed 
itself.

It gets worse if someone is sending spoofed response.  In this case, the 
resolver gets a spoofed response signed by the compromised key #1 and a 
valid response signed by your new key #2.  As before, the resolver will 
drop the response signed by key #2.  The resolver will also believe
the (forged) response signed by key #1.  If you had kept key #1, the 
resolver would have received two different answers that were both signed 
by key #1.  If you had kept key #1, there would be confusion that might 
cause you to "try contacting the admin, delay my current attempt to access 
data, etc."  You create confusion only by keeping key #1.  Removing key #1 
just makes the forged answer look better.

For more general cases, look at the 4 possible scenarios described
in my last message and note that removing key #1 causes you to lose 
everytime. 

| 
| Part of the problem is the definition of "MUST."  I think the text being
| offered is mixing protocol definition and operational procedure, a mix
| which leads to confusion.
| 

I also disagree with this.  The protocol needs a MUST here and this is 
not mixing operation with specification.  There are a number of possible 
operational procedures that let you achieve the requirements and I list 
one possible operational procedure below.

| 
| A specification cannot "MUST" that two entities have the same value for
| something.  A specification can suggest this and should indicate what to do
| when the entities differ.
| 
| To push the limits of sane conversation - because of the special theory of
| relativity - it is impossible for two entities to change a value
| simultaneously to all observers, ergo, you can't MUST that the set at the
| parent agree with the child's set.
| 

There is no requirement for things to be done simultaneously and this
lack of simultaneous changes is one of the big advantages of DS.  Here 
is the operational procedure we are planning to start experimenting with 
in our testbed:

1) create the new KEY, add it to the KEY set, add the SIGs.
2) send the new DS record to the parent
3) wait for parent to update the DS set in the parent zone
4) removed the old KEY/SIGs (after in step 3 parent has updated the DS set).

Note it always meets the specification wording (assuming MUST) and requires no 
simultaneous changes at parent and child.  The consequence of not obeying 
the MUST in the spec wording is that you blackhole the zone and make it 
easier for someone to spoof your data so the MUST belongs in the protocol 
spec.  I agree that the operational procedures like the one described above
belong elsewhere.  

Dan

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Tue, 21 Aug 2001 08:41:16 -0700 (PDT)

>   make it easier to spoof your data if you are under attack

I completely agree. This is a problem in any mechanism where 
parent stores any kind of signatures over child data, but can not
immediately synchronize with the child after child key compromise.

One solution to this could be for the child itself to announce key
compromise into its name servers. The idea is that packet
hijacking
(either removing/redirecting packets from wire, or a man-in-the-middle
attack) is MUCH 
harder (although by no means impossible) than spoofing or introducing
bogus packets.  This way, the resolver (or a cache server) would get both
bogus info signed under the compromised key introduced by the hacker as
well as revocation information signed under the compromised key from the 
legitimate server. By preferring and caching such revocation info, servers
can protect themselves from bogus info.

Thus, the attacker would be successful under this model only for the
first query, even after compromising the key and spoofing replies.

BTW, has there been any discussion on impact of DoS attacks on DNSSec in
general? If someone can even observe DNSSec-enabled query requests
and spoof replies, he can make life miserable
for a resolver/cache...

-ramki

---

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Aug 2001 10:54:01 -0400

I'll try to restate myself.

Under normal conditions, the keys indicated in the parent-held DS RR set
are a superset of the keys is use in the child zone.

Under a normal key change, the keys indicated in the parent-held DS RR set
include a subset of keys in retirement, a subset of keys in current use and
a subset of keys to be used in the future.  (Note that a set may be empty.)

(The two paragraphs above are actually the same, I just put more detail in
the key change to be more explicit.)

Under an emergency condition, things are a bit different.  There are a few
different situations that may arise.

Case 1. The child zone has lost the zone keys. (E.g., disk crash, no backups.)
Case 2. The child zone suspects someone has guessed or seen the private keys.
Case 3. Some one is spoofing data without bothering to guess the key.

In case 1, the child needs to create new zone keys, perhaps retype in zone
data, and fire the administrator.  In the moment of time that the child
signs the new zone and is trying to contact the parent, the DS RR set of
keys and child set of keys do not agree.  Eventually that will be fixed,
but in the mean time, the sets are not in agreement.

In case 2, all bets are off.  Because DNS does not have a means to revoke
data, nor does DNSSEC add any revocation service, as long as the previous
DS RR set is in a cache somewhere, an attacker can continue to spoof data.
IMHO, it would be wise if the child simply dumped the bad keys and
regenerated new ones and immediately started to use the new keys, then
contact the parent.  Of course this means that no resolver will trust the
child at this moment in time - but during an emergency, its not always
possible to maintance a state of grace.

In case 3, the appearance to the resolver is the same as case 1 with the
exception that this is a persistent error (no eventual reconcilliation).

In case 1, there is a temporary blackholing of the child zone.  In case 3,
there is a conflict between persistently failing data and perhaps some of
the right data getting through.  In case 2, the attacker is able to
convince some resolvers that it is sending the right data - until the old
DS RR set vanishes.

I suppose yet another exercise is:

Case 1: Query, followed by one unvalidated response.
Case 2a: Query, followed by multiple validated responses
Case 2b: same as in case 3...
Case 3: Query, followed by an unvalidated response and a valid response.

In case 1, the resolver should accept the lone response.  In case 2a
(pre-discovery), the resolver should pick the right one.  In case 2b, the
resolver should pick the invalid one.  In case 3, the resolver should pick
the valid one.  (Notice the inconsistency.)  There's no clear "right thing
to do."

Perhaps if in case 2, the new keys aren't used, then case 2b never arises.
But you are still under a potentially successful attack before falling into
case 1.

....

Looking at this, I can't justify the use of a "MUST" when linking the set
of keys indicated by the DS RR set and the keys used to sign the child
zone.  It is obvious that in normal situations the DS RR set is supposed to
indicate the child's zone keys.  But given case 1 of the emergency, the
child cannot be in compliance with this MUST.  BTW, what is the penalty for
failing to comply with the MUST?  A US$500 fine? ;)

My problem with the MUST is that I can't see it as a testable feature of
the software implementing this record.  I understand the intent, but I
think the use of MUST is wrong.

....

My point here is: The MUST requiring the DS RR set to have the child zone
keys is misplaced and an untestable requirement.  Emergency processing in
DNS is a mess, and DNSSEC can't *completely* clean this up.

---

From: Dan Massey <[email-masked]>
Date: Tue, 21 Aug 2001 12:23:57 -0400

On Tuesday, August 21, 2001 at 10:54AM, Ed Lewis wrote:
| 
| My point here is: The MUST requiring the DS RR set to have the child zone
| keys is misplaced and an untestable requirement.  Emergency processing in
| DNS is a mess, and DNSSEC can't *completely* clean this up.
| 

There is no magical untestable requirement being added here and no attempt
to clean up anything after emergencies.  The use of the MUST simply reflects 
what is actually required to make the zone accessible to a resolver.  The 
text says:  

 DS records MUST only appear at secure delegations in the parent zone.
 The records list the child's keys and at least one of these keys MUST 
 sign the child's key set.  Insecure delegation MUST NOT have a DS record. 
 Secure delegations MUST have at least one DS record.  The presence of one 
 or more DS records MUST be considered an indication that the child zone 
 is secure.

I strongly object to replacing any of the MUSTs with SHOULD.  If you fail 
to follow any of these MUSTs, then there is a real penalty.  The penalty 
is that you blackhole your zone and make it easier for others to spoof 
you.  Failing to follow the above MUSTs defeats the purpose of DNS 
since your data becomes inaccessilbe and defeats the purpose of DNSSEC 
since it becomes easier to spoof data.  Adding a SHOULD instead of a MUST 
implies that there are some rare scenarios where it would be okay to 
deviate from the above text.  There are no such scenarios.  

I could live with the following text that removes the MUST but conveys 
the same basic instructions to zones:

 DS records MUST only appear at secure delegations in the parent zone.
 The records list the child's keys.  If none of these keys are used sign 
 the child's key set, then the child zone data is not accessible to any 
 resolvers and the child zone is more vulnerable to spoofing attacks.  
 Insecure delegation MUST NOT have a DS record.  Secure delegations MUST 
 have at least one DS record.  The presence of one or more DS records MUST 
 be considered an indication that the child zone is secure.

Dan

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 27 Aug 2001 19:29:37 -0400

How about a more comprehensive approach: a cache-invalidation protocol
extension, like NOTIFY except generalized to all record types, including the
DNSSEC record types? Such an extension might also be able to at last deal
with the "tiny TTLs for load balancing and/or failover" syndrome as well
(since client implementors aren't exactly racing with each other to get
SRV support added to their codebases).

- Kevin

---

From: Roy Arends <[email-masked]>
Date: Tue, 28 Aug 2001 03:01:56 +0200 (CEST)

> SRV support added to their codebases).

And how do you discriminate between notifies ? i.e. which one do you
accept, and which will be ignored ? Do you "broadcast" a notify or send
one to each individual cache (providing that there is such a list).

Regards,

Roy Arends
Nominum
-------------
0-14-023750-X dcrpt ths 43.0D.01 01.05.0C 84.18.03 8A.13.04 2D.0B.0A

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 27 Aug 2001 22:45:27 -0400

> one to each individual cache (providing that there is such a list).

As a client, you accept a NOTIFY from whomever has the same credentials as the
answer you originally accepted. You could use source address as "credentials", if
you trust it, or some form of crypto (e.g. TSIG), or both.

As an answerer, by default you'd send the NOTIFY to each cache that asked for it,
when the data changes. The NOTIFYs should cascade backwards through nth-level
caches and/or forwarders.

Yes, this requires keeping state. But the saving grace is that older entries can
be purged -- there's no point in keeping state about a client after the point at
which the client should have expired the entry. In resource-emergency situations,
answerers could fall back to tiny TTLs (no worse than the current situation)
until such time as sufficient resources can be reclaimed to start storing state
again.

Maybe NOTIFY could even be extended so as to allow answer data to be included in
the packet, subject to crypto-authentication. This would help reduce the number
of transactions to a minimum.

I think such an extension, in a finished form, could restore some much-needed
balance between the need for dynamism, e.g. load-balancing, failover, quick key
revocation, on the one hand, and the need, on the other, to conserve nameserver
and/or network resources. Currently I think that balance is way out of whack.

- Kevin

P.S. I have other ulterior motives for allowing NOTIFY packets to be signed. I
eventually want to enable slave auto-configuration via the receipt of NOTIFY
packets, and obviously this requires a degree of trust as to their authenticity.

---

From: Robert Elz <[email-masked]>
Date: Tue, 28 Aug 2001 13:31:51 +0700

Date:        Mon, 27 Aug 2001 22:45:27 -0400
    From:        Kevin Darcy <[email-masked]>
    Message-ID:  <[email-masked]>

  | As a client, you accept a NOTIFY from whomever has the same credentials
  | as the answer you originally accepted.

No, you can't do that unless the credentials are verifiable.

  | You could use source address as "credentials", if you trust it,

No, you can't - there's a big difference between receiving an answer to
a question you sent before, where getting it fro the address you expect
to get it from isn't proof it came from there, but isn't trivial to fake
either (at the very least it needs packet snooping to be able to spot the
query and send the bogus data at just the right time).

Accepting a random message based just on the source address would be lunacy.

  | As an answerer, by default you'd send the NOTIFY to each cache that
  | asked for it, when the data changes.

That's way too much state to keep - the only way a server could ever
survive would be to force all the TTLs to such low values that caching
would effectively be disabled everywhere.   Busy servers are probably doing
upwards of 100K queries / second these days (not so busy ones do tens of
thousands).   Retaining the IP address of the resolver (16 bytes for IPv6...)
the expiry time issued (time reply was sent + TTL), and a pointer to the
RR in question (or from it and a linked list to the next) and you're at 24
bytes/query (and I probably neglected stuff you need).   That's 2.4MB
a second.   Give a 300 second (5 minute) TTL, and you have a state database
that's 7GB big.   No thanks (not to forcing the TTLs to be that low, nor
to requiring that quantity of state).

  | I think such an extension, in a finished form, could restore some
  | much-needed balance between the need for dynamism,

There should be no such need in the DNS.   All the nonsense that is requiring
it should be being done other ways.   While it can be done without perverting
the DNS design, then there's not much point objecting.  But deliberately
changing things so that stuff which was never intended to work can be made to
work is definitely not the direction to head.

  | P.S. I have other ulterior motives for allowing NOTIFY packets to be signed.
  | I eventually want to enable slave auto-configuration via the receipt of
  | NOTIFY packets, and obviously this requires a degree of trust as to
  | their authenticity.

Like much which seems obvious, this is false.   NOTIFY now is just a hint that
you might want to do something (zone transfer currently).  That's all it needs
to be for your proposal - when the secondary gets an unexpected NOTIFY, it
can go check the primary, using whatever authentication it needs, determine
if it is supposed to be configured as secondary for the zone, and if so,
configure itself.   If the NOTIFY turns out to be bogus, then you've wasted
an authenticated query/response.   While someone could bombard you with
bogus NOTIFY packets, and consume resources, whether the resources are
consumed doing an extra query, or whether they're consumed doing SIG validation
on the NOTIFY packets doesn't seem like a difference worth arguing about.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 28 Aug 2001 15:13:02 +0700

In my previous message, I think I made an order of magnitude error in
my mental arithmetic, but that doesn't matter, the answer is still too
big, and the TTL too small...

kre

---

From: Edward Lewis <[email-masked]>
Date: Tue, 28 Aug 2001 10:50:16 -0400

In summary: please stop this madness! (;))

At 10:45 PM -0400 8/27/01, Kevin Darcy wrote:
>answer you originally accepted. You could use source address as
>"credentials", >if you trust it, or some form of crypto (e.g. TSIG), or
>both.

Consider the most popular website in existence.  (Off hand, I don't
know/care which it is, but whatever it is...)  How many caches would have
it's A record?  A lot!  (I won't feign numbers.)

That means the authoritative name servers each need, roughly, a lot of
TSIGs.  If you go for the IP address as credential option - we'll let's not
even try to argue that from a security perspective (now that Windows will
let you change the IP header bits in the latest OS release).

>As an answerer, by default you'd send the NOTIFY to each cache that asked for
>it, when the data changes. The NOTIFYs should cascade backwards through
>nth-level caches and/or forwarders.

A new DDOS vulnerability - just get a million drones to ask for an address
from a server.  The server then has to keep a list of everywhere the data
went.

>Yes, this requires keeping state. But the saving grace is that older entries
>can be purged -- there's no point in keeping state about a client after the
>point at which the client should have expired the entry. In resource-emergency
>situations, answerers could fall back to tiny TTLs (no worse than the
>current >situation) until such time as sufficient resources can be
>reclaimed to start >storing state again.

This assumes the remote caches (strictly) enforce the TTL's.  Otherwise a
should-have-been-revoked and should-have-been-retired-by-TTL record might
still hang around because the record was assumed to have been retired.
('Course, caches might ignore the NOTIFY too.)

>and/or network resources. Currently I think that balance is way out of whack.

I admire the desire, but remember that we are dealing with DNS, circa RFC
1035.  Such an overhaul would be more work than the original system - and
makeing this work in a backwards compatible fashion would be harder than
starting from scratch (no data to back this up).

>packets, and obviously this requires a degree of trust as to their

I believe (I haven't checked) that NOTIFY's are covered by TSIG in BIND if
the "server" statement is the configuration file.  (Not too pick on a
particular implementation in this protocol discussion list.)

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 28 Aug 2001 23:56:25 -0400

Edward Lewis wrote:

> TSIGs.

Perhaps "the most popular website in existence" would use something more scalable
than TSIG to establish the trustworthiness of every DNS-resolution of its name, if
such a thing were desired and/or even possible.

> If you go for the IP address as credential option - we'll let's not

Pardon my naivete, but why is it any more dangerous to accept a NOTIFY based on
IP address that says "hey, this data has changed!" than it is to accept the answer
in the first place from that IP address? (I think kre tried to explain this, but
I had trouble parsing that particular sentence). Because the hacker has more time
in which to cook up a bogus packet? Is that it?

> from a server.  The server then has to keep a list of everywhere the data

No, it doesn't *have* to keep a list that long. It could choose to limit the
amount of state it keeps for any given RRset and/or from any given client and/or
the total amount of state it keeps *period*. Let's not assume the stupidest
possible implementation of such an extension. I've always interpreted
RFC 1034/1035's admonition to "bound the amount of work done" to apply to
maintenance of metadata as well as plain data, and this would be no exception.

In any case, if a hacker has a million drones at his or her disposal, I think
there is plenty of havoc they can wreak with or without this extension.

> ('Course, caches might ignore the NOTIFY too.)

There's only so much one can do in the face of non-compliance. At least if you
send a revocation downstream you give an opportunity for revocation to actually
occur. If there's no mechanism for revocation at all, however, then you just have
to buckle up and live with the potential for being spoofed for the lifetime of the
compromised key.

> starting from scratch (no data to back this up).

Actually, we're not dealing with DNS, circa RFC 1035; we're dealing with
post-EDNS0 DNS. This special "NOTIFY callback" or whatever you want to call it
could be put under OPTION control (could you let me know if the answer to this
question changes? roger, will do!) without freaking out any backlevel clients or
servers.

> particular implementation in this protocol discussion list.)

Well, as a minor technical nit, the NOTIFY RFC forbids anything in the Additional
Section (although it invites a "future revision" to lift the prohibition), so
officially TSIG-signed NOTIFYs remain illegal.

- Kevin

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 29 Aug 2001 00:21:51 -0400

> No, you can't do that unless the credentials are verifiable.

If one requires verification, sure.

> query and send the bogus data at just the right time).

Sorry, parse error. Which two things are you contrasting here?

> Accepting a random message based just on the source address would be lunacy.

It wouldn't be lunacy if something like IPSEC were in force, or for casual use
where perhaps the local security policy deems source-address-based authentication
to be sufficient. I'm not saying source-address-based authentication is to be
recommended in the general case. If it helps, forget I even included source address
as a possible form of credentials. Instead, assume only crypto.

> would effectively be disabled everywhere.

And how is this different from domain owners reducing the TTLs to ridiculously low
values, which they are doing today? I don't see that this proposal is any worse,
and it could make things better.

> Busy servers are probably doing
> that's 7GB big.   No thanks (not to forcing the TTLs to be that low, norto
> requiring that quantity of state).

First of all, note that I said "to each cache that asked for it". Not all caches
would necessarily ask for this.

Secondly, not all data in the DNS is so volatile. It could be left up to the
discretion of the domain owners which RRsets would be marked as NOTIFY-able, i.e.
ones for which load-balancing was desired, or failover, or (as prompted this
thread) keys for which fast revocation might be desired.

Thirdly, your calculations do not reflect the fact that the number of queries/sec
would probably *decrease* if this mechanism were in effect, assuming that the
domain owners follow suit and start restoring their TTLs  to reasonable values.
That's largely (in addition to speeding up change-propagation) the whole point of
the exercise. To reduce the query-transaction rate. Would one rather keep approx.
24 bytes of state data around or would one rather have that client make that same
query 3 or 4 or 5 times as often, based on a tiny TTL reflecting the mere
possibility that the data has changed because of node failure or load shift or key
revocation or whatever? I expect the answer is usually: I'd rather keep the state
and reduce my query rate since memory (who said all of this state data would even
need to be held in RAM?) is cheaper in the grand scheme of things than network
bandwidth/infrastructure.

Fourthly, in high-volume situations as you describe, it might be possible to
offload the NOTIFY-sending function onto another box.

Fifthly, under certain circumstances the server may be able to play prediction
games, e.g. if a particular name has historically been queried only infrequently by
downstream clients ("infrequency" being judged relative to the TTL, of course),
then maybe don't bother honoring NOTIFY-ability for it, since it'll probably just
be a waste to store the state anyway.

Lastly, any given server has the option of declining any client's request for a
NOTIFY-upon-change, for any reason whatsoever. The presumption is that all of this
will be under OPTION control. So this extension simply gives servers another item
in their toolkit for optimizing their performance, one which they can choose to use
or not use on an RRset-by-RRset or even a query-by-query basis, depending on policy
and local conditions (e.g. which is closer to capacity at this very moment, my
memory usage or the packet traffic on my primary network interface? which do I need
to conserve more?)

> it should be being done other ways.

Well, this gets to the crux of the matter, now doesn't it? DNS was undoubtedly
never intended to provide dynamic-load-balancing, generalized failover (outside of
MX records of course) or key-revocation functions. I can certainly empathize with
not wanting to accommodate "perversions" of DNS. But let's face reality. DNS is
being used for dynamic-load-balancing and non-MX-failover, and not via the
"officially-approved" SRV method either (which is also perceived as lacking
sufficient dynamism, not to mention requiring non-trivial rewrites of the
DNS lookup code in every piece of client software). Accommodation is starting to
look like the lesser of two evils, the greater evil being tiny TTLs and the
consequent ever-increasing query rates and inefficiency.

> While it can be done without perverting

To distill things ever further, DoS-prevention requires that authentication occur
*sometime* before the AXFR is requested. In my concept of a streamlined automatic
slave-creation sequence, there would be no extra step for "determin[ing] if it is
supposed to be configured as secondary for the zone"; this would be determined in
an implementation-specific way, which would accommodate both stealth slaves as well
as registered ones. It would just be a NOTIFY followed by an AXFR. In that case,
signing the NOTIFY would be obligatory. Possibly it could be streamlined even more
by having the master send unsolicited-yet-signed AXFRs to all of its intended
slaves every time a new zone is configured. The recipient could always break the
TCP connection if the AXFR is being sent to it in error.

But, automatic slave-creation is getting a little far afield from generalized
NOTIFY anyway...

- Kevin

---

From: Edward Lewis <[email-masked]>
Date: Wed, 29 Aug 2001 11:32:35 -0400

At 11:56 PM -0400 8/28/01, Kevin Darcy wrote:
>in the first place from that IP address? (I think kre tried to explain this,
>but I had trouble parsing that particular sentence). Because the hacker has
>more time in which to cook up a bogus packet? Is that it?

Since a zone transfer would require a TCP connection, if an attacker got to
a machine between the primary and secondary, the attacker could fudge the
NOTIFY to make the secondary request a zone transfer - which the attacker
could provide.  That's why an IP-based NOTIFY is more "dangerous" than a
key-based NOTIFY.

As far as the "is it any more ... than ..." question, I don't understand
what you are asking.  I don't understand what "the answer" is that I would
"accept" from "that IP address."  I understand the questioning the
trustworthyness of the unsigned NOTIFY, but I don't know to what you are
comparing that.

PS - Also, given all the recent problems of putting IP addresses in
applications, substituting secrets instead of IP's reduces the problem a
bit.  Not that we can erase all IP addresses from DNS. ;)

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 29 Aug 2001 16:32:32 -0400

> could provide.  That's why an IP-based NOTIFY is more "dangerous" than a

Agreed. Crypto-authenticated NOTIFY is, all other things being equal, obviously
more secure than source-address-authenticated NOTIFY. But that wasn't what I was
really getting at.

> trustworthyness of the unsigned NOTIFY, but I don't know to what you are

Apparently I haven't made myself very clear. If NOTIFY were generalized to other
types of RRs and transactions besides SOA refresh/serial-number-check, then
under the "generalized NOTIFY" concept, conceivably any answer that is given to
a client could (assuming the client requested it and the server agreed to
provide it) result in a subsequent NOTIFY if the data changed. My question is:
if the original answer were authenticated by source-address alone, why is it
inherently any riskier than that to authenticate the subsequent NOTIFY by the
same criterion?

- Kevin

---

From: [email-masked]
Date: Thu, 30 Aug 2001 12:28:47 +1000

> inherently any riskier than that to authenticate the subsequent NOTIFY by the

	Because the first is the result of a pull operation, with
	a small window of vulnerability to spoofed respones.

	The second is the result of a push operation with a infinitly
	wide window to spoofed messages along with a flood of
	spoofed respones to the subsequent query.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 29 Aug 2001 20:13:15 -0700

quite aside from the other perfectly valid reasons mentioned here as to why
generalized notify is dangerous from a security point of view, there's the
question of scale.  it's just not realistic to either (a) spam the universe
every time an RR changes, or (b) remember who you've sent an answer to in
case you learn that an RRset has changed before its TTL has expired.  in fact
if you combine concerns (a) and (b) from above you can easily see that even
the simple act of transmitting a notify due only to (b) actually qualifies as
(a) from the recipients' point of view since they may never use that cached
RRset again or indeed they may not even have cached it.

people who need their RRsets to change often have to use short TTL's.  i do
not regret specifying NOTIFY with the text...

   [RFC1996 1.2.] ...  This specification only allows
   slaves to be notified of SOA RR changes, but the architechture of
   NOTIFY is intended to be extensible to other RR types.

...but i am mindful of the comments made during the preparation of RFC1996
as to NOTIFY's complete lack of scalability to any other imaginable use.

---

From: Robert Elz <[email-masked]>
Date: Thu, 30 Aug 2001 13:12:58 +0700

Date:        Wed, 29 Aug 2001 00:21:51 -0400
    From:        Kevin Darcy <[email-masked]>
    Message-ID:  <[email-masked]>

  | And how is this different from domain owners reducing the TTLs
  | to ridiculously low values, which they are doing today?

Only those domains which actually need this do that - and if we (generically
not the DNS community) come up with a better way (perhaps using anycast,
or something) for these purposes, then even that can be stopped.
The DNS neither is, nor should be, a generic tool for every purpose
anyone can imagine, however easily it may seem to be to tweak this or
that to make it seem to work.   The more we can do to prevent many of
these hacks, the better.

  | First of all, note that I said "to each cache that asked for it".
  | Not all caches would necessarily ask for this.

In that case you get no benefit at all.   If you're doing load balancing
or similar, the idea is to make the old data go away quickly - that means
a small TTL, or could be done by revocation (notify).  But you need it to
go away from everywhere, not just a few random caches that happened to be
kind to you - so with that caveat, you'd have to keep the low TTLs for
everyone who didn't ask, and the state for everyone who did.  Useless.

What's more, a cache has no way to tell when it should ask, and when it
shouldn't - it doesn't know what RRs are subject of load balancing or
similar - so its only option would be to always ask.   Given that, and the
above, the obvious solution is to forget the "asked for it" stuff, and
simply apply the technique to every query - then it doesn't scale - though
allowing it to be specified for just some RRs helps.  Not enough unfortunately,
as the very reason you want to do this is because lots of people ask for
those RRs - that's why you want to add load balancing in the first place.
ie: it isn't some rarely used RR that would require keeping state of
accesses, it is the ones used most often.

  | Thirdly, your calculations do not reflect the fact that the number
  | of queries/sec would probably *decrease* if this mechanism were in effect,

Perhaps, but not by much, certainly not enough to account for just the
natural growth of the net.  If the data isn't changing often enough that
the notify/re-query cycle isn't happening much, then the TTL could just
be larger to start with.

And none of this does anything to affect the use of small TTLs by people
who aren't changing the data, but just want to get a count on how many times
it is referenced, and find that the cache in the way lowers their counts...

  | I expect the answer is usually: I'd rather keep the state and reduce
  | my query rate since memory (who said all of this state data would even
  | need to be held in RAM?) is cheaper in the grand scheme of things than
  | network bandwidth/infrastructure.

I think you'll find that either there's another way to solve the problem
(most traditional "want to change now but TTL is big" problems can be
handled just by duplicating the server for a while), or the net traffic
rate doesn't actually decrease at all - if you're really dynamically
changing RRs at a high rate (such that you currently need a small TTL to
get the benefit) then you'd be sending NOTIFY and getting new queries
at a similar rate.   Much extra cost, almost no benefit.

  | Fourthly, in high-volume situations as you describe, it might be possible to
  | offload the NOTIFY-sending function onto another box.

That changes nothing at all.

  | Fifthly, under certain circumstances the server may be able to play
  | prediction games,

even more state to keep... and for 0 benefit - the names that no-one queries
don't accumulate much state, and hence wouldn't cost much.  It is the ones
that lots of people send queries to that accumulate the state, and which are
also the very ones that you want this to work for.   The rest doesn't matter.

  | Lastly, any given server has the option of declining any client's request
  | for a NOTIFY-upon-change, for any reason whatsoever.

But as the only rationale for any of this is to benefit the server (less
queries need to be sent to it) this basically means that you're discarding
the benefit.  Hence low TTLs would need to remain, because no-one could
be sure that the server will actually do what it should.

  | So this extension simply gives servers another item
  | in their toolkit for optimizing their performance,

And one that only works if caches are all upgraded to know about it.
SOA notify works because there's only a few systems that we need to
care about (in any particular case) and I can easily discover whether
or not they will accept a notify (and perhaps config the SOA parameters
accordingly, using refresh as a backup for notify failure, rather than
as a primary mechanism).   You can't do that in general.   You will never
be able to reply upon any particular cache doing anything with a notify
you send, so you have to guard against that in some other way.  ie: you
have to have the ttl remain low.  Gain 0, cost huge.

If you really think this through, including what happens to intermediate
caches that asked for notify, but hand out answers to others who don't,
etc, then I think you'll begin to see that this simply can't work.

  | Accommodation is starting to look like the lesser of two evils,

not to me.

  | In my concept of a streamlined automatic slave-creation sequence, there
  | would be no extra step for "determin[ing] if it is
  | supposed to be configured as secondary for the zone";

And this happens so frequently that saving that extra step is worthwhile???
Really???

kre

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 30 Aug 2001 18:18:44 -0400

>         spoofed respones to the subsequent query.

The window isn't "infinitely" wide, since, just as the server has no reason to
send a NOTIFY after the calculated expiration of the entry on the client, the
client has no reason to pay heed to a NOTIFY for an RRset which is not in cache.
It should just assume those are spoofed and ignore them.

If this is really an issue, folks who don't want to go all the way to crypto, but
who are paranoid about trusting source addresses alone, could use, in addition,
some intermediate-strength form of authentication, e.g. the original query
provides a token consisting of, say, 32 bits of entropy, the response provides an
independent token, and the NOTIFY would only be accepted if it bore a token
consisting of an XOR of the two. This would be relatively hard to exploit, since
it would require access to both the original query and the response. If a hacker
has access to both of those, and the ability to spoof the server's address, then
all bets are pretty much off anyway...

- Kevin

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 30 Aug 2001 23:55:05 -0400

You make some good points here, but I'm not sure I'm quite willing to abandon the
idea. A further refinement might be: for the same answer, give *different* TTLs,
depending on whether "generalized NOTIFY" is in effect or not. So backlevel caches,
or caches that for whatever reason (e.g. a firewall in the way) choose not to
request NOTIFY, get the smaller TTLs, and this is no different that what we have
today. For caches that are willing and able to participate in the new regime, they
request NOTIFY, get a "preferred", larger TTL and can potentially reap the benefits
of a reduced query rate. There would thus be an incentive for caches to use
generalized NOTIFY, but in cases where they don't, things would just degenerate
into what we have now.

I think this addresses the main thrust of your concerns, i.e. that one of two
situations would occur, either a) state would need to be kept for *everybody*,
which would only be possible by artificially reducing TTLs, thus defeating the
whole purpose or b) the domain owners would never raise the TTLs because they would
never get to a point of trusting that their changes would propagate quickly if they
did so.

I'll also answer some of the other miscellaneous points...

Robert Elz wrote:

> anyone can imagine, however easily it may seem to be to tweak this orthat to make
> it seem to work.

I think timely and efficient name-to-address resolution falls squarely within the
mandate of DNS. The trouble is, small TTLs sacrifice efficiency for timeliness.
It's become an either/or struggle. I'm just trying to find a way to get the best of
both worlds.

> accesses, it is the ones used most often.

See above. Caches would have an incentive to request NOTIFY. But there might be
extenuating circumstances under which they might not request it. There shouldn't be
any all-or-nothing mandate here. Caches should have some latitude as to whether and
how much they use the extension, if at all.

> the notify/re-query cycle isn't happening much, then the TTL could just

a) sometimes customers want failover but not necessarily load balancing. In these
cases, an RRset may change infrequently, yet the TTL may be low so that when it
does change, the change will be visible quickly. Generalized NOTIFY could be a big
win here. Admittedly, the savings might not be as dramatic for truly
*volatile* data that is actually changing all of the time, but then again, not much
state is going to be necessary for such volatile data, since once you NOTIFY, you
don't need to keep the state around any more. Also, remember that this thread
sprouted from the question of how to handle key revocation. That's another
situation in which the data wouldn't change very often, but when it does, you want
the change to propagate quickly. That's why I thought generalized NOTIFY might be a
good fit for that requirement.

b) it wouldn't have to be a "notify/re-query cycle". It is sufficient that the
recipient cache purge the NOTIFYed cache entry, or simply mark it as invalid. It
can wait for one of its downstream clients to query the data again (if ever) before
re-querying it.

> it is referenced, and find that the cache in the way lowers their counts...

I consider that DNS abuse. If there is a legitimate need for such statistics, maybe
a "report query counts" extension could be added to DNS, or the idea of a
nameserver MIB could be resurrected...

> That changes nothing at all.

Strictly at a protocol level, you are correct -- it changes nothing. But it might
make the storage of the state-data more efficient and manageable. The main
objection here, after all, as I understand it, is not that the protocol can't
handle this extension, only that the benefits of implementing/using it would be
more than offset by the (state-data management) costs of doing so.

> And this happens so frequently that saving that extra step is worthwhile???

Yes, nameservers get configured as slaves quite frequently.

Why do you think the extra "find out from the master whether I should really be a
slave" step is necessary, by the way? Particularly in the case of a stealth slave,
I don't see that it accomplishes anything useful at all.

- Kevin

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 30 Aug 2001 23:52:07 -0400

Paul A Vixie wrote:

> case you learn that an RRset has changed before its TTL has expired.

I've already gone over most of this ground with kre. Highlights: a) only clients
that ask for this would get it (non-caching resolvers, for instance, would have
no reason to ask), b) the administrator could limit the
clients/address-ranges/keys for which the NOTIFY service was offered, as well as
perhaps a global limitation on the total amount of state data to be stored,
c) the state information wouldn't grow without bound because old entries can be
purged, d) in resource emergencies, the server could decline to honor
*any* NOTIFY-callback requests until resources free back up again.

> in fact

Again, it's up to the client to ask for the NOTIFY-callback service in the first
place. (I assume you're familiar with EDNS0 OPTIONs? :-) Then the server chooses
whether or not to honor that request. Non-caching resolvers simply don't play in
this space. It's primarily a server-to-server (that is to say, primarily an
authoritative-server-to-cache and cache-to-cache) extension.

> as to NOTIFY's complete lack of scalability to any other imaginable use.

If formulated reasonably, it can be as scalable as the implementors and/or
administrators wish to make it. It's only in the straw-man "remember everyone
who asked this, unconditionally, for all eternity" formulation that it is
inherently unscalable.

- Kevin