Subject: Re: WG Last Call: DNSSEC bis documents

From: Rob Austein <[email-masked]>
Date: Tue, 01 Jun 2004 15:15:19 -0400

Having attempted to keep an open mind while all the interesting NSEC2
(etc) debate has raged, I will nonetheless note that today is the last
day of the WGLC, so here's my opinion, for whatever it's worth:

Summary: Ship it.

Disclaimers: I'm one of the DNSSECbis editors, so I have to recuse on
whether the current documents adaquately express the current protocol.
Due to my day job, I also have some interest in getting BIND 9.3.0 out
the door, and thus find last minute proposals for semantic changes
somewhat disturbing, particularly given that the January 2004 WGLC
concluded that the protocol semantics were cooked and that it was just
the documents expressing those protocol semantics that still needed
work.  None of this is the WG's problem, just bias disclosure.

Rationale for why I think we should ship DNSSECbis as it stands:

- I believe that the protocol is reasonable as an attempt to address
  the stated design goals (see draft-ietf-dnsext-dns-threats-07 and
  the earlier source material it references).

- I, personally, wearing my just-another-bozo-on-this-bus hat, do not
  believe that the NSEC enumeration threat is worth further delay at
  this point, for two reasons: avoiding it wasn't a design goal, and
  I, personally, don't believe that the information leak in question
  can really be controlled in any case, given the combination of
  dictionary attacks, address walking, web crawling, and so forth.

- I do understand that some view zone walking as a serious problem,
  and would not be adverse to further work that attempts to find a way
  to avoid it, but will note that this would be design goal change and
  might have nontrivial implications that we don't yet understand.

- Part of my reason for wanting to ship now is that I have learned,
  the hard way, that DNSSEC is (necessarily, due to backward
  compatability issues) a very complex beast whose semantics we aren't
  smart enough to change quickly (at least, I know that -I'm- not that
  smart -- whether others here really are that smart or are just
  kidding themselves is a personal matter between any such people and
  their respective rabbis, none of my business).

- As one of the people who was originally muttering about perhaps
  adding a version number in the NSEC RR, I should state that over the
  weekend I came to the same conclusion as Paul Vixie did, namely,
  that another typecode roll would probably be the best way to handle
  an incompatable change (whether to NSEC2 or to something else).

- To the extent that DNSSECbis as currently specified might be useful
  to anybody, it would be a disservice to those users to delay it (yet
  again) while we hack new semantics.

- At the end of the day, I'm left asking myself a simple question: is
  DNSSECbis cooked enough that it's better than what the users have
  now?  I think that it is, so I think we should ship it.

Finally, a recommendation: If I were on the IESG and I were to receive
a request for advancement of the DNSSECbis docs, I would find it very
helpful to receive, as part of the write-up, several paragraphs
explaining the discussion which the WG has already had on this topic,
since otherwise I would feel duty-bound to ask the WG about it.  This
is a sufficiently complex topic and has gone on at sufficient length
that it would not be reasonable to expect the entire IESG to follow
the debate (not if we also expect them to get anything else done,
anyway).  So we need to help.  That's our chairs' job, but they may
need our help, in which case I expect that they will ask us for it.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Tue, 1 Jun 2004 15:30:43 -0400

>   their respective rabbis, none of my business).

To wit: after talking on the phone with someone about my earlier 
message on NSEC2 (not a linear growth, but a small constant bump), 
the question of all the new hash names was still there.  I.e., do we 
have to provide auth denial for the names created as part of the 
hash?  What if there's a name clash?

Not to discuss that - but to illustrate - there's still a lot to consider.

>   an incompatable change (whether to NSEC2 or to something else).

Again - there's a lot more needed on this.  What is the impact on the 
design of the applications "above" DNS?  I don't think we've 
adequately discussed and presented this to applications developers.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Even the voices inside my head are refusing to talk to me anymore.

---

From: Rob Austein <[email-masked]>
Date: Tue, 01 Jun 2004 16:01:33 -0400

> adequately discussed and presented this to applications developers.

I'm reasonably confident that a complete type code roll would simply
revert any DNSSECbis-using applications back into the universe we have
today in a relatively clean way.

A partial type code roll might be more, um, "interesting".

---

From: [email-masked] (Geoffrey Sisson)
Date: Wed, 2 Jun 2004 00:48:45 +0100 (BST)

> dictionary attacks, address walking, web crawling, and so forth.

I hope that, if nothing else, one key point isn't entirely lost: my
concerns about NSEC RRs are not limited to information leakage, but
also to the potential resource implications of abuse.  Do TLDs really
want to have to provision substantial additional capacity just to serve
the data mining "community"?  As Jay mentioned, it's not inconceivable
that were we to deploy DNSSECbis, well over half of all DNS queries
might be associated with NSEC RR traversal activity.  These of course
needn't be explicit NSEC RR queries but could be fabricated queries for
non-existant domains.  [As an aside: this activity should be measurable
if not preventable.  Currently we see queries which result in NXDOMAIN
responses at a rather steady rate of ~ 6% of total queries; the extent
to which this proportion shifted with DNSSEC deployment could serve as
a metric of NSEC RR abuse.]

