Subject: Re: WGLC for DNSSECbis docs

From: [email-masked] (Ted Lindgreen)
Date: Wed, 2 Jun 2004 10:24:38 +0200

[Quoting Geoffrey Sisson, on Jun  2,  1:59, in "Re: WGLC for DNSSECb ..."]
...
> 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.  ...

Please, let's stay to facts based on real measurements and don't get
excited by FUD based on gross miscalculations.

The message from Jay you are refering to contains at least 3 errors
and should therefore not be taken seriously.
I expected that this was immediately clear to everybody whois dealing
with real-life root or TLD operations, but appearently the FUD did
stick by some.

[Quoting "Jay Daley", on May 31, 23:37, in "Re: Proposal to fix  ..."]
....
> Let me just put this one in perspective.  Each of our nameservers has an 
> average load of 100 million queries per day with about 4 million records 
> in our zone files.  That means it will take only 25 spammers doing a full 
> walk in one day to double the load on that server (this is on top of the 
> huge increase in traffic that DNSSEC means).  As we have on average 3,000 
> new domains registered per day we can safely expect these spammers to do 
> this every day.  Once the script kiddie tools are out then we can expect 
> many, many more than just 25.
> 
> Jay

In short:
 "4 million records x 25 spammers" == 100 million queries per day
 hugely increases the load on the UK nameservers.

Error 1:
 A load of 100 million queries per day is not something to get excited
 about. See the real measurements by CAIDA, RIPE, and NLnet Labs on root
 and TLD nameserver loads.
 For your information:
   with 500 Mhz Athlon or Pentium class systems (off the shelf PC's
   in 2000), both BIND-8 and BIND-9 can easily handle 6000 queries
   per second, with NSD this is some 30000.
   That amounts to 2592000000 per day, or 25 times your current
   query load,.

Error 2:
 NSEC walking goes by domainname, not by record. There are multiple
 records per domainname, so here goes another factor.

Error 3:
 To walk NSECs, one needs the answer on a previous query, before one
 can construct the next one. Depending on network, both nameserver
 and walking systems, and nameserver software implementation, there
 is a delay of several tens of milliseconds.
 Lets say 50, then, one walk can do at most 1728000 lookups per day.

In conclusion: the load caused by zonewalkers can be neglected,
even if hundreds of spammers are doing it simultaneously.

-- ted

--
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: Simon Josefsson <[email-masked]>
Date: Wed, 02 Jun 2004 11:57:03 +0200

>  records per domainname, so here goes another factor.

My tool iterate over each RRset.  How would you get all records,
otherwise?  ANY queries aren't reliable, as far as I know.

>  can construct the next one.

Sorry, no, it is possible to parallelize it.  Send 10^10 queries for
uniformly distributed name/type/class, under the target zone, and
piece together the replies.  If by inspecting the NSEC chain, you
realize you didn't get everything, get those specifically, possibly by
querying for uniformly distributed name/type/class in the interesting
area.  Or just increase the initial amount to 10^11 queries for
uniformly distributed name/type/class, until you do get everything.

Thanks,
Simon

---

From: [email-masked]
Date: Wed, 2 Jun 2004 12:09:00 +0200 (CEST)

Don't fight FUD with FUD. Playing number games is not to be taken lightly.
Ask your average Big Corp Accountant Fall Guy. (If you don't know who that
is, you're probably the Fall Guy :).

Below I've put some references together and my attempt to number games.

My conclusion about this attempt is that load concerns definitly are
valid.

1) Performance statistics on BIND and NSD:
   http://www.nlnetlabs.nl/nsd/presentations/ripe47/mgp00010.html It is
   hard to see from this statistic to see the qps for BIND9 at 99 or 100%
   response rate, but I guess around 4000 would be right.

2) Currently, co.uk resides on 9 nameservers, 7 of which are bind 9.2.3
   (2 of which are UltraDNS Version 2.7.3.1 Build 989)

3) Nominet statistics, registrations under co.uk:
   http://www.nominet.org.uk/Statistics/RegistrationStatistics/
   5624944 registrations under co.uk on 31st of May this year, with an
   average growth of 80000 per month.

4) Proof of concept tool at: http://www.josefsson.org/walker/
   Queries individual records PLUS the NSEC records. For a delegation only
   zone, this would be delegation*2+3 (the 3 are the SOA/NSEC/NS at the
   apex).

5) Assuming that one can build a non-parallel, slow lookup thinghy that
   can do at most 1728000 queries a day, while a 500 Mhz Athlon or Pentium
   class system with off the shelf PCs in 2000, can serve 2592000000
   queries is just naive.

What this boils down to is, when I run 'walker', pointing at a single
authoritative server on a currently signed co.uk: 11249891 queries.

There is an average load on co.uk of 100.000.000 a day (according to Jay's
mail), with the help of 10 script kiddies/spammers this would double the
load.

200M queries a day may not shake an average TLD, but this exercise assumes
just 10 kiddies or spammers are interested in the co.uk zone.

Roy

---

From: "Jay Daley" <[email-masked]>
Date: Wed, 2 Jun 2004 10:41:22 +0100

Ted

> with real-life root or TLD operations, but appearently the FUD did

I think you have forgotten that we do run a TLD and therefore have 
considerable real-life experience.  FUD is not the way we work and it is 
unfortunate that you see it that way.

>    That amounts to 2592000000 per day, or 25 times your current

You are confusing capacity with load.  My point is that it takes only a 
very small number of people to create a very large percentage increase in 
load.

>  records per domainname, so here goes another factor.

My terminology was imprecise - I meant 4 million domain names.
 
>  Lets say 50, then, one walk can do at most 1728000 lookups per day.

To parallelise this is trivial, just start at different points in the 
alphabet, use multiple IP addresses and multiple servers.  That has the 
added advantage of making it harder to detect.

Jay

---

From: Derek Atkins <[email-masked]>
Date: Wed, 02 Jun 2004 10:35:59 -0400

>    zone, this would be delegation*2+3 (the 3 are the SOA/NSEC/NS at the

Note that this assumes all your children are signed.  Remember that NS
and Glue records are not signed.  If your children are not signed then
there is no authoritative data and therefore no NSEC.  This means is a
delegation-only zone you're only signing the SOA and DS records.  This
definitely limits the walkability of the full zone, as the NSEC tree
is limited to the DS content.

Unless, of course, you're actually serving non-delegation data in your
zone?

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 2 Jun 2004 16:47:20 +0200

> Unless, of course, you're actually serving non-delegation data in your

There are NSECs proofing that there is no DS above the delegation point 
for each unsecured child.

--Olaf

---

From: [email-masked]
Date: Wed, 2 Jun 2004 16:53:23 +0200 (CEST)

On Wed, 2 Jun 2004, Derek Atkins wrote:

> there is no authoritative data and therefore no NSEC.

Errr no.

If your children are not signed, you have a NSEC with the DS bit clear in
the type bit map to proof the child is not signed.

The way the tool works is that it queries for NSEC, followed by queries
listed in the type-bit-map of the queried NSEC.

> This means is a delegation-only zone you're only signing the SOA and DS
> records.  This definitely limits the walkability of the full zone, as
> the NSEC tree is limited to the DS content.

Are you talking opt-in?

Roy

---

From: David Blacka <[email-masked]>
Date: Wed, 2 Jun 2004 10:55:40 -0400

On Wednesday 02 June 2004 10:35 am, Derek Atkins wrote:
> >    Queries individual records PLUS the NSEC records. For a delegation
> > only zone, this would be delegation*2+3 (the 3 are the SOA/NSEC/NS at the
> > apex).
>

Delegation NS records get an NSEC.  This is a basic rule spelled out in 
-protocol.

However, what you are describing isn't a bad idea, IMHO.   It is called 
"Opt-In".

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    VeriSign Applied Research

---

From: Derek Atkins <[email-masked]>
Date: Wed, 02 Jun 2004 10:59:29 -0400

Olaf Kolkman <[email-masked]> writes:

> There are NSECs proofing that there is no DS above the delegation
> point for each unsecured child.

Yes, but unless things have changed yet again, NS delegation records
are not authoritative data, which means you shouldn't need an NSEC at
the name to prove that no DS exists.  E.g.:

@ = example.

a NS ..
  DS ..
  SIG(DS) ..
  NSEC c ...
  SIG(NSEC)

b NS ..

c NS ..
  DS ..
  SIG(DS) ..
  NSEC . ..
  SIG(NSEC)

"b NS" isn't authoritative so you don't need an NSEC at the node.  The
'a NSEC c' proves that no DS exists for b.  From
draft-ietf-dnsext-nsec-rdata-06 section 2.1.1:

    Owner names of RRsets not authoritative for the given zone (such as
    glue records) MUST NOT be listed in the Next Domain Name unless at
    least one authoritative RRset exists at the same owner name.

Neither NS delegations nor glue A records are authoritative data.

-derek

---

From: Derek Atkins <[email-masked]>
Date: Wed, 02 Jun 2004 11:09:16 -0400

> Delegation NS records get an NSEC.  This is a basic rule spelled out in 

Hmm.. Then -nsec needs to get corrected because it's less clear there.
The -nsec spec says you only need NSECs for authoritative data (of
which an NS delegation is not).  You are correct that -protocol
explicitly specifies authoritative data AND NS delegations (section
2.3).

If -protocol is the correct "will of the people" than -nsec should be
changed to match.

> However, what you are describing isn't a bad idea, IMHO.   It is called 

I thought we had agreed that NS delegations did not NEED to be part of
the NSEC chain, but clearly I had too much Guiness that night.  :(

-derek

---

From: Don Stokes <[email-masked]>
Date: Thu, 03 Jun 2004 17:04:05 +1200

>just 10 kiddies or spammers are interested in the co.uk zone.

If NSEC2 or something a lot like it is deployed, I don't think this will
get rid of spammers/scammers/script kiddies doing NSEC2 walks.

If you download the entire NSEC2 chain you can do direct dictionary
attacks on the zone, without requiring network traffic.  

Quick tests suggest that even my baby desktop box can do something like
6,000,000 SHA1 hashes per second.  A local outfit here was selling
second-hand PII/400s for about NZ$40 each -- at that kind of price I can
get a *lot* of compute power for very little money.

Out of curiosity, I did some experiments today, taking an old copy of a
TLD zone, and subjecting it to tests for susceptibility to dictionary
attacks.  (Note that this is the reverse of actually performing the
attack, and, uh, somewhat faster.)  

These tests suggest I could find 50% of names in a zone in the space of
a few hours, on one box, using a fairly dumb dictionary attack on a
stored list of hashes.  More sophisticated attacks could get better hit
rates for more time.  While cranking up the NSECINFO iteration count
would slow the ratbags down (at the expense of legitimate hash
calculations), I fear that NSEC2 will not solve the problem of data
mining via traversal of authenticated denial records. It'll be only a
matter of time before even script-kiddies are doing NSEC2 traversals and
launching dictionary attacks on large zones for fun and profit.

-- don

---

From: [email-masked]
Date: Thu, 3 Jun 2004 09:16:44 +0200 (CEST)

Don,

That attack was mentioned in:

> Date: Wed, 19 May 2004 15:40:01 +0200 (CEST)
> From: [email-masked]
> To: [email-masked]
> Subject: Re: Proposal to fix NSEC
>
> <hat EDITOR=off>
>
> You're basically bringing back the NO record, with some added jazz:
> http://josefsson.org/draft-ietf-dnsext-not-existing-rr.txt
>
...
<SNIP>
...
> In case you're trying to solve zone walking: Zone walking is still
> possible, hash by hash. An offline dictionary attack (remember that the
> NSECINFO trick does not work) does the rest. To speed things up, you
> could brute-force labels with length up to 5 or 6 characters.

But this was handwaived by some. The crux of it was that with a
enumeration of the reverse space, cache poking or other attacks the road
to zone-enumeration is shorter, especially if your requirement is to just
get to 70% to 75% of the entire zone.

Roy

---

From: Alex Bligh <[email-masked]>
Date: Thu, 03 Jun 2004 08:27:15 +0100

--On 03 June 2004 17:04 +1200 Don Stokes <[email-masked]> wrote:

>> 200M queries a day may not shake an average TLD, but this exercise
>> assumes just 10 kiddies or spammers are interested in the co.uk zone.
>

I may have missed it, but how do you get from the chain of hashed values
(which you can download, but are uninteresting and ephemeral) to a
list of domain names (assuming SHA-1 is one-way).

Alex

---

From: [email-masked]
Date: Thu, 3 Jun 2004 10:04:12 +0200 (CEST)

On Thu, 3 Jun 2004 [email-masked] wrote:

> On Thu, 3 Jun 2004, Alex Bligh wrote:
>
> It was suggested by Don and me to do a dictionary attack to find a
> collision with a hashed label. It might even be feasible to do a brute
> force on labels with 6 characters, considering 37 possible values for a
> character.
>
> A device capable of performing 6000000 hash functions per second (quoting
> Don) walks a space of 37^6 in about 7 minutes.
>
> local hash functions is a wee bit more efficient then online querying

PS. That's why Ben added an iterations field to NSECINFO to up the cost.

Roy

---

From: Don Stokes <[email-masked]>
Date: Thu, 03 Jun 2004 20:30:50 +1200

>list of domain names (assuming SHA-1 is one-way).

By dictionary attack.  I'm not saying they get the full, complete zone. 
NSEC2 is proof against that.  

What I am saying is that walking an NSEC2 chain is still useful to the
sorts of people we've been denying AXFRs to.  The most obvious, but not
the only, use for the chain is a dictionary attack -- you can easily
get 50-80% of names in a typical TLD zone via a straight dictionary
attack, given a local copy of the complete NSEC2 chain and surprisingly
little money's worth of compute power.

>PS. That's why Ben added an iterations field to NSECINFO to up the cost.

Unfortunately, it ups the cost to everyone else, too.

-- don

---

From: "Jay Daley" <[email-masked]>
Date: Thu, 3 Jun 2004 10:00:18 +0100

Don

> little money's worth of compute power.

I don't have any analysis to back this up but I doubt very much if any 
dictionary attack can get anything like the percentages you quote, 
probably much less than 50%.  Once most of the single word DNs have gone 
most people fall back to double word DNs  (e.g.  don-systems.co.uk) or 
other pairings (ds-systems.co.uk) and the variety of ways in which this is 
done increases the search scope enormously.  The susceptibility of a TLD 
zone to dictionary attack may well be inversely proportional to its size.

Jay

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 3 Jun 2004 11:15:09 +0200

On Wed, 02 Jun 2004 11:09:16 -0400
Derek Atkins <[email-masked]> wrote:

> which an NS delegation is not).  

The details are further addressed in proto. These issues have been the
subject of a number of questions that where posted to the mailinglist
over the last few months. Let us not re-iterate.

Relevant text is in proto-2.3

   The bitmap for the NSEC RR at a delegation point requires special
   attention.  Bits corresponding to the delegation NS RRset and the RR
   types for which the parent zone has authoritative data MUST be set to
   1; bits corresponding to any non-NS RRset for which the parent is not
   authoritative MUST be set to 0.

in proto-3.1.4:

   If no DS RRset is present at the delegation point, the name server
   MUST return both the NSEC RR which proves that the DS RRset is not
   present and the NSEC RR's associated RRSIG RR(s) along with the NS
   RRset.  The name server MUST place the NS RRset before the NSEC RRset
   and its associated RRSIG RR(s).

in proto-3.1.5

   NSEC RRs appear in both the parent and child zones at a zone cut, and

   are authoritative data in both the parent and child zones.  The
   parental and child NSEC RRs at a zone cut are never identical to each
   other, since the NSEC RR in the child zone's apex will always
   indicate the presence of the child zone's SOA RR while the parental
   NSEC RR at the zone cut will never indicate the presence of an SOA
   RR.  As with any other authoritative RRs, NSEC RRs MUST be included
   in zone transfers of the zone in which they are authoritative data:
   the parental NSEC RR at a zone cut MUST be included zone transfers of
   the parent zone, while the NSEC at the zone apex of the child zone
   MUST be included in zone transfers of the child zone.

and in 

-- 

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

---

From: [email-masked]
Date: Thu, 3 Jun 2004 10:02:39 +0200 (CEST)

Roy

---

From: [email-masked]
Date: Thu, 3 Jun 2004 12:49:42 +0200 (CEST)

> zone to dictionary attack may well be inversely proportional to its size.

Okay, I did a small proof of concept test.

I took an arbitrary european TLD zone from november 2003.

Number of registrations under TLD: 169209
Number of unique characters in label: 37
Bruteforce until 7 characters: 60153 hits (36%)

Dictionary attack on the left 109056 labels:

Wordlist of 3M words matched in the following order:

word, %n$word, %n-$word, %n%n-$word, %n%n%n-$word, etc.

Where %n is [0--9]

This gets 80292 of the leftover 109056 labels

So in total I get about 83%.

Roy

---

From: Roy Badami <[email-masked]>
Date: Thu, 3 Jun 2004 12:31:46 +0100

>>>>> "Olaf" == Olaf M Kolkman <[email-masked]> writes:

    Olaf> The details are further addressed in proto. These issues
    Olaf> have been the subject of a number of questions that where
    Olaf> posted to the mailinglist over the last few months. Let us
    Olaf> not re-iterate.

I have to say that as someone reading the doc set for the first time,
I this point confusing.  -protocol clearly states (2.3) that
delegation points require NSEC records.

But -records states that the NSEC RR contains the owner name of the
next authoritate RRset (section 4, and again in 4.1.1) and as Derek
points out this is not true, since an insecure delegation contains no
authoritative data.

This seems to me to be an editorial error in -records

     -roy

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 3 Jun 2004 08:18:03 -0400

> -----Original Message-----
> From: [email-masked]
>

Also take into consideration that a random non-existant response will
contain one or more NSEC2 RRs, and each NSEC2 RRs has 2 hash values of valid
names.  An attacker may get a large portion of the (hashed) namespace by
doing random queries like this without too much effort.  They still need to
do the dictionary attack however.

I also have a question about the salt field in the original spec.  I still
am not sure it is useful.  A determined attacker will just take the salt
value anyway and use that.  Why not just have the hash be the FQDN?  For
example:  Hash(www.example.com).example.com.

Mainly I'm thinking of ways to reduce the need for the NSECINFO RR and move
the remaining fields (hash algo and iterations) into the NSEC2 RR.

Scott

---

From: [email-masked]
Date: Thu, 3 Jun 2004 14:29:45 +0200 (CEST)

> example:  Hash(www.example.com).example.com.

The salt value is a protection against pre-hashing. If you could prehash
your dictionary, searching for collisions would be very fast.

Roy

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 3 Jun 2004 09:26:16 -0400

> From: [email-masked] [mailto:[email-masked]]

> your dictionary, searching for collisions would be very fast.

But that will only slow them down - a bit.  Attackers will just do it in
real time, and eventually will still be able to do it.  The names remain the
same, just the tag in front of it changes.  They just need to stop and get
the new salt whenever it is rolled over.  The salt value becomes just
another knob that admins need to worry about and most will do "whatever the
default tool does".

I'm not totally against adding the field.  I think it would work, but
considering how static most DNS names are, I don't know if it will help DNS
as it does in other uses.

Scott

---

From: Greg Hudson <[email-masked]>
Date: Thu, 03 Jun 2004 11:18:05 -0400

> example:  Hash(www.example.com).example.com.

Hm.  I was going to say that the salt forces you to attack each hash
separately, instead of the entire zone.  But on consideration (and
rechecking the draft), it looks like the salt has to be the same for the
whole zone in order for NSEC2 to be useful.

So, if I've procured most of the NSEC2 records for a zone (I can't just
download the chain, as some people theorized; as you noted, I have to
make random queries until I've accumulated most of the records), I can
perform a single walk of my dictionary and test each result for
inclusion within the set of NSEC2 hashes.  That doesn't seem very
expensive at all.

Also, if I want to procure lots of NSEC2 records, since I'm just making
random queries, I don't need to parallelize as much as I do for NSEC
walking (where I have to wait an RTT for each packet).  So in some ways
it's easier than an NSEC walk.  If I can run a script on one machine and
get 50-80% of a 4-million-record zone in one day (NSEC2), I might prefer
that to getting 100% of a 4-million-record zone in ten days, or having
to use ten machines to get them all in one day (NSEC).

I'm a little skeptical that spammers will be all that interested in
domain walks of any sort. 
http://www.cdt.org/speech/spam/030319spamreport.shtml suggests that most
spammers are content to harvest unobfuscated email addresses on the web,
and don't take advantage of easy opportunities to harvest other
readily-available sources of addresses (Usenet, WHOIS).  And even if I
experience zero loss in your domain walk (NSEC), I don't necessarily get
many high-quality addresses out of that.  If I have four million
domains, I'm not going to try thousands of addresses per domain; I'm
going to try a few likely targets like "postmaster" and "webmaster" and
"root" and "abuse".  But even then, probably the vast majority of my
email will wind up not even hitting a spam filter, and the people who do
read those addresses aren't likely spam suckers.

I would be more concerned with underhanded DNS "competitors" who want to
replicate the data in your zone and add their own records.  Lossiness is
a much bigger deal to that category of people, and they have to rescan
frequently to remain "competitive"... but there also aren't as many of
them, so they're unlikely to generate a lot of load.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 03 Jun 2004 15:40:34 +0000

> do the dictionary attack however.

as was discussed in the kerberos community a few years ago, offline dictionary
attacks -- where the victim has no idea how much effort is being expended and
things like botnets and distributed.net can come into play -- are dangerous.

> example:  Hash(www.example.com).example.com.

that looks really cool, but it doesn't change the danger.  home pee cees now
have 4GHz processors, and it's still doubling every once in a while.  apple's
"altivec" may be the first mass production example of what's about to be a
very popular kind of technology -- maybe a million vector processors running
insecure operating systems on 24x7 DSL lines is the right threat model here.

> the remaining fields (hash algo and iterations) into the NSEC2 RR.

there's a lot of room to clean this up, but it's not on the critical path to
getting dnssec-bis out the door.  i'm enjoying the thread, but the goals of
the WG wrt dnssec are still (1) measure/prove the dnssec-bis document/protocol
quality; and (2) select one or several ways that -bis can become -ter later.

---

From: [email-masked]
Date: Thu, 3 Jun 2004 17:55:10 +0200 (CEST)

On Thu, 3 Jun 2004, Greg Hudson wrote:

> readily-available sources of addresses (Usenet, WHOIS).

Because there is no index.... yet.

Roy

---

From: Rob Austein <[email-masked]>
Date: Thu, 03 Jun 2004 12:17:34 -0400

> points out this is not true, since an insecure delegation contains no

The NSEC RR at the delegtion point is authoritative.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 03 Jun 2004 17:29:34 +0100

Scott Rose wrote:

>>>I also have a question about the salt field in the original
>>
>>spec.  I still
>>

That doesn't matter - they have to run the _whole_ dictionary each time 
to get the new names.

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

---

From: Ben Laurie <[email-masked]>
Date: Thu, 03 Jun 2004 17:27:34 +0100

> do the dictionary attack however.

Note that my plan was to set the time taken (via iterations) to around 
the network turnaround time for a query (i.e. of the order of milliseconds).

> example:  Hash(www.example.com).example.com.

The salt is to avoid precalculated dictionary attacks - on each walk, 
the attacker must recalculate everything.

> the remaining fields (hash algo and iterations) into the NSEC2 RR.

I forgot to mention this last time around. So, if we move the info into 
NSEC2, it must be the same for the whole zone. Therefore, although the 
signature must be over the complete record, the server only needs to 
store _one_ copy of the redundant data, and insert it when sending the 
NSEC2s. Does this reduce your desire to eliminate NSECINFO data?

Cheers,

Ben.

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 3 Jun 2004 12:57:56 -0400

> NSEC2s. Does this reduce your desire to eliminate NSECINFO data?

I'm not dead set against it, so I can accept it.  I'm just wondering if it
is better to have everything in the NSEC to avoid larger responses.  It is a
question whether 8 more bytes in each NSEC2 RR would mean a smaller response
vs. a whole NSECINFO RR and covering RRSIG.  I don't know if it makes sense
to optimize zone database size at the expense of response size.

And the complexity that comes with having another RR for storing some
information about other RR types.

Scott

---

From: Damien Miller <[email-masked]>
Date: Fri, 04 Jun 2004 10:03:36 +1000

> insecure operating systems on 24x7 DSL lines is the right threat model here.

A solution to this is to make the iterations the log2 of the number of
hash rounds, rather than a counter. This better matches the (so far)
exponential increase in CPU speed.

This approach is used by the OpenBSD blowfish password hash function:

http://www.openbsd.org/papers/bcrypt-paper.ps

-d

---

From: Ben Laurie <[email-masked]>
Date: Fri, 04 Jun 2004 07:29:37 +0100

> exponential increase in CPU speed.

That doesn't solve the problem, but it might be a good idea anyway.

Cheers,

Ben.