I believe that NSEC RR traversal will be *so* much more attractive than
any other form of information gathering that it will become pervasive.
It's lossless and simple.  Implementation-based anti-abuse mechanisms
may reduce the simplicity but will not, without dubious guile, reduce
the losslessness.  Tools will be designed which will take advantage of
parallelism and a virtually inexhaustible supply of unsecured resolvers
to accelerate traversal and evade anti-abuse strategies.  The only way
I see to mitigate this is to make the same information available via
less expensive facilities, e.g. unrestricted FTP/HTTP access.  This may
be an option for some operators of nameservers with large zones but,
unfortunately, it's not an option for us.

This isn't to suggest that something like NSEC2 will be a magic bullet
against abuse.  Users would no doubt employ NSEC2 RR elaboration
combined with cryptographic dictionary attacks to harvest data.  But
this is harder and lossier, and I believe will consequently prove to be
much less attractive, especially in comparison to other data gathering
techniques.

Perhaps this all sounds overwrought or FUD-ish; however one of the
depressing entertainments of working for a ccTLD registry has been
observing the resourcefulness and tenacity of abusers, who, year after
year, becomes progressively more sophisticated.

I appreciate that this message comes late in the day.  I regret that
we've not shared our operational experiences prior to now.  And it is
no doubt extremely frustrating to those who have poured a lot of effort
into DNSSEC and DNSSECbis to hear it only as the current drafts go to
WGLC.

>                     DNSSEC is (necessarily, due to backward
>   smart enough to change quickly

Yes, I think we have no illusions about this . . .

Regards

Geoff

---

From: Paul Vixie <[email-masked]>
Date: Wed, 02 Jun 2004 06:31:50 +0000

> ...

I agree.  Unless the servers also offer the zone by FTP and AXFR, that is.

(Ooops, I think my skirt is showing.)

> It's lossless and simple.

It's not lossless.  If a zone changes during an AXFR, then either the AXFR
is TCP-RST'd (BIND4, BIND8, most nonBINDs) or it continues but using the old
zone contents (BIND9), but if a zone changes during an NSEC traversal, there
will almost certainly be some data loss due to the rewritten NSEC chain.

> ...
> The only way I see to mitigate this is to make the same information
> available via less expensive facilities, e.g. unrestricted FTP/HTTP
> access.  This may be an option for some operators of nameservers with
> large zones but, unfortunately, it's not an option for us.

Your position is quite well understood.  For the record, did anyone from
Nominet comment during the January WGLC on the design goals of DNSSEC-BIS?

> ...

For my part, it's not frustration but rather sadness.  DNSSEC-BIS will be
deployed, and some parts of the DNS tree won't benefit from it, and that's
how it has to be, but I don't have to like it and in fact I don't like it.

Onward to DNSSEC-TER.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 02 Jun 2004 15:48:36 +0900

> will almost certainly be some data loss due to the rewritten NSEC chain.

If you are saying AXFR not with BIND9 is lossless, if you frequently
check SOA during the traverse, you can simulate TCP-RST. Throw away
data after the last unmodified serial.

							Masataka Ohta

---

From: [email-masked] (Geoffrey Sisson)
Date: Wed, 2 Jun 2004 08:51:10 +0100 (BST)

> will almost certainly be some data loss due to the rewritten NSEC chain.

True, "lossless" is technically inaccurate.  "Practically lossless"
(from the standpoint of a data miner, for whom other techniques may be
at best somewhere on the order of 80% or 90% lossy) is more accurate.

> Nominet comment during the January WGLC on the design goals of DNSSEC-BIS?

No, and for this I can only say "mea culpa".  While we've been aware of
the potential of NXT/NSEC abuse, it was only in the course of a recent
painful legal action (involving WHOIS abuse, and still ongoing) that we
fully connected the dots.

> how it has to be, but I don't have to like it and in fact I don't like it.

I'm concerned that even the parts of the DNS tree who do deploy may
face operational issues unless they give away the data in their zone
files with no questions asked.  Even a minor procedural obstacle, such
as requiring a subscription to a service or formal request via a web
form, may result in an abuser preferring the simplicity/anonymity of
NSEC RR elaboration instead.

I also may have under-represented the case of DNS end-users, for whom
simple privacy is the principal concern.  Even using split DNS, they
may have information they'd prefer not to broadcast.

Regards

Geoff

---

From: Ben Laurie <[email-masked]>
Date: Wed, 02 Jun 2004 12:33:39 +0100

Edward Lewis wrote:

> To wit: after talking on the phone with someone about my earlier message 
> on NSEC2 (not a linear growth, but a small constant bump), the question 
> of all the new hash names was still there.  I.e., do we have to provide 
> auth denial for the names created as part of the hash?  What if there's 
> a name clash?

My view would be that the names don't really exist, or can be considered 
to be in a different namespace. I don't know if there's some obscure 
reason that this is the wrong view to have, though.

> Not to discuss that - but to illustrate - there's still a lot to consider.

I guess we have to discuss it at some point!

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff